RFC, bei dem DNS-Server auf unbekannte Domänenanforderungen antworten müssen

Mein Domain-Registrar und mein DNS-Anbieter ignorieren derzeit DNS-Anfragen an unbekannte Domains. Mit Ignorieren meine ich Schwarze Löcher und antworte nie, was dazu führt, dass meine DNS-Clients und Resolver-Bibliotheken es erneut versuchen, zurücksetzen und schließlich eine Zeitüberschreitung verursachen.

dig @NS3.DNSOWL.COM somedomainthatdoesntexist.org
...
;; connection timed out; no servers could be reached

Bei der Untersuchung anderer beliebter Domain-Name-Dienste sehe ich, dass dieses Verhalten ziemlich einzigartig ist, da andere Anbieter einen RCODE von 5 (VERWEIGERT) zurückgeben:

dig @DNS1.NAME-SERVICES.COM somedomainthatdoesntexist.org
dig @NS-284.AWSDNS-35.COM somedomainthatdoesntexist.org
dig @NS21.DOMAINCONTROL.COM somedomainthatdoesntexist.org

Alle geben ungefähr Folgendes zurück:

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 64732

oder

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 31219

Zurück REFUSEDoder NXDOMAINsofort ist meiner Meinung nach angemessen, anstatt die Anfrage einfach auf dem Serverraum abzulegen.

Wenn ich mich bei meinem Provider beschwere, dass ihre Server nicht antworten, bitten sie mich, den RFC zu zitieren, gegen den ihre Server verstoßen. Ich weiß, dass es seltsam ist, dass sie mich bitten zu beweisen, dass ihre Server auf alle Anfragen antworten sollen, aber so soll es sein.

Fragen :

• Ich gehe davon aus, dass ein Server immer auf die Anfrage antworten sollte, es sei denn, es gibt doppelte Anforderungs-IDs oder eine Art DOS-Antwort. Ist das richtig?
• Welchen RFC und spezifischen Abschnitt sollte ich zitieren, um meine Bestimmung zu unterstützen?

Für mich ist es schlecht, nicht auf eine DNS-Anfrage zu antworten. Die meisten Clients ziehen sich zurück und übertragen dieselbe Abfrage erneut an denselben DNS-Server oder einen anderen Server. Sie verlangsamen nicht nur die Clients, sondern bewirken auch, dass dieselbe Abfrage von ihren eigenen oder anderen Servern abhängig von den autorisierenden Nameservern und NS-Einträgen erneut ausgeführt wird.

In RFC 1536 und 2308 werden aus Leistungsgründen und zum Stoppen der erneuten Übertragung derselben Abfrage viele Informationen zum negativen Caching angezeigt. In 4074 werden Informationen zum Zurückgeben einer leeren Antwort mit einem RCODE von 0 angezeigt, sodass der Client weiß, dass keine IPv6-Informationen vorhanden sind, die den Client veranlassen sollten, nach A RRs zu fragen, was ein weiteres Beispiel für eine leere Antwort ist.

Ich kann jedoch keinen RFC finden, der besagt, dass ein DNS-Server auf eine Anfrage antworten soll, wahrscheinlich weil dies impliziert ist.

Das spezifische Problem tritt auf, wenn ich meine Domain (und die zugehörigen DNS-Einträge) auf ihre Server migriere oder die ersten X Minuten, nachdem ich eine neue Domain bei ihrem Dienst registriert habe. Es gibt eine Verzögerung zwischen der Änderung der autorisierenden Nameserver (was heutzutage verdammt schnell ist) und dem Beginn der Bereitstellung meiner DNS-Einträge durch ihre Server. Während dieser Verzögerungszeit denken DNS-Clients, dass ihre Server autorisierend sind, aber sie antworten nie auf eine Anfrage - selbst mit einem REFUSED. Ich verstehe die Verzögerung, die in Ordnung ist, aber ich bin nicht einverstanden mit der Entscheidung, nicht auf die DNS-Anfragen zu antworten. Ich verstehe, wie man diese Einschränkungen in ihrem System umgeht, aber ich arbeite immer noch mit ihnen zusammen, um ihre Dienste so zu verbessern, dass sie dem DNS-Protokoll besser entsprechen.

Danke für die Hilfe.

Bearbeiten:

Innerhalb von ein paar Monaten, nachdem sie dies veröffentlicht und mit meinem Provider Kontakt aufgenommen hatten, wechselten sie ihre Server, um NXDOMAINfür unbekannte Domains zurückzukehren.

