• This forum has a zero tolerance policy regarding spam. If you register here to publish advertising, your user account will be deleted without further questions.

Nach Serverumzug keine DNS Auflösung mehr

p0se

Member
Hallo,

ich habe dieses Wochenende einen Server umgezogen, nun habe ich teilweise Probleme mit der DNS Auflösung.
Ich bin wie folgt vorgegangen.

1. Beim Domainanbieter den eigenen DNS Server Eintrag angepasst (30.09.2022)
ns1.domain.de - IPv4_alt - IPv6_alt zu ns1.domain.de - IPv4_neu - IPv6_neu
ns2.domain.de - IPv4_alt - IPv6_alt zu ns2.domain.de - IPv4_neu - IPv6_neu

Die Einstellung wurde auch nach 24 Stunden wirksam.

2. Serverdaten kopiert

3. DNS auf dem Zielserver via Plesk aktiviert und alle Einträge kontrolliert. (30.09.2022)

Nun habe ich einige Domains, die nicht auflösbar sind, seit der Umstellungen sind nun insgesamt ca. 30 Stunden vergangen.
Alle ns1/ns2 Einträge bei meinem Domainanbieter zeigen auf die richtige neue DNS IP (getestet mit MXtoolbox).
Die Domain selbst jedoch nicht, diese zeigt teilweise ins leere bzw. auf den alten Server.
Mit einem nslookup erhalte ich *** domain wurde von UnKnown nicht gefunden: Non-existent domain.
Die Webseite dazu ist trotzdem problemlos aus dem Internet aufrufbar, von überall.

Bei den Domains wo die Auflösung funktioniert, werden die Subdomains dennoch vom alten Server aufgelöst, obwohl ns1/ns2 bereits auf den neuen Server zeigen.
Passe ich die Einstellungen auf dem alten DNS an, funktioniert das auch. Dennoch werden mir diese auch als Non-existent domain angezeigt.

Beispiel: sende ich eine Mail an ein Postfach auf dem neuen Server, erhalte ich von meinem Mailanbieter den Hinweis, dass die Domain nicht existiert.
Sende ich eine Mail von einem Postfach auf dem neuen Server, landet diese in der Warteschleife und kann nicht aufgelöst werden.

Vom Verständnis her, wie kann es sein, dass ich eine Domain/Subdomain über den alten Server verwalten kann, obwohl ich beim Domain Anbieter den Nameserver geändert habe und diese Änderung auch übernommen wurde?
 
- Vom wo aus testest du denn die DNS-Auflösung
- Wie testest du die Auflösung? Welcher Befehl
- Was steht in der /etc/hosts
- Was steht in der /etc/resolv.conf
- Ist bind9 (DNS) in Plesk als Primär- oder Sekundär-Nameserver gesetzt
 
- Vom wo aus testest du denn die DNS-Auflösung
von meinem Privaten Anschluss

