Quale porta usa il DNS? La porta 53, e quando non la usa

Quale porta usa il DNS per una ricerca ordinaria?

Una query normale, il tipo che il tuo browser invia decine di volte al minuto, esce come un singolo pacchetto UDP verso la porta 53 e torna nello stesso modo. L’RFC 1035 definisce UDP "il metodo raccomandato per le query standard su Internet" perché non serve alcuna stretta di mano: un pacchetto in uscita, uno in entrata, fatto. Questo è anche il motivo per cui il DNS sembra istantaneo quando funziona e perché un solo pacchetto perso basta a farlo sembrare rotto, dato che UDP non riprova automaticamente per te. Il software resolver sul tuo dispositivo o router gestisce il nuovo tentativo, di solito contro un secondo server configurato se il primo resta in silenzio.

Quando il DNS usa TCP invece?

Due situazioni spingono uno scambio DNS su TCP porta 53. La prima è un trasferimento di zona, dove un nameserver secondario recupera una copia completa di una zona dal primario. L’RFC 1035 è esplicito nel dire che "UDP non è accettabile per i trasferimenti di zona" perché l’operazione richiede un flusso affidabile e ordinato, non un singolo pacchetto best-effort. La seconda è una risposta che non entra nella dimensione massima del messaggio UDP in uso. Quando succede, il server rimanda indietro un pacchetto UDP troncato con il bit TC (truncated) impostato, e un resolver conforme nota quel bit e reinvia la stessa query via TCP per ottenere la risposta completa. Puoi forzare tu stesso questo comportamento e vedere direttamente la risposta completa:

dig +tcp example.com

Le query quotidiane raramente hanno bisogno di questo percorso, ma esiste proprio perché il DNS continui a funzionare quando una risposta cresce oltre ciò che un singolo pacchetto UDP può contenere, il che succede più spesso di un tempo.

Qual era il limite di 512 byte, e cosa lo ha cambiato?

L’RFC 1035 fissava la dimensione del messaggio UDP a 512 byte, header incluso, senza contare gli header IP o UDP stessi. Quel numero era generoso nel 1987, quando una risposta DNS era una manciata di record di indirizzo. Ha smesso di essere generoso quando le firme DNSSEC, i nomi host più lunghi e i record con molti indirizzi IP sono diventati normali, perché una risposta firmata con un record RRSIG supera regolarmente i 512 byte da sola.

L’RFC 6891, pubblicato nel 2013, ha alzato il tetto senza toccare il protocollo di trasmissione: EDNS0 aggiunge uno pseudo-record OPT che permette a un resolver di dichiarare "il payload UDP più grande che può essere riassemblato e consegnato nello stack di rete del richiedente", e l’RFC suggerisce 4096 byte come punto di partenza pratico. Un resolver e un server che supportano entrambi EDNS0 possono scambiarsi risposte molte volte più grandi del vecchio limite di 512 byte in un singolo pacchetto UDP, e ricorrere a TCP solo quando anche quel margine più ampio non basta. Quasi tutti i resolver oggi in uso, incluso quello del tuo sistema operativo, parlano EDNS0 per impostazione predefinita, quindi questo aggiornamento è già avvenuto senza alcuna azione da parte tua.

Perché i firewall che permettono solo UDP 53 causano problemi reali

Una regola firewall scritta anni fa e mai rivista spesso recita "permetti la porta UDP 53, nega tutto il resto legato al DNS". Quella regola blocca il ripiego TCP di cui il protocollo ha bisogno, e il guasto che produce è facile da diagnosticare male perché la maggior parte delle ricerche continua a funzionare bene. Solo quelle che crescono oltre il limite UDP falliscono, e falliscono in un modo che sembra casuale: un dominio si risolve normalmente quasi sempre e poi va in timeout, in particolare quando è coinvolta la validazione DNSSEC, dato che un resolver che valida deve recuperare i record RRSIG e DNSKEY insieme alla risposta che ha chiesto.

Il risultato pratico è che le zone firmate con DNSSEC e qualsiasi insieme di record con molti valori (un dominio con una dozzina di server di posta, per esempio) diventano inaffidabili dietro un firewall solo-UDP, mentre tutto il resto sembra sano. Bloccare TCP 53 in uscita, o bloccarlo in una sola direzione, è una delle interruzioni DNS autoinflitte più comuni, e raramente emerge in un controllo di connettività di base perché quel controllo di solito prova solo UDP.

DNS over TLS e DNS over HTTPS: porte diverse, stesse ricerche

Due trasporti più recenti trasportano le stesse query e risposte DNS ma le spostano completamente fuori dalla porta 53. DNS over TLS, definito nell’RFC 7858, avvolge ogni query in una sessione TLS sulla porta TCP 853, scelta così che un operatore di rete possa comunque vedere che sta avvenendo DoT (e bloccarlo) anche senza decifrarlo, dato che la porta stessa è un segnale chiaro.

