Reinicio de NTP, DNS y DHCP tras una caída total de la red: un arranque ordenado según las dependencias

Objetivo

Reiniciar los servicios básicos de infraestructura de una red pequeña en un orden que permita que cada uno arranque correctamente, tras una caída total en la que NTP, DNS y DHCP estuvieron fuera de servicio a la vez.

Requisitos previos

Saber qué host ejecuta cada servicio; acceso por consola o fuera de banda a cada host, ya que el acceso remoto que depende de la red puede no funcionar todavía; que la conectividad básica de los propios hosts ya esté restablecida (alimentación eléctrica, enlaces de red físicos o virtuales activos); y que los propios servidores NTP, DNS y DHCP tengan direcciones estáticas, no obtenidas por DHCP.

Pasos

1. Levantar primero la hora, en los hosts que sirven NTP. La validación de certificados, la vigencia de los tickets de Kerberos y la correlación de marcas de tiempo en los registros durante el resto de la recuperación dependen de que los relojes estén razonablemente cerca de la hora correcta. Si el reloj de un servidor se desvió mucho durante la caída, conviene dejar que se corrija (por salto o por ajuste gradual) antes de que dependa de él cualquier cosa que compruebe periodos de validez de certificados. Un resolvedor que valida DNSSEC también falla si el reloj está muy desajustado. La dependencia, sin embargo, es circular: un servidor NTP cuyos upstream son nombres de host (un nombre de pool, servidores NTS) no puede alcanzarlos hasta que DNS funcione, así que solo ofrece la hora de su reloj de hardware o, si está configurada, su referencia local. Conviene darle al menos un upstream por dirección IP, o asumir que la hora se volverá a corregir cuando DNS esté activo.
2. Levantar después DNS, en los hosts que lo sirven. Muchos servicios se localizan entre sí, y validan certificados TLS, por nombre. Si DNS arranca antes que DHCP, incluso los hosts con configuración estática pueden resolver nombres desde el principio, incluido el propio servidor DHCP si en su arranque resuelve algo por nombre.
3. Levantar DHCP en último lugar de los tres. Los clientes que perdieron su concesión (lease) necesitan que DHCP vuelva a asignar direcciones; al servidor DHCP le conviene tener la hora correcta (marcas de tiempo de las concesiones, registros) y solo necesita DNS para las actualizaciones dinámicas de DNS, si están configuradas.
4. Volver a comprobar cada servicio desde un cliente antes de dar la red por recuperada: una comprobación de hora (si el reloj del cliente converge hacia el servidor NTP), una resolución de un nombre interno y de uno externo, y una renovación de concesión DHCP en un cliente de repuesto.
5. Solo cuando los tres servicios estén confirmados, reiniciar los que dependen de todos ellos: la autenticación (Kerberos/LDAP, que necesitan la hora correcta y nombres resolubles) y los servicios de aplicación que usan certificados de corta duración o descubrimiento de servicios por nombre.

Resultado esperado

Cada servicio debería arrancar sin quedar a la espera de alguno de los otros dos, ni fallar en silencio por su causa; los clientes deberían recuperar la conectividad completa en el mismo orden en que se levantaron los servicios, sin una segunda ronda de reinicios causada por una dependencia pasada por alto.

Límites y base de verificación

Este es un orden general propuesto, no un sustituto de un runbook específico de cada sitio: en una red donde la dirección del servidor DHCP es estática y DNS lo presta el mismo host que NTP, hay menos dependencias reales que ordenar. Los despliegues virtualizados o en contenedores, en los que los tres servicios se ejecutan como servicios de aplicación detrás de su propio balanceador de carga, pueden tener dependencias adicionales (el plano de control del hipervisor o del orquestador) que deben estar activas antes que cualquiera de los tres. No se afirma que exista ningún experimento ni medición en campo de este orden; se ha deducido a partir de las dependencias habituales de estos servicios respecto de la hora y la resolución de nombres, y un sitio concreto puede tener menos dependencias o distintas.