Unternehmensdomains und DNS absichern: Registrar, DNSSEC, CAA und Notfallzugriff

Fachlich geprüft von Robin Roeder, Geschäftsführer der SCREENUS GmbH · zuletzt geprüft am 03.10.2026.

Eine Unternehmensdomain ist mehr als eine Webadresse. Über sie werden Website, E-Mail, Zertifikate, Cloud-Anmeldungen und häufig zahlreiche externe Dienste gesteuert. Wer das Registrar-Konto oder die DNS-Zone übernimmt, kann Datenverkehr umleiten, E-Mails abfangen oder Dienste unerreichbar machen. Deshalb gehört die Domain in dieselbe Schutzklasse wie administrative Konten, Backup und Identitätsmanagement.

Warum die Domain ein besonders kritisches Betriebsmittel ist

Die Domain verbindet Namen mit technischen Zielen. A- und AAAA-Einträge führen zur Website, MX-Einträge zum Maildienst, TXT-Einträge bestätigen Dienste und Sicherheitsregeln, NS-Einträge bestimmen die autoritativen Nameserver. Zusätzlich verlassen sich Zertifizierungsstellen bei der Ausstellung von TLS-Zertifikaten auf DNS-Informationen. Ein Fehler oder unbefugter Eingriff wirkt deshalb gleichzeitig auf mehrere Geschäftsprozesse.

CISA beschreibt DNS-Manipulation als Angriffspfad, bei dem kompromittierte Zugangsdaten genutzt werden, um beispielsweise A-, MX- oder NS-Einträge auf Infrastruktur des Angreifers zu ändern. Dadurch können Web- und E-Mail-Verkehr umgeleitet oder abgefangen werden. Die erste Schutzfrage lautet daher nicht „Welchen DNS-Anbieter nutzen wir?“, sondern „Wer kann welche Änderung auslösen, wie wird sie bestätigt und wie schnell erkennen wir sie?“

Die Sicherheitskette von außen nach innen betrachten

1. Registranten- und Vertragsdaten. Die Organisation muss als berechtigte Inhaberin erkennbar sein, Verlängerung und Zahlungsweg dürfen nicht an einer einzelnen Person hängen.
2. Registrar-Konto. Dieses Konto steuert Transfer, Kontakte, Nameserver und häufig DNSSEC. Es benötigt ein eigenes starkes Kennwort, Mehrfaktor-Authentisierung und klar begrenzte Zugriffsrechte.
3. Domain- und Transfer-Sperren. Verfügbare Client- oder Registry-Locks erschweren ungewollte Transfers oder Änderungen. Ihr Umfang und der geregelte Entsperrprozess müssen bekannt sein.
4. Autoritative DNS-Zone. Änderungen an A, MX, NS, TXT und CAA werden nachvollziehbar freigegeben, versioniert und überwacht.
5. Abhängige Dienste. Website, E-Mail, Fernzugriff, Cloud-Identitäten und Zertifikate benötigen eigene Prüfungen nach jeder DNS-Änderung.

Registrar-Konto wie ein privilegiertes Administratorkonto behandeln

Das Registrar-Konto sollte nicht über ein allgemein genutztes Sammelpostfach wiederherstellbar sein, dessen Zustellung selbst von der betroffenen Domain abhängt. Sinnvoll ist ein gesonderter, dokumentierter Wiederherstellungsweg. Ein hardwaregebundener oder phishingresistenter zweiter Faktor ist dort besonders wertvoll, sofern der Registrar ihn unterstützt. Wiederherstellungscodes werden getrennt und geschützt verwahrt.

ICANN weist darauf hin, dass Registranten ihre Domaineinstellungen über den Registrar verwalten und Rechte sowie Pflichten aus dem Registrierungsvertrag entstehen. Dadurch sind aktuelle Kontaktdaten, Vertragszugriff und Verlängerung keine Formalitäten, sondern Teil der Betriebssicherheit. Ein veraltetes Konto eines ehemaligen Mitarbeiters oder eine private Zahlungsadresse kann den technischen Schutz entwerten.

Locks richtig einordnen

Eine Transfersperre kann verhindern, dass eine Domain ohne vorgesehenes Verfahren zu einem anderen Registrar übertragen wird. Je nach Endung und Anbieter stehen unterschiedliche Statuswerte oder zusätzliche Registry-Locks zur Verfügung. Ein Lock ist aber kein Ersatz für sicheren Kontozugriff: Wer das Registrar-Konto kontrolliert, kann je nach Verfahren auch die Sperre lösen oder andere kritische Einstellungen verändern.

Vor dem Aktivieren muss deshalb geklärt werden, wer eine Entsperrung beantragen darf, welche Nachweise benötigt werden und wie lange der Vorgang im geplanten Providerwechsel dauern kann. ICANNs Transfer Policy beschreibt unter anderem den Status clientTransferProhibited und sichere Bestätigungsmechanismen bei Änderungen des Registranten. Der konkrete Ablauf bleibt vom Registrar und der Top-Level-Domain abhängig.

DNS-Zonen kontrolliert ändern

Eine DNS-Änderung sollte wie eine produktive Konfigurationsänderung behandelt werden. Dazu gehören Anlass, Sollwert, Freigabe, Zeitpunkt, vorherige Zonenkopie, Rückfallplan und anschließende Prüfung aus externer Sicht. Besonders MX-, NS- und Authentisierungseinträge können weitreichende Folgen haben. Niedrige TTL-Werte beschleunigen nicht automatisch jede Korrektur; bereits zwischengespeicherte Antworten und die Delegation beim Parent müssen mitgedacht werden.

