È vero che un nameserver deve rispondere alle query su TCP?

23

Sono il processo di impostazione di un monitoraggio dei server DNS di numerosi host Web di grandi dimensioni. Il mio obiettivo è confrontare i tempi di risposta dei loro server DNS monitorando la loro risposta al ping.

Nel processo, ho scoperto che i nameserver Bluehost non rispondono al ping. Ho provato a ottenere maggiori informazioni eseguendo Pingdom DNS Check su bluehost.com e ha prodotto il seguente errore:

Il server dei nomi ns1.bluehost.com (74.220.195.31) non risponde alle query su TCP.

Il server dei nomi non è riuscito a rispondere alle query inviate su TCP. Ciò è probabilmente dovuto al nome del server non impostato correttamente o al filtro non configurato correttamente in un firewall. È un'idea sbagliata piuttosto comune che il DNS non abbia bisogno del TCP a meno che non forniscano trasferimenti di zona - forse l'amministratore del server dei nomi non è a conoscenza del fatto che il TCP di solito è un requisito.

Vorrei sapere quanto segue:

In che misura è vera la precedente affermazione?
Quali sono le implicazioni di un nameserver che non risponde alle query su TCP?

domain-name-system nameserver

— Taras Mankovski
fonte

47

Il testo diagnostico di Pingdom è esattamente corretto. TCP non è solo per i trasferimenti di zona.

Le implementazioni del server DNS sono ora "richieste" (in quanto qualsiasi RFC richiede qualsiasi cosa) per supportare TCP, per RFC 5966 , "Trasporto DNS su TCP - Requisiti di implementazione".

Si noti che questo è un requisito per l'implementazione del software server, non si applica strettamente al funzionamento di alcun server - la pratica operativa non è coperta.

Detto questo, se i tuoi particolari server DNS non sono configurati per supportare TCP, o se è bloccato, l'effetto a lungo termine sarà l'incapacità di supportare correttamente DNSSEC. Allo stesso modo, qualsiasi altro dato DNS che causa risposte superiori a 512 byte potrebbe essere bloccato.

Disclaimer: ho scritto che RFC.

EDIT RFC 5966 è stato ora sostituito da RFC 7766

— Alnitak
fonte

RE: pratica operativa, chi odia DNSSEC potrebbe semplicemente disabilitare TCP e rilasciarlo nel firewall per buona misura. Non sorprende che ci siano conseguenze. Nessun supporto per EDNS0 a due endpoint può forzare i dispositivi tra loro a non interferire in alcun modo. (frammentazione, falsa segnalazione da parte di antichi firewall, ecc.) Se si dispone di record DNS di grandi dimensioni sul server di autenticazione (TXT gonfio), sarà richiesto TCP se non si desidera escludere un segmento del pubblico. Allo stesso modo, disabilitarlo su un server ricorsivo ti isola dalle risposte DNS che il tuo cluster di posta potrebbe aver bisogno di gestire lo spam.

— Andrew B,

3

dovrebbe supportare TCP e UDP - il TCP è per dimensioni di risposta> 512 byte (che includerebbe i trasferimenti di zona) (secondo le cose che ho letto, comunque. Di solito abilito TCP e UDP per gli NS che eseguo ...)

— Mark Regensberg
fonte

-2

È bello sapere cosa dicono gli RFC sull'argomento e abbiamo già una buona risposta autorevole al riguardo, ma per scopi pratici trovo abbastanza divertente il consiglio del Prof. Daniel J. Bernstein, PhD, autore di DJBDNS.

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

Quando vengono inviate le query TCP?

Se ti trovi in una delle seguenti situazioni, devi configurare il tuo server DNS per rispondere alle query TCP:

Si desidera pubblicare set di record di dimensioni superiori a 512 byte. (Questo è quasi sempre un errore.)

Si desidera consentire i trasferimenti di zona in uscita, ad esempio a un server di terze parti.

Un server di appartenenza rifiuta di delegarti un nome fino a quando non imposti il servizio TCP.

Se non ci si trova in nessuna di queste situazioni, non è necessario fornire il servizio TCP e non è necessario configurarlo. DNS-over-TCP è molto più lento di DNS-over-UDP ed è intrinsecamente molto più vulnerabile agli attacchi denial-of-service. (Questo vale anche per BIND.)

Si noti che omette una menzione esplicita di DNSSEC; il motivo è che, secondo DJB, DNSSEC rientra nella categoria "sempre un errore". Vedi https://cr.yp.to/djbdns/forgery.html per maggiori dettagli. DJB ha uno standard alternativo, chiamato DNSCurve - http://dnscurve.org/ - che è già stato adottato in modo indipendente da alcuni provider (come OpenDNS). Di interesse: /security/45770/if-dnssec-is-so-questionable-why-is-it-ahead-of-dnscurve-in-adoption .

Si noti che se la documentazione di cui sopra sulla configurazione di DJBDNS è indicativa delle sue caratteristiche, sembra che supporti solo AXFR per TCP. Poiché molti provider utilizzano ancora DJBDNS, è improbabile che supportino DNS su TCP senza sforzi aggiuntivi.

