Wie sollen DNS-Timeouts funktionieren?

Ich hatte kürzlich ein Problem, bei dem ein Remotedienst, der die IP-Adresse für meinen Server anforderte (mit einem gehosteten DNS-Anbieter), antwortete mit:

DNS problem: SERVFAIL looking up A for mysql.xavamedia.nl

(Update: Der hier erwähnte Remote-Dienst ist Let's Encrypt. Ich habe einen Fehler gegen den Issue-Tracker gemeldet , der mich auf diesen Weg geführt hat.)

Beim Testen in meinem lokalen Netzwerk konnte ich feststellen, dass ich manchmal eine leere DNS-Antwort vom gehosteten DNS-Server erhalte. Anscheinend ist dies zeitweise, da es nur passiert, wenn sich die DNS-Einträge nicht im Cache befinden, und es nur dann ein Problem ist, wenn der DNS-Server wirklich ausgelastet ist.

Hier ist eine Wireshark-Beschreibung einer leeren Antwortnachricht:

Da die meisten DNS-Abfragen und -Antworten über UDP gesendet werden, wartet ein lokaler Resolver natürlich nur eine Weile auf die Antwort und gibt dann auf. Ich frage mich jetzt, ob es Richtlinien für DNS-Antwortzeiten gibt. Mein DNS-Hoster zuckte die Achseln und sagte, mein lokaler Resolver habe die leere Antwort zu früh gesendet. Ich hatte dieses Problem noch nie zuvor, bin aber überrascht über den Fehlermodus - eine leere DNS-Antwort ohne Fehlercode.

Kennt jemand einige Richtlinien, wie dies funktionieren soll und wann / wie ich nachweisen kann, dass mein DNS-Hosting etwas falsch macht?

domain-name-system dns-hosting

— djc
quelle

Können Sie bitte die Frage aktualisieren, um weitere Informationen zur leeren Antwort bereitzustellen? Dies kann eine Reihe von Dingen bedeuten, abhängig von den gesetzten Flags und dem Aussehen des Berechtigungsabschnitts. Wir müssten entweder die Ausgabe von dig/ nslookupoder eine Wireshark-Dissektion sehen. ( tcpdumpwird nicht gut genug sein) Wenn Sie verwenden nslookup, führen Sie set debugzuerst aus.

— Andrew B

Ich habe eine PC-Kappe, bin mir aber nicht sicher, wie ich sie hier am besten zeigen kann?

— DJC

Öffnen Sie es in Wireshark, klicken Sie auf das Paket und erweitern Sie die Informationen für das DNS-Protokoll. Erweitern Sie auch die Unterkategorien und veröffentlichen Sie einen Screenshot in Ihrer Frage mit der Schaltfläche Bild einfügen. Sie können den Screenshot auf das DNS-Protokoll zuschneiden.

— Andrew B

Antworten:

Die leere Antwort, die Sie betrachten, ist ein synthetischer Zustand, der als bekannt ist NODATA. NODATAund NXDOMAINbeide zeigen an, dass der Name nicht existiert, aber auch NXDOMAINfür alle Namen unter dem angegebenen Datensatz gilt. NODATAweist darauf hin, dass entweder dieser Name mit Datensätzen eines nicht angeforderten Typs verknüpft ist oder dass sich andere Datensätze unter dem befinden, was Sie anfordern. (dh example.test.xavamedia.nl.)

Ihr Mitnehmen von NODATAund NXDOMAINist in diesem Zusammenhang praktisch dasselbe: Der Datensatz des angeforderten Namens und Typs war nicht vorhanden. Ein maßgeblicher Name - Server wurde für die gewünschte Domain erreicht, und es antwortete Angabe zurück , dass ein Datensatz mit diesem Namen und Typ nicht existierte. Dies ist kein Kommunikationsfehler. Der autorisierende Server sagte, dass er die Daten nicht hatte. Höchstwahrscheinlich hat der Server, mit dem Sie gesprochen haben, diese Anforderung bereits verarbeitet und das Fehlen dieses Datensatzes innerhalb der letzten vier Stunden zwischengespeichert. (14400 Sekunden ist das negative Cache-Intervall, das im SOA-Datensatz für definiert ist. xavamedia.nl.)

Weder NXDOMAINnoch NODATA für sich allein führt in dieser Instanz zu einer Zeitüberschreitung, aber Ihre Resolver-Bibliothek wird wahrscheinlich von hier aus zum Anhängen des DNS-Suchsuffix übergehen, was wiederum eine Zeitüberschreitung für die autorisierenden DNS-Server der Suchdomäne auslösen kann.

Es sollte beachtet werden, dass nichts davon erklärt, warum Sie SERVFAILbeim Nachschlagen auf eine Antwort gestoßen sind mysql.xavamedia.nl.. Dies weist auf ein Problem hin, bei dem der rekursive Server die Antwort von den autorisierenden Servern erhält. Entweder antwortete der autorisierende Server mit SERVFAIL, der rekursive Server konnte keinen der autorisierenden Server erreichen, oder der rekursive Server stellte fest, dass die zurückgegebenen Daten ungültig waren. Nichts davon kann mit den von Ihnen angegebenen Informationen nachgewiesen werden.

— Andrew B.
quelle

Vielen Dank für Ihre ausführliche Antwort! Einige Dinge sind noch unklar: Wenn die NODATA-Antwort irgendwie vom autorisierenden Server initiiert wird, hat mein DNS-Hosting ein Problem, da diese Domänen schon lange existieren (aufgrund eines Platzhalter-A-Datensatzes). Meine andere Frage ist also, wie ich beweisen kann, ob der autorisierende Server etwas falsch gemacht hat.

— DJC

Das NODATAin Ihrer Paketerfassung ist der Beweis. Die relevante Frage lautet: "Warum hat ein autorisierender Server geantwortet und gesagt, dass kein solcher Datensatz vorhanden ist?" . Leider ist es schwierig, Druck auszuüben, es sei denn, Sie können dies durch direkte Suche nach den autorisierenden Servern beweisen (wodurch die Möglichkeit beseitigt wird, die Betreiber der rekursiven Server zu zucken und zu beschuldigen), wobei zu berücksichtigen ist, dass sich nur einer der drei gelegentlich schlecht verhält.

— Andrew B

NODATAbedeutet, dass der Name zwar vorhanden ist, jedoch kein Datensatz des angeforderten Typs vorhanden ist. ZB fragen Sie nach AAufzeichnung, aber es hat nur MXAufzeichnung. Dies kann auch vorkommen, wenn der Name für einen Zwischenknoten in der DNS-Hierarchie steht und keine eigenen Datensätze enthält.

— Barmar

@Barmar Ja, hier wird gesagt, dass der autorisierende Server ein Fehlen dieses Datensatznamen + Typ-Paares meldet und djc diesbezüglich aufgrund eines Wildcard-Datensatzes, der seit einiger Zeit vorhanden ist, Verwirrung darüber ausdrückt.

— Andrew B

Mein Kommentar richtet sich an Ihren ersten Punkt "NODATA und NXDOMAIN zeigen beide an, dass der Name nicht existiert". NXDOMAINbedeutet, dass der Name nicht existiert, NODATAbedeutet , dass der Name existiert, der angeforderte Datensatztyp jedoch nicht.

— Barmar

Ich kenne keine spezifischen Richtlinien außer den in Abschnitt "6.1.3.3 Effiziente Ressourcennutzung" von RFC 1123 http://tools.ietf.org/rfcmarkup?rfc=1123#page-77 definierten

Dort wird ein Timeout-Wert von "nicht weniger als 5 Sekunden" angegeben. Der RFC gibt außerdem an, dass temporäre Fehler zwischengespeichert werden sollten. Dies dient dazu, eine übermäßige Anzahl von DNS-Anforderungen zu verhindern, wenn Clients gegen Abschnitt 2.2 des RFC verstoßen. In diesem Abschnitt heißt es, dass Clients bei weichen Fehlern zwischen den Wiederholungsversuchen eine "angemessene" Zeit warten sollten.

Es gibt auch einen Stackoverflow-Thread zu diesem Thema, der jedoch nur einige reale Beobachtungen enthält. /programming/3036054/ideal-timeout-period-for-dns-lookup

Das ist alles, was ich zu diesem Thema sagen kann. Wenn jemand anderes mehr hinzuzufügen hat, wäre ich auch interessiert.

— Janek Bevendorff
quelle