Resumen

  • Publicado como BCP 16 en julio de 1997, RFC 2182 trató la ubicación de servidores como un problema operativo de fiabilidad.
  • Su recomendación de tres servidores para la mayoría de las zonas organizativas exigía que al menos uno estuviera bien separado de los demás.
  • La norma era una guía: el listado de servidores no demuestra independencia de rutas, energía, proveedores ni disponibilidad real.

Una zona podía publicar tres servidores de nombres y disponer de una sola ruta práctica para obtener una respuesta. Si los tres dependían del mismo enlace, edificio o suministro eléctrico, una avería podía dejar fuera de servicio a todo el conjunto. El número parecía redundante; las dependencias no lo eran.

Ese fue el problema operativo que abordaron Robert Elz, Randy Bush, Scott Bradner y Michael Patton en RFC 2182, «Selection and Operation of Secondary DNS Servers». El IETF lo publicó en julio de 1997 como Best Current Practice 16. No era un nuevo protocolo DNS. Pretendía que la redundancia prevista por el sistema funcionara fuera del fichero de zona.

DNS ya exigía varios servidores autoritativos para una zona delegada. RFC 2182 separó dos funciones que podían confundirse. El primario conserva los datos configurados localmente; el secundario los obtiene del primario mediante una transferencia de zona. Pero ni los resolutores ni la zona padre ordenan las respuestas según esa distinción. Para el resto del DNS son varios servidores autoritativos publicados. Un secundario solo ayuda si los clientes pueden alcanzarlo cuando otro servidor —o la infraestructura que comparten— deja de responder.

Los autores partían de problemas operativos que afirmaban ya observar: malas elecciones de servidores secundarios. La ubicación geográfica y la diversidad de conectividad podían aumentar la fiabilidad y mejorar el rendimiento. Situar todos los servidores en el mismo lugar era una mala práctica explícita. Una caída del enlace, del sitio, del edificio, de la sala o de la alimentación podía desconectarlos a todos. No se trataba de suponer que cualquier máquina remota era segura, sino de preguntar qué fallos podían afectar a varias a la vez.

RFC 2182 recomendó tres servidores para la mayoría de las zonas de organizaciones, con al menos uno situado claramente lejos de los otros. Cuatro o cinco podían tener sentido si se necesitaba más fiabilidad. Añadir servidores sin límite tampoco era mejor: los conjuntos NS grandes aumentaban el tamaño de los paquetes DNS y las oportunidades de que una configuración errónea pasara inadvertida. La cantidad era una referencia dentro de una decisión de ubicación, no un umbral universal de cumplimiento.

El consejo también planteaba una dependencia práctica: alguien debía alojar la copia remota. El RFC describía a organizaciones de tamaño parecido que intercambiaban servicio secundario. Como los datos transferidos ya eran públicos, esa cooperación no revelaba información confidencial. Repartía la redundancia entre operadores, pero exigía mantener las transferencias, los números de serie y la accesibilidad.

El BCP no midió si las organizaciones seguían sus recomendaciones ni si una topología concreta sobrevivía a una caída. Un conjunto NS publicado no demuestra que dos proveedores usen tránsitos distintos, que sus instalaciones tengan energía independiente o que las rutas sigan separadas bajo presión. «Tres servidores» demuestra un recuento, no una auditoría de los caminos de fallo.

El documento de 1997 también contiene una afirmación sobre las respuestas DNS negativas que quedó anticuada. Decía que, por regla general, las respuestas negativas no se almacenaban en caché. RFC 2308 normalizó el almacenamiento negativo al año siguiente y la errata 4631 del RFC Editor señaló después que aquella generalización era inexacta. Hasta las mejores prácticas operativas tienen fecha e historia de mantenimiento.

La idea duradera de RFC 2182 era más concreta que un número mágico: la redundancia depende de las dependencias. El tercer servidor importa cuando cambia qué elementos pueden fallar juntos.

Fuentes