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

23

Ich bin dabei, eine Überwachung der DNS-Server mehrerer großer Webhosts einzurichten. Mein Ziel ist es, die Antwortzeiten ihrer DNS-Server zu vergleichen, indem sie ihre Antwort auf Ping verfolgen.

Dabei stellte ich fest, dass Bluehost-Nameserver nicht auf Ping reagieren. Ich habe versucht, durch Ausführen von Pingdom DNS Check auf bluehost.com mehr Informationen zu erhalten. Dabei ist der folgende Fehler aufgetreten :

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

Der Nameserver konnte keine über TCP gesendeten Anfragen beantworten. Dies liegt wahrscheinlich daran, dass der Nameserver nicht richtig eingerichtet ist oder dass die Filterung in einer Firewall falsch konfiguriert ist. Es ist ein weit verbreitetes Missverständnis, dass DNS kein TCP benötigt, es sei denn, es werden Zonentransfers bereitgestellt. Vielleicht ist dem Nameserveradministrator nicht bewusst, dass TCP normalerweise erforderlich ist.

Ich möchte folgendes wissen:

Inwieweit stimmt die obige Aussage?
Was bedeutet es, wenn ein Nameserver keine Anfragen über TCP beantwortet?

domain-name-system nameserver

— Taras Mankovski
quelle

47

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

DNS-Serverimplementierungen sind jetzt "erforderlich" (insofern, als ein RFC etwas erfordert), um TCP gemäß RFC 5966 "DNS-Transport über TCP - Implementierungsanforderungen" zu unterstützen.

Beachten Sie, dass dies eine Voraussetzung für die Implementierung der Serversoftware ist und nicht unbedingt für den Betrieb eines Servers gilt. Die betriebliche Praxis wird nicht behandelt.

Wenn Ihre DNS-Server jedoch nicht für die Unterstützung von TCP konfiguriert oder blockiert sind, kann DNSSEC auf längere Sicht nicht ordnungsgemäß unterstützt werden. Ebenso können alle anderen DNS-Daten blockiert werden, die dazu führen, dass die Antworten 512 Byte überschreiten.

Haftungsausschluss: Ich habe diesen RFC geschrieben.

EDIT RFC 5966 wurde nun durch RFC 7766 ersetzt

— Alnitak
quelle

RE: die betriebliche Praxis, einer, der hasst DNSSEC konnte einfach deaktivieren TCP und legen Sie es an der Firewall für eine gute Maßnahme. Es überrascht nicht, dass es Konsequenzen gibt. Keine Unterstützung für EDNS0 an zwei Endpunkten kann die Geräte zwingen, in irgendeiner Weise nicht zu interferieren. (Fragmentierung, falsches Markieren durch alte Firewalls usw.) Wenn Sie große DNS-Einträge auf Ihrem Authentifizierungsserver haben (aufgeblähtes TXT), ist TCP erforderlich, wenn Sie einen Teil Ihrer Zielgruppe nicht ausschließen möchten. Ebenso werden Sie durch das Deaktivieren auf einem rekursiven Server von DNS-Antworten isoliert, die Ihr E-Mail-Cluster möglicherweise zur Behandlung von Spam benötigt.

— Andrew B

3

es sollte TCP und UDP unterstützen - das TCP ist für Antwortgrößen> 512 Bytes (einschließlich Zonenübertragungen) (je nachdem, was ich sowieso gelesen habe. Ich aktiviere normalerweise TCP und UDP für die NS, die ich ausführe ...)

— Mark Regensberg
quelle

-2

Es ist gut zu wissen, was die RFCs zu diesem Thema sagen, und wir haben bereits eine gute maßgebliche Antwort darauf, aber aus praktischen Gründen 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-Abfragen 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 Datensätze veröffentlichen, die größer als 512 Byte sind. (Dies ist fast immer ein Fehler.)

Sie möchten ausgehende Zonenübertragungen zulassen, z. B. an einen Drittanbieter-Server.

Ein übergeordneter Server lehnt es ab, einen Namen an Sie zu delegieren, bis Sie den TCP-Dienst eingerichtet haben.

Wenn Sie sich in keiner dieser Situationen befinden, müssen Sie keinen TCP-Dienst bereitstellen und sollten ihn nicht einrichten. DNS-over-TCP ist viel langsamer als DNS-over-UDP und von Natur aus 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, dass DNSSEC laut DJB in die Kategorie "Immer ein Fehler" fällt. Weitere Informationen finden Sie unter https://cr.yp.to/djbdns/forgery.html . DJB hat einen alternativen Standard namens DNSCurve - http://dnscurve.org/ - der bereits von einigen Anbietern (wie OpenDNS) unabhängig übernommen wurde. Von Interesse: /security/45770/if-dnssec-is-so-questable-why-is-it-ahead-of-dnscurve-in-adoption .

