Nameserver-Check
Antworten die Nameserver deiner Domain auf beiden Wegen — über UDP und über TCP? Der zweite fehlt öfter, als man denkt, und fällt erst auf, wenn die Antworten größer werden.
Warum TCP hier eine eigene Spalte bekommt
Fast jedes DNS-Werkzeug fragt über UDP und weicht bei einer gekürzten Antwort still auf TCP aus. Für eine Auskunft ist das genau richtig. Für eine Prüfung verdeckt es den Fehler, den man sucht: Ein Nameserver ohne TCP sieht darin aus wie ein gesunder — solange die Testantwort klein genug war.
Dass TCP Pflicht ist, steht seit 2016 in RFC 7766. Die ältere Lesart — TCP sei ein Notnagel für Zonentransfers — stammt aus RFC 1035 und ist überholt. Der Grund ist der Alltag: DNSSEC-Signaturen, Domains mit vielen Mailservern, lange SPF- und DKIM-Einträge. Antworten oberhalb der Puffergrenze sind der Normalfall geworden.
Der Ablauf im Fehlerfall ist tückisch, weil er nichts kaputtgehen lässt, was man sofort bemerkt: Der Resolver fragt über UDP, bekommt eine gekürzte Antwort mit gesetztem TC-Bit, baut daraufhin eine neue Verbindung über TCP auf — und läuft in den Zeitablauf. Für den Nutzer sieht das aus wie „das Internet hängt manchmal".
Deshalb steht hier jede Frage zweimal. Und deshalb wird zusätzlich ohne EDNS gefragt: Ein Server, der nur mit OPT-Record antwortet, bricht bei alten Clients weg.
Noch nichts geprüft.
Was oft als Nächstes dran ist
- Zonentransfer (AXFR)Die andere Frage an dieselben Server: Geben sie die ganze Zone heraus, ohne zu fragen?
- DNSSEC-PrüfungSignierte Zonen sind der Grund, warum Antworten heute über die UDP-Grenze wachsen — ohne TCP brechen sie zuerst weg.
- DNS-PropagationMelden die Server verschiedene Seriennummern, steht hier, wie weit die Änderung schon durch ist.
- MTU & PaketgrößeWarum eine Antwort ab einer bestimmten Größe unterwegs hängen bleibt — dieselbe Ursache, andere Ebene.
