Versión ejecutiva (del FAQ de www.nic.cl:

NIC Chile refresca su zona cada 30 minutos (a las 0 y 30 minutos de cada hora), con los cambios efectuados en los nombres de dominio hasta ese momento.

Además, debe considerar que la información DNS puede tardar hasta dos días en propagarse por Internet.

Versión completa:

Cómo funciona el DNS

El DNS es un sistema altamente distribuido y “debilmente coherente”, en el sentido que se puede asegurar que dentro de una ventana tiempo todos sus componentes deberían tener la misma información, pero ese tiempo no es instantáneo. Los cambios en DNS tardan en “propagarse” a través de Internet.

Primero identifiquemos los distintos tipos de actores en la arquitectura DNS. En un orden desde lo “más cercano a la autoridad”, tenemos:

• Padre de un dominio: los DNS autoritativos de la zona superior en la jerarquía DNS. Acá se encuentra NIC Chile, que es el padre de todos los dominios .CL
• Autoritativos para un dominio: los DNS que se registran en NIC Chile como “servidores NS” para un dominio. Son los también llamados “primarios y secundarios” de una zona.
• “Resolvers” o Recursivos: estos son los intermediarios que resuelven finalmente la pregunta “¿qué IP tiene este nombre?”, recorriendo la información de los autoritativos. Generalmente los resolvers están en los ISPs, empresas, universidades; dando servicio a todos sus clientes.
• “Stubs”: son servicios que almacenan localmente, en los celulares, tablets, notebooks o PCs de los usuarios; las consultas DNS que hace un usuario.

Entonces, puede haber información de un nombre de dominio en cualquiera de estos lugares (y otros más que no mencionamos por simplicidad, como los “forwarders”), y cada uno de ellos tiene el derecho de mantener un registro en una memoria interna llamada “caché” y seguir utilizándola durante ese tiempo, sin necesidad de resolverlo nuevamente. Cuando se hace un cambio en NIC Chile, es complejo responder cuánto tiempo tardará un usuario final en ver los cambios. Depende de:

1. publicación de cambios en zona CL por NIC Chile
2. TTLs de caché de NS en zona CL de NIC Chile
3. TTLs de caché de NS en zonas autoritativas
4. estado del caché de los resolvers
5. estado del caché de los stubs del usuario
6. cachés internos de las aplicaciones como navegador, lector de correo, etc.

NIC Chile solo puede asegurar y es responsable de lo que ocurra en las primeras 2 etapas. La 3 depende del DNS primario de la zona y la 4 del ISP/empresa/universidad que posee el resolver. Solo las 5 y 6 dependen del usuario, en el sentido que un reinicio de su PC/teléfono/tablet puede refrescar la información del punto 5, y cerrar/abrir el navegador puede refrescar el punto 6.

Para DNS autoritativos: ¿Cómo puedo apurar los cambios?

El factor más importante que afecta al tiempo que tarda una zona en actualizarse es el TTL que poseen los registros relevantes. La recomendación en un estado normal es tener unos TTLs de 86400 segundos (1 día), que tiene la ventaja de asegurar que las respuestas serán rápidas para los usuarios finales y que existe un tiempo largo de estabilidad del dominio en caso de fallas de los DNS primarios. Sin embargo, cuando se realiza un cambio y se necesita un refresco rápido es conveniente bajar los TTLs con la anterioridad suficiente para acelerar la actualización, y una vez realizado el cambio, volver a los TTLs normales.

Una estrategia recomendada es:

1. verifique qué TTLs tienen los registros actuales
2. en un tiempo anterior al cambio de al menos segundos, rebaje los TTLs relevantes a una cantidad entre 60 y 300 segundos
3. realice el cambio en el momento elegido, usando TTLs pequeños como los del paso 2
4. pasado un tiempo prudente, al menos el del paso 1, y asegurándose que el dominio es estable desde todos lados, vuelva a cambiar los TTLs al estado del punto 1.

$ dig @IP-DNS-PRIMARIO midominio.cl ns $ dig @IP-DNS-PRIMARIO www.midominio.cl a

Diagnósticos: ¿Cómo puedo revisar lo que va pasando?

Existen herramientas para diagnosticar DNS en distintas plataformas. En este ejemplo utilizaremos “dig”, que es la recomendada por ISC, quienes desarrollan “bind”, el servidor autoritativo más popular.

La técnica es saber a quién dirigir las preguntas.

Lo primero cuando quiero diagnosticar mi dominio, es preguntar directamente a NIC Chile (el padre de los CLs). Esto se logra saltándose los intermediarios como los resolvers, indicando uno de los NS de .CL en la consulta, en este caso a.nic.cl:

$ dig @a.nic.cl midominio.cl ns

Con esto sabremos qué información es la que NIC Chile entrega, y es el primer paso en la cadena de resolución.

Luego puedo verificar qué información me están dando los DNS autoritativos del dominio, que debieran ser las correctas y definitivas:

$ dig @<IP DEL PRIMARIO> www.midominio.cl a $ dig @<IP DE SECUNDARIO 1> www.midominio.cl a $ dig @<IP DE SECUNDARIO 2> www.midominio.cl a $ ...

Finalmente puedo consultar a los recursivos relevantes, por ejemplo el que se utiliza en su lugar de trabajo, el del ISP del que se es cliente, y algunos que son abiertos como el de Google (8.8.8.8). Para esto:

$ dig @<IP DEL RECURSIVO> www.midominio.cl a

En caso que la información no sea la correcta, es importante en este paso verificar qué TTL responde el recursivo, por ejemplo:

“` $ dig @8.8.8.8 www.nic.cl a [ … ] ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12102 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;www.nic.cl.                    IN      A

;;ANSWER SECTION: www.nic.cl.             130      IN      A       200.7.7.3

;; Query time: 154 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Wed Jul 08 23:44:40 CLT 2015 ;; MSG SIZE  rcvd: 55 “`

En este caso se puede ver que el registro A da la IP 200.7.7.3 con un TTL de 72 segundos. Eso quiere decir que el recursivo aún mantendrá por 130 segundos más esa información. Eso puede dar una pista de cuándo fue que el recursivo obtuvo ese registro (restando el TTL del autoritativo con el del recursivo), y puede dar una pista que el registro fue obtenido hace bastante tiempo, quizás antes del cambio en los primarios.

Lamentablemente en caso de que el TTL del recursivo aún sea muy alto, no hay forma de forzar un refresco, salvo contactando a los administradores del recursivo y pidiendo un refresco manual del registro. Esto puede ser muy engorroso y es difícil que funcione sin tener los contactos adecuados, por lo que solo queda es esperar que transcurra ese TTL y que el recursivo refresque la información automáticamente.

Descargo: trabajo en el área técnica de NIC Chile, pero la información de este post es genérica del protocolo DNS.