A DNS query is a message sent by a client to a DNS server requesting records for a specific domain name, record type, and class, typically using UDP on port 53 as defined in RFC 1035. The query initiates nearly every network connection, making query volume a direct measure of DNS service demand and a critical metric for identifying capacity needs, misconfigured clients, and potential security issues. Monitoring query logs, implementing rate limiting, and maintaining redundant servers are essential operational practices to detect problems like query floods, NXDOMAIN spikes, and malware-generated random lookups before they impact application availability and user experience.
So funktioniert eine DNS-Abfrage
Eine DNS-Abfrage enthält eine Anfrage, die aus einem Namen, einem Eintragstyp und einer Klasse besteht. Der Client sendet sie an einen Resolver, der entweder aus seinem Cache antwortet oder die DNS-Hierarchie durchläuft, um die Antwort zu finden.
- Aufbau der Anfrage: Der Client bildet eine Anfrage mit dem zu suchenden Domainnamen, dem Datensatztyp (z. B. A, AAAA, MX oder TXT) und der Klasse, die fast immer „IN“ für das Internet ist.
- An einen Resolver senden: Der Stub-Resolver des Clients sendet die Abfrage an einen konfigurierten rekursiven Resolver, in der Regel über UDP auf Port 53.
- Cache prüfen: Der rekursive Resolver gibt eine zwischengespeicherte Antwort zurück, wenn er eine noch gültige Antwort für denselben Namen und Typ vorrätig hat.
- Abfrage bei autoritativen Servern: Wenn keine Antwort im Cache vorhanden ist, sendet der Resolver iterative Abfragen an Root-, Top-Level-Domain- und autoritative Server, bis einer die Antwort liefert oder einen Fehler meldet.
- Antwort zurücksenden: Der Resolver sendet die Antwort an den Client und speichert sie für die Dauer, die durch die „Time to Live“-Einstellung des Eintrags festgelegt ist, im Cache.
Abfragen verwenden normalerweise UDP, und der Client versucht es erneut über TCP, wenn eine Antwort abgeschnitten ist. Der Antwortcode gibt das Ergebnis an, z. B. „kein Fehler“ oder „NXDOMAIN“ für einen Namen, der nicht existiert. Erweiterungen wie EDNS und verschlüsselte Transportprotokolle wie DNS über TLS ändern die Art und Weise, wie Abfragen übertragen werden, nicht jedoch, wonach gefragt wird.
Häufige Probleme bei DNS-Abfragen
Eine große Flut von Abfragen, oft nach zufälligen Namen oder aus gefälschten Quellen, kann die CPU des Resolvers, die Sockets oder die Upstream-Bandbreite überlasten. Symptome sind steigende Latenz, SERVFAIL-Fehler oder Timeouts sowie eine Abfragefrequenz, die weit über dem normalen Basiswert liegt.
Ein falsch konfigurierter Client oder eine Anwendung, die TTL und Caching ignoriert, kann dieselbe Abfrage viele Male pro Sekunde senden. In den Protokollen zeigt sich dies dadurch, dass ein einzelner Client die Liste der „Top-Talker“ für einen bestimmten Namen anführt.
Ein plötzlicher Anstieg von NXDOMAIN-Antworten lässt sich oft auf eine fehlerhafte Anwendung, ein falsches Suchdomänen-Suffix oder eine veraltete Konfiguration zurückführen, die auf einen entfernten Namen verweist. Clients können zudem mehrere Suchsuffixe anhängen, wodurch sich die Anzahl der fehlgeschlagenen Abfragen pro Suchvorgang vervielfacht.
Wenn eine Antwort die Größe überschreitet, die ein Client über UDP akzeptiert, setzt der Server das Truncation-Flag, und der Client muss den Vorgang über TCP wiederholen. Firewalls, die den TCP-Port 53 blockieren, verursachen zeitweise Ausfälle bei großen Antworten, beispielsweise solchen mit DNSSEC-Daten.
Clients, die mit einem öffentlichen oder veralteten Resolver konfiguriert sind, umgehen das interne DNS, sodass interne Namen nicht aufgelöst werden oder andere Antworten zurückgeben. Dies tritt häufig nach Änderungen des DHCP-Gültigkeitsbereichs oder auf Geräten mit fest programmierten DNS-Einstellungen auf.