Cómo comprobar la propagación de DNS

De dónde viene la espera

Imagina la cadena que recorre una consulta. Tu dispositivo le pregunta a un resolutor recursivo, gestionado por tu proveedor de internet o por un servicio público. Si ese resolutor tiene una respuesta reciente en caché, devuelve la que tiene guardada sin preguntar a nadie más. Solo cuando esa caché ha caducado baja hasta los servidores raíz, el registro del dominio de nivel superior y, por último, tus servidores de nombres autoritativos, que son los que guardan el registro que editaste.

Así que cuando cambias un registro A, el nuevo valor existe en el segundo en que tu proveedor de DNS lo guarda. Cada resolutor que todavía tenga la respuesta antigua sigue sirviéndola hasta que su copia caduca. El TTL, time to live, es un número en segundos asociado al registro que le dice a los resolutores cuánto tiempo pueden guardarlo en caché. Un registro con un TTL de 3600 se puede servir desde la caché durante una hora tras haberse consultado, así que una hora es el peor caso para un resolutor que lo consultó justo antes de tu edición.

Por eso dos personas en la misma oficina pueden ver resultados distintos, y por eso limpiar tu propia caché no ayuda a nadie más. No hay una difusión global que esperar, solo muchos temporizadores independientes que van agotándose en momentos distintos.

Cómo comprobarlo desde varios resolutores

La forma manual es preguntar a varios resolutores la misma cuestión y comparar sus respuestas:

dig +short example.com @8.8.8.8      # Google Public DNS
dig +short example.com @1.1.1.1      # Cloudflare
dig +short example.com @9.9.9.9      # Quad9
dig +short example.com               # tu propio resolutor
dig +short example.com @ns1.yourdns.example  # autoritativo: la fuente de verdad

La consulta autoritativa es la importante. Si devuelve el nuevo valor, tu cambio es correcto y está completo, y todo lo demás es una cuestión de caché. Si devuelve el valor antiguo, el cambio no se guardó, editaste la zona equivocada o los servidores de nombres del dominio no son los que crees.

Para ver el tiempo de caché restante en lugar de solo el valor, quita +short y lee la columna del TTL:

dig example.com @8.8.8.8 | grep -A1 "ANSWER SECTION"

El número antes del tipo de registro cuenta hacia atrás a medida que envejece la copia en caché, lo que te dice exactamente cuánto tiempo más servirá ese resolutor la respuesta antigua. En Windows, nslookup example.com 8.8.8.8 hace la misma comparación sin herramientas adicionales. Una búsqueda de DNS por web que consulte desde muchas ubicaciones a la vez hace el mismo trabajo más rápido, y además cubre resolutores a los que no puedes llegar desde tu propia máquina.

Por qué puede tardar horas

• Manda el TTL antiguo, no el nuevo. Si el registro tenía un TTL de 86400 y lo bajas al hacer el cambio, los resolutores que ya tenían el registro antiguo en caché siguen teniendo derecho a un día entero. Bajar el TTL solo ayuda al siguiente cambio.
• Algunos resolutores ignoran los TTL cortos. Varios proveedores de internet imponen su propio mínimo, normalmente una hora o más, sin importar lo que diga tu registro.
• Los cambios de servidores de nombres son más lentos. Los registros NS a nivel de registro suelen tener un TTL medido en días, así que cambiar de proveedor de DNS de verdad puede tardar de uno a dos días en asentarse en todas partes.
• La caché negativa también cuenta. Si un nombre no existía cuando alguien lo buscó, la respuesta de "no existe" también se guarda en caché, durante el periodo que fije el campo mínimo del SOA de la zona.
• Cachés encadenadas. Un navegador guarda DNS en caché, el sistema operativo guarda DNS en caché, y un resolutor corporativo puede estar delante del público. Cada capa añade su propio retraso.
• Conexiones de larga duración. Las aplicaciones que resolvieron un nombre de host una vez al arrancar siguen usando esa dirección hasta que se reinician, sin importar lo que diga el DNS ahora.

Cómo hacer rápido el próximo cambio

1. Baja el TTL primero, y luego espera. Reduce el TTL del registro a 300 segundos y déjalo así al menos durante lo que dure el TTL antiguo antes de hacer el cambio real. Para entonces, todas las copias en caché tendrán ya el valor corto.
2. Haz el cambio. Con un TTL de 300 segundos, la mayoría de los resolutores lo recogen en cinco minutos.
3. Mantén el servidor antiguo respondiendo durante el solapamiento. No lo apagues en cuanto se actualice el DNS. Déjalo sirviendo hasta que el tráfico hacia él se detenga, y la migración pasará sin que nadie lo note.
4. Verifica contra los servidores de nombres autoritativos y varios resolutores públicos antes de darlo por terminado.
5. Vuelve a subir el TTL una vez que el cambio se haya asentado, para que el tráfico normal vuelva a beneficiarse de la caché.

Para un cambio de servidores de nombres no hay atajo, porque el TTL del registro no lo fijas tú. Cuenta con uno o dos días, y mantén a los dos proveedores de DNS sirviendo registros idénticos durante todo el proceso para que no importe a cuál le pregunte un resolutor.

Después de que el cambio se haya asentado

Comprobar unos cuantos resolutores a mano te dice hasta dónde ha llegado un cambio en el momento en que miras, lo cual es útil durante una migración e inútil el resto del tiempo. Los fallos que merece la pena detectar son los posteriores: un registro que cambia sin que nadie se dé cuenta, un servidor de nombres que deja de responder, una zona que caduca. La monitorización continua de DNS consulta desde muchas ubicaciones de forma periódica y avisa en cuanto la respuesta deja de coincidir con lo que debería ser, lo que también detecta el caso de "funciona desde aquí, falla desde allí" que una sola consulta no puede ver. Haz una consulta ahora con la herramienta de consulta DNS. Si el sitio no es accesible para ti pero funciona bien en otros sitios, está caído para todo el mundo o solo para mí continúa desde ahí.