¿Por qué solo hay 13 grupos de servidores raíz en todo el mundo?

1. La restricción estricta del protocolo: 512 bytes

1.1 MTU de IPv4 y UDP sin fragmentar

Las primeras redes ARPANET / IPv4 exigían una MTU mínima de 576 bytes. Todos los hosts tenían que poder recibir paquetes de ese tamaño; de lo contrario, ni siquiera se podía garantizar la conectividad básica (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.

• Longitud total de 576 bytes − encabezado IP típico de 20 bytes − encabezado UDP de 8 bytes ≈ 548 bytes utilizables (con opciones IP el encabezado puede llegar a 60 bytes, lo que deja menos)
• RFC 1035 § 4.2.1 fijó la potencia de dos más conservadora, 512 bytes, como límite estricto de DNS sobre UDP: es seguro incluso cuando el encabezado IP lleva todas las opciones
• Si una respuesta UDP supera los 512 bytes, debe truncarse y marcarse con el indicador TC, lo que obliga al cliente a recurrir a TCP; y el handshake de tres vías de TCP multiplica la latencia de la primera resolución

Es decir, "la lista completa de servidores raíz debe caber en un solo paquete UDP de 512 bytes"; de lo contrario, todas las consultas a la raíz del mundo tendrían que ir por TCP, algo casi catastrófico con el hardware de los años 80.

1.2 Distribución de bytes del mensaje DNS

Estructura completa de la respuesta a una consulta de los registros NS de . (el servidor devuelve todos los registros NS raíz más los registros A glue):

Header   (12 bytes)

Fórmula de la longitud total:

Sustituyendo el límite de 512 bytes:

En teoría esto permite hasta 15 grupos, pero hace falta margen para las firmas DNSSEC, el pseudorregistro OPT de EDNS0 y el relleno de campos, así que se quedó en 13 grupos: RFC 2010 (1996) estableció los criterios operativos de los servidores raíz, y la cifra no ha cambiado desde que M-root entró en servicio al año siguiente.

1.3 Compruébalo tú mismo: <code>dig +noedns -t ns .</code> devuelve unos 490–510 bytes

Esa es la teoría. Ahora consultemos de verdad un servidor raíz con dig y veamos qué tamaño tiene la respuesta real:

$ 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 registros NS en total, se omiten c–l)
.                       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
…  (caben los 13 registros 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
↑ solo caben 2 registros AAAA: el paquete está lleno

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

La línea clave está al final: una respuesta total de unos 490–510 bytes, holgadamente por debajo de 512 (la cifra exacta depende de a qué raíz preguntes y de cuántos registros glue IPv6 se devuelvan), lo que coincide con el presupuesto de bytes anterior. Fíjate en el indicador +noedns: dig envía EDNS0 por defecto, y así la respuesta supera los 800 bytes. Precisamente por eso los 512 bytes dejaron de ser un límite estricto cuando EDNS0 se generalizó, pero para entonces el 13 ya estaba fijado.

2. ¿De dónde sale el 13? Breve historia

Esta cifra no se fijó desde el principio. El número de servidores raíz pasó por varias ampliaciones; desde que M-root (WIDE, Japón) entró en servicio en 1997, no ha vuelto a cambiar:

Una vez fijada la cifra en 13, los nombres con letras de la A a la M no cambian nunca: solo se actualiza el hardware y se añaden réplicas anycast. El archivo de pistas raíz de internet (named.root) lleva mucho tiempo integrado en el código de miles de millones de resolutores recursivos y clientes stub; cambiar un solo número supondría actualizar todo internet.

3. Pero ¿de verdad hay solo 13 máquinas en todo el mundo?

No. Es el malentendido más común. "13 grupos de servidores raíz" se refiere a 13 nombres NS (a–m.root-servers.net), cada uno asociado a una dirección IPv4 y una IPv6, no a 13 máquinas físicas.

Detrás de cada IP hay un clúster anycast: cientos de centros de datos de todo el mundo anuncian a la vez la misma dirección IP por BGP, y la consulta DNS de cada usuario se enruta a la réplica más cercana según el RTT. Cuando un servidor raíz "se cae", normalmente solo significa que la réplica de una ciudad está en mantenimiento; la resolución global no se ve afectada.

Estado de los 13 grupos de servidores raíz en 2024

China continental (Pekín, Shanghái, Shenzhen, Guangzhou, Hefei y otras ciudades) alberga nodos de réplica anycast de varios servidores raíz, como F / I / J / K / L; el RTT medido hacia los servidores raíz desde China suele ser inferior a 20 ms.

4. Con EDNS0, los 512 bytes dejaron de ser un límite real

Quizá te preguntes: hoy en día son habituales los paquetes DNS de 4 KB o más, así que ¿por qué no "superar el 13"?

• EDNS0 (RFC 2671 en 1999; actualmente RFC 6891): negocia una carga útil UDP mayor (normalmente 4096 bytes) y todos los resolutores modernos lo admiten
• DNSSEC exige EDNS0, porque solo los datos de las firmas ya superan con creces los 512 bytes
• Fallback a TCP: el handshake de tres vías de TCP más TLS / cookies ya resulta barato hoy en día

Pero la lista de servidores raíz es ya un consenso de toda la red: todos los resolutores recursivos del planeta tienen estos 13 grupos fijados en su archivo de pistas (named.root), y detrás de esos resolutores hay miles de millones de dispositivos. El incentivo para cambiarlo es nulo, y el riesgo es fracturar internet a escala mundial, así que es casi seguro que esta cifra seguirá siendo 13 para siempre.

En resumen: los "13 grupos" quedaron obsoletos físicamente hace mucho, pero en la práctica de ingeniería son imposibles de cambiar.

5. Puntos clave

1. Razón histórica: límite de 512 bytes de DNS sobre UDP → techo matemático de 15 grupos → se eligen 13 para dejar margen, fijados desde que M-root entró en servicio en 1997
2. Inercia del protocolo: actualizar los archivos de pistas de miles de millones de dispositivos no es viable, así que nunca cambia
3. Capacidad real: más de 1395 nodos de réplica anycast, con un riesgo de punto único de fallo casi nulo
4. Accesibles desde China: varios servidores raíz, como F / I / J / K / L, tienen réplicas en China continental, con un RTT medido < 20 ms