Gehen DNS-Abfragen immer über UDP?


33

Ich habe einige Zeit damit verbracht, mich mit diesem Thema zu befassen, und kann anscheinend keine genaue Antwort finden. Daher bin ich ziemlich sicher, dass es sich nicht um ein Duplikat handelt, und obwohl meine Frage auf einem Sicherheitsbedürfnis basiert, denke ich, dass es immer noch sicher ist Fragen Sie hier, aber lassen Sie es mich wissen, wenn ich die Sicherheitsgemeinschaft bewegen muss.

Verwenden DNS-Abfragen im Wesentlichen jemals TCP (wenn ja, in welchem ​​Szenario könnte dies auftreten)? Wieder spreche ich nur über Fragen. Können sie über TCP reisen? Wenn Domains nur maximal 253 Bytes lang sind und UDP-Pakete bis zu 512 Bytes lang sind, werden Abfragen dann nicht immer als UDP ausgeführt? Ich dachte nicht, dass eine auflösbare Abfrage groß genug sein könnte, um die Verwendung von TCP zu erfordern. Wenn ein DNS-Server jemals eine Anfrage für eine Domain mit mehr als 253 Bytes erhalten hat, würde der Server diese löschen / nicht versuchen, sie aufzulösen? Ich bin mir sicher, dass ich hier einige falsche Annahmen getroffen habe.

In einigen Fällen arbeite ich mit der Sicherheitsgruppe zusammen, um DNS-Abfragen in ihr Sicherheitsüberwachungstool zu integrieren. Aus verschiedenen Gründen haben wir beschlossen, diesen Datenverkehr über die Standard-Paketerfassung auf DNS-Servern und Domänencontrollern zu erfassen. Die Hauptanforderung besteht darin, alle DNS-Abfragen zu erfassen, damit festgestellt werden kann, welcher Client versucht hat, eine bestimmte Domäne aufzulösen. Basierend auf dieser Anforderung geht es uns nicht darum, DNS-Antworten oder andere verkehrsähnliche Zonentransfers zu erfassen, was auch darauf zurückzuführen ist, dass wir das Protokollvolumen so weit wie möglich begrenzen müssen. Daher planen wir, nur DNS-Abfragen zu erfassen, die für den DNS-Server bestimmt sind und über UDP gesendet werden. Für mehr Kontext (eine Art von Fragenspektrum, das sich hier einschleicht) wurde jetzt die Frage aufgeworfen, ob wir die Sicherheit erweitern müssen. ' s Sichtbarkeit, damit sie Aktivitäten wie verdeckte Kanäle überwachen können, die über DNS ausgeführt werden (was die Erfassung von DNS-Antworten und anschließendem TCP-Verkehr erforderlich machen würde). Aber selbst in einem solchen Szenario dachte ich, dass jeder ausgehende DNS-Verkehr in Form von Suchanfragen erfolgt und dass diese immer über UDP erfolgen, auch wenn sie von einer böswilligen Quelle stammen (aufgrund meiner Überlegungen im ersten Absatz). Das wirft also einige zusätzliche Fragen auf:

  • Würden wir nicht mindestens die Hälfte des Gesprächs mit dem von mir skizzierten Ansatz aufzeichnen? Oder würde ein Client jemals DNS-Datenverkehr senden, der nicht in Form einer Abfrage vorliegt? (Vielleicht wie eine Art Antwort auf die Antwort eines DNS-Servers, und am Ende geht es vielleicht über TCP aus)

  • Können DNS-Abfragen für die Verwendung von TCP geändert werden? Würde ein DNS-Server eine über TCP eingehende DNS-Abfrage akzeptieren und darauf antworten?

Ich bin mir nicht sicher, ob dies relevant ist, aber wir beschränken DNS-Anfragen auf autorisierte DNS-Server und blockieren den gesamten ausgehenden Datenverkehr über Port 53. Ich bin definitiv ein Anfänger. Es tut mir leid, wenn meine Frage nicht konform ist, und lassen Sie es mich wissen wie soll ich das modifizieren.


2
Paging @Alnitak, wir besprechen Ihr Baby. :)
Andrew B

Wie kann ich erzwingen, dass die Standard-DNS-Abfrage im TCP-Modus funktioniert? . Obwohl ein OS X / macOS q / a mit einigen Mods, funktioniert es auch für Linux / Windows.
Klanomath

Natürlich heutzutage mit DNS über HTTPS und DNS über TLS und bald DNS über QUIC ...
Patrick Mevzek

Warum leiten Sie nicht alle DNS-Anfragen an einen oder mehrere DNS-Server Ihrer Wahl weiter?
Craig Hicks

Antworten:


38

