Resumen

  • APNIC PING difundió el 3 de septiembre un estudio controlado de enero de 2026 que compara las consultas ordinarias a la raíz con el tráfico de mantener una copia local.
  • En cuatro días, BIND con IXFR promedió 4,35 MB por resolvedor al día; Unbound mediante DNS, 3,93 MB; y Knot Resolver con una descarga HTTPS diaria, 2,65 MB.
  • Los 105,12 MB de Unbound sobre HTTPS provienen de descargar los 2,19 MB de la zona completa cada 30 minutos. El informe lo registra como un fallo confirmado, no como una propiedad de HTTPS.

En el laboratorio había cuatro máquinas que podían describirse con la misma etiqueta: raíz local. Dos miraban el número de serie y transferían cambios. Knot recuperaba una copia completa aproximadamente una vez al día. La cuarta descargaba el archivo completo 48 veces, hubiera cambiado o no.

Ese contraste es la noticia que recoge APNIC PING. George Michaelson conversa sobre el proyecto de Ilyas Rahimi con su autor y con Willem Toorop, de NLnet Labs. El experimento no transfiere autoridad sobre la raíz; mide la obligación de distribución que sustituye a muchas consultas pequeñas.

Cuatro comportamientos detrás de una etiqueta

El informe de Rahimi convierte ambos lados en MB por resolvedor y día. La base convencional usa RSSAC002 del 1 al 7 de enero: casi todas las letras quedan entre 0,67 y 1,34 MB, salvo F-root con 11,18 MB. Las capturas locales abarcan del 20 al 23 de enero en un entorno virtual controlado.

Configuración Actualización observada MB/resolvedor/día
BIND, DNS IXFR Transfiere al cambiar la serie, 2-4 veces al día 4,35
Unbound, DNS IXFR Transfiere al cambiar la serie, 2-4 veces al día 3,93
Knot Resolver, HTTPS Una copia completa aproximada al día 2,65
Unbound, HTTPS Copia completa cada 30 minutos 105,12

BIND movió unos 1,45 MB por actualización incremental y Unbound sobre DNS, 1,31 MB. Hubo dos, tres, cuatro y tres cambios diarios. La cuenta varía con los cambios reales.

Knot obtuvo el total menor del ensayo, pero mediante una frecuencia más conservadora. Menos bytes no significa que cada cambio llegue de inmediato. El caso de 105,12 MB muestra el error opuesto: Unbound recuperaba la zona completa sin comprobar primero si la serie había avanzado. El informe afirma que un desarrollador confirmó el fallo y esperaba corregirlo. Presentarlo como costo inherente de HTTPS borraría el hallazgo principal.

No decide si conviene desplegarlo

Todas las configuraciones locales superaron la referencia convencional del estudio durante las ventanas elegidas. Son cuatro días de capturas locales y siete de base. No se midieron latencia, costo de DNSSEC, complejidad, recuperación ni el valor de reducir dependencia de las rutas públicas hacia la raíz.

La población utilizada para escalar tampoco es un censo. El trabajo aproxima un resolvedor por cada origen único de RSSAC002. NAT y la agregación IPv6 rompen esa equivalencia. Multiplicar las diferencias por unos 59,1 millones de orígenes ilustra la escala lineal, pero no pronostica terabytes reales.

RFC 8806 mantiene el límite estable: una copia completa, vigente y validada con DNSSEC, con salida hacia raíces no locales antes de servir datos caducados. El Internet-Draft individual versión 07 propone verificar el estado antes de bajar toda la zona y estudia distribución HTTPS eficiente. Aunque su nombre histórico contiene bcp, la nota editorial dice que no se tramita como BCP. No es política vigente del IETF.

La conclusión operativa requiere observar la serie, si hubo transferencia completa o incremental, los bytes, la frecuencia, la validación y la edad de la copia. «Local» describe la ubicación, no demuestra el funcionamiento del ciclo.