Quando il DNS usa UDP e quando TCP sulla porta 53, cosa fa scattare il flag TC, perché DNSSEC rende le risposte enormi e come il DDNS ti permette di raggiungere casa con IP dinamico.
1. Messaggi DNS: quando UDP e quando TCP?
Il DNS usa la porta 53 sia su UDP che su TCP: UDP per le query standard veloci e leggere, TCP quando serve affidabilità o la risposta è troppo grande per entrare in un datagramma UDP.
Il protocollo DNS è query/response: client chiede, server risponde. Per default la scelta è UDP/53 perché è connectionless, ha 8 byte di overhead e nessuna fase di handshake → risposta in pochi millisecondi. Il 90% del traffico DNS quotidiano è questo.
Veloce e leggero
Risoluzione di A, AAAA, MX, NS, CNAME. Query frequenti, risposte <512 byte (o <4096 con EDNS0). È ciò che fa il browser ogni volta che digiti www.example.com.
Affidabile e capiente
Trasferimento di zona AXFR/IXFR, risposte > limite UDP (flag TC=1), query DNSSEC con RRSIG voluminose. TCP gestisce ritrasmissioni e ordine.
Apri Chrome e vai su www.istituto.edu. Wireshark mostra: Standard query A www.istituto.edu su UDP 53 verso 8.8.8.8, risposta in 12ms con IP. Nessun TCP. Ora fai dig AXFR istituto.edu @ns1.istituto.edu dal server DNS: vedrai subito negoziazione TCP three-way handshake perché il client sa già che sta chiedendo l'intera zona.
All'orale: se ti chiedono "DNS UDP o TCP?" rispondi sempre: "Entrambi su porta 53, ma UDP di default per efficienza, TCP quando serve affidabilità o la risposta supera EDNS0 o è un AXFR. Dal 2020 con DNSSEC l'uso di TCP è molto aumentato". Questa frase ti fa prendere punti pieni.
2. Il flag TC (Truncated) ed EDNS0
Storicamente il DNS su UDP aveva un limite di 512 byte. Se la risposta sforava, il server non la spezzava: tagliava e impostava il bit TC=1 nell'header. Il client capiva che la risposta era troncata e doveva ripetere la stessa query in TCP.
Oggi con EDNS0 (Extension Mechanisms for DNS, RFC 6891) il client può annunciare un buffer più grande (tipicamente 1232 o 4096 byte) nell'OPT RR. Questo riduce i casi di troncamento, ma non li elimina: con DNSSEC o record TXT molto lunghi (SPF/DKIM) si sfora comunque.
Dire "se la risposta è >512 byte il DNS fallisce" è sbagliato. Non fallisce: il server setta TC=1 e il client riprova in TCP. Con EDNS0 il limite negoziato è più alto, quindi molti domini moderni non vedono mai TC=1 tranne che con DNSSEC.
512 byte
Limite RFC 1035 originale. Ancora usato se client non supporta EDNS0.
1232–4096 byte
Consigliato 1232 per evitare frammentazione IP. Cloudflare e Quad9 usano 1232.
TCP obbligatorio
Se anche EDNS0 non basta → TC=1 → retry TCP. Deterministico.
3. Trasferimento di zona: AXFR e IXFR
Il trasferimento di zona è la replica del database di una zona DNS dal server primario (master) ai secondari (slave): AXFR trasferisce tutta la zona, IXFR solo le differenze incrementali.
Per un secondario, avere tutta la zona è vitale per rispondere se il primario è down. Ma una zona può contenere migliaia di record: non sta in UDP. Per RFC 5936, AXFR/IXFR devono avvenire su TCP/53.
| Caratteristica | AXFR – Full Transfer | IXFR – Incremental |
|---|---|---|
| Quando | Prima sincronizzazione, serial molto vecchio | Aggiornamenti periodici, NOTIFY ricevuto |
| Cosa trasferisce | Tutti i RR della zona (SOA → SOA) | Solo i delta: aggiunge/rimuove RR tra due serial |
| Protocollo | TCP/53 sempre | TCP/53 sempre |
| Efficienza | Costoso, alto traffico | Leggero, ideale per zone dinamiche |
| RFC | RFC 5936 | RFC 1995 |
Se allow-transfer { any; }, chiunque può scaricare l'intera mappa DNS: server interni, IP di stampanti, nomi di sistemi. È la prima tecnica usata in footprinting OSINT. In laboratorio verifichiamo con dig AXFR istituto.edu @ns1.istituto.edu: se risponde, la configurazione va corretta subito.
Sul PC del lab: dig +short NS istituto.edu → ottieni primari. Poi prova dig AXFR istituto.edu @192.168.1.10. Se ottieni "Transfer failed", il server è protetto. Se ottieni decine di record, hai trovato una vulnerabilità da segnalare nella relazione di laboratorio.
4. DNSSEC: firme digitali, non cifratura
Il DNS classico non verifica chi ha scritto la risposta: un attaccante può avvelenare la cache (DNS cache poisoning) e farti risolvere banca.com verso il suo IP. DNSSEC (DNS Security Extensions) risolve questo aggiungendo firme crittografiche (RRSIG) su ogni RRset, con catena di fiducia fino alla root.
Firma del RRset
Ogni insieme di record dello stesso tipo è firmato con chiave privata della zona. Il resolver verifica con DNSKEY pubblica.
Catena di fiducia
DNSKEY contiene chiave pubblica. DS nella zona parent certifica la chiave child, fino al trust anchor root.
Prova di non-esistenza
Per dire "questo nome non esiste" in modo autenticato, senza permettere zone walking enumerativo (NSEC3 con hash).
DNSSEC non cifra le query! Un osservatore vede ancora cosa stai chiedendo. Per la privacy serve DoH (DNS over HTTPS, porta 443) o DoT (DNS over TLS, porta 853). DNSSEC garantisce autenticità e integrità, non riservatezza. Confondere questi due punti è errore grave all'orale.
Impatto su TCP: una risposta DNSSEC può contenere RRSIG a 1024+ bit, DNSKEY, NSEC. Una query A + RRSIG può facilmente superare 1232 byte. Risultato: molto più traffico DNS finisce in TCP, come previsto da RFC 7766 (DNS over TCP should be supported).
5. DNS Dinamico (DDNS): IP che cambia, nome che resta
Il DDNS aggiorna automaticamente il record A/AAAA associato a un hostname quando l'IP pubblico del cliente cambia, tipico nelle linee domestiche con IP dinamico.
Nelle ADSL/FTTC/FTTH domestiche l'ISP assegna IP pubblico dinamico che ruota ogni 12-24h o ad ogni riavvio router. Se vuoi raggiungere un NAS, telecamera IP, server Minecraft o VPN domestica dall'esterno, non puoi affidarti all'IP. Serve un nome stabile che segua l'IP.
Scenario operativo completo
IP dinamico
Vuoi accedere a 82.55.12.34 ma domani diventa 82.55.44.91. Port forwarding inutile se non sai l'IP.
Client DDNS sul router
Ogni 5 min controlla "qual è il mio IP pubblico?" via http://checkip.dyndns.org. Se cambia, invia update autenticato.
Nome fisso
miarete.ddns.net → sempre IP attuale. Puoi creare CNAME o A aggiornato via API RFC 2136.
In aula abbiamo un Raspberry Pi con telecamera. Il router di lab ha IP pubblico dinamico. Configuriamo DuckDNS lab5f.ddns.net: il Pi ogni 5 minuti lancia il curl. Da casa apri lab5f.ddns.net:8000 e vedi streaming. Se domani l'IP cambia da 95.233.10.5 a 95.233.22.18, DuckDNS aggiorna in 60s e il link continua a funzionare. Senza DDNS dovresti chiedere a qualcuno in lab "che IP avete oggi?".
Provider comuni: No-IP (piano free con conferma ogni 30 gg), DuckDNS (free, open source, integrato in OpenWRT, Fritz!Box, Synology), DynDNS (ora a pagamento). Molti router hanno già sezione DDNS nel firmware: basta inserire hostname, user, pass.
6. Verifica / Esercizio pratico
🔬 Attività – Analizziamo il traffico DNS reale
Hai catturato con Wireshark 3 minute di navigazione in laboratorio. Il file contiene 120 query DNS.
- Conta quante query sono su UDP/53 e quante su TCP/53. Perché quelle TCP ci sono solo quando interroghi
grande-istituto.eduche ha 15 TXT con SPF/DKIM + DNSSEC? - Trova un pacchetto con
dns.flags.truncated = 1. Cosa fa il client subito dopo? Descrivi la sequenza completa. - Un compagno dice "AXFR va su UDP perché è più veloce per clonare la zona". Smentisci con RFC e motivi di affidabilità.
- Progetta DDNS per accedere al PLC di laboratorio dall'esterno: scegli provider, porta, tempo TTL del record, e spiega come il client rileva il cambio IP.
1. UDP vs TCP: 112 su UDP (93%) – tipiche A/AAAA/MX. 8 su TCP (7%) tutte verso grande-istituto.edu perché risposta 1840 byte (TXT 15x + RRSIG) > 1232 byte EDNS0 → TC=1 → retry TCP. Con DNSSEC è normale.
2. TC flag: Pacchetto #47 server→client TC=1. Client in #48-50 fa TCP handshake su 53, #51 ripete query con 2-byte length prefix, #52 riceve risposta full 1840 byte. Poi FIN. In Wireshark vedi DNS over TCP.
3. AXFR no UDP: RFC 5936 §4: AXFR must use TCP. UDP non garantisce ordine, può perdere pacchetti, non gestisce risposte >64KB. Una zona da 5000 record richiede affidabilità, altrimenti secondario rimane inconsistente. UDP sarebbe insicuro anche per poisoning durante transfer.
4. DDNS PLC: Scelgo DuckDNS (gratis, token, OpenWRT compatibile). Hostname plc-5f-lab.duckdns.org. TTL 60s (basso per propagazione rapida quando IP cambia). Client su router OpenWRT: script ogni 5 min curl https://www.duckdns.org/update?domains=plc-5f-lab&token=XXX&ip= (IP auto-detected). Rilevamento: se curl ifconfig.me != ultimo IP salvato → update. Port forward 502 → 192.168.1.50:502 (Modbus TCP) + firewall solo IP scuola/WAN list. In più VPN WireGuard su 51820 per sicurezza.
7. Riepilogo e concetti chiave
📚 Prossimo passo – Posta elettronica SMTP POP3 IMAP MIME
Ora che sai come i nomi diventano IP e come proteggerli con DNSSEC/DDNS, vedremo cosa succede quando su quell'IP c'è un mail server: come SMTP consegna, come POP3/IMAP recuperano, e come MIME trasporta allegati. Porta con te Wireshark: snifferemo una sessione SMTP.