DNS Transfer Cheat Sheet

Erstentwurf – Review ausständig; Fehler möglich; Änderungen vorbehalten.

Hilfestellung beim DNS-Umzug

Beim Umzug von Domains gibt es ein paar Dinge zu beachten.

In diesem Artikel beschreibe ich stark vereinfacht und gekürzt ein paar Grundlagen des Domain Name Systems, die für Domaininhaber, die den Registrar wechseln möchten, von Relevanz sind. Immer wieder liest man in Support-Foren von verzweifelten Nutzern, denen offenbar nicht klar ist, dass ein Domain-Umzug nicht in Echtzeit abläuft, sondern, dass ein Domaintransfer ein paar Vorbereitungen und etwas Nachbearbeitung erfordert, damit die Ausfallzeiten möglichst gering ausfallen.

Wenn man sich vorher informiert, schont das die Nerven aller Beteiligten – vor allem aber die eigenen.

Wie funktioniert das Domain Name System?

Für Laien erklärt, ist das DNS am ehesten mit einem Telefonbuch für eine Region vergleichbar. Es übersetzt Namenseinträge (Domainnamen und Hostnamen) in Nummern (Internetprotokolladressen – kurz IP-Adressen). Die einfachste Art eines solchen Datensatzes ist ein sogenannter „A-Eintrag“ für das Internetprotokoll in der Version 4 (IPv4), dem heutzutage noch gängigen Protokoll, oder einem „AAAA-Eintrag“ für das Nachfolgeprotokoll IPv6.

Solche Einträge sehen in etwa so aus – im Beispiel sind die öffentlich abrufbaren Google-Nameserver:

dns.google.com. IN A 8.8.8.8
dns.google.com. IN AAAA 2001:4860:4860::8888

Dieses „Telefonbuch“ ist hierarchisch aufgebaut, d.h. es gibt einen Haupteintrag, unter dem dann weitere Einträge oder Verweise zu finden sind.

Organisatorisch läuft das wie folgt ab:

Ganz oben steht die  Top Level Domain („TLD“). Ein prominentes Beispiel für eine TLD ist „.com“. Für eine TLD zuständig ist eine Vergabestelle (Registry). Sie regelt, wer unter welchen Voraussetzungen einen Namen unterhalb der TLD registrieren darf. Wer eine Domain registriert, wird zum Domaininhaber (Registrant). Die Registry bedient sich meist mehrerer Vertragspartner (Registrare), um diese Domains zu verkaufen – sprich: Namensrechte auf Zeit zu lizenzieren. Die Registrare  sind die primären Vertragspartner der Registrants und vermitteln gegenüber der Registry – sie verrechnen dem Registrant auch die anfallenden Gebühren und rechnen sie mit der Registry ab.

Technisch funktioniert DNS so:

Die Registry betreibt sogenannte Root-Nameserver, die in aller Regel nur einen Verweis vom registrierten Namen vorhalten, der auf untergeordnete Nameserver (DNS-Server) zeigt. Haben diese DNS-Server einen Hostnamen, der innerhalb der Domain, um die es geht, liegen -es geht zum Beispiel um die Domain example.com, und der DNS-Server heißt ns1.example.com- ist zusätzlich ein sogenannter „Glue-Record“ vonnöten. Dabei handelt es sich schlicht um einen „A“ oder „AAAA“ -Eintrag, den allerdings der Registrar bei den Nameservern der Registry hinterlegen muss, damit er funktioniert.

Zusätzlich können die Rootserver auch noch kryptographische Schlüssel und Signaturen ausliefern, anhand derer man gefälschten Domaininformationen vorbeugen kann. Das gegenwärtig vorherrschende System dafür heißt DNSSEC.

Die Verweise vom Root-Nameserver zu den Servern des DNS-Providers (in der der Regel sind das zugleich die des Registrars) heissen „NS-Einträge“.

Im Falle dieses Blogs ist der Registrar der deutsche Hoster „netcup“ und die Einträge sehen so aus:

grundsoli.de. 120 IN NS root-dns.netcup.net.
grundsoli.de. 120 IN NS second-dns.netcup.net.
grundsoli.de. 120 IN NS third-dns.netcup.net.

Wir sehen also, dass für den Namen „grundsoli“ innerhalb der TLD „.de“ drei verschiedene Server zuständig („autoritativ“) sind.

Jeder dieser drei Server hält die sogenannte „Zone“ vor. Die Zone kann im einfachsten Fall eine Textdatei sein, oder die in ihr enthaltenen Informationen liegen in einer Datenbank.

Die Zone im Detail beschrieben:

Eine Zone setzt sich aus mehreren Resource Records („RR“) zusammen. Zu diesen RRs gehören auch die zuvor genannten NS, A und AAAA-Einträge.

