Frage Stimmt es, dass ein Nameserver Anfragen über TCP beantworten muss?


Ich bin dabei, eine Überwachung von DNS-Servern mehrerer großer Web-Hosts einzurichten. Mein Ziel ist es, die Antwortzeiten ihrer DNS-Server zu vergleichen, indem ihre Antwort auf Ping verfolgt wird.

Dabei habe ich festgestellt, dass Bluehost Nameserver nicht auf Ping reagieren. Ich habe versucht, mehr Informationen zu bekommen, indem ich rannte Pingdom DNS Überprüfen Sie auf bluehost.com und es erzeugte den folgenden Fehler:

Der Nameserver ns1.bluehost.com (74.220.195.31) beantwortet keine Abfragen über TCP.

Der Nameserver konnte keine über TCP gesendeten Abfragen beantworten. Dies ist wahrscheinlich darauf zurückzuführen, dass der Name-Server nicht korrekt eingerichtet wurde oder weil in einer Firewall nicht ordnungsgemäß gefiltert wurde. Es ist ein weit verbreiteter Irrtum, dass DNS TCP nur dann benötigt, wenn es Zonentransfers gibt - vielleicht weiß der Nameserveradministrator nicht, dass TCP normalerweise eine Voraussetzung ist.

Ich würde gerne folgendes wissen:

  • In welchem ​​Umfang ist die obige Aussage wahr?
  • Was sind die Auswirkungen von a Nameserver antwortet nicht auf Anfragen TCP?

21
2017-09-16 18:57


Ursprung




Antworten:


Der Diagnosetext von Pingdom ist genau richtig. TCP ist nicht nur für Zonentransfers.

DNS-Serverimplementierungen sind jetzt "erforderlich" (insofern RFC irgendwas benötigt) um TCP zu unterstützen, per RFC 5966, "DNS-Transport über TCP - Implementierungsanforderungen".

Beachten Sie, dass dies bei der Implementierung der Serversoftware erforderlich ist nicht strikt gelten für den Betrieb eines Servers - Betriebspraxis ist nicht abgedeckt.

Das heißt, wenn Ihre bestimmten DNS-Server nicht zur Unterstützung von TCP konfiguriert sind oder wenn sie blockiert sind, ist der langfristige Effekt, dass DNSSEC nicht korrekt unterstützt wird. Ähnlich können alle anderen DNS-Daten blockiert werden, die dazu führen, dass Antworten 512 Byte überschreiten.

Ob Disclaimer: Ich habe diesen RFC geschrieben.

BEARBEITEN RFC 5966 wurde jetzt durch ersetzt RFC 7766


43
2017-09-17 07:56



RE: Betriebspraxis, jemand, der DNSSEC hasst könnte Deaktivieren Sie einfach TCP und legen Sie es an der Firewall ab. Es ist nicht überraschend, dass es Konsequenzen gibt. Keine Unterstützung für EDNS0 an zwei Endpunkten kann dazu führen, dass die Geräte zwischen ihnen auf irgendeine Weise nicht stören. (Fragmentierung, falsche Markierung durch alte Firewalls usw.) Wenn Sie große DNS-Einträge auf Ihrem Authentifizierungsserver haben (aufgeblähtes TXT), wird TCP benötigt, wenn Sie ein Segment Ihrer Zielgruppe nicht ausschließen möchten. Wenn Sie sie auf einem rekursiven Server deaktivieren, werden Sie ebenfalls von DNS-Antworten isoliert, die Ihr Mail-Cluster möglicherweise zum Behandeln von Spam benötigt. - Andrew B


Es sollte TCP und UDP unterstützen - das TCP ist für Antworten Größen> 512 Bytes (was Zonentransfers beinhalten würde) (entsprechend Sachen, die ich gelesen habe, sowieso. Ich aktiviere normalerweise TCP und UDP für die NS, die ich laufe ...)


3
2017-09-16 19:08





Es ist gut zu wissen, was die RFCs zu dem Thema sagen, und wir haben bereits eine gute autoritative Antwort darauf, aber für praktische Zwecke finde ich den Rat von Prof. Daniel J. Bernstein, PhD, dem Autor von DJBDNS, ziemlich unterhaltsam.

http://cr.yp.to/djbdns/tcp.html#why (2003-01-16)

Wann werden TCP-Anfragen gesendet?

