Die DNS-Records, auf die es wirklich ankommt

Jedes Mal, wenn ich Zugang zur DNS-Zone eines Kunden bekomme, bietet sich mir dasselbe Bild. Es gibt Records von Diensten, die einmal ausprobiert und nie entfernt wurden. Da liegt ein SPF-Record herum, der auf einen Mail-Provider verweist, von dem man sich vor zwei Jahren getrennt hat. Und fast immer fehlt ein wirklich kritischer Eintrag oder ist falsch konfiguriert, was im Hintergrund lautlos Probleme verursacht.

DNS-Zonen vermüllen mit der Zeit, weil sich das Löschen eines Eintrags gefährlicher anfühlt als ihn einfach stehen zu lassen – selbst wenn niemand weiß, was er eigentlich tut. Hier ist die kurze Liste, die ich tatsächlich überprüfe, und zwar genau in dieser Reihenfolge.

A und AAAA: Die absoluten Basics

Der A-Record (IPv4) fehlt fast nie. Aber der AAAA-Record (IPv6) ist entweder gar nicht vorhanden oder – noch schlimmer – er zeigt auf eine IPv6-Adresse, die nicht mehr existiert. Ein verwaister AAAA-Record führt dazu, dass Dual-Stack-Clients zunächst IPv6 probieren, in einen Timeout laufen und erst dann auf IPv4 zurückfallen. Das fügt jeder einzelnen Verbindung ein massives Delay hinzu.

Wenn man IPv6 nicht aktiv und korrekt auf dem Server betreibt, ist es tausendmal besser, gar keinen AAAA-Record zu haben als einen kaputten.

MX und die Mail-bezogenen TXT-Records

Wenn die Domain E-Mails sendet oder empfängt, zeigen die MX-Records auf den Mailserver. SPF, DKIM und DMARC (allesamt TXT-Records) regeln, ob E-Mails, die unter dieser Domain verschickt werden, vertrauenswürdig sind.

Ich habe bereits ausführlicher darüber geschrieben, wie man das richtig einrichtet, aber die Prüfung hier ist simpler: Entsprechen diese Records noch der Realität? Ein SPF-Record, der einen alten, nicht mehr genutzten Provider listet, ist kein harmloser Datenmüll. Er kann aktiv dafür sorgen, dass völlig legitime Mails vom aktuellen Provider das SPF-Alignment nicht bestehen und direkt im Spam-Ordner landen.

NS-Records: Stimmen sie mit dem Registrar überein?

Es klingt trivial, aber man sollte immer überprüfen, ob die NS-Records, die die Zone selbst zurückgibt, auch mit denen übereinstimmen, die beim Domain-Registrar hinterlegt sind.

Eine Diskrepanz entsteht meistens während eines Providerwechsels, der nicht sauber abgeschlossen wurde. Das bedeutet, dass einige Resolver (abhängig vom Caching) die alten Einträge sehen und andere die neuen. Das erzeugt exakt jene "Bei mir geht's, bei denen aber nicht"-Szenarien, die einen stundenlang in den Wahnsinn treiben, wenn man diesen Punkt nicht direkt als Erstes checkt.

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

CAA: Der einfache Record, der fast immer fehlt

CAA-Records (Certification Authority Authorization) legen exakt fest, welche Zertifizierungsstellen (CAs) SSL-Zertifikate für die Domain ausstellen dürfen. Fast niemand richtet das ein.

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

Es verhindert nicht jeden denkbaren Angriff, aber es eliminiert komplett die Gefahr von fehlerhaften Ausstellungen durch CAs, die man nie genutzt hat. Das "kostet" einen einzigen Eintrag, den man nur anpassen muss, falls man den SSL-Anbieter wechselt. Wenig Aufwand, sehr nützlich – und es signalisiert sofort, dass derjenige, der die Zone eingerichtet hat, wusste, was er tut.

TTL: Niedrig bei Änderungen, hoch im Alltag

Das ist kein Record-Typ, aber ein Stolperstein für viele. Eine niedrige TTL (z. B. 300 Sekunden) ist während einer Migration sinnvoll, damit Änderungen schnell greifen oder Rollbacks zügig umgesetzt werden können.

Sobald alles stabil läuft, reduziert eine höhere TTL (ein paar Stunden bis zu einem Tag) die Abfragelast beim DNS-Provider und macht die Auflösung für die Endnutzer minimal schneller, da deren lokale Resolver die Antwort länger cachen. Der Fehler, den ich am häufigsten sehe, ist eine dauerhaft niedrige TTL, die von einer Migration übrig geblieben ist, die vor Monaten abgeschlossen wurde. Es ist harmlos, aber ein untrügliches Zeichen dafür, dass niemand mehr aufgeräumt hat, nachdem sich der Staub gelegt hatte.

Die eigentlich wichtige Angewohnheit

Keiner dieser Einträge ist exotisch, und die Prüfung erfordert nichts weiter als dig und fünf Minuten Zeit. Der wahre Wert liegt darin, eine DNS-Zone als etwas zu begreifen, das die aktuelle Realität abbilden muss – und nicht als archäologische Ausgrabungsstätte jedes Dienstes, der jemals mit der Domain in Berührung kam.

Wenn ich ein Projekt abschließe, das DNS-Änderungen beinhaltete, dauert es dreißig Sekunden, ungenutzte Records zu löschen. Das bewahrt die nächste Person (oftmals mich selbst Monate später) davor, sich ewig zu fragen, ob man diesen einen mysteriösen TXT-Record nun gefahrlos löschen darf oder nicht.