Le query DNS viaggiano sempre su UDP?

Ho trascorso un po 'di tempo a cercare questo argomento e non riesco a trovare una risposta esatta, quindi sono abbastanza sicuro che non sia un duplicato e, sebbene la mia domanda sia basata su un'esigenza di sicurezza, penso che sia ancora sicuro chiedi qui, ma fammi sapere se devo spostarlo nella comunità della sicurezza.

In sostanza, le query DNS usano mai TCP (in tal caso, quale scenario potrebbe verificarsi)? Ancora una volta, sto solo parlando di domande. È possibile che viaggino su TCP? Se i domini possono avere una lunghezza massima di 253 byte e i pacchetti UDP possono arrivare a 512 byte, le query non verranno sempre inviate come UDP? Non pensavo che una query risolvibile potesse essere abbastanza grande da richiedere l'uso del TCP. Se un server DNS avesse mai ricevuto una richiesta per un dominio di dimensioni superiori a 253 byte, il server lo avrebbe eliminato / non avrebbe provato a risolverlo? Sono certo di aver fatto alcune ipotesi false qui.

Per alcuni contesti, sto lavorando con il gruppo di sicurezza per integrare le query DNS nel loro strumento di monitoraggio della sicurezza e per vari motivi abbiamo deciso di acquisire questo traffico tramite l'acquisizione di pacchetti standard su server DNS e controller di dominio. Il requisito fondamentale è acquisire tutte le query DNS in modo che possano identificare quale client ha tentato di risolvere un determinato dominio. Sulla base di questo requisito, non ci occupiamo di acquisire risposte DNS o altri tipi di traffico come i trasferimenti di zona, il che dipende anche dal fatto che dobbiamo limitare il volume dei log il più possibile. Pertanto, stiamo pianificando di acquisire solo query DNS destinate al server DNS e inviate tramite UDP. Per più contesto (tipo di ambito di domande che si insinua qui), ora è stato sollevato il fatto che potremmo aver bisogno di espandere la sicurezza visibilità in modo che possano monitorare attività come i canali nascosti in esecuzione su DNS (il che presenterebbe la necessità di acquisire anche le risposte DNS, e successivamente il traffico TCP). Ma anche in quel tipo di scenario, ho pensato che qualsiasi traffico DNS in uscita sarebbe stato sotto forma di ricerche / query e che questi sarebbero sempre stati su UDP, anche se da una fonte malevola (a causa del mio ragionamento nel primo paragrafo). Quindi questo porta ad alcune domande aggiuntive:

• Non avremmo almeno catturato metà della conversazione con l'approccio che ho delineato? O un client invierebbe mai traffico DNS che non ha la forma di una query? (forse come una sorta di risposta alla risposta di un server DNS, e forse finisce per uscire su TCP)

• Le query DNS possono essere modificate per utilizzare TCP? Un server DNS accetterebbe e risponderebbe a una query DNS proveniente da TCP?

Non sono sicuro che sia pertinente, ma limitiamo le richieste DNS ai server DNS autorizzati e blocchiamo tutto il traffico in uscita sulla porta 53. Sono sicuramente un novellino, quindi mi dispiace se la mia domanda non è conforme e fammi sapere come dovrei modificare.

Le query DNS normali utilizzano la porta UDP 53, ma query più lunghe (> 512 ottetti) riceveranno una risposta "troncata", che si traduce in una conversazione TCP 53 per facilitare l'invio / la ricezione dell'intera query. Inoltre, il server DNS si collega alla porta 53, ma la query stessa ha origine su una porta a numero elevato casuale (49152 o superiore) inviata alla porta 53. La risposta verrà restituita a questa stessa porta dalla porta 53.

Porte di rete utilizzate da DNS | Microsoft Docs

Pertanto, se stai pianificando di eseguire alcuni snooping della sicurezza sulle query DNS dalla tua rete, dovrai tenere conto di quanto sopra.

Per quanto riguarda il traffico senza ricerca, considera che anche il DNS utilizza i trasferimenti di zona (tipo di query AXFR) per aggiornare altri server DNS con nuovi record. Un uomo nel mezzo dell'attacco può iniziare con un tale trasferimento, DDOS su un server dei nomi primario in modo che sia troppo occupato per rispondere a un Secondario che richiede record aggiornati. L'hacker quindi esegue lo spoofing dello stesso Primario per alimentare i record "avvelenati" al Secondario, che reindirizza i domini DNS popolari agli host compromessi.

Pertanto, il controllo di sicurezza deve prestare particolare attenzione al tipo di query AXFR e i sistemi DNS devono accettare scambi AXFR solo da indirizzi IP specifici.

Sala di lettura InfoSec Institute SANS | sans.org

Questo è iniziato come un commento alla risposta di George, ma è durato molto. Il quadro più ampio è alquanto complicato, poiché richiede di comprendere un po 'di storia.

• RFC 1035 inizialmente prevedeva un limite di 512 byte per evitare la frammentazione UDP. Datagrammi UDP frammentati e TCP sono stati scelti come opzioni di ultima istanza al fine di ridurre al minimo il sovraccarico delle transazioni DNS. I trasferimenti di zona utilizzano sempre TCP, a causa dei trasferimenti di zona che occupano> 512 byte per loro stessa natura. (sarebbe uno spreco di larghezza di banda iniziare con UDP affatto)