Resource Records setzen sich zusammen wie folgt:

  • dem Zonennamen = Domain. Mancherorts wird auch vom „Origin“ gesprochen. Dieser Zonenname kann stets mit dem Platzhalter „@“ abgekürzt werden.
  • der TTL (Time to Live). Dieser Wert bestimmt, wieviele Sekunden der SOA-Eintrag in einem Cache gültig bleibt.
  • dem Schlüsselwort „IN“ für die Zonenklasse „Internet“. Einen anderen Wert wird man in der Praxis kaum je irgendwo sehen.
  • dem Typ – ich nenne hier nur die häufigsten – wer mehr wissen möchte, kann im RFC 1035 nachlesen.
    • A für einen Hostnamen
    • NS für einen autoritativen Name Server
    • CNAME für einen kanonischen Namen (in aller Regel also ein Verweis auf A oder AAAA)
    • SOA für den Beginn einer Autoritätszone („start of a zone of authority“)
    • PTR für einen „Domain Name Pointer“ – dieser Typ ist nur für die umgekehrte Namensauflösung von einer IP-Nummer in einen Domain-/Hostnamen erforderlich, aber für unsere Thema hier nicht relevant
    • MX für den Mail exchange. Dieser Eintrag bestimmt, an welchen Mailserver E-Mails gesendet werden sollen.
    • TXT für Texteinträge. Diese Eintragsart ist vor allem für Verifikationsdienste (Bestätigung der Inhaberschaft gegenüber bestimmten Anbietern) von zunehmender Bedeutung.
  • einem Wert oder mehreren Werten für den jeweiligen Typ.

Am Beginn der Zone steht stets ein Eintrag vom Typ SOA. Kehren wir zum Beispiel mit example.com zurück:

@ 3600 IN SOA dns1.example.com. hostmaster.example.com. (
2019090900 ; serial
3600 ; refresh
1800 ; retry
604800 ; expire
600 ; nc-ttl
);

Wir haben also die Variable für den Domainnamen „@“, die Gültigkeitsdauer des SOA-Eintrag in Caches „3600“, die Klasse Internet „IN“, die Art des Eintrags „SOA“ den primären Nameserver, das ist jener autoritative Nameserver, von dem aus die Zone vervielfältigt wird „dns1.example.com“ und eine E-Mailadresse in besonderer Schreibweise „hostmaster.example.com“ für hostmaster@example.com. Die Punkte am Ende von dns1.example.com. und hostmaster.example.com. sind extrem wichtig, da sie das Ende des Werts markieren. Fehlt der Punkt am Ende wird der Domainname an den Wert erneut angehängt. Aus „dns1.example.com“ würde dann „dns1.example.com.example.com“ – ein von Anfängern häufig gemachter Fehler. Die in Klammern folgenden Zahlenwerte schlüsseln sich wie folgt auf:

  • serial: die Versionsnummer -also fortlaufende Nummern- der Zone. Es hat sich eingebürgert, hier einen Datumsstempel der Art [vierstellige Jahreszahl, zweistellige Monatsnummer, zweistellige Tageszahl und zweistellige fortlaufende Nummer] zu verwenden. „2019090900“ steht also für die erste Version der Zone, die am 9. September 2019 erstellt worden ist. Siehe auch RFC 1912.
  • refresh: Ein Intervall in Sekunden, nach dessen Ablauf sekundäre Nameserver die Seriennummer vom primären Master erneut abfragen sollen. Empfohlen wird von RIPE NCC 86400 ≙ 24 Stunden¹.
  • retry: Ein Sekundenintervallwert, der zum Tragen kommt, um einen Refresh zu wiederholen, der fehlgeschlagen ist. RIPE-Empfehlung: 7200 ≙ 2 Stunden¹.
  • expire: Wenn diese Zeitspanne in Sekunden verstrichen ist, ohne, dass ein Refresh funktioniert hat, verwirft der sekundäre Nameserver seine zuletzt  erhaltene Zone. RIPE-Empfehlung: 3600000 ≙ 1000 Stunden¹
  • nc-ttl: Time to Live für Negatives Caching – seit RFC 2308. Zuvor: Minimale Lebensdauer für alle Resource Records, wenn diese nicht explizit angegeben waren. Negatives Caching bedeutet, dass ein cachender DNS-Server mit „NXDOMAIN“ antwortet, wenn ihm der abgefragte Eintrag nicht bekannt ist.
    RIPE-Empfehlung: 3600 ≙ 1 Stunde¹.

1: Die RIPE-Empfehlungen gelten stets für „für kleine und stabile Zonen“.

Der Wert für Retry muss kleiner sein, als der für Refresh. Der Wert für expire darf nicht kleiner sein als die Summe von Refresh und Retry.

Und damit haben wir die technischen Grundlagen für beeinflussbare Verzögerungen beim Domaintransfer im Grunde vollständig besprochen.

