DNS-Handover ohne böse Überraschungen: Wer kontrolliert Domain, DNSSEC und Mail?

Die Website läuft. Die Agenturbeziehung endet, ein Hostingwechsel steht an oder ein interner Mitarbeiter verlässt das Unternehmen. Dann fällt plötzlich auf: Der Registrar-Login liegt bei einer privaten Agenturadresse, die Nameserver zeigen zu einem alten Dienstleister und niemand weiß, ob DNSSEC aktiv ist.

Das ist kein exotisches Problem. Eine Domain ist nicht nur eine URL. Sie ist ein Kontrollpunkt für Website, TLS-Zertifikate, E-Mail und oft weitere Dienste.

Ein gutes Handover prüft deshalb nicht nur, ob jemand eine Zone exportieren kann. Es klärt, wer die Domain tatsächlich verwalten kann, welche DNS-Abhängigkeiten existieren und wie ein Wechsel ohne unnötigen Ausfall zurückgerollt werden könnte.

Der wichtigste Unterschied: Registrar ist nicht gleich DNS-Provider

Beim Registrar wird die Domain verwaltet: Dort liegen unter anderem die Delegation zu den autoritativen Nameservern und – bei DNSSEC – die DS-Informationen für die übergeordnete Zone. Der DNS-Provider betreibt dagegen typischerweise die Zone mit A-, AAAA-, CNAME-, MX-, TXT- und weiteren Records.

Diese Rollen können beim selben Anbieter liegen, müssen es aber nicht.

Genau hier entstehen Übergabefehler: Ein Team erhält Zugriff auf das DNS-Dashboard und glaubt damit, die Domain übernommen zu haben. Wenn aber nur die ehemalige Agentur Zugriff auf den Registrar hat, fehlen im Ernstfall Nameserver-Änderung, DNSSEC-Anpassung oder Registrar-Transfer.

ICANN beschreibt den Auth-Code als notwendiges Element für den Transfer einer gTLD zu einem anderen Registrar. Wenn Sie keinen Zugriff auf das Registrar-Konto oder keinen belastbaren Recovery-Weg haben, ist das deshalb ein konkretes Betriebsrisiko.

Red Flag 1: Die Domain hängt an einer persönlichen Agentur- oder Mitarbeiteradresse

Ein Handover sollte beantworten:

• Wer ist beim Registrar als Domaininhaber beziehungsweise Registrant hinterlegt?
• Welches Konto kann Nameserver, DNSSEC und Transfer-Einstellungen ändern?
• Wer kontrolliert MFA und Recovery?
• Wohin gehen Verlängerungs- und Sicherheitsbenachrichtigungen?
• Gibt es mindestens zwei verantwortliche Personen oder einen dokumentierten Notfallweg?
• Kann der Auth-Code bei Bedarf beschafft werden?

Die Lösung ist nicht, Zugangsdaten in einem Chat herumzureichen. Besser ist ein Unternehmensaccount mit sauberer Rollenverteilung, MFA und dokumentiertem Recovery-Prozess.

Red Flag 2: Vor dem Wechsel existiert kein vollständiges DNS-Inventar

Eine DNS-Zone enthält häufig weit mehr als die sichtbare Website.

Neben A, AAAA und CNAME können dort unter anderem liegen:

• MX für eingehende E-Mail,
• SPF als TXT-Record,
• DKIM-Keys unter Selektoren in _domainkey,
• DMARC unter _dmarc,
• CAA für Zertifikatsausstellung,
• Verifizierungsrecords für SaaS-Dienste,
• Subdomains für APIs, Shops, Tracking, Statusseiten oder Kundensysteme.

RFC 7208 definiert SPF über DNS-TXT-Records. RFC 6376 beschreibt die DNS-basierte Veröffentlichung von DKIM-Schlüsseln. RFC 9989 legt DMARC-Policy-Records in DNS fest.

Wer beim Umzug nur die Website-Records kopiert, kann deshalb eine perfekt erreichbare Startseite und gleichzeitig kaputte E-Mail-Zustellung erzeugen.

