Resumen

  • El tráfico de consultas y el tráfico de distribución de la zona raíz son libros contables distintos.
  • En el banco de pruebas de Ilyas Rahimi, BIND, dos configuraciones de Unbound y Knot Resolver superaron la referencia media usada para el modelo convencional, con diferencias gobernadas por la frecuencia y la lógica de actualización.
  • El periodo fue breve y controlado; los resultados no demuestran que LocalRoot siempre consuma más ancho de banda ni que menos consultas impliquen más resiliencia o privacidad total.

Cambiar de patrón no elimina la dependencia

En el modelo normal, el resolver intercambia muchas preguntas pequeñas con instancias públicas de la raíz. Con LocalRoot, la mayor parte de esas preguntas desaparece del camino exterior. Pero la información sigue naciendo fuera del resolver y cambia varias veces al día. La interacción pasa de ser impulsada por consultas a ser impulsada por publicaciones.

Rahimi hizo comparables ambos lados en bytes por resolver y día. Para las consultas utilizó siete días de RSSAC002; para la distribución capturó cuatro días de tráfico real de actualización en un entorno virtual. La tabla de tráfico convencional osciló, salvo un valor atípico de f-root, aproximadamente entre 0,67 y 1,34 MB diarios por resolver. El modelo de escala usó cerca de 2 MB como media general.

No es una lectura directa de cada máquina. Las cifras RSSAC combinan volumen agregado, cubos de tamaños y fuentes únicas aproximadas. Conservan suficiente señal para comparar, pero no autorizan una afirmación exacta sobre cualquier red.

La diferencia está en cuándo se descarga

BIND, usando transferencias DNS, movió alrededor de 1,45 MB por cambio y promedió 4,35 MB diarios. Unbound por DNS movió unos 1,31 MB por actualización y promedió 3,93 MB. Ambos consultaban el SOA y transferían cuando avanzaba el serial.

El Unbound configurado con HTTPS descargaba la zona completa cada treinta minutos, aunque no hubiera cambio: 2,19 MB por descarga, 48 veces al día, 105,12 MB. El informe atribuye ese pico a un bug, confirmado como tal en una comunicación con un desarrollador sénior. Presentarlo como “el coste de HTTPS” borraría la causa observada.

Knot Resolver también empleó HTTPS, pero realizó aproximadamente una descarga diaria y promedió 2,65 MB. El contraste muestra que el transporte por sí solo explica poco. La detección previa de cambios, la frecuencia, la transferencia incremental y los reintentos escriben la factura.

La copia atraviesa varias puertas

El Internet-Draft de julio de 2026 sobre la población de resolvers con la zona raíz propone que la implementación descubra o configure fuentes, priorice una eficiente y compruebe la frescura antes de bajar el objeto completo. Una respuesta HEAD o una consulta SOA puede evitar trabajo innecesario. Un serial menor debe rechazarse; un fallo puede llevar a otra fuente y, al agotarlas, a esperar un intervalo de refresco.

Después de recibir los bytes, el objeto todavía no es apto. La implementación valida ZONEMD y autentica ese registro con DNSSEC y el trust anchor raíz de IANA. Solo entonces puede activarlo. Una copia indisponible o caducada exige volver a consultas normales, con un límite que no supere el SOA expire.

RFC 8806 exige además que la zona sea completa e idéntica a la raíz pública, que las respuestas firmadas se validen y que el servicio local solo responda a resolvers del mismo host. LocalRoot cambia el lugar de ejecución; no convierte una copia en una autoridad independiente ni permite servir datos viejos.

Una conclusión acotada

La observación LocalRoot duró cuatro días y la referencia siete. No se midieron latencia, coste de CPU, complejidad operativa ni resultados de incidentes. La población global de resolvers fue aproximada a partir de fuentes únicas. Versiones futuras, otras configuraciones y diferentes tasas de cambio pueden alterar la relación.

El hallazgo sólido es metodológico. No sustituir bytes por consultas, ni consultas por privacidad, ni validación por frescura. Un camino puede ser ligero porque dejó de actualizar. Otro puede ser pesado porque repite un archivo sin cambios. Y una copia actual puede fallar al activarse o al regresar a raíces remotas.

Un recibo por decisión

Cada ciclo necesita conservar: consultas y bytes de cliente, control de serial, fuente, bytes nuevos y repetidos, errores y reintentos, mecanismo de transferencia, versión y configuración, timers SOA, ZONEMD, DNSSEC, hash, activación, vencimiento, fallback, latencia y resultado visible.

El valor aparece al relacionar esos recibos sin fundirlos. Solo así una reducción de consultas puede convivir honestamente con un aumento de distribución, y una ganancia de privacidad localizada puede convivir con observadores que no desaparecieron.

Fuentes

Informe de Rahimi, NLnet Labs, APNIC, borrador de Kumari y coautores y RFC 8806.