Shane's Rat ist richtig. Wenn Daten vor dem Einleiten einer Umstellung nicht von einem autorisierenden Server auf einen anderen migriert werden, ist dies eine Einladung zu einem Ausfall. Unabhängig davon, was ab diesem Zeitpunkt passiert, handelt es sich um einen Ausfall, der von der Person ausgelöst wurde, die die NS-Aufzeichnungen geschwungen hat. Dies erklärt, warum mehr Personen diese Beschwerde nicht bei Ihrem Anbieter einreichen.

Trotzdem ist dies immer noch eine interessante Frage, die ich beantworten muss, also werde ich mich darum kümmern.

Die Grundfunktionalität von DNS-Servern wird durch die Dokumente RFC 1034 und RFC 1035 abgedeckt , die zusammen STD 13 bilden . Die Antwort muss entweder von diesen beiden RFCs stammen oder durch einen späteren RFC geklärt werden, der sie aktualisiert.

Bevor wir fortfahren, gibt es hier eine massive Gefahr außerhalb des DNS-Bereichs, die hervorgehoben werden muss: Beide RFCs stammen aus der Zeit vor BCP 14 (1997), dem Dokument, in dem die Sprache von MAI, MUSS, SOLLTE usw. klargestellt wurde.

• Standards, die vor der Formalisierung dieser Sprache verfasst wurden, haben möglicherweise eine klare Sprache verwendet, in einigen Fällen jedoch nicht. Dies führte zu unterschiedlichen Implementierungen von Software, Massenverwirrung usw.
• STD 13 ist leider schuldig, in mehreren Bereichen interpretativ zu sein. Wenn die Sprache in einem Einsatzbereich nicht fest ist, ist es häufig erforderlich, einen klarstellenden RFC zu finden.

Beginnen wir damit, was RFC 1034 §4.3.1 zu sagen hat:

• Der einfachste Modus für den Server ist nicht rekursiv, da er Anfragen nur mit lokalen Informationen beantworten kann: Die Antwort enthält einen Fehler, die Antwort oder eine Weiterleitung an einen anderen Server, der "näher" an der Antwort liegt. Alle Nameserver müssen nicht rekursive Abfragen implementieren.

...

Wenn kein rekursiver Dienst angefordert wird oder nicht verfügbar ist, lautet die nicht rekursive Antwort wie folgt:

• Ein autorisierender Namensfehler, der angibt, dass der Name nicht vorhanden ist.

• Eine vorübergehende Fehleranzeige.

• Eine Kombination von:

  RRs, die die Frage beantworten, zusammen mit einer Angabe, ob die Daten aus einer Zone stammen oder zwischengespeichert sind.

  Ein Verweis auf Nameserver, deren Zonen näher am Namen liegen als der Server, der die Antwort sendet.

• RRs, die der Nameserver für nützlich hält, erweisen sich für den Anforderer als nützlich.

Die Sprache hier ist ziemlich fest. Es gibt kein "sollte sein", sondern ein "wird sein". Dies bedeutet, dass das Endergebnis entweder 1) in der obigen Liste definiert sein muss oder 2) in einem späteren Dokument auf dem Standards Track berücksichtigt werden muss, das die Funktionalität ändert. Mir ist keine solche Redewendung bekannt, die zum Ignorieren der Anfrage existiert, und ich würde sagen, dass der Entwickler verpflichtet ist, eine Sprache zu finden, die die Forschung widerlegt.

Angesichts der häufigen Rolle von DNS in Netzwerkmissbrauchsszenarien kann nicht gesagt werden, dass die DNS-Serversoftware nicht die Knöpfe zum selektiven Ablegen von Datenverkehr auf dem Boden bietet, was technisch eine Verletzung davon wäre. Dies sind jedoch entweder keine Standardverhaltensweisen oder sehr konservative Standardeinstellungen. Beispiele für beides wären Benutzer, bei denen die Software einen bestimmten Namen löschen muss ( rpz-drop.) oder bestimmte numerische Schwellenwerte überschritten werden (BINDs max-clients-per-query). Nach meiner Erfahrung ist es fast unbekannt, dass die Software das Standardverhalten für alle Pakete in einer Weise vollständig ändert, die gegen den Standard verstößt, es sei denn, die Option erhöht die Toleranz für ältere Produkte, die gegen einen Standard verstoßen. Das ist hier nicht der Fall.