Wenn Sie sich in einer der folgenden Situationen befinden, müssen Sie Ihren DNS-Server so konfigurieren, dass er TCP-Abfragen beantwortet:

  • Sie möchten Datensatzgruppen veröffentlichen, die größer als 512 Byte sind. (Dies ist fast immer ein Fehler.)
  • Sie möchten zonenüberschreitende Zonentransfers zulassen, z. B. an einen Drittanbieterserver.
  • Ein übergeordneter Server verweigert die Zuweisung eines Namens an Sie, bis Sie den TCP-Dienst eingerichtet haben.

Wenn Sie sich in keiner dieser Situationen befinden, müssen Sie den TCP-Dienst nicht bereitstellen, und Sie sollten ihn nicht einrichten. DNS-over-TCP ist wesentlich langsamer als DNS-over-UDP und ist daher wesentlich anfälliger für Denial-of-Service-Angriffe. (Dies gilt auch für BIND.)

Beachten Sie, dass er eine explizite Erwähnung von DNSSEC auslässt; Der Grund dafür ist laut DJB, DNSSEC fällt unter die Kategorie "immer ein Fehler". Sehen https://cr.yp.to/djbdns/forgery.html für mehr Details. DJB hat einen alternativen Standard namens DNSCurve - http://dnscurve.org/ - die bereits von einigen Anbietern (wie OpenDNS) selbständig übernommen wurde. Von Interesse: https://security.stackexchange.com/questions/45770/if-dnssec-is-so-questionable-why-is-it-ahead-of-dnscurve-in-adoption.

Beachten Sie, dass, wenn die obige Dokumentation zu DJBDNS-Setup einen Hinweis auf seine Funktionen enthält, es anscheinend nur AXFR für TCP unterstützt. Da viele Anbieter immer noch DJBDNS verwenden, würden sie DNS ohne TCP nicht ohne zusätzlichen Aufwand unterstützen.

P.S. Beachten Sie, dass DJB tatsächlich das tut, was er predigt. Seine eigenen Server, (1), führen DNSCurve, (2), TCP nicht richtig beantworten. Nur der +notcp würde gelingen (das ist Standard):

% dig +trace @ordns.he.net +notcp cr.yp.to | tail
yp.to.                  86400   IN      NS      uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to.
yp.to.                  86400   IN      NS      uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to.
;; Received 300 bytes from 216.74.32.100#53(tonic.to) in 151 ms

cr.yp.to.               600     IN      A       131.155.70.11
cr.yp.to.               600     IN      A       131.155.70.13
yp.to.                  3600    IN      NS      uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to.
yp.to.                  3600    IN      NS      uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.yp.to.
;; Received 244 bytes from 131.155.70.13#53(uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to) in 14 ms

, während a +tcp würde fehlschlagen (anscheinend mit einer anderen Fehlermeldung, abhängig davon, welcher seiner Server ausgewählt wird):

% dig +trace @ordns.he.net +tcp cr.yp.to | tail
yp.to.                  86400   IN      NS      uz5hjgptn63q5qlch6xlrw63tf6vhvvu6mjwn0s31buw1lhmlk14kd.ns.yp.to.
;; Received 300 bytes from 216.74.32.100#53(tonic.to) in 150 ms

;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.155.70.13#53: end of file
;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.155.70.13#53: end of file
;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.193.32.147#53: end of file
;; connection timed out; no servers could be reached

-3
2018-01-12 20:47



Dein DJB Fanboi Act wird eher getragen. Die DNS-Gemeinschaft hat sich für DNSSEC entschieden, und ein großer Teil der Literatur über DNSCurve vereinheitlicht die senkrecht Anforderungen von Authentizität der Daten und Verschlüsselung der Daten. IMNSHO, trägt der Großteil Ihrer Antwort bei nichts auf diese Frage. - Alnitak
@ Alnitak, Ihre Beharrlichkeit, dass TCP für DNS erforderlich ist, macht es nicht zu einer tatsächlichen Anforderung für DNS. Viele Leute laufen ohne TCP und haben keine Probleme mit der Verfügbarkeit ihrer eigenen Websites. Dennoch fördern Sie weiterhin Fehlinformationen und FUD. - cnst
Ist das Dokument wirklich von 2003? Wie können Sie mit einem klaren Gesicht behaupten, dass es 2017 noch relevant ist? - Michael Hampton♦
@MichaelHampton, ja, von ganzem Herzen und absolut. Manche Dinge ändern sich nicht, und DJB mag ein Arschloch sein, aber er ist ziemlich schlau. Alle Argumente, die er präsentiert, sind philosophischer Natur und ändern sich nicht so wie die Technologie. Inzwischen, (1), warum ist es so schwer zu glauben, (2), warum ist die Verbindung zu noch älteren RFCs mit einem geraden Gesicht gemacht, und ohne dass du ein Heuchler bist, (3), welche tatsächlichen Gegenargumente hast du außer ein Treffen"? Die Leute sagen immer wieder, dass es Interoperabilitätsprobleme auf seinem Weg gibt, doch gerade die Argumente, die vorgeschlagen wurden (z. B. Bounce Mail), entlarvte er schon 2003! - cnst


