¿Qué porcentaje de servidores de nombres honran TTL en estos días?

Hace algunos años tuve que hacer varios cambios de DNS en el transcurso de varias semanas a medida que movía partes de equipos de un centro de datos a otro. En el momento en que hice esto, aproximadamente el 95% de los servidores de nombres en el mundo parecía respetar el valor TTL, y aproximadamente el 5% ignoró el nuestro y creó el suyo. En otras palabras, el 95% del tráfico se movió dentro del TTL de 15 minutos que definimos. Otro 3% lo hizo en la primera hora, 1% en el primer día, y algunos rezagados tardaron hasta tres días.

(Sí, está bien, estoy confundiendo el porcentaje de tráfico con el porcentaje de servidores de nombres. Inserte handwaving).

Sin embargo, esto fue aproximadamente en 2001, y estábamos usando dinosaurios para transmitir paquetes a través de los tubos. Mi suposición es que los servidores de nombres de hoy se comportan mejor y habrá menos problemas con los rezagados. ¿Alguien tiene idea de qué porcentaje de tráfico cambiará dentro del TTL definido en estos días? ¿Todavía hay muchos servidores de nombres que ignoran TTL?

Nos mudamos recientemente y tuvimos todo tipo de problemas con DNS.

Cuando hicimos el cambio, la mayoría de los clientes comenzaron a atacar las nuevas IP de inmediato. Pero algunos seguían golpeando las viejas IP por semanas. Dejamos un servidor en funcionamiento durante aproximadamente un mes. Finalmente, revisamos los registros de IIS en la máquina antigua y llamamos a los clientes para que les dijeran que vaciaran DNS en los servidores DNS de la compañía o ISP. Eso hizo que el último de ellos se moviera.

Fue un pequeño número de personas las que mantuvieron las antiguas IP. De 20 mil clientes, tal vez 50 tuvieron problemas después del primer día.

Los valores de TTL (muy) largos de las semanas son honrados en mayo de 2011 por la mayoría de los servidores de nombres con resolución de DNS hasta 2 semanas.

En una prueba con just-dnslookup.com, que tiene 50 puntos de medición activos distribuidos globalmente, con un TTL de registro A establecido en 99.999.999 = 165 semanas (preciso: 165 semanas 2 días 9 horas 46 minutos 39 segundos) y un TTL predeterminado de 2 semanas (= SOA + NS TTL).

Primera búsqueda devuelve:

• TTL de 1 semana, para 3 de 50 puntos de medición
• TTL de 165 semanas, para 47 de 50 puntos de medición

Retornos de búsqueda consecutivos (convertidos al valor TTL original):

• TTL de 1 semana, para 3 de 50 puntos de medición
• TTL de 2 semanas, para 46 de 50 puntos de medición
• TTL de 165 semanas, para 1 de 50 puntos de medición

A continuación se muestra una segunda prueba (usando un dominio diferente) donde el TTL predeterminado se establece en 4 semanas (= SOA + NS TTL).

Primera búsqueda devuelve:

• TTL de 1 semana, para 3 de 50 puntos de medición
• TTL de 2 semanas, para 1 de 50 puntos de medición
• TTL de 165 semanas, para 46 de 50 puntos de medición

Retornos de búsqueda consecutivos (convertidos a la longitud TTL completa):

• TTL de 1 semana, para 3 de 50 puntos de medición
• TTL de 2 semanas, para 47 de 50 puntos de medición
• TTL de 165 semanas, para 0 de 50 puntos de medición

De los servicios de resolución públicos más conocidos / mejor conectados:

• El DNS público de Google [8.8.8.8 y 8.8.4.4] se reduce a 1 día.
• UltraDNS [rdns (1 | 2) .ultradns.net] honra las 165 semanas completas.
• Sprintlink [ns (1 | 2 | 3) .sprintlink.net] honra 165 semanas completas.

Recientemente moví DNS para algunos dominios que alojan mi sitio personal y sitios de proyecto de GoDaddy a DNS interno (sí, literalmente mi casa ). En general, todos los sitios a los que tengo acceso remoto respetaron el TTL e hicieron bien la transición. Todos los amigos que pude consultar me informaron lo mismo, tanto a través de un teléfono fijo como móvil. El único problema, irónicamente, fueron los principales servidores DNS de almacenamiento en caché en $ University donde trabajo, que parecían ignorar totalmente TTL para consultas en caché (e incluso ignorar el valor TTL que estaban asignando al resultado en caché).