DNS over HTTPS, definito nell’RFC 8484, va oltre. Invia le query DNS come normali richieste HTTPS sulla porta 443, la stessa porta di ogni altro sito che visiti, e l’RFC indica "la capacità di mescolare il traffico DoH con altro traffico HTTPS sulla stessa connessione" come una proprietà deliberata. Questo è tutto il punto di DoH: una rete che ispeziona o filtra solo in base alla porta non può separare una ricerca DNS da qualsiasi altra richiesta HTTPS, perché sono lo stesso protocollo sulla stessa porta. Chrome, Firefox ed Edge possono tutti inviare il DNS in questo modo per impostazione predefinita ora, motivo per cui bloccare la "porta 53" su una rete non garantisce più di aver bloccato il DNS. Garantisce di aver bloccato il trasporto classico; un browser con DoH attivo continua a risolvere i nomi sulla 443 comunque.

Cos’è mDNS sulla porta 5353?

Multicast DNS è un protocollo diverso che porta un nome simile. L’RFC 6762 lo definisce come dispositivi che "inviano messaggi di query e risposta UDP simili al DNS tramite IP Multicast alla porta UDP 5353", indirizzati al gruppo multicast 224.0.0.251 (o il suo equivalente IPv6, FF02::FB) invece che a un server specifico. Non c’è alcun nameserver centrale coinvolto: ogni dispositivo sul segmento di rete locale ascolta sulla porta 5353 e risponde per il proprio nome. È così che una stampante o uno smart speaker diventa raggiungibile come device.local senza che nessuno configuri un record DNS per esso. È confinato per progetto al collegamento locale e non ha nulla a che fare con la risoluzione di un nome di dominio pubblico, quindi il traffico mDNS non ha mai bisogno di lasciare il tuo router.

Come verificare se la porta 53 è raggiungibile

Inizia con una query diretta contro un resolver noto e funzionante, il che ti dice se le ricerche UDP ordinarie funzionano affatto:

nslookup example.com 8.8.8.8
dig example.com @1.1.1.1

Se questo funziona ma sospetti che il percorso di ripiego TCP sia bloccato, forza TCP e confronta:

dig +tcp example.com @1.1.1.1

Una query UDP che riesce mentre la versione forzata su TCP va in timeout è un forte segnale che qualcosa tra te e il resolver sta scartando specificamente TCP 53, esattamente il guasto descritto sopra. Testare la raggiungibilità grezza della porta dall’esterno della tua rete è dove torna utile il nostro strumento di controllo porta: puntalo sulla porta 53 del tuo resolver o nameserver e apre una vera connessione TCP da un’altra rete, confermando se TCP 53 è raggiungibile. Leggi il risultato con un avvertimento in mente: un controllore di porte testa TCP, quindi un esito positivo lì conferma che il percorso di ripiego è aperto ma non dice nulla su UDP, che non ha alcuna stretta di mano da testare allo stesso modo. Per la query stessa, incluso confrontare le risposte da più resolver pubblici e regioni diverse contemporaneamente, esegui lo strumento di query DNS.

Domande frequenti

Devo aprire anche TCP 53 oltre a UDP 53?

Sì, per il traffico in uscita verso i resolver. Un firewall che permette solo UDP 53 gestirà bene la maggior parte delle query e poi fallirà in modo imprevedibile sulle risposte più grandi, tipicamente firmate DNSSEC, che hanno bisogno del ripiego TCP.

Bloccare la porta 53 blocca tutto il traffico DNS?

Non più. Blocca il trasporto classico UDP/TCP. DNS over HTTPS gira sulla porta 443 e sembra qualsiasi altra richiesta HTTPS, e DNS over TLS gira sulla propria porta 853, quindi un browser o un’app con uno dei due attivo continua a risolvere i nomi.

DNS over HTTPS è lo stesso protocollo del DNS normale?

Le query e le risposte sono gli stessi record e codici DNS definiti dall’RFC 1035. Cambia solo il trasporto: invece di un pacchetto UDP o TCP grezzo sulla porta 53, la stessa richiesta viene avvolta dentro una richiesta HTTPS sulla porta 443.

Perché a volte dig usa TCP senza che glielo si chieda?

Quando una risposta UDP torna troncata, con il bit TC impostato, un client conforme agli standard reinvia automaticamente la query via TCP per ottenere la risposta completa. Lo vedi più spesso sui domini con DNSSEC attivo o con molti record dello stesso tipo.

mDNS sulla porta 5353 è la stessa cosa del DNS del mio provider?

No. mDNS funziona solo sul tuo segmento di rete locale, non ha alcun server centrale, e risolve nomi come device.local per i dispositivi sullo stesso collegamento. Non ha alcun ruolo nella risoluzione di un dominio pubblico come example.com.

Qual è una dimensione normale del payload EDNS0 oggi?

L’RFC 6891 suggerisce 4096 byte come predefinito pratico, e la maggior parte dei resolver attuali dichiara qualcosa in quell’intervallo, ben oltre il tetto originale di 512 byte, prima di ricorrere a TCP solo quando anche quello non basta.