Die nicht beeinflussbaren Faktoren liegen bei der Registry, die etwa Widerspruchsfristen für einen Transfer definieren kann. Sie ist es auch, die festlegt, zu welchen Tageszeiten die Root-Nameserver eine neue Information, die von einem ihrer Registrare eingemeldet worden ist – wir reden da von neuen Nameserver-Einträgen – verarbeitet wird.

Um also einen Transfer so durchzuführen, dass er möglichst schnell über die Bühne geht, sollte man Tage oder Wochen vor dem Transfer die Werte für TTL, Refresh und NC-TTL verringern, wodurch in aller Regel auch der Wert für Retry verringert werden wird müssen. Dadurch setzt man sich vorübergehend zwar einem erhöhten Risiko aus, dass die Zone im Fehlerfall des Primärservers auch auf den Sekundärservern schneller mit ausfällt, umgekehrt müssen aber auch DNS-Resolver Dritter, auf die wir im Normalfall keinen Einfluss nehmen können, sofern sie standardkonform arbeiten, die vorgehaltenen Informationen schneller verwerfen.

Wenn man sich nun noch informiert, wann die Registry die Daten neu laden lässt, kann man den  Umzug auch dahingehend zeitlich koordinieren.

Laden beispielsweise etwa die Root-Nameserver laut Registry um 13 und um 16 Uhr die Daten neu, und der Registrar aktualisiert alle 15 Minuten, so kann man nach 13 Uhr die Änderungen machen. Die anderen Kunden des Registrars hätten die neuen Informationen so – sofern sie nicht in einem Cache liegen, um 13.15 Uhr, weltweit würde der Verweis auf die neuen Server erst um 16 Uhr aktiv. Um also Gleichzeitigkeit zu erwirken, wären die Änderungen nach 15.45 Uhr, aber vor 16.00 in Auftrag zu geben. Caching Server würden die alte Information aber zumindest noch für die in TTL definierte Zeit ausliefern, wenn sie die Standards einhalten – sonst länger.

Da sich heutzutage aber auch sogenannte Public-DNS-Resolver-Dienste großer Beliebtheit erfreuen – gemeint sind damit Google DNS, Cloudflare, OpenDNS und dergleichen, und diese oft eine Möglichkeit bieten, die Cache-Information über ein Webinterface neu zu laden, also den „Cache“zu „flushen“, kann man auch hier mit globaler Wirkung für alle Nutzer dieses Dienstes Einfluss auf die Erneuerung der Information nehmen. In der Linksammlung stehen einige Dienste gelistet.

 

Linksammlung:

How to Clear DNS Cache on Chrome, Firefox and Safari

Olympia GSM-Alarmanlage und Yesss SIM

Interessante Beobachtung: Bei einer Olympia Protect Serie 96XX GSM-Alarmanlage funktioniert anscheinend eine Charge von Yesss/A1 SIM-Karten nicht.
Während die Karten in einem alten Handy klaglos funktionieren, findet die Basiseinheit eines getesteten Alarmsets schlicht kein Netz. Die sonst bei GSM in einem Radiolautsprecher typischen Geräusche, wenn ein Handy sich ins Netz einbucht, fehlen in diesem Fall gänzlich. Konkret sind mit mehreren Yesss-SIM Serie 89431215071000XXXXX mit einer Olympia Protect 9061 (5943 rev.03) diese Anomalien zu beobachten gewesen, während folgende Serien funktionieren:
89431215050304XXXXX
89431214093005XXXXX
89431214093005XXXXX

Spannend…

Hallo Leser – Willkommen!

Willkommen auf grundsoli(.)de!

Hier befassen wir uns mit Reviews von IT- und Telekommunikationsprodukten, Security Audits, OpenSource und Sparangeboten. Wenn ich einem Thema begegne, das mich bewegt, schreibe ich einfach einmal meine Gedanken hier nieder und nehme Feedback entgegen. Betrachten wir es als öffentlich einsehbares Notizbuch, das auch dem Leser punktuell grundsolides IT-Wissen vermitteln und andererseits eine Entscheidungshilfe sein soll. Die Beiträge werden, soweit es für das deutschsprachige Publikum dieses Blogs von Interesse ist, mit https://technicalexperiments.wordpress.com abgestimmt.

Es ist geplant, die geringen Kosten des Betriebs dieses Blogs durch Werbeeinnahmen zu decken. Auf Werbung wird auch als solche hingewiesen werden. Soweit jedoch ein Artikel Produkte behandelt , die auf Amazon.de erhältlich sind, werden diese auch verlinkt. Ungeachtet dessen wird die Kritik schonungslos sein, denn meine Leser möchte ich ja nun wirklich nicht vergrämen.

Wir starten am heutigen 30. November 2018.

In diesem Sinne, herzlich willkommen!