Mindestens die geschäftskritischen Einträge sollten regelmäßig außerhalb des DNS-Anbieters gesichert werden. Eine Zonenkopie ersetzt zwar keinen funktionierenden Dienst, beschleunigt aber den Wiederaufbau und hilft beim Vergleich nach einem Vorfall. Monitoring prüft nicht nur Erreichbarkeit, sondern auch unerwartete Änderungen an Nameservern, Mailzielen und Zertifikaten.

DNSSEC: signierte Antworten, keine vertraulichen Antworten

DNSSEC ergänzt DNS um kryptografische Signaturen und eine Vertrauenskette. Nach RFC 4033 können validierende Resolver damit Herkunft und Integrität von DNS-Daten prüfen. DNSSEC bietet ausdrücklich keine Vertraulichkeit: Abfragen und Antworten werden dadurch nicht verschlüsselt. Es verhindert auch nicht, dass jemand mit legitimer Kontrolle über die Zone falsche Werte veröffentlicht.

Die Aktivierung betrifft mindestens zwei Ebenen: Der DNS-Anbieter signiert die Zone, der Registrar beziehungsweise die Registry veröffentlicht den passenden DS-Eintrag in der übergeordneten Zone. Wenn Schlüsselwechsel oder Delegation nicht sauber koordiniert werden, kann eine korrekt betriebene Domain für validierende Resolver unerreichbar werden. Deshalb gehören Aktivierung, Schlüsseldrehung, Providerwechsel und Rückbau in einen dokumentierten Ablauf mit externer Validierung.

CAA: Zertifizierungsstellen begrenzen

CAA-Einträge geben an, welche Zertifizierungsstellen Zertifikate für eine Domain ausstellen dürfen. RFC 8659 beschreibt CAA als zusätzliche Kontrolle zur Verringerung des Risikos unbeabsichtigter Zertifikatsausstellung. Die Regel wirkt bei der Ausstellung durch öffentliche Zertifizierungsstellen; sie ersetzt weder den Schutz des Registrar-Kontos noch die spätere Zertifikatsprüfung im Browser.

Vor einer Einschränkung muss vollständig bekannt sein, welche Plattformen und Dienstleister Zertifikate im Namen der Organisation beziehen. Dazu können Webserver, Hosting-Plattformen, Content-Delivery-Netze oder Cloud-Dienste gehören. Eine zu enge, ungeprüfte CAA-Regel kann notwendige Erneuerungen blockieren. Änderungen werden daher zunächst inventarisiert, dann kontrolliert eingeführt und anschließend an allen betroffenen Diensten beobachtet.

Notfallzugriff und Wiederherstellung vorbereiten

Im Vorfall zählt nicht nur, ob ein Zugang existiert, sondern ob er unabhängig von der gestörten Umgebung funktioniert. Das Notfallpaket benennt Registrar, Registry beziehungsweise Domain-Endung, DNS-Anbieter, Vertragsinhaber, berechtigte Rollen, Supportweg, Wiederherstellungscodes und eine aktuelle Zonenkopie. Geheimnisse stehen nicht im Klartext in der Betriebsdokumentation, sondern werden über ein getrennt geschütztes Verfahren bereitgestellt.

1. Erkennen. Alarm zu Login, Delegation, DNS-Eintrag, Zertifikat oder Erreichbarkeit fachlich bewerten.
2. Zugriff sichern. Aktive Sitzungen, Zugangsdaten und Faktoren nach einem geprüften Plan erneuern; keine Beweise vorschnell vernichten.
3. Sollzustand vergleichen. Registrar-Daten, NS-Delegation, DS-Eintrag und Zonendaten mit der freigegebenen Fassung abgleichen.
4. Dienste prüfen. Website, E-Mail, TLS, Cloud-Anmeldungen und externe Integrationen aus unabhängigen Netzen testen.
5. Nachverfolgen. Zertifikatstransparenz, DNS-Änderungen und Protokolle über den unmittelbaren Rückbau hinaus beobachten.

Ein kompakter Quartalscheck

Viermal pro Jahr sollte eine zuständige Rolle prüfen, ob Domaininhaber, Kontakte, Zahlungsweg und Verlängerung stimmen; welche Personen Administratorrechte besitzen; ob Mehrfaktor-Authentisierung und Wiederherstellung funktionieren; ob Transfer- und Änderungssperren passend gesetzt sind; ob Nameserver, DS-, MX- und CAA-Einträge dem Soll entsprechen; und ob die gesicherte Zonenkopie aktuell ist. Zusätzlich wird kontrolliert, ob Warnungen an tatsächlich überwachte Empfänger gehen.

Nach Providerwechseln, Umfirmierungen, Personalwechseln oder größeren Cloud-Projekten ist diese Prüfung sofort fällig. Ein kurzer dokumentierter Wiederherstellungstest zeigt, ob Supportnummern, Vertragsnachweise und Notfallzugänge im Ernstfall ausreichen, ohne produktive Einstellungen zu verändern.

Domain-Sicherheit ist laufender IT-Betrieb

SCREENUS betrachtet Domains nicht isoliert: Registrar-Konto, DNS, E-Mail-Sicherheit, Zertifikate, Hosting, Monitoring und Notfallzugriff müssen zusammenpassen. So bleibt nachvollziehbar, wer Änderungen freigibt, wie Abweichungen erkannt werden und wie der Betrieb bei einer Störung kontrolliert zurückkehrt.

Cybersicherheit ansehen Web & Hosting Domain-Sicherheit besprechen