Normale DNS-Abfragen verwenden UDP-Port 53, aber längere Abfragen (> 512 Oktette) erhalten eine "abgeschnittene" Antwort, die zu einer TCP-53-Konversation führt, um das Senden / Empfangen der gesamten Abfrage zu erleichtern. Der DNS-Server stellt auch eine Verbindung zu Port 53 her, die Abfrage selbst stammt jedoch von einem zufälligen Port mit hoher Nummer (49152 oder höher), der an Port 53 gesendet wurde. Die Antwort wird von Port 53 an denselben Port zurückgesendet.

Von DNS verwendete Netzwerkports | Microsoft Docs

Wenn Sie also vorhaben, DNS-Abfragen aus Ihrem Netzwerk zu überprüfen, müssen Sie die oben genannten Punkte berücksichtigen.

Beachten Sie, dass DNS bei Nicht-Lookup-Datenverkehr auch Zonenübertragungen (Abfragetyp AXFR) verwendet, um andere DNS-Server mit neuen Einträgen zu aktualisieren. Ein Mann in der Mitte des Angriffs kann mit einer solchen Übertragung beginnen, indem er einen primären Nameserver unter DDOS setzt, sodass er zu beschäftigt ist, um auf eine sekundäre Anforderung nach aktualisierten Datensätzen zu antworten. Der Hacker fälscht dann dieselbe Primärdatenbank, um "vergiftete" Datensätze an die Sekundärdatenbank weiterzuleiten, die beliebte DNS-Domänen an gefährdete Hosts umleiten.

Daher sollte bei Ihrer Sicherheitsüberprüfung der Abfragetyp AXFR besonders berücksichtigt werden, und Ihre DNS-Systeme sollten nur AXFR-Austausche von bestimmten IP-Adressen akzeptieren.

SANS Institute InfoSec Lesesaal | sans.org


1
Danke George, wirklich hilfreiches Zeug! Um also schnell Ihren ersten Satz zu klären - ein UDP-Paket kann nur 512 Bytes aufnehmen, oder? Wenn eine DNS-Abfrage größer als 512 wäre, würde sie dann nicht direkt über TCP gestartet? Ich habe versucht, dies selbst zu testen, indem ich wireshark ausgeführt habe und nslookup zum Auflösen großer Domänen verwendet habe, aber es scheint mich daran zu hindern, Domänen mit mehr als 200 Zeichen auszuprobieren (nicht die genaue Zahl, aber der Punkt ist, dass ich dieses Szenario nicht vollständig testen konnte). .
Caderade

3
Es ist nicht die "Abfrage", sondern die "Antwort", die mehr als 512 Bytes betragen würde und der Client würde nicht wissen, wie die "Antwort" lauten würde.
AbraCadaver

7
@Caderade Ja, Sie haben Recht, dass es sich um TCP oder UDP handeln kann. Es werden jedoch nur Zonenübertragungen als TCP gestartet. Client-Abfragen sind UDP, es sei denn, sie erhalten eine Antwort vom Server, auf dem das Kürzungsbit gesetzt ist. Dann kann man dann TCP nutzen.
AbraCadaver

1
Können Clients TCP trotzdem für kleine Antworten verwenden?
Mehrdad

2
"Ein UDP-Paket kann nur 512 Bytes aufnehmen" Nein, es wird davon ausgegangen, dass der Puffer des Clients nur 512 Bytes aufnehmen kann, was dazu führt, dass sich Server so verhalten. Server können mithilfe von EDNS über einen längeren Puffer benachrichtigt werden.
Bryan

28

Dies begann als Kommentar zu Georges Antwort, aber es dauerte lange. Das Gesamtbild ist etwas kompliziert, da man etwas Geschichte verstehen muss.

  • RFC 1035 forderte ursprünglich ein Limit von 512 Bytes, um eine UDP-Fragmentierung zu vermeiden. Fragmentierte UDP-Datagramme und TCP wurden als letzte Option ausgewählt, um den Aufwand für DNS-Transaktionen zu minimieren. Zonentransfers verwenden immer TCP, da Zonentransfers von Natur aus mehr als 512 Byte beanspruchen. (Es wäre eine Verschwendung von Bandbreite, überhaupt mit UDP zu beginnen.)

  • TCP-Wiederholungsversuche beim Abschneiden werden weitgehend unterstützt, da sie seit 1989 in RFC 1123 angegeben sind .

  • EDNS (0) ist in RFC 6891 (2013) definiert und existierte zuvor als vorgeschlagener Standard aus dem Jahr 1999 . Es definiert einen Mechanismus, mit dem Clients und Server UDP-Größen größer als 512 aushandeln können. Aufgrund der Neuheit von EDNS (0) treffen viele Hardware-Appliances Annahmen über die Struktur von DNS-Paketen, die dazu führen, dass kompatible Pakete verworfen werden. Der häufigste Grund ist die Annahme, dass DNS-Nachrichten mit mehr als 512 Byte ungültig sind, aber dies ist eine von mehreren.

