Perché nel mondo esistono solo 13 gruppi di server root DNS?

1. Il vincolo rigido del protocollo: 512 byte

1.1 MTU IPv4 e UDP senza frammentazione

Le prime reti ARPANET / IPv4 imponevano un MTU minimo di 576 byte. Ogni host doveva poter ricevere pacchetti di queste dimensioni, altrimenti non si poteva garantire nemmeno la raggiungibilità di base (RFC 791).

Total Length is the length of the datagram, measured in octets,
including internet header and data.  This field allows the length of
a datagram to be up to 65,535 octets.  Such long datagrams are
impractical for most hosts and networks.  All hosts must be prepared
to accept datagrams of up to 576 octets (whether they arrive whole
or in fragments).  It is recommended that hosts only send datagrams
larger than 576 octets if they have assurance that the destination
is prepared to accept the larger datagrams.

• 576 byte di lunghezza totale − 20 byte tipici di intestazione IP − 8 byte di intestazione UDP ≈ 548 byte utilizzabili (con le opzioni IP l'intestazione può arrivare a 60 byte, lasciando meno spazio)
• La RFC 1035 § 4.2.1 ha scelto la potenza di due più prudente, 512 byte, come limite rigido per il DNS su UDP: un valore sicuro anche quando l'intestazione IP contiene tutte le opzioni
• Se una risposta UDP supera i 512 byte deve essere troncata con il flag TC impostato, costringendo il client a ripiegare su TCP; e l'handshake TCP a tre vie moltiplica la latenza della prima risoluzione

In altre parole, «l'elenco completo dei server root deve stare in un unico pacchetto UDP da 512 byte»: altrimenti ogni query alla root nel mondo avrebbe dovuto passare su TCP, cosa che sull'hardware degli anni Ottanta sarebbe stata quasi catastrofica.

1.2 La struttura in byte del messaggio DNS

La struttura completa della risposta a una query dei record NS di . (il server restituisce tutti i record NS della root più i record glue A):

Header   (12 byte)

Formula della lunghezza totale:

Sostituendo il limite di 512 byte:

In teoria ci starebbero fino a 15 gruppi, ma serve margine per le firme DNSSEC, lo pseudo-record OPT di EDNS0 e il padding dei campi, quindi ci si è fermati a 13 gruppi: la RFC 2010 (1996) ha definito i criteri operativi dei server root e il numero non è più cambiato da quando, l'anno successivo, è entrato in servizio M-root.

1.3 Provalo tu stesso: <code>dig +noedns -t ns .</code> restituisce circa 490–510 byte

Questa è la teoria. Ora interroghiamo davvero un server root con dig e vediamo quanto è grande la risposta reale:

$ dig +noedns -t ns .

; <<>> DiG 9.10.6 <<>> +noedns -t ns .
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35973
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 15

;; QUESTION SECTION:
;.                                IN      NS

;; ANSWER SECTION:
.                       430502  IN      NS      a.root-servers.net.
.                       430502  IN      NS      b.root-servers.net.
…  (13 record NS in totale, c–l omessi)
.                       430502  IN      NS      m.root-servers.net.

;; ADDITIONAL SECTION:
a.root-servers.net.     516909  IN      A       198.41.0.4
b.root-servers.net.     562547  IN      A       170.247.170.2
…  (ci stanno tutti i 13 record glue A)
m.root-servers.net.     516941  IN      A       202.12.27.33
a.root-servers.net.     516930  IN      AAAA    2001:503:ba3e::2:30
b.root-servers.net.     562547  IN      AAAA    2801:1b8:10::b
↑ ci stanno solo 2 record AAAA: il pacchetto è pieno

;; Query time: 8 msec
;; SERVER: 192.168.1.1#53
;; MSG SIZE  rcvd: 492

La riga chiave in fondo (una risposta totale di circa 490–510 byte, ben sotto i 512; il valore esatto dipende dalla root interrogata e da quanti record glue IPv6 vengono restituiti) corrisponde al budget di byte calcolato sopra. Nota il flag +noedns: per impostazione predefinita dig invia EDNS0, e la risposta supera abbondantemente gli 800 byte. È proprio per questo che i 512 byte hanno smesso di essere un limite rigido quando EDNS0 si è diffuso ovunque; ma a quel punto il 13 era già fissato.

2. Da dove viene il 13? Breve storia

Questo numero non è stato fissato fin dall'inizio. Il numero di server root è cresciuto in più fasi; dopo l'entrata in servizio di M-root (WIDE, Giappone) nel 1997 non è più cambiato:

Una volta fissato il 13, i nomi con le lettere dalla A alla M non cambiano mai: si aggiorna solo l'hardware e si aggiungono mirror anycast. Il file dei root hint di Internet (named.root) è da tempo incorporato nel codice di miliardi di resolver ricorsivi e client stub; cambiare un solo numero significherebbe aggiornare l'intera Internet.

3. Ma nel mondo ci sono davvero solo 13 macchine?

No. È l'equivoco più diffuso. «13 gruppi di server root» indica 13 nomi NS (a–m.root-servers.net), ciascuno associato a un indirizzo IPv4 e a uno IPv6, non 13 macchine fisiche.

Dietro ogni IP c'è un cluster anycast: lo stesso indirizzo IP viene annunciato via BGP contemporaneamente da centinaia di datacenter nel mondo e la query DNS dell'utente viene instradata al mirror più vicino in termini di RTT. Quando un server root «va giù», di solito significa solo che il mirror di una città è in manutenzione: la risoluzione globale non ne risente.

Stato dei 13 gruppi di server root nel 2024

La Cina continentale (Pechino, Shanghai, Shenzhen, Canton, Hefei e altre città) ospita nodi mirror anycast di diversi server root, tra cui F / I / J / K / L; l'RTT misurato verso i server root dall'interno della Cina è in genere inferiore a 20ms.

4. Dopo EDNS0, i 512 byte hanno smesso di essere un vero limite

Potresti chiederti: oggi i pacchetti DNS da 4KB o più sono comuni, quindi perché non «superare il 13»?

• EDNS0 (RFC 2671 nel 1999, oggi RFC 6891): negozia un payload UDP più grande (di solito 4096 byte) ed è supportato da tutti i resolver moderni
• DNSSEC richiede obbligatoriamente EDNS0, perché i soli dati delle firme superano di gran lunga i 512 byte
• Fallback su TCP: oggi l'handshake TCP a tre vie più TLS / cookie costa già poco

Ma l'elenco dei server root oggi è un consenso condiviso da tutta la rete: ogni resolver ricorsivo sulla Terra ha questi 13 gruppi scritti nel proprio file di hint (named.root), e dietro quei resolver ci sono miliardi di dispositivi. L'incentivo a cambiare è nullo e il rischio è una frattura di Internet a livello globale, quindi questo numero resterà quasi certamente 13 per sempre.

In sintesi: i «13 gruppi» sono superati da tempo sul piano fisico, ma impossibili da ribaltare sul piano ingegneristico.

5. Punti chiave

1. Motivo storico: il limite di 512 byte del DNS su UDP → un tetto matematico di 15 gruppi → scelti 13 per avere margine, fissati con l'entrata in servizio di M-root nel 1997
2. Inerzia del protocollo: aggiornare i file di hint su miliardi di dispositivi non è realistico, quindi non cambierà mai
3. Capacità reale: 1395+ nodi mirror anycast, che rendono quasi nullo il rischio di un singolo punto di guasto
4. Raggiungibili dalla Cina: diversi server root, tra cui F / I / J / K / L, hanno mirror nella Cina continentale, con un RTT misurato < 20ms