DNS-Timeout oder SERVFAIL: Der Unterschied

Nicht jeder fehlgeschlagene DNS-Lookup scheitert auf dieselbe Weise. Zwei der häufigsten Fehler außer NXDOMAIN – ein Timeout und ein SERVFAIL – sehen von außen ähnlich aus (es kam keine brauchbare Antwort zurück), weisen aber auf deutlich unterschiedliche Ursachen hin.

Timeout: Keine Antwort in der vorgesehenen Zeit

Ein Timeout bedeutet genau das, wonach es klingt: Die Abfrage wurde gesendet, und innerhalb der konfigurierten Wartezeit kam keine Antwort zurück. Das kann passieren, weil der autoritative Server überlastet ist, wegen Paketverlusts irgendwo auf dem Netzwerkpfad oder weil eine Firewall DNS-Traffic stillschweigend verwirft, statt ihn ausdrücklich abzulehnen. Aus Sicht des Fragenden sind ein Timeout und ein schlicht nicht existierender Server nicht zu unterscheiden – beides ist nur Stille.

SERVFAIL: Eine Antwort kam, und sie lautete „Ich kann nicht“

SERVFAIL ist eine echte Antwort, keine Stille. Der antwortende Server sagt ausdrücklich, dass bei der Verarbeitung der Abfrage ein Problem aufgetreten ist – eine fehlerhaft konfigurierte Zone, ein fehlgeschlagener DNSSEC-Validierungsversuch, ein interner Fehler auf Seiten des Resolvers. Ein SERVFAIL zeigt, dass auf Serverseite etwas Konkretes passiert ist, während ein Timeout vergleichsweise wenig darüber verrät, wo das Problem tatsächlich liegt.

Da beide möglicherweise vorübergehend sind, ist die richtige Behandlung in der Praxis dieselbe: wenige Male mit exponentiellem Backoff wiederholen und erst nach Ausschöpfen dieser Versuche einen echten Fehler melden – genau so behandelt dieses Tool beide Codes anders als ein endgültiges NXDOMAIN.

REFUSED bedeutet meist eine Richtlinie, keinen Fehler

REFUSED wird oft mit SERVFAIL in einen Topf geworfen, weil in beiden Fällen der Server „Nein“ sagt statt zu schweigen, doch die Gründe dahinter sind meist ganz verschieden. Ein Nameserver gibt häufig REFUSED zurück, wenn er nur für bestimmte Zonen antworten soll und nach etwas außerhalb seines Zuständigkeitsbereichs gefragt wird, wenn eine Zugriffskontrollliste die abfragende IP blockiert oder wenn ein Resolver ausdrücklich so konfiguriert ist, dass er Abfragen von außerhalb des eigenen Netzwerks ablehnt (etwa ein rekursiver Resolver, der Fremden im Internet keine rekursiven Antworten liefert – korrektes, gewolltes Verhalten, kein Fehler). Ein REFUSED von einem Server, den Sie nicht kontrollieren, lässt sich selten durch Wiederholen oder eine Backoff-Strategie beheben; prüfen Sie lieber, ob Sie überhaupt den richtigen Server abfragen.

Eine häufige, konkrete SERVFAIL-Ursache: defektes DNSSEC

Eines der ärgerlicheren SERVFAIL-Szenarien tritt bei Domains auf, für die DNSSEC aktiviert, aber falsch konfiguriert ist – eine abgelaufene Signatur, ein Schlüssel, der am Nameserver rotiert, beim Registrar aber nicht aktualisiert wurde, oder eine unterbrochene Vertrauenskette irgendwo zwischen der Domain und der Root. Ein validierender Resolver, der DNSSEC beachtet, verweigert eine Antwort, die er nicht kryptografisch überprüfen kann, und gibt SERVFAIL zurück, statt die defekte Signatur stillschweigend zu ignorieren. Das Unangenehme daran: Die Domain funktioniert oft einwandfrei über einen Resolver, der DNSSEC gar nicht validiert. Deshalb wird diese Ursache leicht mit „Bei mir geht es“ fehldiagnostiziert, obwohl sie für einen erheblichen Teil der realen Besucher tatsächlich defekt ist.