• Il tentativo di TCP sul troncamento è ampiamente supportato poiché è stato specificato in RFC 1123 dal 1989.

• EDNS (0) è definito da RFC 6891 (2013), e prima esisteva come Standard proposto risalente al 1999 . Definisce un meccanismo in cui client e server possono negoziare dimensioni UDP superiori a 512. A causa della novità di EDNS (0), molte appliance hardware fanno ipotesi sulla struttura dei pacchetti DNS che causano l'eliminazione dei pacchetti conformi. Il motivo più frequente è l'assunto che i messaggi DNS di oltre 512 byte non siano validi, ma questo è uno dei tanti.

Se lo suddividiamo nei comportamenti osservati:

1. Le query DNS di solito iniziano come UDP, a meno che non si sappia in anticipo che la risposta sarà troppo grande per cominciare. (trasferimenti di zona)
2. La risposta può attivare un nuovo tentativo TCP nel client se viene visualizzata una risposta troncata. Questo è abbastanza ben supportato.
3. Una risposta UDP superiore a 512 byte può essere visualizzata se il client utilizza EDNS (0) per pubblicizzare un payload più grande e il server ricevente lo supporta. Questo accadrà solo se l' hardware che si trova tra i due non interferisce e si traduce in un pacchetto scartato o rovinato.
4. Il client può scegliere di riprovare una query EDNS (0) con un payload pubblicizzato più piccolo se non si vede una risposta, ma le specifiche possono variare tra le implementazioni.
   • È importante notare che la risposta che alla fine riesce a superare potrebbe essere troppo grande per adattarsi alla dimensione richiesta, il che comporta il comportamento n. 2 sopra. (vecchio TCP riprovare)
   • Il lato client può scegliere di ricordare le dimensioni che alla fine hanno portato a un successo. Ciò consente di evitare di sprecare query non necessarie per sondarlo di nuovo. Fare altrimenti sarebbe piuttosto dispendioso, in particolare se il risultato finale richiedesse il fallback TCP.

È inoltre necessario tenere presente che RFC 7766 consente il riutilizzo della connessione su TCP ed è possibile riscontrare il pipelining delle query su TCP in natura. Alcuni strumenti non rilevano query DNS oltre alla prima vista in una sessione TCP, dnscap ne è un esempio.

Vi è RFC 7766, trasporto DNS su TCP - Requisiti di implementazione .

1. introduzione

La maggior parte delle transazioni DNS [ RFC1034 ] avvengono su UDP [ RFC768 ]. TCP [ RFC793 ] viene sempre utilizzato per i trasferimenti di zone complete (tramite AXFR) e viene spesso utilizzato per i messaggi le cui dimensioni superano il limite originale di 512 byte del protocollo DNS. La crescente distribuzione di DNS Security (DNSSEC) e IPv6 ha aumentato le dimensioni di risposta e quindi l'uso di TCP. La necessità di un maggiore utilizzo del TCP è stata anche guidata dalla protezione che fornisce contro lo spoofing degli indirizzi e quindi lo sfruttamento del DNS negli attacchi di riflessione / amplificazione. Ora è ampiamente utilizzato nella limitazione della velocità di risposta [ RRL1 ] [ RRL2 ]. Inoltre, recenti lavori su soluzioni di privacy DNS come [ DNS-over-TLS] è un'altra motivazione per rivisitare i requisiti DNS su TCP.

La sezione 6.1.3.2 di [RFC1123] afferma:

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

Tuttavia, alcuni implementatori hanno preso il testo sopra citato per indicare che il supporto TCP è una funzionalità opzionale del protocollo DNS.

La maggior parte degli operatori di server DNS supporta già TCP e la configurazione predefinita per la maggior parte delle implementazioni software è quella di supportare TCP. Il pubblico principale di questo documento sono quegli implementatori il cui supporto limitato per TCP limita l'interoperabilità e ostacola l'implementazione di nuove funzionalità DNS.

Questo documento pertanto aggiorna le specifiche del protocollo DNS di base in modo che il supporto per TCP sia d'ora in poi una parte NECESSARIA di un'implementazione completa del protocollo DNS.

Ci sono molti vantaggi e svantaggi nell'aumentato uso di TCP (vedi Appendice A ) e dettagli di implementazione che devono essere considerati. Questo documento risolve questi problemi e presenta TCP come valida alternativa di trasporto per DNS. Estende il contenuto di [ RFC5966 ], con ulteriori considerazioni e insegnamenti tratti dalla ricerca, dagli sviluppi e dall'implementazione di TCP in DNS e in altri protocolli Internet.

Sebbene questo documento non soddisfi requisiti specifici che gli operatori dei server DNS devono soddisfare, offre alcuni suggerimenti agli operatori per garantire che il supporto per TCP sui loro server e sulla rete sia ottimale. Va notato che l'incapacità di supportare TCP (o il blocco di DNS su TCP a livello di rete) comporterà probabilmente errori di risoluzione e / o timeout a livello di applicazione.

Non filtrare TCP / 53 in nessuna direzione. Ad esempio, le nsupdatequery possono utilizzare TCP non appena la richiesta è troppo grande (il che può avvenire rapidamente). Quindi dovresti lasciare UDP e TCP per la porta 53 (in IPv4 e V6!) Scorrere in tutte le direzioni.

Inoltre, c'è sempre più lavoro verso DNS su TLS, quindi TCP sarà necessario in entrambe le direzioni. Vedi RFC7858.