Resumen

  • Exigir checksum UDP a todas las respuestas era una prueba concreta dentro de una cartera mayor: software actualizable, tiempo autenticado, host dedicado, redundancia, registros, capacidad, contactos y políticas de transferencia y recursión.
  • RFC 2010 dejó fuera la selección de sitios y administradores y el proceso ante incumplimientos; una respuesta íntegra no demostraba que la zona fuese correcta, la designación legítima o el servicio universalmente accesible.

Un checksum UDP puede detectar corrupción accidental de un datagrama. No puede decidir si la respuesta contiene la verdad que debía publicar la raíz. Esa distancia resume RFC 2010: cada control debía demostrar una cosa limitada. En lugar de tratar a un administrador capaz como garantía indivisible, el documento distribuyó la confianza entre pruebas que podían fallar por separado.

La red de servidores raíz de 1996 descansaba en voluntarios muy competentes y una coordinación laxa mediante el Network Information Center. El zone master, identificado entonces como IANA, escogía el software y podía exigir una actualización en 96 horas. El servidor debía usar un host dedicado, evitar servicios ajenos, cifrar la administración remota, tomar la hora de al menos dos servidores NTP autenticados y anunciar una sola interfaz de red aunque contara con varias conexiones físicas.

De la reputación a superficies observables

El acceso físico debía estar controlado. Alimentación y red necesitaban redundancia. Los sucesos de seguridad debían quedar registrados. La cifra histórica de capacidad —1.200 consultas por segundo de media con menos de cinco milisegundos de respuesta, y 2.000 como deseable— no es una recomendación moderna. Era una forma de convertir la palabra “margen” en una prueba.

AXFR quedaba restringido a destinos aprobados; el texto también describía transferencia completa por FTP, NOTIFY e IXFR. La recursión se desactivaba salvo una excepción estrecha por glue ausente. Los correos ordinarios merecían respuesta en 24 horas. Una interrupción imprevista o anunciada con menos de 24 horas requería una llamada. Máquina, instalación y persona de guardia formaban capas distintas del mismo servicio.

Ninguna capa certificaba a las demás. Un checksum no prueba contenido autorizado. Dos relojes no prueban disponibilidad global. Dos fuentes eléctricas pueden compartir subestación. Un registro prueba que se escribió un evento, no que se resolvió. Un aviso de caída no es un recibo de recuperación.

La lista termina antes de la política

RFC 2010 excluyó expresamente cómo elegir sitios y administradores y qué hacer ante la no conformidad. Por eso podía describir el deber operativo de un servidor sin legitimar a quien lo administraba ni crear una autoridad de ejecución. Confundir esas capas convertiría evidencia técnica en poder político por accidente.

El RFC fue Informational, hoy aparece como Legacy y no constituyó una recomendación respaldada por el IETF. RFC 2870 lo dejó obsoleto; RFC 7720 documentó después requisitos del servicio de nombres raíz. Esa historia demuestra cambio documental, no implantación completa ni práctica actual.

La primacía del código operativo de Lu Heng pide configuración y resultados, no símbolos. Su especificación inicial mínima separa coordinación de adopción automática, y sus capas de realidad mantienen aparte el texto, la ejecución y el efecto. RFC 2010 fue importante porque hizo discutible la evidencia de operación sin pretender haber resuelto la autoridad sobre la raíz.

Fuentes