Parece que, en general, TTL debe ser respetado. El 56% de los servidores autorizados para dominios .com y .net ejecutan BIND, lo que obviamente juega bien con los estándares. Cablevision / Optimum (al menos en NJ) parece estar usando Nominum CNS, que también respeta los TTL.

Esta no es una respuesta a su pregunta específicamente; sino más bien, cosas adicionales a considerar que juegan en su prueba:

Recurrentes DNS encadenados y demonios de almacenamiento en caché

No son solo los recursores DNS de borde los que almacenan en caché los registros. A veces las personas encadenan los recurrentes y esto agrega tiempo. Si esto debería hacerse o no, podría ser una larga discusión basada en lo que la gente intentaba resolver. He visto 3 niveles de recursión en un centro de datos. La mezcla de recursores puede tener resultados mixtos, ya que los decrementos TTL no siempre se conservan. Algunos sistemas operativos almacenan registros en caché. Algunos sistemas también utilizan cosas como nscd, dnsmasqy otros métodos para minimizar el impacto de los problemas recursor locales y para reducir la carga en sus recursors. Las características del sistema operativo varían según la versión de lanzamiento, el almacenamiento en caché de demonios, la versión de almacenamiento en caché de demonios, etc.

[Editar] Para reiterar, este no es un comportamiento normal de un recursor o demonio de almacenamiento en caché. No voy a avergonzar a los con errores, pero uno de ellos se considera no mantenido, a pesar de que está incluido en muchas distribuciones de Linux.

Caché de DNS de aplicación

Algunos navegadores también almacenan en caché los registros. Java y otras aplicaciones también almacenan en caché DNS. A veces puede limitar el ttl máximo dentro de las aplicaciones.

Los resultados finales pueden sesgarse

Los elementos anteriores pueden convertir fácilmente un TTL de 15 minutos en más de 60 minutos o incluso más.

Es por eso que a menudo sugiero que las aplicaciones o los sitios web deberían considerar tener múltiples nodos activos en su diseño de tolerancia a fallas, para que el cliente pueda determinar más rápido cuando un punto de entrada a su sitio haya fallado y manejar el problema automáticamente en una mansión elegante y predecible , cuando sea posible. Anycast es un método que utilizan algunas empresas para hacer que la conmutación por error sea algo transparente y no depender tanto de los cambios de DNS. También hay algunos métodos inteligentes de equilibrio de carga que se pueden hacer en JavaScript utilizando múltiples registros DNS.

Antigua pregunta, pero nuevas respuestas (2017, 6 años después):

1. Parece que casi todos los servidores DNS en todo el mundo se actualizan en 5 minutos
2. Google y OpenDNS le permiten vaciar manualmente un registro DNS, acelerando las actualizaciones de propagación

Antes de los experimentos a continuación, previamente había cambiado mi TTL de 14400 (segundos = 4 horas) a 300 (segundos = 5 minutos) pero lo hice 2 horas antes de los experimentos y como el TTL anterior fue de 4 horas, no estoy seguro de mi cambio habría salido si los servidores DNS no tuvieran su propio TTL mínimo.

Mis experimentos:

Experimento 1:

Cambié una traducción de nombre a IP (registro A) en el servidor autorizado y luego verifiqué:

• https://www.whatsmydns.net
• https://dnschecker.org

Después de 5 minutos (300 segundos), aproximadamente la mitad de los servidores globales verificados por esos sitios habían sido eliminados.

Después de 7 minutos, todo se había actualizado, excepto 1.

Experimento 2:

Google y OpenDNS le permiten vaciar manualmente su caché DNS para un dominio particular. Campo de golf:

• Vacíe la entrada de caché DNS de Google para su dominio: https://developers.google.com/speed/public-dns/cache
• Lavar los OpenDNS DNS entrada de caché 's para su dominio: https://cachecheck.opendns.com/

Actualicé otro registro A, y luego inmediatamente borré el caché DNS de Google. Tienen un captcha que me hizo "hacer clic en todos los cuadrados con signos" 3 veces, por lo que me llevó 1-2 minutos antes de que pudiera completar el color.

Después de 4 minutos, solo 1 servidor DNS verificado por esos sitios tenía la antigua dirección IP. Todos los demás habían sido actualizados.

Por lo tanto, borrar el caché DNS de Google y obligarlo a volver a consultar el servidor autorizado, parece haber acelerado la propagación global del DNS, quizás al activar actualizaciones de caché en todos los servidores del mundo.

Sin embargo, incluso sin la descarga de Google, parece que la propagación es en minutos, no en horas o días.