Kurz gesagt, dieser RFC kann und wird nach Ermessen der Bediener verletzt, aber normalerweise erfolgt dies mit einer gewissen Präzision. Es ist äußerst ungewöhnlich, Abschnitte des Standards, wie es zweckmäßig ist, vollständig zu ignorieren, insbesondere wenn der professionelle Konsens (Beispiel: BCP 16 §3.3 ) dahingehend irrt, dass es unerwünscht ist, das DNS-System als Ganzes unnötig zu belasten. Unnötige Versuche, alle Anfragen zu löschen, für die keine maßgeblichen Daten vorliegen, sind in diesem Sinne weniger wünschenswert.

Aktualisieren:

@Alnitak teilte uns mit, dass es derzeit einen BCP-Entwurf gibt , der dieses Thema ausführlich behandelt , da es unerwünscht ist, Anfragen selbstverständlich auf den Boden zu werfen . Es ist etwas verfrüht, dies als Zitat zu verwenden, aber es hilft zu verstärken, dass der Konsens der Gemeinschaft mit dem übereinstimmt, was hier ausgedrückt wird. Im Speziellen:

Sofern ein Nameserver nicht angegriffen wird, sollte er auf alle Anfragen antworten, die aufgrund folgender Delegierungen an ihn gerichtet sind. Außerdem sollte der Code nicht davon ausgehen, dass keine Delegierung an den Server erfolgt, auch wenn er nicht für die Bereitstellung der Zone konfiguriert ist. Unterbrochene Delegierungen treten häufig im DNS auf, und das Empfangen von Abfragen für Zonen, für die der Server nicht konfiguriert ist, ist nicht unbedingt ein Hinweis darauf, dass der Server angegriffen wird. Übergeordnete Zonenbetreiber sollen regelmäßig überprüfen, ob die delegierenden NS-Datensätze mit denen der delegierten Zone übereinstimmen, und sie korrigieren, wenn sie nicht [RFC1034] sind. Wenn dies regelmäßig durchgeführt würde, wären die Fälle von unterbrochenen Delegationen viel geringer.

Diese Antwort wird aktualisiert, wenn sich der Status dieses Dokuments ändert.

Wenn Sie autorisierendes DNS für eine Domain auf einen neuen Anbieter verschieben, sollten Sie immer (immer!) Explizit gegen den neuen Anbieter testen (und sicherstellen, dass er genaue, konfigurierte Datensätze sendet), bevor Sie Ihre Domainregistrierungsinformationen (whois) ändern um auf die neuen autorisierenden DNS-Server zu verweisen.

Ungefähr die Schritte, die Sie unternehmen werden:

1. Richten Sie alles auf dem neuen DNS-Anbieter ein. Sie sollten alle Zonen erstellen und füllen.

2. Stellen Sie sicher, dass die neuen autorisierenden Server ordnungsgemäß funktionieren. Fragen Sie sie explizit ab:

   dig @new-ns.example.com mydomain.com
   

   Wie es sich aus Ihrer Frage anhört, ist, dass sie nicht auf diese Fragen antworten? Sie sagten jedoch "unbekannte Domänen", die zu diesem Zeitpunkt nicht vorhanden sein sollten. Sie sollten vollständig in ihrem System konfiguriert sein (und mit den von Ihnen konfigurierten Datensätzen antworten).

   Wenn Sie die Domäne jedoch bereits in ihrem System konfiguriert haben , muss sie zu diesem Zeitpunkt mit den richtigen Datensätzen antworten. Wenn dies nicht der Fall ist, wird die Zone nicht ordnungsgemäß gehostet, und Sie sollten sie anschreien. Ob es auf eine nicht konfigurierte Domäne reagiert oder nicht, sollte keine Rolle spielen. (Wenn mir immer noch irgendwie fehlt, was Sie sagen, lassen Sie es mich bitte wissen).

3. Wechseln Sie autorisierende Nameserver mit Ihrem Domain-Registrar (whois) und lassen Sie den alten DNS-Anbieter so lange aktiv, bis der Datenverkehr ihn nicht mehr trifft (geben Sie ihm mindestens 24 Stunden Zeit).

Wenn der neue Anbieter die Datensätze vor dem Wechsel absolut nicht ausfüllen kann, spielt es keine Rolle, wie sie reagieren. Wenn Sie Benutzer auf eine Berechtigung verweisen, die die Abfrage vollständig ablehnt, entstehen Ausfallzeiten für Ihre Domain, genau wie bei Ihnen überhaupt keine Antwort bekommen.