PS Nota che DJB, in effetti, pratica ciò che predica. I suoi server, (1), eseguono DNSCurve, (2), non rispondono correttamente a TCP. Solo il +notcpsuccesso (che è predefinito):

% 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

, mentre a +tcpfallirebbe (apparentemente con un messaggio di errore diverso, a seconda di quale dei suoi server viene selezionato):

% 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
fonte

2

Il tuo atto di fan del DJB sta diventando piuttosto da indossare. La comunità DNS ha scelto DNSSEC e gran parte della letteratura su DNSCurve integra completamente i requisiti ortogonali di autenticità dei dati e crittografia dei dati . IMNSHO, la maggior parte della tua risposta non contribuisce a questa domanda.

— Alnitak,

@Alnitak, la tua insistenza sul fatto che TCP sia richiesto per DNS non lo rende un vero requisito per DNS. Chiaramente molte persone corrono senza TCP e non riscontrano NESSUN problema con la disponibilità dei propri siti Web. Eppure continui a promuovere disinformazione e FUD.

— primo

2

Quel documento è davvero del 2003? Come puoi affermare con una faccia seria che è ancora rilevante nel 2017?

— Michael Hampton

1

@MichaelHampton, sì, con tutto il cuore e assolutamente. Alcune cose non cambiano e DJB potrebbe essere uno stronzo, ma è piuttosto intelligente. Tutti gli argomenti che presenta sono di natura filosofica e non cambiano come fa la tecnologia. Nel frattempo, (1), perché è così difficile da credere, (2), perché il collegamento con RFC ancora più vecchi è fatto con una faccia seria, e senza che tu sia un ipocrita, (3), quali reali controargumenti hai altro che una data"? La gente continua a dire che la sua strada ha problemi di interoperabilità, eppure gli stessi argomenti proposti (ad esempio, la posta rimbalzata) ha debunked nel 2003!

— primo

-5

TCP è richiesto solo e di solito viene utilizzato solo quando è richiesta una risposta lunga. Ci possono essere impatti negativi. I trasferimenti di zona vengono effettuati su TCP poiché sono di grandi dimensioni e devono essere affidabili. Non consentire TCP da server non attendibili è un modo per garantire che vengano fornite solo piccole risposte.

Con l'introduzione delle risposte DNS firmate, è stato necessario allentare il limite di 512 byte alle risposte UPD. EDNS0 fornisce il meccanismo per risposte UDP più lunghe. L'incapacità di consentire DNS su TCP è altamente probabile che interrompa un'implementazione DNS sicura.

È perfettamente possibile eseguire un server DNS che ha solo la porta UDP 53 aperta su Internet. È richiesto l'accesso TCP ai peer DNS, ma questo è un piccolo elenco di host.

Esiste un nuovo RFC596 che ora richiede TCP per un'implementazione DNS completa. Questo è rivolto agli implementatori. I documenti in particolare non riguardano gli operatori, ma avvertono che non consentire TCP può comportare una serie di scenari di errore. Descrive in dettaglio un'ampia gamma di errori che possono verificarsi se DNS su TCP non è supportato.

Ci sono state discussioni sull'uso di TCP per prevenire attacchi di amplificazione DNS. TCP ha i suoi rischi di negazione del servizio, ma la distribuzione è più difficile.

— BillThor
fonte

DNSSEC non ha allentato il limite, come ha fatto EDNS0, nel 1999 (vedi RFC 2671).

— Alnitak,

No, come spiegato da Alnitak, nella maggior parte dei casi è richiesto TCP (a meno che tu non sia assolutamente certo che non avrai mai una risposta> 512 byte, qualcosa che in genere non conosci in anticipo)

— bortzmeyer

Ho eseguito correttamente DNS attraverso un firewall che consente solo UDP. Escludendo le configurazioni patologiche, le ricerche di indirizzi avranno una lunghezza inferiore a 512 caratteri. Ho visto riferimenti che i percorsi DNS sono limitati a 256 caratteri. Le prove nel database del mio server di posta suggeriscono che i percorsi DNS del server raramente superano i 100 caratteri e i siti con più nomi restituiti da un record PTR raramente si ripresentano oltre 256 caratteri. Tutte queste risposte sarebbero eseguite su UDP. Qualcuno ha un caso ragionevole che corre vicino a 512 caratteri senza DNSSEC o un trasferimento di zona.

— BillThor,

Per quanto riguarda DNSSEC, non ho verificato RFC per dimensioni estese, ma gli unici riferimenti che ho visto sull'uso di dimensioni estese di pacchetti su UDP hanno ben DSNSEC.

— BillThor,

Uno dei grandi fornitori di contenuti è stato sbloccato qualche anno fa quando hanno aggiunto così tanti record A per uno dei loro webfarm che ha superato i 512 byte. Ciò ha causato problemi di interoperabilità reali.

— Alnitak,