Vor jedem Nameserverwechsel gehört ein Export oder zumindest ein strukturiertes Inventar der produktiven Zone in die Übergabedokumentation.

Red Flag 3: DNSSEC ist aktiv, aber niemand hat einen Migrationsplan

DNSSEC erzeugt eine kryptografische Vertrauenskette. RFC 4033 beschreibt diese Kette unter anderem über DNSKEY- und DS-Records. Bei einer signierten Delegation muss der Parent zur tatsächlich verwendeten Signatur der Child-Zone passen.

Genau deshalb ist ein Nameserverwechsel mit DNSSEC nicht einfach nur „neue NS eintragen“.

Ein alter DS-Record kann nach einem Wechsel auf neue Nameserver nicht mehr zu deren Schlüsseln passen. Validierende Resolver können die Zone dann als fehlerhaft behandeln. Cloudflare warnt für seinen eigenen Migrationspfad ausdrücklich davor, Nameserver zu wechseln, solange noch unpassende alte DS-Daten aktiv beziehungsweise gecacht sind; für fortgeschrittene Setups gibt es dagegen Multi-Signer-Migrationsverfahren.

Die richtige Reihenfolge hängt vom bisherigen und neuen DNS-Provider ab. Deshalb:

1. Vor dem Wechsel feststellen, ob DS-Records vorhanden sind.
2. Dokumentieren, wer die DNSSEC-Schlüssel verwaltet.
3. Den vom alten und neuen Provider unterstützten Migrationsweg festlegen.
4. TTLs und Wartezeiten der Delegation berücksichtigen.
5. Nach dem Wechsel mit validierenden Resolvern prüfen, ob die Kette wieder korrekt ist.

DNSSEC sollte nicht aus Bequemlichkeit dauerhaft abgeschaltet werden. Aber eine ungeplante Schlüssel- und Delegationsmigration kann aus einem Sicherheitsfeature einen Ausfall machen.

Red Flag 4: CAA blockiert plötzlich die Zertifikatsausstellung

CAA erlaubt Domaininhabern festzulegen, welche Certificate Authorities Zertifikate für eine Domain ausstellen dürfen. RFC 8659 verlangt von konformen CAs, vorhandene relevante CAA-Einträge bei der Ausstellung zu berücksichtigen.

Das wird beim Providerwechsel leicht übersehen.

Vielleicht hat der bisherige Hoster Zertifikate über CA A ausgestellt, der neue über CA B. Wird ein restriktiver CAA-Record unverändert übernommen, kann die Website zunächst noch funktionieren – bis das bestehende Zertifikat erneuert oder ein neues für eine Subdomain benötigt wird.

Prüfen Sie deshalb vor dem Cutover:

• Gibt es CAA-Records?
• Welche CA nutzt die neue Plattform tatsächlich?
• Werden Wildcard-Zertifikate anders behandelt?
• Kann die Plattform Zertifikate bereits vor dem Nameserverwechsel vorbereiten?
• Ist der Renewal-Pfad nach dem Wechsel getestet?

Ein gültiges Zertifikat am Migrationstag beweist noch nicht, dass die nächste Erneuerung funktioniert.

Red Flag 5: TTLs werden erst fünf Minuten vor dem Cutover geändert

RFC 1035 definiert TTL als Zeitraum, in dem ein Resource Record gecacht werden darf, bevor die Quelle erneut konsultiert werden soll.

Das hat eine praktische Konsequenz: Eine kurz vor dem Wechsel reduzierte TTL löscht bereits gecachte Antworten nicht rückwirkend.

Wenn ein kritischer Record vorher beispielsweise lange gecacht werden durfte, können Resolver diese alte Antwort noch bis zum Ablauf ihres bestehenden Cache-Eintrags verwenden.

Darum gehört TTL-Planung vor die Migration. Für Records, die gezielt umgeschaltet werden sollen, kann eine rechtzeitig vorher reduzierte TTL die Übergangsphase verkürzen. Nach Stabilisierung kann sie wieder auf einen sinnvollen Betriebswert erhöht werden.

