Was Sie sehen
Jede Abfrage geht an einen öffentlichen rekursiven Resolver, der entweder aus seinem Cache antwortet (die angezeigte TTL ist die Restzeit in diesem Cache) oder die autoritativen Server der Zone fragt. Deshalb können zwei Resolver nach einer Änderung uneins sein: Einer hält den alten Eintrag, bis seine TTL abläuft. Der Resolver-Vergleich macht das sichtbar; stimmen beide mit dem Erwarteten überein, ist die Änderung für den größten Teil des Internets angekommen. Vollständige Propagation heißt schlicht „jeder Cache ist abgelaufen“, deshalb ist die TTL einen Tag vor einer Änderung zu senken der einzige Weg, sie schnell zu machen.
Eintragstypen in Kürze
| Typ | Enthält | Typische Prüfung |
|---|---|---|
| A / AAAA | IPv4- / IPv6-Adresse | zeigt die Seite auf den richtigen Server |
| CNAME | Alias auf einen anderen Namen | kann nicht neben anderen Einträgen am selben Namen stehen; nie am Zonen-Apex |
| MX | Mailserver mit Priorität | die niedrigste Zahl wird zuerst versucht; das Ziel braucht A/AAAA, keinen CNAME |
| TXT | Freitext: SPF, DMARC, DKIM, Site-Verifizierung | genau ein SPF-Eintrag |
| NS | autoritative Nameserver | müssen mit der Delegation der Elternzone übereinstimmen |
| SOA | Zonenparameter: Serial, Refresh, Retry, Expire, Minimum | Serial steigt bei jeder Änderung; Minimum ist die Negativ-Cache-TTL |
| CAA | welche Zertifizierungsstellen ausstellen dürfen | Let’s Encrypt braucht issue "letsencrypt.org" oder gar kein CAA |
| SRV | Dienstort: Priorität, Gewicht, Port, Ziel | _sip._tcp, _xmpp-client._tcp, _minecraft._tcp |
| DS / DNSKEY | DNSSEC-Vertrauenskette | DS in der Elternzone muss zu einem KSK der Zone passen; das AD-Flag zeigt erfolgreiche Validierung |
| HTTPS / SVCB | Service-Binding: ALPN (h2, h3), ECH, IP-Hinweise | was Cloudflare für HTTP/3 und Encrypted Client Hello veröffentlicht |
| TLSA | DANE-Zertifikats-Pinning | vor allem für SMTP zwischen Mailservern |
SPF und das 10-Lookup-Limit
Ein SPF-Eintrag listet auf, wer Mail für die Domain senden darf. Jeder include:-, a-, mx-, ptr-, exists- und redirect=-Term kostet den empfangenden Server eine DNS-Abfrage, und RFC 7208 begrenzt die Summe auf zehn, über alle verschachtelten Includes gezählt. Wer darüber liegt, bekommt von Empfängern permerror, was DMARC als Fehlschlag wertet; Mail von einer Domain mit zu vielen Includes landet also an dem Tag im Spam, an dem ein Anbieter seinem eigenen Eintrag ein weiteres Include hinzufügt. Die Kettenansicht löst jedes Include auf und zeigt die laufende Summe; die übliche Lösung ist, include: durch die ip4:-Bereiche des Anbieters zu ersetzen oder nicht mehr genutzte Absender zu entfernen. Includes, die auf keinen SPF-Eintrag auflösen, zählen als „void lookups“, davon sind zwei erlaubt.
DMARC und DKIM
DMARC liegt unter _dmarc.domain und sagt, was passieren soll, wenn weder SPF noch DKIM zur From-Adresse passen: p=none beobachten, p=quarantine Spam-Ordner, p=reject abweisen. DKIM-Public-Keys liegen unter selektor._domainkey.domain; der Selektor steht im s=-Tag des DKIM-Signature-Headers jeder gesendeten Nachricht, dort finden Sie ihn, wenn Sie ihn nicht kennen. Übliche Selektoren: google (Google Workspace), selector1/selector2 (Microsoft 365), k1 (Mailchimp), default, mail, dkim.
Fragen
Warum geben Cloudflare und Google unterschiedliche Antworten?
Caching. Ein Resolver hat den Eintrag vor Ihrer Änderung geholt und behält ihn, bis seine TTL abläuft; der andere hat ihn danach geholt. Warten Sie, bis die alte TTL abgelaufen ist, oder senken Sie die TTL vor der nächsten Änderung. Sind sie danach immer noch uneins, sind vielleicht Ihre autoritativen Nameserver untereinander nicht synchron (vergleichen Sie die SOA-Serial auf jedem).
Warum gibt es keinen Eintrag, obwohl ich weiß, dass er existiert?
Prüfen Sie den genauen Namen: www.example.com und example.com sind verschiedene Namen. Ein CNAME am Namen verdeckt andere Typen. Lautet der Status NXDOMAIN, existiert der Name gar nicht; NOERROR ohne Antworten heißt, der Name existiert, hat aber keinen Eintrag dieses Typs.
Was bedeutet das DNSSEC-Flag (AD)?
Der Resolver hat die Antwort gegen die DNSSEC-Vertrauenskette validiert, und sie war in Ordnung. Ist die Zone signiert und das Flag fehlt bei beiden Resolvern, passt der DS-Eintrag in der Elternzone vielleicht nicht zum Schlüssel der Zone (ein Klassiker nach einem DNS-Anbieterwechsel), was die Domain für validierende Resolver unerreichbar macht.
Ist das dasselbe wie dig oder nslookup?
Fast. dig +dnssec example.com MX @1.1.1.1 stellt demselben Resolver dieselbe Frage. Diese Seite nutzt die DNS-over-HTTPS-Endpunkte der Resolver, damit sie im Browser laufen kann; sie kann Ihre eigenen Nameserver nicht direkt befragen, für autoritative Antworten also dig @ns1.ihrdns.com verwenden.
Warum weicht die SPF-Lookup-Zählung von einem anderen Tool ab?
Tools unterscheiden sich darin, ob sie den redirect=-Modifier, verschachtelte Includes und a/mx-Terme mit expliziten Argumenten zählen. Diese Seite folgt RFC 7208 Abschnitt 4.6.4: include, a, mx, ptr, exists und redirect zählen alle, auf jeder Verschachtelungsebene; ip4, ip6 und all sind frei.