TCP wird nur benötigt und normalerweise nur verwendet, wenn eine lange Antwort erforderlich ist. Es kann negative Auswirkungen haben. Zonenübertragungen erfolgen über TCP, da sie groß sind und zuverlässig sein müssen. TCP nicht von nicht vertrauenswürdigen Servern zuzulassen ist eine Möglichkeit sicherzustellen, dass nur kleine Antworten gegeben werden.

Mit der Einführung von unterschriebenen DNS-Antworten war eine Lockerung der 512-Byte-Grenze für UPD-Antworten erforderlich. EDNS0 bietet den Mechanismus für längere UDP-Antworten. Wenn DNS nicht über TCP zugelassen wird, wird höchstwahrscheinlich eine sichere DNS-Implementierung beschädigt.

Es ist durchaus möglich, einen DNS-Server zu betreiben, der nur den UDP-Port 53 für das Internet geöffnet hat. TCP-Zugriff auf DNS-Peers ist erforderlich, aber dies ist eine kleine Liste von Hosts.

Es gibt ein neueres RFC596 Das erfordert jetzt TCP für eine vollständige DNS-Implementierung. Dies richtet sich an Implementoren. Die Dokumente adressieren insbesondere keine Operatoren, warnen jedoch davor, dass das Nicht-Erlauben von TCP zu einer Anzahl von Fehlerszenarien führen kann. Es beschreibt eine Vielzahl von Fehlern, die auftreten können, wenn DNS über TCP nicht unterstützt wird.

Es gab Diskussionen über die Verwendung von TCP zur Verhinderung von DNS-Amplifikationsangriffen. TCP hat seine eigenen Denial-of-Service-Risiken, aber die Verteilung ist schwieriger.


-5
2017-09-17 04:41



DNSSEC hat das Limit nicht gelockert, EDNS0 hat es 1999 getan (siehe RFC 2671). - Alnitak
Nein, wie von Alnitak erklärt, ist TCP in den meisten Fällen erforderlich (es sei denn, Sie können absolut sicher sein, dass Sie niemals eine Antwort> 512 Bytes haben werden, etwas, das Sie normalerweise nicht im Voraus wissen) - bortzmeyer
Ich habe DNS erfolgreich durch eine Firewall laufen lassen, die nur UDP erlaubt. Wenn keine pathalogischen Konfigurationen vorgenommen werden, liegt die Adresssuche unter 512 Zeichen. Ich habe Referenzen gesehen, dass DNS-Pfade auf 256 Zeichen begrenzt sind. Hinweise in der Datenbank für meinen Mail-Server deuten darauf hin, dass Server-DNS-Pfade selten 100 Zeichen überschreiten und Websites mit mehreren Namen, die von einem PTR-Datensatz zurückgegeben werden, selten mehr als 256 Zeichen zurückgeben. Alle diese Antworten würden auf UDP laufen. Hat jemand einen vernünftigen Fall, der fast 512 Zeichen ohne DNSSEC oder eine Zonenübertragung ausführt? - BillThor
Zu DNSSEC, ich habe RFC für erweiterte Größen nicht überprüft, aber die einzigen Referenzen, die ich gesehen habe, um erweiterte Paketgrößen auf UDP zu verwenden, haben DSNSEC. - BillThor
Einer der großen Content-Provider kam vor ein paar Jahren zum Absturz, als sie so viele A-Records für einen ihrer Webfarmen hinzufügten, dass sie 512 Byte überschritten. Das hat echte Interop-Probleme verursacht. - Alnitak