Resumen

  • La recomendación de tres servidores para la mayoría de las zonas organizativas exigía que al menos uno estuviera realmente alejado en geografía y topología.
  • Una dirección anunciada pero inaccesible obliga a resolutores de muchas redes a probar, esperar y reintentar, y puede reducir la fiabilidad aparente de toda la zona.
  • NS, respuesta autoritativa, serial SOA y transferencia de zona son comprobantes distintos; ninguno garantiza por sí solo datos idénticos, infraestructura independiente o servicio final disponible.

El plural del archivo de zona

BCP 16 se publicó en julio de 1997 para corregir una ilusión muy sencilla. Varios procesos podían responder por una zona y, aun así, desaparecer ante el mismo corte. Si todos estaban en la misma habitación o detrás del mismo enlace, la replicación protegía contra la avería de una máquina, no contra la pérdida del servicio.

RFC 2182 exigió separación geográfica y topológica. La primera distribuye riesgos de edificio, energía y entorno físico. La segunda distribuye rutas, enlaces y proveedores. Un mapa con puntos lejanos no prueba caminos distintos; dos contratos tampoco prueban que no exista una dependencia común.

De ahí que “tres” fuera una guía condicionada. Dos servidores cuidadosamente situados podían bastar, pero una indisponibilidad prolongada dejaba sólo uno. Para la mayoría de las zonas de organizaciones, el documento recomendó tres, con al menos uno bien separado. Cuatro o cinco podían servir a necesidades mayores. El número nunca sustituyó el análisis de qué podía fallar al mismo tiempo.

El servidor que hace esperar al mundo

Una dirección incluida en la respuesta debe ser alcanzable desde las redes cuyos resolutores la recibirán. Un host detrás de un cortafuegos, una conexión intermitente o una interfaz sólo interna no añade una segunda autoridad útil para Internet.

El resolutor aprende la falta de alcance mediante fracaso. Envía la consulta, espera el timeout y repite porque el silencio también puede ser pérdida transitoria. El programa que originó la búsqueda puede abandonar antes de que esa investigación termine. Después, otros resolutores repiten el mismo experimento desde otros lugares.

El texto original afirmaba que la ausencia de resultado no se almacenaba en caché. La errata editorial 4631, retenida para actualizar el documento, aclara que RFC 2308 introdujo caché negativa según comportamiento y configuración. Esa precisión histórica no convierte una dirección inalcanzable en redundancia: sigue exportando sondeos y retrasos a quienes no controlan la red.

La referencia podía además circular entre resolutores. Por eso no bastaba con que la primera máquina alcanzara el servidor. Todas las direcciones del RRset debían ser adecuadas para su audiencia. No era válido ocultar una dirección problemática ni darle un TTL especial mientras las demás se presentaban normalmente. Cuando la visibilidad interna y externa difería, había que diseñar vistas y nombres coherentes para cada lado.

Cuando añadir copias resta control

Muchos servidores agrandan los paquetes y acercan las respuestas a límites que tienen consecuencias de rendimiento. También multiplican configuraciones, relaciones de transferencia, versiones de software y responsables. Cada copia adicional puede quedar mal configurada o averiada sin que nadie la detecte.

Los servidores stealth ofrecen una salida más precisa. Una organización puede mantener copias autoritativas locales para seguir resolviendo durante una desconexión externa sin anunciarlas todas en NS. Publicarlas obligaría al resto de Internet a probar una colección que comparte el mismo enlace caído. La utilidad local no implica publicidad global.

La versión forma parte de la disponibilidad

El secondary consulta el serial SOA para saber si debe actualizar su copia. El primary debe incrementarlo con cada cambio. Si un error eleva demasiado el valor, reducirlo directamente puede ser interpretado como retroceso; los servidores que vieron el número alto pueden ignorar la corrección.

RFC 2182 prescribe un recorrido por incrementos válidos conforme a RFC 1982. En cada etapa se espera y se comprueba que todos los secundarios relevantes adoptaron el valor antes de continuar y cruzar el punto de vuelta. La seguridad de la operación reside en las observaciones intermedias, no en una orden única.

Eso separa los comprobantes. NS acredita que un nombre fue anunciado. Una respuesta acredita la actividad de un proceso. SOA muestra el serial observado en un instante. Una transferencia terminada acredita transporte. Falta todavía saber si la versión se cargó y se sirve, si los datos coinciden, si el camino es independiente y si la aplicación resulta accesible.

El RFC tampoco ofreció una garantía de seguridad. Indicó que no resolvía los problemas existentes y advirtió que un secondary comprometido podía afectar a hosts del dominio. La independencia útil debe combinar disponibilidad y confianza.

La aportación histórica de RFC 2182 fue cambiar la pregunta. Ya no basta “¿cuántos servidores hay?”. Hay que preguntar qué puede derribarlos juntos, quién puede llegar a cada dirección y qué versión responde realmente.

Fuentes

  1. RFC 2182 — Selection and Operation of Secondary DNS Servers
  2. Información de RFC 2182
  3. RFC 1982 — Serial Number Arithmetic
  4. RFC 2181 — Clarifications to the DNS Specification
  5. RFC 2308 — Negative Caching of DNS Queries
  6. Erratas de RFC 2182