Wenn wir das in die beobachteten Verhaltensweisen aufteilen:

  1. DNS-Abfragen werden normalerweise als UDP gestartet, es sei denn, es ist im Voraus bekannt, dass die Antwort zu groß ist. (Zonentransfers)
  2. Die Antwort kann einen TCP-Neuversuch im Client auslösen, wenn eine abgeschnittene Antwort angezeigt wird. Dies wird ziemlich gut unterstützt.
  3. Eine UDP-Antwort mit mehr als 512 Bytes kann angezeigt werden, wenn der Client EDNS (0) verwendet hat, um eine größere Nutzlast anzukündigen, und der empfangende Server dies unterstützt. Dies ist nur dann der Fall, wenn sich die zwischen den beiden Geräten befindliche Hardware nicht gegenseitig stört und zu einem verworfenen oder entstellten Paket führt.
  4. Der Client kann sich dafür entscheiden, eine EDNS (0) -Anfrage mit einer kleineren angekündigten Nutzlast erneut zu versuchen, wenn keine Antwort angezeigt wird. Die Einzelheiten variieren jedoch zwischen den Implementierungen.
    • Es ist wichtig zu beachten, dass die Antwort, die es schließlich schafft, zu groß sein kann, um in die angeforderte Größe zu passen, was zu dem obigen Verhalten Nr. 2 führt. (Ihr alter TCP-Wiederholungsversuch)
    • Die Client-Seite kann sich die Größe merken, die letztendlich zu einem Erfolg geführt hat. Auf diese Weise wird vermieden, dass unnötige Abfragen erneut ausgeführt werden. Andernfalls wäre es ziemlich verschwenderisch, wenn das Endergebnis ein TCP-Fallback erfordert.

Sie sollten auch bedenken, dass RFC 7766 die Wiederverwendung von Verbindungen über TCP ermöglicht und dass Query Pipelining über TCP in der Natur auftreten kann. Einige Tools erkennen keine DNS-Abfragen, die über die ersten in einer TCP-Sitzung festgestellten hinausgehen. Ein Beispiel hierfür ist dnscap.


Einer der Gründe für das Setzen von Kürzungsbits ist die Begrenzung der Antwortrate (RRL). Als Verfahren zur DNS-Amplifikationsreduzierung kann der Server abgeschnittene Pakete senden, um gut funktionierende Clients dazu zu bringen, zu TCP zu wechseln, und hoffentlich Antworten auf Pakete von gefälschten Adressen zu verhindern.
Edheldil

Verbindungswiederverwendung: Bringen Sie Ihrem Resolver also bei, zuerst nach google.com zu fragen, bevor er nach scantycladladies.com fragt. Dann bemerkt dnscap nichts. ;-)
Lenne

6

Es gibt RFC 7766, DNS-Transport über TCP - Implementierungsanforderungen .

  1. Einführung

Die meisten DNS- Transaktionen [ RFC1034 ] finden über UDP [ RFC768 ] statt. TCP [ RFC793 ] wird immer für vollständige Zonenübertragungen (unter Verwendung von AXFR) verwendet und wird häufig für Nachrichten verwendet, deren Größe das ursprüngliche 512-Byte-Limit des DNS-Protokolls überschreitet. Die zunehmende Bereitstellung von DNS-Sicherheit (DNSSEC) und IPv6 hat die Antwortgröße und damit die Verwendung von TCP erhöht. Der Bedarf an verstärkter TCP-Nutzung wurde auch durch den Schutz vor Adressspoofing und damit der Ausbeutung von DNS bei Reflection / Amplification-Angriffen getrieben. Es wird jetzt häufig bei der Begrenzung der Rücklaufquote [ RRL1 ] [ RRL2 ] verwendet. Darüber hinaus wurden kürzlich Arbeiten zu DNS-Datenschutzlösungen wie [ DNS-over-TLS] ist eine weitere Motivation, die DNS-over-TCP-Anforderungen zu überdenken.

In Abschnitt 6.1.3.2 von [RFC1123] heißt es:

  DNS resolvers and recursive servers MUST support UDP, and SHOULD
  support TCP, for sending (non-zone-transfer) queries.

Einige Implementierer haben den oben zitierten Text jedoch so verstanden, dass die TCP-Unterstützung eine optionale Funktion des DNS-Protokolls ist.

Die Mehrheit der DNS-Server-Betreiber unterstützt bereits TCP, und die Standardkonfiguration für die meisten Software-Implementierungen ist die Unterstützung von TCP. Dieses Dokument richtet sich in erster Linie an Implementierer, deren eingeschränkte Unterstützung für TCP die Interoperabilität einschränkt und die Bereitstellung neuer DNS-Funktionen behindert.

