¿Cuánto tiempo tarda el DNS en actualizar nuevos registros? ¡Extraño comportamiento de DNS!

Tenía mi sitio personal en freehostia y ahora he cambiado a otro servidor. Ha pasado casi una semana y, por supuesto, a medida que los NameServers cambiaron para el nuevo host, realicé los cambios necesarios con domain-register-company, para mi dominio.

Ahora, cuando intento abrir mi sitio, a veces abre el nuevo sitio alojado, a veces abre la página 404 del sitio anterior.

Creo que 1 semana, digamos que incluso 4 días es mucho tiempo para que ocurra la propagación de DNS. ¿Es este un comportamiento extraño?

Cuando abro el sitio desde la dirección IP, se abre, pero cuando abro el sitio con un nombre de dominio, a veces se abre y a veces no. ¿Cualquier pista?

Lo intenté con dos de mis amigos, que nunca han visitado mi sitio, por lo que no tiene memoria caché dns en su máquina, se abrió para uno y no se abrió para el otro. Gracias

- Desde http://Squish.net, el
25.0% de las consultas serán devueltas por 66.40.52.47 (dns1.freehostia.com) vks.uni.cc. 3600 IN A 66.40.52.64
25.0% de las consultas serán devueltas por 66.40.66.152 (dns2.freehostia.com) vks.uni.cc. 3600 IN A 66.40.52.64
25.0% de las consultas serán devueltas por 72.55.164.113 (ns1.softuff.com) vks.uni.cc. 14400 IN A 72.55.164.113
25.0% de las consultas serán devueltas por 70.38.29.161 (ns2.softuff.com) vks.uni.cc. 14400 IN A 72.55.164.113

No entiendo qué es este 25%, por qué no es 100% o 50%
dns1.freehostia.com y dns2.freehostia.com eran servidores antiguos. ns1.softuff.com y ns2.softuff.com son nuevos servidores.

Mi respuesta a esta pregunta tiene una disminución del tiempo de propagación que vincularé en lugar de copiar + pegar aquí.

Más específicamente de su pregunta, me parece que los servidores de nombres autorizados no se han actualizado (o se enumeran incorrectamente, por lo que se consultan los incorrectos). Para ver qué servidor de nombres registra los servidores DNS locales que se están utilizando para el dominio, puede usar dig <domain.tld> NSlo siguiente:

$ dig spillett.net NS
;; ANSWER SECTION:
spillett.net.           316     IN      NS      ns1.nogoodnamesareleft.com.
spillett.net.           316     IN      NS      ns2.nogoodnamesareleft.com.

luego puede verificarlos para ver si todos tienen la dirección correcta para el nombre:

$ dig @ns1.nogoodnamesareleft.com www.spillett.net
;; ANSWER SECTION:
www.spillett.net.       349     IN      CNAME   spillett.net.
spillett.net.           349     IN      A       69.94.124.51
;; AUTHORITY SECTION:
spillett.net.           349     IN      NS      ns2.nogoodnamesareleft.com.
spillett.net.           349     IN      NS      ns1.nogoodnamesareleft.com.
;; ADDITIONAL SECTION:
ns1.nogoodnamesareleft.com. 3499 IN     A       69.94.124.137
ns2.nogoodnamesareleft.com. 3499 IN     A       78.105.118.25

(repita lo anterior para cada registro NS devuelto por su primera consulta)

Los valores TTL que devuelven las consultas directamente contra los servidores de nombres de su dominio siempre deben ser el valor real establecido en el registro de zona (son bajos en el ejemplo anterior ya que ese dominio se movió recientemente y olvidé volver a configurarlos cuando ' d terminado), donde-como para las consultas contra servidores no autorizados (es decir, uno de sus servidores de nombres locales predeterminados, que se consultará si dig no recibe una @<server>directiva) será cuánto tiempo antes de que ese servidor verifique (contra los servidores de nombres enumerados como registros NS para el dominio) si es necesario actualizar su versión en caché.

Verificar las pruebas anteriores para su dominio puede darle algunas pistas más sobre dónde se encuentra el origen del problema. Si está utilizando Linux y no lo tiene dig, generalmente se encuentra en un paquete llamado algo así dnsutils(se llama así en Debian y Ubuntu, supongo un arreglo similar en otras distribuciones): no hay duda de que hay muchos puertos para Windows ( esta es la primera página de aspecto relevante devuelta por Google ) aunque nunca he usado ninguna de ellas.

Parece que el servidor DNS que USTED está utilizando está almacenando en caché el resultado anterior.

El tiempo de almacenamiento en caché de un registro DNS generalmente depende del TTL (tiempo de vida), pero no todos los servidores DNS lo respetan.

Una cosa más (tal vez obvia) ... si está utilizando su servidor DNS VIEJO para búsquedas ... asegúrese de haber eliminado la zona anterior. :-)

Si funcionó para sus dos amigos, pero no para usted, recomendaría cambiar los servidores DNS que usa su computadora para las búsquedas ... incluso si es temporal.

Recomiendo cambiar los servidores de búsqueda DNS de su computadora a algo como OpenDNS ... solo para probar y ver.

http://www.opendns.com

208.67.222.222

208.67.220.220

Si nada de eso funciona ... háganos saber con qué nombre de dominio está teniendo el problema y estoy seguro de que alguien aquí lo buscará por usted y le dirá si se propagó o no.

Espero que esto ayude.

depende del registro dns ttl. una semana suena bastante larga. intente verificar cuáles son las respuestas para las consultas dns de todos los servidores responsables; visite, por ejemplo , http://www.squish.net/dnscheck/ , escriba su nombre de dominio, seleccione tipo: CUALQUIERA y ejecute la comprobación.

tal vez uno de los servidores involucrados todavía devuelve registros antiguos.

Una semana es tiempo más que suficiente para que ocurra cualquier propagación. Tuve un problema similar y el problema era que el servidor primario y el secundario no estaban sincronizados. Usé nslookup para verificar el estado actual. Si bien mi problema fue con los registros MX, es posible que desee verificarlo .

El único tiempo que debería tomar más que el TTL para actualizar sería si está cambiando los registros con su registrador. Por lo general, un registrador actualizará los registros una o dos veces cada 24 horas. Normalmente, sin embargo, estos registros son los que apuntan su dominio a sus servidores DNS.

Si está actualizando registros normales (A, PTR, CNAME, etc.) en sus servidores DNS, y están ejecutando bind, debería poder hacer un "rndc reload domain.name" (o "rndc reload domain .name IN view ") para programar una actualización inmediata.

Una última advertencia, los navegadores mantienen su propia caché, así como el cliente DNS del sistema operativo. Me ha frustrado más de una vez por una aparente falta de actualización cuando todo lo que realmente necesitaba hacer era "ipconfig / flushdns" en el cliente de Windows.

Los cambios de DNS son casi instantáneos; lo que creo que está preguntando es cuánto tiempo lleva propagarse si realiza cambios en el registrador.

Si cambia sus servidores de nombres en el registrador, puede incurrir entre 6 y 48 horas de tiempo de inactividad mientras los cambios se propagan en todo el mundo.

Si simplemente agrega o modifica registros a su consola de administración de DNS, los cambios son prácticamente instantáneos.