DNS-Einträge abfragen

Die Einträge, und wofür sie tatsächlich da sind

„Propagation“ ist das falsche Wort

Das Nützlichste, was man über DNS verstehen kann, denn es verwandelt ein unvorhersehbares Warten in eine Zahl, die Sie steuern.

Nichts propagiert. Es gibt kein Verteilen, kein Ausrollen, keine Welle von Aktualisierungen, die über das Internet läuft. Ihr Nameserver hat den neuen Wert in dem Moment, in dem Sie speichern. Zeit kostet etwas anderes: Jeder Resolver der Welt hält eine zwischengespeicherte Kopie der alten Antwort und behält sie, bis die ihm mitgegebene TTL abläuft.

Die Verzögerung ist also nicht rätselhaft — sie ist genau die TTL, die veröffentlicht war, als der jeweilige Resolver zuletzt fragte. Hatte Ihr Eintrag eine TTL von 3600 Sekunden, fragen manche Resolver nach fünf Minuten erneut und andere nach einer Stunde, weshalb eine Änderung Menschen ungleichmäßig zu erreichen scheint.

Daraus ergibt sich das Vorgehen für jede geplante Änderung:

1. Einen Tag vorher die TTL auf 300 Sekunden senken. Warten, bis die alte TTL abgelaufen ist, damit alle die kurze übernommen haben.
2. Die Änderung vornehmen. Sie dauert nun fünf Minuten statt einen Tag.
3. Wenn sich alles gesetzt hat, die TTL wieder anheben.

Der Grund fürs Anheben: Eine niedrige TTL bedeutet mehr Anfragen, mehr Latenz bei einem Cache-Fehlschlag und eine härtere Störung, falls Ihre Nameserver unerreichbar werden — niemand hat dann eine brauchbare zwischengespeicherte Antwort als Rückfallebene.

Die Mail-Einträge, wo die meisten Probleme sitzen

Drei TXT-Einträge entscheiden, ob Ihrer Post geglaubt wird. Sie sind häufig falsch konfiguriert, und der Fehlschlag ist lautlos — Post landet im Spam statt zurückzukommen, also sagt es Ihnen niemand.

SPF

Listet, welche Server Post für Ihre Domain senden dürfen. Die Fehler, nach Häufigkeit:

• Zwei SPF-Einträge. RFC 7208 verlangt von Empfängern, das als permanenten Fehler zu behandeln, die Prüfung fällt also vollständig durch. Führen Sie sie zu einem zusammen.
• Mehr als zehn DNS-Abfragen. Jedes include: zählt, und Includes verschachteln sich. Ein Mailanbieter plus eine Marketingplattform plus ein Helpdesk bringen Sie schnell dorthin, und eine Überschreitung lässt die Prüfung scheitern.
• Ein Abschluss mit `~all` oder `?all`. Beide heißen „wahrscheinlich nicht wir, aber macht, was ihr wollt“. Nur -all bittet Empfänger, abzuweisen.

DKIM und DMARC

DKIM signiert jede Nachricht mit einem Schlüssel, dessen öffentliche Hälfte in einem TXT-Eintrag unter einem Selektornamen wie selector1._domainkey.example.com liegt — man muss den Selektor kennen, um ihn nachzuschlagen, weshalb er in der Standardabfrage oben nicht enthalten ist. DMARC liegt unter _dmarc.example.com und sagt Empfängern, was zu tun ist, wenn SPF und DKIM uneins sind, und wohin Berichte gehen.

Schlagen Sie oben _dmarc.yourdomain.com nach. Kommt nichts zurück, haben Empfänger keine Anweisung und entscheiden bei allem, was Sie fälscht, nach eigenem Ermessen.

Die CNAME-Regel am Apex

Ein CNAME kann nicht neben irgendeinem anderen Eintrag für denselben Namen stehen. Der Apex einer Domain muss SOA- und NS-Einträge haben, kann also keinen CNAME führen — weshalb example.com auf einen SaaS-Anbieter zeigen zu lassen umständlich ist, www.example.com dagegen trivial.

Die Behelfe sind anbieterspezifisch: ALIAS, ANAME oder CNAME-Flattening, die alle das Ziel serverseitig auflösen und mit einem A-Eintrag antworten. Sie funktionieren, sie sind nicht standardisiert, und man sollte von ihnen wissen, bevor man einen Nachmittag darauf verwendet.

Verwandt

Wenn die Einträge zeigen, wohin sie sollen, prüfen Sie das Zertifikat, das der Host tatsächlich vorlegt, und welche Header er zurückgibt. Welches Netz eine Adresse besitzt, auf die ein Eintrag zeigt, beantwortet die ASN-Abfrage.