Zuvor festgelegte DNS-Records werden nach Domainumzug nicht gesetzt

  • Hallo,


    Es scheint reproduzierbar so zu sein, dass wenn man bei der Domainbestellung im CCP bereits DNS-Einträge eingibt, diese nicht tatsächlich gesetzt werden sobald die Domain erfolgreich zu Netcup umgezogen ist. In dem Fall gibt eine Whois-Abfrage der Domain zwar die Nameserver von Netcup zurück, die Nameserver geben jedoch keinerlei Records für die Domain aus. Das ändert sich erst, wenn man im CCP (oder auch per API) einen DNS-Eintrag verändert (es scheint egal zu sein, welcher) - danach fangen die Nameserver an, die anderen Einträge auch auszugeben.


    Ist an sich jetzt keine Katastrophe, aber hat mich etwas kalt erwischt bei einer (nicht .de)-Domain, bei welcher der Umzug etwas gedauert hat, weil ich zu dem Zeitpunkt dann im Urlaub war und plötzlich war alles down :S Das Problem besteht aber definitiv auch bei .de-Domains, nur geht der Umzug da in der Regel so schnell dass man ohnehin noch im CCP zugange ist ^^


    Ist das ein bekannter Bug?

  • Das Problem verfolgt mich auch gerade. Ich habe zwei für E-Mails genutzte Domains umgezogen und vorher die MX-Einträge getätigt. Nach dem Eintragen des Authcode meldeten sofort diverse DNS-Server (Cloudflare, Google, Quad9) aktuelle NS-Daten, aber fehlerhafte MX-Werte. Ein unterbrechungsfreier Umzug, bei dem man keine Mails verliert, ist so nicht möglich.

  • Ein vollig unterbechungsfreier Umzug ist auf diese Weise sowieso nicht möglich. Allerdings sollte man dabei eigentlich keine Mails verlieren. Zumindest keine, die von einem Mailserver gesendet werden, der den Namen verdient. Da sollten wegen ein paar Stunden Unterbrechung eigentlich keine Mails verloren gehen. Trotzdem sollte das nicht so sein. Wenn man die Werte beim Umzug eintragen kann, dann sollten sie auch zumindest nach dem Umzug in den dann authoritativen Nameservern von netcup im Zonenfile stehen.


    Haben sich die MX-Einträge beim Umzug geändert oder sind die selben wie zuvor bei netcup eingetragen worden (inklusive der IP, auf die sie aufgelöst werden)? Ansonsten wird es ja immer so sein, dass in einer Übergangszeit ein Teil der sendenden Server die alten und ein Teil die neuen MXe benutzen wird. Je kürzer die TTL des Eintrags vor dem Umzug, desto kürzer sollte die Übergangszeit sein. Mit der Betonung auf "sollte", nicht alle DNS-Server halten sich daran. Das weltweite DNS wird auch sowieso nicht in Echtzeit upgedatet.

  • Ein vollig unterbechungsfreier Umzug ist auf diese Weise sowieso nicht möglich.

    Das verstehe ich nicht, wieso sollte das nicht möglich sein? Ein anfragender MTA sollte entweder die DNS-Einträge des alten oder des neuen Registrars sehen, aber niemals einen Zwischenstand mit "Domain existiert, hat aber keine MX-Einträge".

    Allerdings sollte man dabei eigentlich keine Mails verlieren. Zumindest keine, die von einem Mailserver gesendet werden, der den Namen verdient. Da sollten wegen ein paar Stunden Unterbrechung eigentlich keine Mails verloren gehen.

    Das kommt vermutlich auf die Konfiguration des Mailservers an, aber für den Fall "es gibt keine MX-Einträge" ist es schon relativ wahrscheinlich, dass die E-Mail als unzustellbar an den Absender zurückgeht. Und wenn dort nicht gerade jemand über die Fehlermeldungen schaut, etwa bei automatisierten Versendern, fällt das vermutlich nicht einmal auf.

    Haben sich die MX-Einträge beim Umzug geändert oder sind die selben wie zuvor bei netcup eingetragen worden (inklusive der IP, auf die sie aufgelöst werden)?

    Bei einer Domain war mailbox.org als MX eingetragen, bei einer anderen AnonAddy, sprich die MX-Einträge haben sich beim Umzug nicht geändert.

  • Das verstehe ich nicht, wieso sollte das nicht möglich sein? Ein anfragender MTA sollte entweder die DNS-Einträge des alten oder des neuen Registrars sehen, aber niemals einen Zwischenstand mit "Domain existiert, hat aber keine MX-Einträge".

    Das kommt vermutlich auf die Konfiguration des Mailservers an, aber für den Fall "es gibt keine MX-Einträge" ist es schon relativ wahrscheinlich, dass die E-Mail als unzustellbar an den Absender zurückgeht. Und wenn dort nicht gerade jemand über die Fehlermeldungen schaut, etwa bei automatisierten Versendern, fällt das vermutlich nicht einmal auf.

    Bei einer Domain war mailbox.org als MX eingetragen, bei einer anderen AnonAddy, sprich die MX-Einträge haben sich beim Umzug nicht geändert.

    Unter "unterbrechungsfrei" verstehe ich hier, dass die MX-Einträge zu jeder Zeit, also unterbrechungsfrei, auch rekursiv abgefragt werden können. Nach meinen Beobachtungen ist das bei einer Änderung der Nameserver nicht der Fall. Bisher hatte ich dabei immer eine - relativ kurze - Zeitspanne, in der gar kein NS-Eintrag aufgelöst werden konnte und somit gar nichts von der Domain. Somit konnte ein Resolver in der Zeit auch die NS und MX höchstens aus seinem Cache auflösen. Wenn allerdings die TTL abgelaufen ist und er eine rekursive Abfrage machen muss, dann kann er halt in der Zeit nichts auflösen. Ansonsten stehen die Chancen jedenfalls wesentlich besser als wenn sich die MX bei der Aktion ändern würden.


    Wie der sendende Mailserver auf das DNS-Desaster reagiert kommt halt darauf an, ob das als permanenter oder temporärer Fehler betrachtet wird.

    Bei automatisierten Versendern der Marke günstig (per PHP mail-Funktion) fällt das wohl wirklich nicht einmal auf. Die Senden genau einmal nach dem Motto "den Rest macht der liebe Gott" - oder halt auch nicht ;). Beim Versand über einen professionellen Massenmailer wird das aber schon ganz anders aussehen.


    Die Geschichte mit mailb0x.org hat eventuell noch eine andere Ausfallmöglichkeit. Es fehlt ja nicht nur der MX, sondern auch der TXT-Eintrag, an dem die MXe von mailb0x.org erkennen, ob sie für die Mail überhaupt zuständig sein sollen oder nicht. Wie lange das ohne den TXT-Eintrag weiterfunktioniert weiss ich nicht. Der TXT-Record könnte eventuell zumindest periodisch überprüft werden, vermutlich aber nicht bei jeder ankommenden Mail. Somit stehen hier die Chancen wohl eher gut. Jedenfalls hast du damit schon eine günstige Konstellation.

  • Eine kurze Unterbrechung kann ja vielleicht vorkommen, aber im Falle von meiner letzten umgezogenen Domain (welche übrigens auch für Mails bei einem externen Anbieter genutzt wurde) war die Unterbrechung etwa 9 Stunden lang, da ich wie gesagt im Urlaub war und mich erst am Abend im Hotel einloggen und eine Änderung der DNS-Einstellungen vornehmen konnte (wobei es wie gesagt reicht, irgendeinen beliebigen Eintrag zu ändern). Sekunden später waren dann bei einer Whois-Abfrage alle Einträge da - einen Zufall halte ich daher für quasi ausgeschlossen.

  • Hallo zusammen,


    ich habe gerade versucht, dies zu reproduzieren, es war mir jedoch nicht möglich. Nach der Registrierung einer Testdomain lieferten unsere autoritativen Nameserver korrekt die hinterlegten DNS-Einträge aus.


    Es gab letzte Woche eine Einschränkung unserer Resolver, die in der Folge theoretisch auch zu kurzzeitigen Störungen bei der Änderung (oder dem Anlegen) von DNS-Zonen auf unseren autoritativen Nameservern führen konnte. Falls eure Domainbestellung in diese Zeit gefallen ist, lag es möglicherweise daran. Wir bitten um Entschuldigung.


    Sollte es bei euch weiterhin auftreten, wendet euch bitte über die üblichen Kanäle an unseren Support, damit wir uns das genauer ansehen können. Danke.

  • Tatsächlich ist es zum ersten mal (und gleich zweimal) aufgetreten, als ich beim Black Friday Sale meine Domains alle zu Netcup umgezogen habe.


    Was mir aufgefallen ist, es scheint nur dann vorzukommen, wenn der Transfer der Domain aus irgendeinem Grund länger als üblich dauert. 2/3 .de Domains liefen normal, aber die Dritte war aus irgendeinem Grund länger im Transit. Die zweite Domain wo es passiert ist (und die, wo ich den ganzen Tag nichts dagegen unternehmen konnte) ist eine .cloud Domain, wo es ja anscheinend normal ist, dass der Umzug ein paar Tage dauert. In meinem Fall war es etwa eine Woche, aber das liegt natürlich an der Registrierungsstelle der Domain und nicht an Netcup.


    Für den Moment habe ich keine Domains mehr die umgezogen werden müssen, aber ich melde mich, falls es nochmal passiert :D

  • Die Geschichte mit mailb0x.org hat eventuell noch eine andere Ausfallmöglichkeit. Es fehlt ja nicht nur der MX, sondern auch der TXT-Eintrag, an dem die MXe von mailb0x.org erkennen, ob sie für die Mail überhaupt zuständig sein sollen oder nicht. Wie lange das ohne den TXT-Eintrag weiterfunktioniert weiss ich nicht.

    Die TXT-Einträge werden nur zum Anlegen der Aliase benötigt und können danach gelöscht werden. Das sollte also keine Probleme verursachen.

  • Es gab letzte Woche eine Einschränkung unserer Resolver, die in der Folge theoretisch auch zu kurzzeitigen Störungen bei der Änderung (oder dem Anlegen) von DNS-Zonen auf unseren autoritativen Nameservern führen konnte. Falls eure Domainbestellung in diese Zeit gefallen ist, lag es möglicherweise daran. Wir bitten um Entschuldigung.

    Bei mir trat das Problem diesen Mittwoch auf, die Störung von letzter Woche sollte damit vermutlich nichts zu tun haben.

    Kommt es eventuell auf die Art der Bestellung an? Ich habe die Domain im CCP geklickt und mit dem Dialog die DNS-Einträge festgelegt bevor die Frage nach dem Authcode kam.