it-swarm.com.de

Werden DNS-Abfragen immer über UDP übertragen?

Ich habe ein wenig Zeit damit verbracht, dieses Thema zu untersuchen, 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 dies immer noch sicher ist Fragen Sie hier, aber lassen Sie mich wissen, ob ich es der Sicherheitsgemeinschaft verschieben muss.

Verwenden DNS-Abfragen im Wesentlichen jemals TCP (wenn ja, in welchem ​​Szenario könnte dies auftreten)? Auch hier handelt es sich nur um Abfragen. Ist es ihnen möglich, über TCP zu reisen? Wenn Domänen kann nur maximal 253 Byte lang sein, und UDP-Pakete können bis zu 512 Byte groß sein. Werden Abfragen nicht immer als UDP ausgegeben? 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 Byte erhalten hat, würde der Server diese löschen/nicht versuchen, sie zu beheben? Ich bin 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 Standardpaketerfassung auf DNS-Servern und Domänencontrollern zu erfassen. Die Hauptanforderung besteht darin, alle DNS-Abfragen zu erfassen, damit sie identifizieren können, welcher Client versucht hat, eine bestimmte Domäne aufzulösen. Aufgrund dieser Anforderung geht es uns nicht darum, DNS-Antworten oder anderen Datenverkehr wie Zonenübertragungen zu erfassen, was auch darauf zurückzuführen ist, dass wir das Protokollvolumen so weit wie möglich begrenzen müssen. Aus diesem Grund planen wir, nur DNS-Abfragen zu erfassen, die für den DNS-Server bestimmt und über UDP gesendet werden. Für mehr Kontext (Art von Fragenbereich, der sich hier einschleicht) wurde jetzt angesprochen, dass wir möglicherweise die Sichtbarkeit der Sicherheit erweitern müssen, damit sie Aktivitäten wie verdeckte Kanäle überwachen können, die über DNS laufen (was auch die Notwendigkeit darstellen würde, DNS-Antworten zu erfassen). und anschließend TCP Verkehr). Aber selbst in einem solchen Szenario dachte ich, dass ausgehender DNS-Verkehr in Form von Suchvorgängen/Abfragen erfolgen würde und dass diese immer über UDP erfolgen würden, selbst wenn aus einer böswilligen Quelle (aufgrund meiner Überlegungen im ersten Absatz). Dies wirft also einige zusätzliche Fragen auf:

  • Würden wir nicht mindestens die Hälfte des Gesprächs mit dem von mir skizzierten Ansatz erfassen? Oder würde ein Client jemals DNS-Verkehr senden, der nicht in Form einer Abfrage vorliegt? (Vielleicht wie eine Antwort auf die Antwort eines DNS-Servers und möglicherweise über TCP)

  • Können DNS-Abfragen geändert werden, um TCP zu verwenden? Würde ein DNS-Server eine über TCP eingehende DNS-Anfrage akzeptieren und darauf antworten?

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

34
Caderade

Normale DNS-Abfragen verwenden den UDP-Port 53, aber längere Abfragen (> 512 Oktette) erhalten eine "abgeschnittene" Antwort, die zu einer Konversation TCP 53) führt, um das Senden/Empfangen der gesamten Abfrage zu erleichtern Der DNS-Server bindet an Port 53, aber die Abfrage selbst stammt 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ückgegeben.

Von DNS | Microsoft Docs verwendete Netzwerkports

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 auch Zonenübertragungen (Abfragetyp AXFR) verwendet, um andere DNS-Server mit neuen Einträgen zu aktualisieren. Ein Mann im mittleren Angriff kann mit einer solchen Übertragung beginnen und einen primären Nameserver DDOS-fähig machen, sodass er zu beschäftigt ist, um auf einen sekundären Nameserver zu antworten, der nach aktualisierten Datensätzen fragt. 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 Ihre Sicherheitsüberprüfung den Abfragetyp AXFR genau berücksichtigen, und Ihre DNS-Systeme sollten nur AXFR-Austausch von bestimmten IP-Adressen akzeptieren.

SoS Institute InfoSec Lesesaal | sans.org

39
George Erhard

