Die DNS-Records, die wirklich zählen

Jedes Mal, wenn ich zum ersten Mal Zugriff auf die DNS-Zone eines Kunden bekomme, ist es dasselbe Muster: eine Handvoll Records von Diensten, die einmal ausprobiert und nie wieder entfernt wurden, ein SPF-Record, der seit dem letzten Mailprovider-Wechsel, oder dem davor, nicht mehr aktualisiert wurde, und oft ein fehlender oder falscher Record für etwas, das gerade jetzt still und leise Probleme macht. DNS-Zonen sammeln Altlasten, weil das Entfernen eines Records riskanter wirkt als ihn zu lassen, selbst wenn niemand mehr sagen kann, wofür er war. Hier ist die kurze Liste, die ich tatsächlich prüfe, in der Reihenfolge, in der ich sie prüfe.

A und AAAA: die Basis, aber beide prüfen

Der A-Record (IPv4) fehlt selten, aber AAAA (IPv6) ist oft entweder nicht vorhanden oder, schlimmer, vorhanden und zeigt auf eine Adresse, die es nicht mehr gibt. Ein veralteter AAAA-Record bedeutet, dass Dual-Stack-Clients zuerst IPv6 versuchen, scheitern und auf IPv4 zurückfallen, was jeder Verbindung eine Verzögerung hinzufügt. Wenn IPv6 nicht aktiv genutzt wird, ist gar kein AAAA-Record besser als ein falscher.

MX und die mailbezogenen TXT-Records

Wenn die Domain Mails versendet oder empfängt, zeigen MX-Records auf den Mailserver, und SPF, DKIM und DMARC, alles TXT-Records, bestimmen, ob Mails im Namen dieser Domain vertraut wird. Ich habe ausführlicher darüber geschrieben, wie man diese richtig einrichtet, aber die Prüfung hier ist einfacher: Beschreiben diese Records noch die Realität? Ein SPF-Record, der einen Mailprovider auflistet, von dem vor zwei Jahren weggezogen wurde, ist aktiv schädlich, er hilft nicht nur nicht, er kann auch dazu führen, dass legitime Mails vom aktuellen Provider beim SPF-Alignment scheitern.

NS-Records: stimmen sie mit dem überein, was der Registrar denkt?

Klingt banal, aber es lohnt sich zu prüfen, ob die NS-Records, die die Zone selbst zurückgibt, mit dem übereinstimmen, was beim Domain-Registrar konfiguriert ist. Eine Diskrepanz hier, oft ein Überbleibsel einer nicht ganz abgeschlossenen DNS-Provider-Migration, bedeutet, dass manche Resolver die Records des alten Providers sehen und manche die des neuen, abhängig vom Caching, was genau die Art von "bei mir geht's, bei denen nicht"-Problem erzeugt, das stundenlange Fehlersuche kostet, wenn man das nicht zuerst prüft.

dig NS example.com
whois example.com | grep -i "name server"

CAA: ein einfacher Eintrag, der fast immer fehlt

CAA-Records (Certification Authority Authorization) legen fest, welche Zertifizierungsstellen Zertifikate für die eigene Domain ausstellen dürfen. Fast niemand setzt das, und es ist ein einzelner Record:

example.com.  CAA  0 issue "letsencrypt.org"

Er verhindert nicht jede Art von Zertifikatsmissbrauch, aber er schließt eine ganze Kategorie von Fehlausstellungen durch CAs aus, die nie genutzt wurden, für den Preis eines Records, der nur aktualisiert werden muss, wenn die Zertifizierungsstelle wechselt. Wenig Aufwand, echter Nutzen, und ein Record, der signalisiert, dass diese Zone mit Sorgfalt aufgesetzt wurde.

TTL: niedrig während Änderungen, höher, wenn alles stabil ist

Das ist kein Record-Typ, aber er sorgt ständig für Probleme. Eine niedrige TTL (zum Beispiel 300 Sekunden) während einer Migration bedeutet, dass Änderungen schnell propagieren, falls etwas zurückgerollt werden muss. Sobald alles stabil ist, reduziert eine höhere TTL (ein paar Stunden bis ein Tag) die Last beim DNS-Provider und beschleunigt die Auflösung für Nutzer leicht, da deren Resolver die Antwort länger cachen. Der häufigste Fehler, den ich sehe, ist eine dauerhaft niedrige TTL, übrig von einer Migration, die vor Monaten abgeschlossen wurde, harmlos, aber auch ein Zeichen, dass niemand danach noch mal aufgeräumt hat.

Die eigentliche Gewohnheit, die sich lohnt

Keiner dieser Records ist exotisch, und keiner davon braucht spezielle Tools über dig und ein paar Minuten hinaus. Der Wert liegt nicht in einem einzelnen Record, sondern darin, eine DNS-Zone als etwas zu behandeln, das die aktuelle Realität widerspiegeln sollte, nicht als archäologische Aufzeichnung jedes Dienstes, der die Domain je berührt hat. Wenn ich ein Projekt abschließe, das DNS angefasst hat, dauert es dreißig Sekunden, die jetzt ungenutzten Records zu entfernen, und erspart der nächsten Person (oft mir selbst) Monate später die Frage, ob dieser mysteriöse TXT-Record gefahrlos gelöscht werden kann.