Beachten Sie, dass die obige Dokumentation zum DJBDNS-Setup nur AXFR für TCP unterstützt. Da viele Anbieter immer noch DJBDNS verwenden, ist es unwahrscheinlich, dass sie DNS über TCP ohne zusätzlichen Aufwand unterstützen.

PS: DJB übt tatsächlich, was er predigt. Seine eigenen Server (1) führen DNSCurve aus (2) und beantworten TCP nicht richtig. Nur die +notcpwürde erfolgreich sein (was Standard ist):

% 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 +tcpfehlschlagen würde (anscheinend mit einer anderen Fehlermeldung, je nachdem 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

— cnst
quelle

2

Dein DJB-Fanboi-Act wird ziemlich langweilig. Die DNS-Community hat sich für DNSSEC entschieden, und ein Großteil der Literatur zu DNSCurve widerspricht vollständig den orthogonalen Anforderungen an die Authentizität der Daten und die Verschlüsselung der Daten . IMNSHO, der Großteil Ihrer Antwort trägt nichts zu dieser Frage bei.

— Alnitak

@Alnitak, Ihre Beharrlichkeit, dass TCP für DNS erforderlich ist, macht es nicht zu einer tatsächlichen Anforderung für DNS. Es ist klar, dass viele Leute ohne TCP arbeiten und keine Probleme mit der Verfügbarkeit ihrer eigenen Websites haben. Dennoch fördern Sie weiterhin Fehlinformationen und FUD.

— 13.

2

Ist das Dokument wirklich aus dem Jahr 2003? Wie kann man mit einem klaren Gesicht behaupten, dass es auch 2017 noch relevant ist?

— Michael Hampton

1

@ MichaelHampton, ja, von ganzem Herzen und absolut. Einige Dinge ändern sich nicht und DJB ist vielleicht ein Arschloch, aber er ist ziemlich schlau. Alle Argumente, die er vorbringt, sind philosophischer Natur und ändern sich nicht wie die Technologie. In der Zwischenzeit, (1), warum ist es so schwer zu glauben, (2), warum wird eine Verknüpfung zu noch älteren RFCs hergestellt, und ohne dass Sie ein Heuchler sind, (3), welche tatsächlichen Gegenargumente haben Sie anders als ein Treffen"? Die Leute sagen immer wieder, dass sein Weg Interoperabilitätsprobleme hat, aber die Argumente, die vorgebracht werden (z. B. zurückgeworfene Post), hat er bereits 2003 entlarvt!

— 16.

-5

TCP ist nur erforderlich und wird normalerweise nur verwendet, wenn eine lange Antwort erforderlich ist. Es kann negative Auswirkungen geben. Zonentransfers erfolgen über TCP, da sie umfangreich sind und zuverlässig sein müssen. Das Nichtzulassen von TCP von nicht vertrauenswürdigen Servern ist eine Möglichkeit, um sicherzustellen, dass nur kleine Antworten gegeben werden.

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

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

Es gibt einen neueren RFC596 , der jetzt TCP für eine vollständige DNS-Implementierung benötigt. Dies richtet sich an Implementierer. Die Dokumente richten sich speziell nicht an Bediener, warnen jedoch, dass das Nichtzulassen von TCP zu einer Reihe von Fehlerszenarien führen kann. Es werden eine Vielzahl von Fehlern beschrieben, 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, die Verteilung ist jedoch schwieriger.

— BillThor
quelle

DNSSEC hat das Limit 1999 nicht gelockert, EDNS0 schon (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 erhalten, was Sie normalerweise nicht im Voraus wissen)

— bortzmeyer

Ich habe DNS erfolgreich über eine Firewall ausgeführt, die nur UDP zulässt. Abgesehen von pathalogischen Konfigurationen dürfen Adressensuchen nicht länger als 512 Zeichen sein. Ich habe Hinweise gesehen, dass DNS-Pfade auf 256 Zeichen begrenzt sind. Beweise in der Datenbank für meinen Mailserver deuten darauf hin, dass die DNS-Pfade des Servers selten mehr als 100 Zeichen umfassen und Websites, die mehrere von einem PTR-Datensatz zurückgegebene Namen aufweisen, selten mehr als 256 Zeichen enthalten. Alle diese Antworten würden auf UDP ausgeführt. Hat jemand einen vernünftigen Fall, der in der Nähe von 512 Zeichen ohne DNSSEC oder eine Zonenübertragung ausgeführt wird.

— BillThor

Bezüglich DNSSEC habe ich RFC nicht auf erweiterte Größen überprüft, aber die einzigen Referenzen, die ich zur Verwendung erweiterter Paketgrößen unter UDP gesehen habe, sind DSNSEC.

— BillThor

Einer der großen Content-Anbieter kam vor einigen Jahren aus dem Ruder, als er so viele A-Datensätze für eine seiner Webfarms hinzufügte, dass 512 Byte überschritten wurden. Das verursachte echte Interop-Probleme.

— Alnitak