Event-Subdomain an einen anderen DNS-Anbieter delegieren: Übergabe-Checkliste
Ein Eventteam kann example.org bei einem DNS-Betreiber belassen und tickets.example.org von einem Ticket-, Registrierungs- oder Partnerdienst in einer eigenen Zone verwalten lassen. Ein NS-Eintrag in der übergeordneten Zone überträgt die Zuständigkeit für diesen Namen und darunterliegende Namen. Das ist mehr als die Weiterleitung eines Hostnamens an eine Anwendung. Diese Checkliste hält Grund, Einträge, beide Verantwortlichen und Prüfergebnisse vor der Änderung fest.
Boletolibre-Redaktion
Veröffentlicht
Prüfen, ob eine eigene Child-Zone nötig ist
Editierbare Subdomain-Übergabekarte herunterladen (Markdown, Englisch)
Ein A-, AAAA- oder CNAME-Eintrag in der Parent-Zone genügt häufig, wenn ein Anbieter nur einen Host auf seinen Dienst zeigen lassen will. Delegation ist sinnvoll, wenn ein anderer Betreiber einen ganzen Namensbereich mit mehreren Eintragstypen verwalten muss. Fordere die genauen DNS-Vorgaben an. Ein TXT-Nachweis oder CNAME ist noch kein Auftrag zur NS-Delegation.[1][2]
AWS beschreibt beide Möglichkeiten: Subdomain-Einträge in der Parent-Zone oder eine eigene autoritative Zone. Cloudflare erklärt die Delegation, weist für seine Child-Zonen aber auf Produkt- und Tarifgrenzen hin. Prüfe deshalb die aktuelle Konfiguration und Berechtigung des Kontos.[1][3]
Parent- und Child-Betreiber benennen
Notiere registrierte Domain, exakten Namen der Child-Zone, beide autoritativen DNS-Anbieter und deren Änderungsberechtigte. Der Parent-Betreiber setzt den NS-Eintrag am Delegationspunkt; der Child-Betreiber verwaltet die Antworten darunter. Ein Wechsel der Nameserver beim Registrar für die registrierte Domain ist ein anderer Vorgang und für die Delegation von tickets.example.org nicht erforderlich.[1]
Erfasse Eventseite, Ticketkauf, Anmeldung, Bestätigung, E-Mail, Zertifikatsprüfung und Anbieter-Verifikation unter dem Child-Namen. Prüfe, ob öffentliches oder privates DNS nötig ist: Eine private Zone schafft allein keine öffentliche Delegation. Benenne eine Person für die Freigabe möglicher Besucherauswirkungen und eine für technische Nachweise.[1]
Child-Einträge vor der Parent-Änderung vorbereiten
Erstelle die Child-Zone nach der aktuellen Anleitung ihres Anbieters. Übernimm die tatsächlich zugewiesenen autoritativen Nameserver, keine Beispielwerte. Inventarisiere alle Einträge am Delegationspunkt und darunter. Lege benötigte Web-, TXT-, MX- und weitere Einträge in der Child-Zone an und frage deren autoritative Server direkt ab. Sichere Antworten und UTC-Zeit.[1]
AWS warnt vor uneinheitlichen Antworten, wenn Parent und Child während des Übergangs unterschiedliche Daten enthalten und Resolver verschiedene Nameserver im Cache haben. Plane, welche alten Einträge wann entfallen; lösche keinen funktionierenden Eintrag, bevor die Child-Zone antwortet. Bei DNSSEC müssen die Betreiber Signierung und Parent-DS nach ihrem unterstützten Verfahren prüfen. Keine DS-Werte improvisieren.[1][3]
Delegation veröffentlichen und Autoritätsweg prüfen
Nach Vorbereitung und Freigabe setzt der Parent-Betreiber einen NS-Eintrag für den exakten Child-Namen mit den Nameservern des Child-Anbieters. Prüfe erst die autoritative Parent-Antwort und dann die Diensteinträge beim Child. Vergleiche Antworten unabhängiger rekursiver Resolver, während Caches aktualisiert werden. Ein korrekt angezeigter NS-Satz beweist allein keinen funktionierenden Ticketkauf.[1]
Teste Eventseite, Ticket- oder Anmeldelink, Bestätigung und E-Mail-Nutzung unter diesem Namen. Prüfe Zertifikat und Anbieter-Verifikation im jeweiligen Dienst. Halte Zeit, Prüfer und Resolver fest. Versprich keine feste Verteilungsdauer; TTL, Cache und Anbieterabläufe unterscheiden sich. Bei widersprüchlichen Antworten pausieren abhängige Änderungen bis zur geprüften Rück- oder Eskalationsentscheidung.[1]
Rückweg und laufende Zuständigkeit festhalten
Der Rückweg braucht Zugriff auf die Parent-Zone, die alten Werte und eine entscheidungsbefugte Person. Die Rückkehr zu Parent-Einträgen muss noch zwischengespeicherte Child-Antworten berücksichtigen. Schließe die Child-Zone nicht, solange Resolver ihre NS-Einträge verwenden könnten. Nach Stabilisierung entferne veraltete Duplikate nach Anbieterplan und archiviere Vorher-Nachher-Nachweise.[1]
Lege fest, wer die Child-Zone pflegt, spätere TXT- oder Zertifikatsanfragen bearbeitet, den Anbieter bezahlt, Zugriffe prüft und die Delegation zum Vertragsende schließt. Sonst bleibt nach der Saison eine vergessene Abhängigkeit. Nimm sie mit Prüftermin ins Domain-Inventar auf. Auch die Rückgabe der Autorität ist eine neue DNS-Änderung mit Vorprüfung und Besuchertests.[1]
Die editierbare Übergabekarte nutzen
Die Vorlage trennt Entscheidung, abhängige Einträge, Verantwortliche, Vorprüfung, beobachtete Ergebnisse und Übergabe. Fülle eine Karte je Child-Zone aus und bewahre sie bei den DNS-Freigaben auf. Sie ist ein Koordinationsdokument, keine universelle Befehlsfolge. Zugangsdaten, API-Tokens, Transfercodes und private Schlüssel gehören nicht hinein.[1]
Wenn Eventseiten oder Links über Boletolibre.com verwaltet werden, erfasse die exakten öffentlichen Hostnamen und Besucheraufgaben. Verwende die tatsächlich bereitgestellten DNS-Anweisungen; dieser Leitfaden setzt nicht voraus, dass Boletolibre Registrar oder autoritativer DNS-Betreiber ist.[1]
Quellen und weiterführende Informationen
- Routing traffic for subdomainsAmazon Route 53 · Abgerufen
- Subdomain delegation and available setupsCloudflare DNS documentation · Abgerufen
- Delegate subdomainsCloudflare DNS documentation · Abgerufen