- Wie testest du die Auflösung? Welcher Befehl
von meinem Privaten Anschluss (nslookup)
dnschecker.org (CNAME, A, AAAA)
mxtoolbox.com (DNS Lookup, CNAME Lookup

- Was steht in der /etc/hosts
Dort steht tatsächlich ein falscher hostname
Auch wenn ich ihn ändere, wird er nach einen Neustart zurückgesetzt.
Your system has configured 'manage_etc_hosts' as True.
# a.) make changes to the master file in /etc/cloud/templates/hosts.debian.tmpl
# b.) change or remove the value of 'manage_etc_hosts' in

Scheinbar wird der Hostname der in Plesk gesetzt wurde und auch richtig angezeigt wird, nicht übernommen....
Kann ich den Wert gefahrlos manuell anpassen?

- Was steht in der /etc/resolv.conf

Code:
nameserver 127.0.0.53
options edns0 trust-ad
search serveranbieter.de

- Ist bind9 (DNS) in Plesk als Primär- oder Sekundär-Nameserver gesetzt
Für alle Domains als Master


Ich erhalte folgende Fehlermeldungen.

Code:
MxToolbox DNS Check für sub.domain.de

Primary Name Server Not Listed At Parent
ns1.sub.domain.de

Bad Glue Detected
Parent server gave glue for ns1.domain.de to be xx.xx.xx.xx1 but we resolve that hostname to xx.xx.xx.xx2 <br/>Parent server gave glue for ns2.domain.de to be xx.xx.xx.xx1 but we resolve that hostname to xx.xx.xx.xx2

Local NS list does not match Parent NS list
xx.xx.xx.xx1 was reported by the parent, but not locally<br/>xx.xx.xx.xx1 was reported by the parent, but not locally<br/>xx.xx.xx.xx2 was reported locally, but not by the parent<br/>xx.xx.xx.xx2 was reported locally, but not by the parent

Code:
MxToolbox CNAME Lookup für sub.domain.de

DNS Record Published - DNS Record not found
 
Last edited:
Scheinbar ist mein Problem, dass die DNS Anfragen noch vom alten Server beantwortet werden.
Dort habe ich im DNS für den Übergang die IPs vom neuen Server eingetragen auf dem auch der neue DNS läuft.

Nach meinem Verständnis, sollten die Anfragen aber nicht mehr zum alten DNS gehen, da ich ja bei meinem Domain Anbieter bereits am Freitag für jede Domain neue DNS Server gesetzt habe.

Schalte ich auf dem alten Server den DNS Dienst ab, funktioniert die Auflösung nicht mehr.

Ich blicke aber nicht durch, wo der Fehler ist, nach meinem Verständnis sollte es doch reichen, den Namensserver beim Domainanbieter (Netcup) anzupassen.
 
Du hast vermutlich als DNS-Server einen A-Record innerhalb deiner Domain verwendet. Damit dieser auch gefunden wird, muss bei der jeweiligen TLD (im Falle von .de also der Denic) ein Glue-Record gesetzt werden. Möglicherweise gibt es dafür einen separaten Punkt, an dem diese sich ändern lassen. MXToolbox hat ja auch ausgegeben, dass der Glue-Record nicht konsistent ist.
 
Ich habe bei meinem Domain Anbieter (Netcup) nicht die Möglichkeit, einen Glue-Record zu setzen, wenn ich einen eigenen Namensserver verwende. Somit müsste ich mich wohl direkt an Netcup wenden und die kommunizieren dann mit Denic?

Der Fehler betrifft auch nur Subdomains.
 
Ich dachte, auf deinem Plesk läuft Bind 9 als DNS und der sendet als Primär-NS per Zonentransfer die Daten an den NS (=Sekundär-NS) des Domain-Anbieters. Wenn Bind 9 auf deinem server der DNS ist, dann verwaltet der doch Subdomains.

Frage halt mal den Support von Netcup, ob deren NS überhaupt Zonentransfer zulässt.
 
Dann habe ich den korrekten Glue Record im CCP gesetzt.

Hostname - IPv4 - IPv6


@GewenDragon

das ist so korrekt, auf meinem Server läuft mit Plesk Bind 9 als Primär-NS.
Nach meinem Verständnis, sollte der dann auch die Subdomains verwalten.

Ich bekomme seit dem Umzug dennoch Bad Glue Detected bei Subdomains.
Mit dem Hinweis, dass der Übergeordnete DNS auf die alte IP zeigt aber mit der neuen aufgelöst wird.
 
das ist so korrekt, auf meinem Server läuft mit Plesk Bind 9 als Primär-NS.
Nach meinem Verständnis, sollte der dann auch die Subdomains verwalten.
Er als Primär-NS muss nur an den Netcup-NS (=Sekundär-NS) die Zonendaten übertragen können. Ich denke aber, du kannst wohl den Netcup-NS eben nicht als Diener deines Herrn Plesk verwenden.

Mein Rat: etas wagen, Netcup fragen.
 
Okay, habe ich falsch verstanden.
Ich will natürlich nicht Netcup als Diener verwenden.

Ich will das die Domains die bei Netcup gelistet sind, auf den den richtigen NS zeigen.
Das tuen sie ja bereits, hier bleibt nur die Frage, ob es auch so richtig funktioniert.

Wenn sie auf den richtigen Nameserver zeigen, soll dieser (Plesk Bind 9) sowohl Domains als auch Subdomains verwalten und bedienen.
Ohne das die DNS Anfragen weitergeleitet werden.

So hatte ich es vor dem Umzug ja auch und es ging ohne Probleme.
Ich habe eigentlich nur die die Glue Records im Netcup CCP angepasst.

Seitdem habe ich die Probleme.
 
Last edited:
Noch eine Verständnisfrage zu DNS.

Sowohl Hostname als auch die verwalteten Domains des neuen DNS Servers haben sich zum alten Server ja nicht verändert.
Lediglich die IP hat sich verändert.

Ich habe dem alten DNS Server nach dem Umzug einen neuen Hostname gegeben.
Dennoch befinden sich dort ja ebenfalls noch alle Einträge, die auch auf dem neuen Server vorhanden sind.
Der Alte Server ist auch nach wie vor Online.

auf dem alten Server gibt es also zu jeder Domain entsprechende NS, A, AAAA usw. records. die ja auch auf dem neuen Server vorhanden sind.

woher weiß nun das "Internet" das domain.de nicht von ns1.domain.de mit der alten IP und dementsprechend vom alten Server aufgelöst wird, sondern vom neuen Server mit einer anderen IP?

Wird das über den Glue Record geregelt?

und wie würde das aussehen, wenn kein Glue Record gesetzt ist und ich meinem Domainanbieter nur mitteile, domain.de wird von ns1.domain.de aufgelöst. ns1.domain.de gibt es in meinem Fall ja auf zwei verschiedenen Servern.
 
Bei der Denic (falls wir von einer de Domain reden) hinterlegt der Domain-Anbieter (in deinem Fall Netcup) die NS-Records für deine Domain. Das kann z.b. ns1.dnsanbieter.de sein oder ns1.deinedomain.de. Wenn einer nun z.B. www.deinedomain.de auflöst, dann sagt der Denic-Nameserver "kann ich dir nicht sagen, aber frag mal" und gibt ihm den Inhalt des NS-Records mit, der bei der Denic hinterlegt ist. Im Falle von ns1.deinedomain.de hast du nun ein Henne-Ei-Problem. Um die IP von ns1.deinedomain.de erhalten zu können, muss er bei eben dieser noch nicht bekannten IP nachfragen, was entsprechend nicht geht. Dafür ist der Glue-Record da, damit wird diese IP bei der Denic hinterlegt und die Denic kann diese auch direkt mitteilen.
Da du sagst, dass es nur für subdomains nicht passt: Verwendest du da evtl. separate Zonen, auf die du von deiner Zone für deinedomain.de verweist?
 
Soweit verstanden, danke dir!

jede Subdomain hat ihre eigene Zone deinedomain.de hat aber keine Einträge zu sub.deinedomain.de
 
Ich habe gerade mal versucht ein neues Zertifikat über Let`s Encrypt für eine domain ( keine subdomain( zu erstellen).
Scheinbar wird dort doch nicht nicht richtig aufgelöst.

Ihre Domain in Plesk wird unter den folgenden IP-Adressen gehostet: xx.xx.xx.xxx 0a0a:00a0:0a0:0a0::0. Für die DNS-Aufforderung wurde jedoch eine andere IP-Adresse verwendet: 0a0a:00a0:0a0:0a0::0.
Die IP-Adressen, die in der DNS-Zone der Domain angegeben sind, müssen mit den IP-Adressen übereinstimmen, auf denen die Domain gehostet ist.

Naja, ich warte mal einfach auf die Antwort von Netcup.
 
Netcup sagt, es liegt daran, dass ich für den zweiten DNS die gleiche IP wie für den ersten setze.

Ich kenne Selbstverständlich die RFC 4697 und über die Sinnhaftigkeit damit keine Redundanz für DNS zu haben brauchen wir nicht zu diskutieren.

Aber....

1. Bei dem Server den ich vorher hatte, also den Server, von dem ich umgezogen bin, war es bis vor einer Woche genau so konfiguriert.
ns1 und ns2 gleiche IP, gleicher Server, nie ein Problem, dass die Registrierung dadurch abgelehnt wurde.

2. Wenn ich mir jetzt eine Domain nehme, meinen alten Server eintrage also wieder gleiche IP bei bei ns1/ns2, funktioniert es nach spätestens 24 Stunden. Dort entsteht der Fehler also nicht.

3. Netcup bestätigt mir immer das eintragen, normalerweise gibt es ja eine Fehlermeldung wenn es nicht klappt.

Aus den Gründen 1/2 ist der Grund für mich nicht ganz nachvollziehbar.
Netcup weiß auch nicht warum es bei dem alten Server geht, sagen aber weiterhin das wäre der Grund.

Lösung für mich gerade also entweder zweiter DNS was wohl auch sinn machen wird wobei Webseiten halt eh auf dem DNS 1 laufen oder aber ne zweite IP auf einem Server.

Ich werde berichten ob es damit geht.
 
Aus den Gründen 1/2 ist der Grund für mich nicht ganz nachvollziehbar.
Für mich schon. Die jeweilige TLD überprüft mittlerweile, ob es mind. zwei verschiedene IP-Adressen sind, wenn diese geändert werden - das war vermutlich in der Vergangenheit wahrscheinlich noch nicht der Fall, weshalb es damals funktioniert hat. Da die Änderung auf den neuen Server nie stattgefunden hat, bleiben die alten Einstellungen bestehen, so dass das Zurückändern letztendlich wieder zu der Situation vor der Änderung geführt hat, weil es so bei der TLD nie geändert wurde. Neben der RFC schreiben übrigens auch einige TLDs mind. zwei unterschiedliche DNS-Server vor.
Also installier dir einen zweiten DNS-Server oder schau nach, ob du die Netcup-Nameserver als sekundäre Nameserver nutzen kannst. Einige (wenn nicht sogar die meisten) Domain-Anbieter bieten das an.
 
Wenn ich bei einer Domain als DNS Netcup DNS wähle und die Einstellung Speicher, wird die Änderung aktiv.
So wie es soll....

Ändere ich danach wieder auf den alten DNS also zwei mal gleich IP, wird das ohne Probleme angenommen.

Ändere ich auf den neuen DNS auch zwei mal gleiche IP wird es nicht übernommen.

Macht also nicht so wirklich Sinn.
 
Wenn ich bei einer Domain als DNS Netcup DNS wähle und die Einstellung Speicher, wird die Änderung aktiv.
Wo wird sie wann aktiv? Wie genau hast Du das von wo aus getestet?


BTW: DNS Probleme ohne Kenntnis der betroffenen Domain(s)/IPs remote per Glaskugel zu lösen, ist durchaus tricky bis nicht möglich...
 
Back
Top