So funktioniert’s
DNSSEC (RFC 4033 bis 4035) ergänzt eine Zone um digitale Signaturen. Zu jedem Satz von Records gibt es einen RRSIG-Record mit Signatur und Ablaufdatum, die öffentlichen Schlüssel stehen in DNSKEY-Records. NSEC- oder NSEC3-Records belegen sogar, dass ein Name nicht existiert.
Damit ein Resolver den Schlüsseln traut, braucht es eine Kette bis zur Root-Zone: Ein DS-Record in der Elternzone, also bei der Registry von .de oder .com, enthält den Hash des Schlüssels deiner Zone. Den DS-Record trägt in der Regel der Registrar ein, oft automatisch, wenn DNS-Anbieter und Registrar derselbe sind.
Ein validierender Resolver wie Google Public DNS, Cloudflare oder Quad9 prüft die Kette bei jeder Antwort. Stimmt alles, setzt er das AD-Flag. Passt etwas nicht, etwa weil eine Signatur abgelaufen ist oder der DS-Record nicht mehr zum Schlüssel passt, antwortet er mit SERVFAIL – die Domain ist für seine Nutzer dann nicht erreichbar.
Warum gefährlich
Ohne DNSSEC kann ein Resolver gefälschte Antworten nicht von echten unterscheiden. DNS-Spoofing und Cache Poisoning lenken Besucher und Mails dann unbemerkt auf fremde Server. DANE für Mailserver setzt DNSSEC zwingend voraus.
Gefährlicher als fehlendes ist kaputtes DNSSEC. Ein DS-Record, der nach einem Wechsel des DNS-Anbieters noch auf den alten Schlüssel zeigt, oder ein ausgefallenes automatisches Neusignieren machen die Domain samt Website und Mail für alle Nutzer validierender Resolver unerreichbar. Weil der eigene, oft nicht validierende Resolver weiter antwortet, fällt der Fehler häufig spät auf.
So vermeidest du es
- DNSSEC beim DNS-Anbieter aktivieren und prüfen, ob der DS-Record in der Elternzone angekommen ist.
- Einen aktuellen Algorithmus nutzen, am besten ECDSA P-256 (13) oder Ed25519 (15), und RSA/SHA-1 oder ältere Verfahren ablösen.
- Vor einem Wechsel des DNS-Anbieters DNSSEC sauber übergeben: entweder den DS-Record entfernen und dessen TTL abwarten oder den Schlüssel des neuen Anbieters vorher in die Kette aufnehmen.
- Bei selbst signierten Zonen das automatische Neusignieren überwachen, damit die Signaturen nicht ablaufen.
- Die Validierung von außen über einen validierenden Resolver prüfen, nicht nur über den eigenen.
So erkennt DomainWarn es
Der Check DNSSEC prüft, ob in der Elternzone ein DS-Record steht, und fragt die Domain über einen validierenden Resolver ab. Ist DNSSEC eingerichtet, die Validierung scheitert aber, ist das kritisch: Nach zwei Läufen eröffnet DomainWarn den Incident „DNSSEC-Validierung fehlgeschlagen“. Ohne DS-Record gibt es nur einen Hinweis.
Zusätzlich überwacht der Check das Ablaufdatum der Signaturen: unter 7 Tagen eine Warnung, unter 2 Tagen kritisch, jeweils mit dem Incident „DNSSEC-Signaturen laufen ab“. Bei Anbietern, die nur für wenige Tage signieren und täglich erneuern, greifen die Schwellen erst, wenn auch der Anteil der Gültigkeitsdauer knapp wird. Abgekündigte Algorithmen wie RSA/MD5, DSA, RSA/SHA-1 und GOST sind eine Warnung. Aktiviertes oder deaktiviertes DNSSEC und ein Schlüsselwechsel erscheinen als Änderung.
DomainWarn prüft das für alle deine Domains regelmäßig und meldet sich, wenn etwas fehlt oder sich ändert.