In diesem Dokument werden daher die Kernspezifikationen des DNS-Protokolls aktualisiert, sodass die Unterstützung von TCP künftig ein ERFORDERLICHER Bestandteil einer vollständigen Implementierung des DNS-Protokolls ist.

Die zunehmende Verwendung von TCP (siehe Anhang A ) sowie die zu berücksichtigenden Implementierungsdetails haben verschiedene Vor- und Nachteile . In diesem Dokument werden diese Probleme behoben und TCP als gültige Transportalternative für DNS vorgestellt. Es erweitert den Inhalt von [ RFC5966 ] um zusätzliche Überlegungen und Erkenntnisse aus der Forschung, Entwicklung und Implementierung von TCP in DNS und anderen Internetprotokollen.

In diesem Dokument werden zwar keine besonderen Anforderungen an die Betreiber von DNS-Servern gestellt, den Betreibern werden jedoch einige Vorschläge unterbreitet, um sicherzustellen, dass TCP auf ihren Servern und im Netzwerk optimal unterstützt wird. Es ist zu beachten, dass die Nichtunterstützung von TCP (oder das Blockieren von DNS über TCP auf Netzwerkebene) wahrscheinlich zu einem Auflösungsfehler und / oder zu Timeouts auf Anwendungsebene führt.


2
Hey Ron, ich habe diesen RFC tatsächlich vor dem Posten gelesen, aber wenn Sie zum Beispiel in den ersten Absatz schauen, scheint es zu betonen, dass TCP zur Unterstützung größerer Antworten erforderlich ist - "Die zunehmende Bereitstellung von DNS-Sicherheit (DNSSEC) und IPv6 hat die Antwortgröße und damit die Verwendung von TCP erhöht ". Wieder ging es bei meiner Frage um Fragen, aber trotzdem danke.
Caderade

4
Der RFC macht absolut klar, dass TCP für DNS unterstützt werden muss, und erläutert die Verwendung von TCP durch Clients. Beispiel: " Clients, die TCP für DNS verwenden, müssen immer darauf vorbereitet sein, Verbindungen wiederherzustellen oder auf andere Weise ausstehende Abfragen erneut zu versuchen. "
Ron Maupin,

Guter Punkt. Ich würde sagen, dass dieser Kommentar angesichts der zusätzlichen Klarheit tatsächlich hilfreich war. Mein Punkt ist, dass ich den RFC tatsächlich gelesen habe und mir immer noch nicht klar war, dass Abfragen mit TCP beginnen können. Wenn Sie also einfach den RFC für eine Antwort ausgeben, ist dies, obwohl es komisch ist, nicht wirklich hilfreich. Es liest sich für mich so, als ob Abfragen über UDP gehen und wenn die Antwort zu groß ist, würde der DNS-Server dem Client mitteilen, dass er dies erneut starten und über TCP ausführen muss. Also dachte ich, ich würde meine ursprüngliche Anforderung immer noch erfüllen, weil ich die ursprüngliche Anforderung erfasst hätte. Ungeachtet dessen schätze ich Ihre Eingabe.
Caderade

1
Der INTERNET STANDARDRFC lautet tools.ietf.org/html/rfc1034 . Sie zitieren a PROPOSED STANDARD, um TCP zu benötigen.
AbraCadaver

3
Dies ist ein Standard-Track-RFC, der einen früheren Standard-Track-RFC in etwa auf den neuesten Stand gebracht hat. Diese Antwort hier auf Serverfehler erklärt solche Dinge. Sogar in dem Dokument, auf das Sie verweisen, heißt es: " Im Internet werden Abfragen in UDP-Datagrammen oder über TCP-Verbindungen ausgeführt. " RFC 7766 soll klarstellen, dass TCP ein erforderlicher und kein optionaler Bestandteil von DNS ist.
Ron Maupin

3

Sie sollten TCP / 53 in keine Richtung filtern. Beispielsweise können nsupdateAbfragen TCP verwenden, sobald die Anforderung zu groß ist (was schnell passieren kann). Daher sollten Sie UDP und TCP für Port 53 (in IPv4 und V6!) In alle Richtungen fließen lassen.

Außerdem wird immer mehr an DNS über TLS gearbeitet, sodass TCP in beide Richtungen benötigt wird. Siehe RFC7858.


Frage hat nichts mit Filtern zu tun, und Ihre Antwort fügt nichts über die anderen Antworten
Bryan

@Bryan danke für deinen sehr hilfreichen und nützlichen Kommentar!
Patrick Mevzek

@PatrickMevzek Verstanden - was ich damit sagen wollte, ist, dass wir über Port 53 nur Datenverkehr zu bestimmten IP-Adressen außerhalb unseres Perimeters zulassen (TCP und UDP sind jedoch zulässig).
Caderade
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.