Dies begann als Kommentar zu Georges Antwort, aber es wurde lang. Das größere Bild ist etwas kompliziert, da es ein gewisses Verständnis der Geschichte erfordert.

  • RFC 1035 forderte ursprünglich ein Limit von 512 Bytes, um eine UDP-Fragmentierung zu vermeiden. Fragmentierte UDP-Datagramme und TCP wurden als letzte Möglichkeit ausgewählt, um den Overhead von DNS-Transaktionen zu minimieren. Zonenübertragungen verwenden immer TCP, da Zonenübertragungen jeweils mehr als 512 Byte beanspruchen Natur. (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 112 angegeben sind.

  • EDNS (0) ist definiert durch RFC 6891 (2013) 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 Bytes ungültig sind, dies ist jedoch eine von mehreren.

Wenn wir das in die beobachteten Verhaltensweisen aufteilen:

  1. DNS-Abfragen normalerweise werden als UDP gestartet, es sei denn, es ist im Voraus bekannt, dass die Antwort zunächst zu groß ist. (Zonentransfers)
  2. Die Antwort kann löst einen TCP Wiederholungsversuch im Client aus, wenn eine abgeschnittene Antwort angezeigt wird. Dies wird ziemlich gut unterstützt.
  3. Eine UDP-Antwort von mehr als 512 Bytes kann wird angezeigt, wenn der Client EDNS (0) verwendet hat, um eine größere Nutzlast anzukündigen, und der empfangende Server unterstützt dies. Dies geschieht nur wenn Hardware, die zwischen den beiden sitzt, stört nicht und führt zu einem verworfenen oder verstümmelten Paket.
  4. Der Client may wählt, eine EDNS (0) -Abfrage mit einer kleineren angekündigten Nutzlast erneut zu versuchen, wenn keine Antwort angezeigt wird, die Einzelheiten jedoch zwischen den Implementierungen variieren.
    • Es ist wichtig zu beachten, dass die Antwort, die es schließlich schafft, möglicherweise zu groß ist, um in die angeforderte Größe zu passen, was zu Verhalten Nr. 2 oben führt. (ye olde TCP wiederholen)
    • 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 verschwendet werden, die erneut ausgeführt werden. Andernfalls wäre es ziemlich verschwenderisch, insbesondere wenn das Endergebnis TCP Fallback) erfordert.

Beachten Sie auch, dass RFC 7766 ermöglicht die Wiederverwendung von Verbindungen über TCP und es möglich ist, dass das Abfrage-Pipelining über TCP in freier Wildbahn) auftritt. Einige Tools DNS-Abfragen werden nicht erkannt, die über die ersten in einer TCP -Sitzung, dnscap als Beispiel dafür hinausgehen) hinausgehen.

29
Andrew B

Dort ist RFC 7766, DNS-Transport über TCP - - Implementierungsanforderungen.

  1. Einführung

Die meisten DNS [ RFC1034 ] Transaktionen finden über UDP [ RFC768 ] statt. TCP [ RFC79 ] wird immer für Vollzonenü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. Die Notwendigkeit einer erhöhten Verwendung von TCP] wurde auch durch den Schutz vor Adressspoofing und damit bestimmt Ausnutzung von DNS bei Reflexions-/Verstärkungsangriffen. Es wird jetzt häufig bei der Begrenzung der Antwortrate verwendet [ RRL1 ] [ RRL2 ]. 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.

Abschnitt 6.1.3.2 von [RFC1123] besagt:

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

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

Die Mehrheit der DNS-Serverbetreiber unterstützt bereits TCP, und die Standardkonfiguration für die meisten Softwareimplementierungen besteht darin, TCP zu unterstützen. Die Hauptzielgruppe für dieses Dokument sind diejenigen 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 so aktualisiert, dass die Unterstützung von TCP) fortan ein ERFORDERLICHER Teil einer vollständigen Implementierung des DNS-Protokolls ist.

Die vermehrte Verwendung von TCP (siehe Anhang A ) sowie Implementierungsdetails, die berücksichtigt werden müssen, haben mehrere Vor- und Nachteile. Dieses Dokument behandelt diese Probleme und präsentiert TCP als gültige Transportalternative für DNS. Es erweitert den Inhalt von [ RFC5966 ] um zusätzliche Überlegungen und Lehren aus Forschung, Entwicklung und Implementierung von = TCP in DNS und in anderen Internetprotokollen.

Dieses Dokument stellt zwar keine spezifischen Anforderungen an die Betreiber von DNS-Servern, bietet den Betreibern jedoch einige Vorschläge, um sicherzustellen, dass die Unterstützung für TCP auf ihren Servern und im Netzwerk optimal ist). Dies sollte beachtet werden Dieser Fehler bei der Unterstützung von TCP (oder das Blockieren von DNS über TCP auf Netzwerkebene)) führt wahrscheinlich zu einem Auflösungsfehler und/oder zu Zeitüberschreitungen auf Anwendungsebene.

6
Ron Maupin

Sie sollten TCP/53 in keine Richtung filtern. Beispielsweise können nsupdate Abfragen TCP verwenden, sobald die Anforderung zu groß ist (was schnell geschehen kann). Sie sollten also 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.

3
Patrick Mevzek