Nicht jeder Record braucht eine Mini-TTL. Sehr niedrige Werte erhöhen Abfragevolumen und lösen keine schlechte Migrationsplanung.

Red Flag 6: Der alte DNS-Provider wird sofort abgeschaltet

Ein Nameserverwechsel ist kein magischer globaler Schalter. Während Delegations- und Cache-Zustände auslaufen, können noch Anfragen beim bisherigen Setup landen.

Deshalb ist es meist sinnvoll, die alte Zone während des kontrollierten Übergangs weiter konsistent zu bedienen, statt sie in dem Moment zu löschen, in dem neue Nameserver eingetragen wurden.

Der saubere Ablauf ist:

1. Zielzone vollständig aufbauen.
2. Records gegen das Produktionsinventar vergleichen.
3. Website, TLS, Mail und wichtige Subdomains auf dem Ziel vorbereiten.
4. DNSSEC-Migrationsweg ausführen.
5. Delegation ändern.
6. Öffentliche DNS-Auflösung, HTTPS und E-Mail beobachten.
7. Alte Infrastruktur erst entfernen, wenn der Übergang nachweislich abgeschlossen ist.

Der 20-Minuten-Handover-Check

Bevor Agentur, Hoster oder DNS-Provider gewechselt werden, beantworten Sie diese Fragen:

Zugriff: Haben wir selbst kontrollierten Zugang zum Registrar und zum DNS-Provider? Funktionieren MFA und Recovery ohne eine einzelne externe Person?

Delegation: Welche Nameserver sind beim Parent tatsächlich eingetragen? Stimmen sie mit dem erwarteten Provider überein?

DNSSEC: Existieren DS-Records? Wer kontrolliert die Signierung? Wie sieht der konkrete Wechselpfad aus?

Zone: Gibt es ein aktuelles Inventar aller produktiven Records und ihrer Zwecke?

E-Mail: Sind MX, SPF, DKIM, DMARC und providerbezogene Verifikationen vollständig dokumentiert?

TLS: Gibt es CAA? Kann die neue Plattform Zertifikate ausstellen und erneuern?

Caching: Welche relevanten TTLs gelten jetzt – nicht erst im geplanten Zielzustand?

Rollback: Wie kommen wir zurück, wenn Website, Mail oder ein kritischer Dienst nach dem Wechsel fehlschlägt?

Monitoring: Wer prüft während und nach dem Cutover DNS, TLS, Website, E-Mail und zentrale Subdomains?

Wenn mehrere Antworten „müssten wir die alte Agentur fragen“ lauten, ist das der eigentliche Befund.

Was Website-Pflichtencheck dabei prüfen kann

Von außen lassen sich nicht alle Eigentums- und Kontodetails eines Registrars verifizieren. Genau diese Grenze ist wichtig.

Website-Pflichtencheck kann jedoch die öffentlich sichtbare technische Kontrollfläche prüfen und daraus konkrete Übergabefragen ableiten, zum Beispiel:

• autoritative Nameserver und Delegation,
• vorhandene DS-Records und sichtbaren DNSSEC-Zustand,
• CAA-Records,
• öffentliche Website- und Subdomain-Records,
• MX sowie sichtbare SPF-, DKIM- und DMARC-Konfiguration,
• TLS-Zertifikatskette und Zertifikatsaussteller,
• Redirects und Erreichbarkeit wichtiger Hosts,
• widersprüchliche oder offensichtlich veraltete DNS-Ziele.

Dazu gehört eine organisatorische Checkliste für Registrar-Zugriff, MFA, Recovery, Verlängerung und Verantwortlichkeiten.

Der Nutzen ist nicht ein hübscher DNS-Export. Der Nutzen ist ein Handover, bei dem Website, Mail und Domain nicht an einem vergessenen Login oder einer übersehenen Vertrauenskette hängen.

Wenn ein Hosting- oder Agenturwechsel bevorsteht, prüfen Sie die Domain-Kontrolle vor dem Kündigungstermin. Danach wird aus einer einfachen Übergabefrage sehr schnell ein Incident.