{"id":2342,"date":"2026-10-20T06:03:09","date_gmt":"2026-10-20T06:03:09","guid":{"rendered":"https:\/\/junglelabs.uk\/"},"modified":"2026-10-20T06:03:09","modified_gmt":"2026-10-20T06:03:09","slug":"what-is-dns-propagation-why-dns-changes-take-time","status":"publish","type":"post","link":"https:\/\/junglelabs.uk\/es\/what-is-dns-propagation-why-dns-changes-take-time\/","title":{"rendered":"\u00bfQu\u00e9 es la propagaci\u00f3n de DNS? \u00bfPor qu\u00e9 los cambios en DNS tardan tiempo"},"content":{"rendered":"

Actualizas los registros DNS de un dominio, guardas el cambio y esperas que el nuevo sitio web o servicio de correo funcione inmediatamente. Pero un compa\u00f1ero todav\u00eda ve el sitio web antiguo, un verificador en l\u00ednea muestra una direcci\u00f3n diferente o la entrega de correos electr\u00f3nicos se comporta de manera inconsistente. Este retraso se denomina com\u00fanmente Propagaci\u00f3n de DNS<\/strong>.<\/p>\n\n\n\n

La frase puede dar la impresi\u00f3n de que una \u00fanica actualizaci\u00f3n viaja a trav\u00e9s de un sistema centralizado de Internet. Sin embargo, DNS es distribuido. La informaci\u00f3n de dominio se almacena y almacena en cach\u00e9 entre servidores de nombres autorizados, resolutores recursivos, routers, sistemas operativos y aplicaciones. Cada sistema puede actualizar su informaci\u00f3n en un momento diferente.<\/p>\n\n\n\n

La mayor\u00eda de los cambios en DNS se hacen visibles a medida que expiran las cach\u00e9s y los resolvers obtienen registros actualizados. La duraci\u00f3n de este proceso depende del Time to Live (TTL) previo del registro, del comportamiento de los resolvers y de si la configuraci\u00f3n DNS autoritativa es correcta. No existe un tiempo universal que garantice que todos los usuarios vean la nueva respuesta.<\/p>\n\n\n\n

Esta gu\u00eda explica qu\u00e9 significa la propagaci\u00f3n de DNS, por qu\u00e9 los cambios en DNS aparecen en diferentes momentos, c\u00f3mo verificar las respuestas actuales de un dominio y qu\u00e9 hacer cuando una actualizaci\u00f3n a\u00fan parece incompleta.<\/p>\n\n\n\n

\u00bfQu\u00e9 significa la propagaci\u00f3n de DNS?<\/h2>\n\n\n\n

La propagaci\u00f3n de DNS es el t\u00e9rmino com\u00fan para el per\u00edodo durante el cual diferentes usuarios o resolutores de DNS pueden recibir respuestas distintas despu\u00e9s de que se hayan modificado los registros de DNS. Un usuario en una red puede ya ver la nueva direcci\u00f3n IP, mientras que el resolutivo de otro usuario sigue devolviendo una direcci\u00f3n antigua almacenada en cach\u00e9.<\/p>\n\n\n\n

El cambio de DNS subyacente se realiza en los servidores de nombres autoritativos para el dominio. Los resolutivos recursivos luego recuperan y almacenan en cach\u00e9 los registros para sus usuarios. Esos resolutivos no necesariamente consultan nuevamente a los servidores autoritativos cada vez que alguien visita el dominio. Pueden reutilizar una respuesta almacenada en cach\u00e9 mientras siga siendo v\u00e1lida.<\/p>\n\n\n\n

Por eso \u201cpropagaci\u00f3n\u201d se entiende mejor como caducidad y actualizaci\u00f3n de la cach\u00e9<\/strong>. No existe una copia central que deba actualizarse en todos los dispositivos conectados a Internet al mismo tiempo. El registro autoritativo puede ya ser correcto incluso mientras algunos resolvers contin\u00faan sirviendo datos cacheados m\u00e1s antiguos.<\/p>\n\n\n\n

C\u00f3mo funciona el almacenamiento en cach\u00e9 de DNS<\/h2>\n\n\n\n

Cuando un navegador necesita encontrar la direcci\u00f3n IP de un dominio, solicita al sistema operativo que resuelva el nombre. El sistema operativo puede tener una respuesta en cach\u00e9. Si no la tiene, consulta a un resolutor recursivo configurado, como uno operado por un proveedor de Internet, una empresa o un servicio DNS p\u00fablico.<\/p>\n\n\n\n

El resolvedor recursivo tambi\u00e9n puede tener una respuesta en cach\u00e9. Si esa respuesta a\u00fan est\u00e1 dentro de su tiempo de vida en cach\u00e9, puede devolverla sin contactar con los servidores de nombres autoritativos. Cuando el registro en cach\u00e9 expire, el resolvedor puede consultar el sistema DNS autoritativo y almacenar la respuesta actualizada.<\/p>\n\n\n\n

El almacenamiento en cach\u00e9 reduce el tiempo de b\u00fasqueda y la carga sobre la infraestructura DNS. Tambi\u00e9n significa que los cambios en los registros no son necesariamente visibles para todos los resolvers al mismo momento. La respuesta anterior sigue siendo utilizable por un resolver hasta que su cach\u00e9 expire o el resolver la actualice de otra manera.<\/p>\n\n\n\n

Diferentes usuarios pueden utilizar diferentes resolutores recursivos. Incluso las personas que viven en el mismo hogar pueden ver respuestas distintas si sus dispositivos utilizan distintos servicios DNS, VPN, redes m\u00f3viles o cach\u00e9s locales.<\/p>\n\n\n\n

\u00bfQu\u00e9 es el TTL en DNS?<\/h2>\n\n\n\n

TTL significa Tiempo de vida<\/strong>. Es un valor, generalmente medido en segundos, que indica a los resolutivos recursivos cu\u00e1nto tiempo pueden almacenar en cach\u00e9 un registro DNS antes de buscar una respuesta actualizada.<\/p>\n\n\n\n

Por ejemplo, un TTL de 3600<\/code> significa una hora. Si un resuelve obtiene un registro con ese TTL, generalmente puede seguir utilizando la respuesta durante hasta una hora antes de que necesite actualizarla. Un TTL de 300<\/code> significa cinco minutos.<\/p>\n\n\n\n

El TTL que importa despu\u00e9s de un cambio suele ser el del registro antiguo que los resolvers ya ten\u00edan en cach\u00e9. Reducir el TTL inmediatamente antes de cambiar un registro puede no acortar el tiempo de espera para los resolvers que ten\u00edan en cach\u00e9 el valor anterior, m\u00e1s alto. Esos resolvers pueden seguir utilizando la respuesta antigua hasta que expire el per\u00edodo original de cach\u00e9.<\/p>\n\n\n\n

Para las migraciones planificadas, los administradores suelen reducir la TTL con antelaci\u00f3n, esperar el tiempo suficiente para que expire la TTL anterior y luego realizar el cambio de DNS. Una vez que el cambio es estable, pueden volver a aumentar la TTL para reducir las consultas repetidas. Los valores adecuados dependen del servicio y del proceso de cambios del operador.<\/p>\n\n\n\n

\u00bfPor qu\u00e9 los cambios de DNS tardan diferentes cantidades de tiempo?<\/h2>\n\n\n\n

La raz\u00f3n m\u00e1s com\u00fan es que los resolvers tienen diferentes copias en cach\u00e9. Algunos ya pueden haber actualizado el registro, mientras que otros siguen utilizando una respuesta no expirada. Un resolver tambi\u00e9n puede aplicar su propio comportamiento de actualizaci\u00f3n o almacenar en cach\u00e9 respuestas negativas, que son respuestas que indican que un registro no existe.<\/p>\n\n\n\n

El almacenamiento en cach\u00e9 local puede a\u00f1adir otra capa. Un ordenador, un router, un navegador o una aplicaci\u00f3n de seguridad pueden retener temporalmente la informaci\u00f3n DNS. Reiniciar un navegador o vaciar la cach\u00e9 DNS del sistema operativo puede ayudar en algunos casos, pero no cambiar\u00e1 lo que un resolutor recursivo tenga a\u00fan almacenado en su cach\u00e9.<\/p>\n\n\n\n

Los cambios en el proveedor de DNS pueden introducir factores adicionales de tiempo. Si cambia los servidores de nombres autoritativos del dominio en el registrador, los resolvers pueden necesitar actualizar la informaci\u00f3n de delegaci\u00f3n, as\u00ed como los registros servidos por esos servidores de nombres. Este es un cambio diferente a editar un registro A o AAAA dentro del mismo servicio de alojamiento DNS.<\/p>\n\n\n\n

Por \u00faltimo, una actualizaci\u00f3n puede no ser correcta en la fuente autoritativa. Si se edit\u00f3 el registro incorrecto, los cambios no se guardaron, el dominio utiliza servidores de nombres autoritativos diferentes o el registro contiene un error de sintaxis, esperar no solucionar\u00e1 la configuraci\u00f3n subyacente.<\/p>\n\n\n\n

Propagaci\u00f3n de DNS vs Actualizaciones de DNS Autoritativo<\/h2>\n\n\n\n

Un servidor DNS autoritativo proporciona los registros oficiales para un dominio o zona. Cuando editas un registro en el panel de control del proveedor de DNS, este deber\u00eda actualizar los datos autoritativos que sirve.<\/p>\n\n\n\n

Un resolutor recursivo proporciona respuestas DNS a los dispositivos cliente. Puede tener datos en cach\u00e9 anteriores al cambio. Por lo tanto, el servidor autoritativo puede devolver la nueva direcci\u00f3n mientras un resolutor recursivo sigue devolviendo una m\u00e1s antigua.<\/p>\n\n\n\n

Esta distinci\u00f3n es \u00fatil al realizar la resoluci\u00f3n de problemas. En primer lugar, comprueba qu\u00e9 devuelven los servidores de nombres autoritativos. Si ya tienen el registro esperado, el cambio se ha publicado en el origen y las diferencias restantes probablemente se deban a la cach\u00e9 o al comportamiento del resolvedor. Si los servidores autoritativos siguen devolviendo el valor antiguo o ning\u00fan valor, investiga la configuraci\u00f3n del proveedor de DNS y los propios registros.<\/p>\n\n\n\n

Cambiar los servidores de nombres a\u00f1ade otra capa. La zona DNS principal debe apuntar a los servidores de nombres autorizados previstos, y esos servidores deben servir la zona correcta. Un registro correcto en un proveedor de DNS no es \u00fatil si el dominio est\u00e1 delegado a los servidores de nombres de otro proveedor.<\/p>\n\n\n\n

Cambios comunes en DNS y sus efectos<\/h2>\n\n\n\n

Cambiando un Un registro<\/strong> changes the IPv4 address returned for a hostname. Changing an registro AAAA<\/strong> cambia su direcci\u00f3n IPv6. Si ambas est\u00e1n presentes, los clientes pueden usar cualquiera de las familias de direcciones seg\u00fan su red y comportamiento de conexi\u00f3n.<\/p>\n\n\n\n

Cambiando un Registro CNAME<\/strong> cambia el nombre de host al que apunta un alias. Los resolvers pueden entonces necesitar buscar el nombre objetivo y su direcci\u00f3n. Un cambio en los registros del objetivo puede afectar el resultado final incluso si el CNAME permanece sin cambios.<\/p>\n\n\n\n

Cambiando un Registro MX<\/strong> afecta a los servidores de correo que reciben el correo electr\u00f3nico para un dominio. Los sistemas de correo pueden almacenar en cach\u00e9 estos registros, y el enrutamiento del correo puede tardar en reflejar las actualizaciones. Al cambiar de proveedor de correo, los administradores deben verificar los registros MX y cualquier registro de autenticaci\u00f3n de correo relacionado, como SPF, DKIM o DMARC, por separado.<\/p>\n\n\n\n

Cambiando nameservers<\/strong> cambios que hacen que el proveedor de DNS sea el autoritativo para el dominio. Esto requiere una delegaci\u00f3n correcta en el registrador y una configuraci\u00f3n de zona correcta en el nuevo proveedor. Una migraci\u00f3n de servidores de nombres debe planificarse cuidadosamente porque la falta de registros en el nuevo proveedor puede hacer que los sitios web, el correo electr\u00f3nico u otros servicios no est\u00e9n disponibles.<\/p>\n\n\n\n

C\u00f3mo comprobar si un cambio de DNS se ha aplicado<\/h2>\n\n\n\n

Empieza consultando el dominio desde el ordenador que est\u00e1s utilizando. En Windows, macOS y Linux, nslookup<\/code> est\u00e1 com\u00fanmente disponible:<\/p>\n\n\n\n

nslookup example.com<\/code><\/pre>\n\n\n\n
Para comprobar un registro de direcci\u00f3n IPv4, utilice:<\/p>\n\n\n\n
nslookup -type=A example.com<\/code><\/pre>\n\n\n\n
Para IPv6:<\/p>\n\n\n\n
nslookup -type=AAAA example.com<\/code><\/pre>\n\n\n\n
Para los registros de servidores de correo:<\/p>\n\n\n\n
nslookup -type=MX example.com<\/code><\/pre>\n\n\n\n
En macOS y Linux, cavar<\/code> proporciona una salida m\u00e1s detallada:<\/p>\n\n\n\n
dig example.com A<\/code><\/pre>\n\n\n\n
Mostrar solo la secci\u00f3n de respuestas:<\/p>\n\n\n\n
dig example.com A +noall +answer<\/code><\/pre>\n\n\n\n
Puedes consultar un resolutor recursivo espec\u00edfico para comparar respuestas. Por ejemplo:<\/p>\n\n\n\n
dig @1.1.1.1 example.com A<\/code><\/pre>\n\n\n\n
En Windows, puedes especificar un servidor DNS con:<\/p>\n\n\n\n
nslookup example.com 1.1.1.1<\/code><\/pre>\n\n\n\n
Reemplazar example.com<\/code> con tu dominio. La direcci\u00f3n del resolvers en estos ejemplos es solo uno de los posibles resolutores p\u00fablicos; tambi\u00e9n puedes consultar el servicio DNS utilizado por tu organizaci\u00f3n o proveedor.<\/p>\n\n\n\n
Registra el resolutivo que consultaste, la respuesta y el tiempo. Comparar los resultados de varios resolutores ayuda a determinar si la diferencia es local a un solo resolutor o aparece m\u00e1s ampliamente.<\/p>\n\n\n\n
C\u00f3mo consultar un servidor de nombres autoritativo<\/h2>\n\n\n\n
Para encontrar los servidores de nombres autorizados para un dominio, utiliza:<\/p>\n\n\n\n
dig example.com NS<\/code><\/pre>\n\n\n\n
Luego, consulta directamente uno de esos servidores de nombres para obtener el registro que has modificado:<\/p>\n\n\n\n
dig @ns1.example-dns.com example.com A<\/code><\/pre>\n\n\n\n
Reemplazar ns1.example-dns.com<\/code> con un servidor autoritativo listado para tu dominio. Si la consulta directa devuelve la direcci\u00f3n esperada pero un resolutor recursivo devuelve la antigua, los datos autoritativos se han actualizado y el resolutor puede seguir utilizando una respuesta en cach\u00e9.<\/p>\n\n\n\n
Tambi\u00e9n puedes preguntar cavar<\/code> para rastrear el proceso de delegaci\u00f3n:<\/p>\n\n\n\n
dig +trace example.com<\/code><\/pre>\n\n\n\n
Esto sigue la jerarqu\u00eda DNS desde la ra\u00edz hacia los servidores autoritativos del dominio. Puede ayudar a identificar problemas de delegaci\u00f3n, aunque su salida es m\u00e1s detallada de lo que requieren la mayor\u00eda de las comprobaciones b\u00e1sicas.<\/p>\n\n\n\n
Si est\u00e1s utilizando el panel de control de un proveedor de DNS, confirma que el dominio est\u00e9 realmente delegado a los servidores de nombres mostrados all\u00ed. Un registro puede ser correcto en el panel de control de un proveedor mientras que el dominio p\u00fablico apunta a otro proveedor.<\/p>\n\n\n\n
\u00bfQu\u00e9 pasa si algunos usuarios ven el sitio web antiguo?<\/h2>\n\n\n\n
Primero, confirma que el registro A o AAAA autoritativo tenga el valor previsto. Luego, consulta varios resolutivos recursivos y comprueba si devuelven la misma respuesta. Si los datos autoritativos son correctos pero algunos resolutivos devuelven una direcci\u00f3n m\u00e1s antigua, es probable que la causa sea el cach\u00e9.<\/p>\n\n\n\n
A continuaci\u00f3n, comprueba la configuraci\u00f3n local del usuario. Una VPN, el resolutor DNS de la empresa, un producto de seguridad, la cach\u00e9 del navegador o el archivo hosts local pueden afectar a la direcci\u00f3n que se devuelve. Compara el resultado obtenido desde otra red, como una conexi\u00f3n m\u00f3vil, para ver si cambia el comportamiento.<\/p>\n\n\n\n
Tambi\u00e9n considere si los servidores antiguos y nuevos responden. Una migraci\u00f3n puede parecer inconsistente si el host antiguo a\u00fan sirve una copia en cach\u00e9 o redirige de manera diferente. El registro DNS puede ser correcto mientras el servidor antiguo sigue siendo accesible para los usuarios cuyo resolvedor no se ha actualizado.<\/p>\n\n\n\n
Si el problema afecta solo a IPv4 o solo a IPv6, compara los registros A y AAAA por separado. Un dispositivo puede conectarse mediante IPv6 mientras que otro utiliza IPv4. Una familia de direcciones puede apuntar al nuevo servidor mientras que la otra sigue apuntando al antiguo.<\/p>\n\n\n\n
\u00bfQu\u00e9 pasa si un sitio web no est\u00e1 disponible despu\u00e9s de un cambio en DNS?<\/h2>\n\n\n\n
Comprueba que los servidores de nombres autoritativos del dominio sean correctos y accesibles. Luego, verifica que los registros pertinentes existan en esos servidores. Si has cambiado recientemente los servidores de nombres, aseg\u00farate de que el nuevo proveedor de DNS tenga todos los registros necesarios, incluidos los de sitio web, correo electr\u00f3nico, verificaci\u00f3n y servicios.<\/p>\n\n\n\n
Confirma que el servidor de destino est\u00e9 listo para aceptar conexiones para el dominio. Actualizar solo los registros DNS cambia la direcci\u00f3n a la que se dirigen los clientes, pero no configura el servidor web, instala un certificado, abre un puerto en el firewall ni copia los archivos del sitio web.<\/p>\n\n\n\n
Si DNS devuelve la direcci\u00f3n IP esperada pero el sitio web sigue fallando, prueba el servidor y la aplicaci\u00f3n por separado. El problema puede estar en el servidor web, el firewall, el certificado TLS, la configuraci\u00f3n del alojamiento o la aplicaci\u00f3n. Una b\u00fasqueda de DNS confirma la resoluci\u00f3n de nombres; no confirma que el servicio est\u00e9 saludable.<\/p>\n\n\n\n
Para una comprobaci\u00f3n general de la ruta entre tu dispositivo y un destino, consulta nuestra gu\u00eda sobre utilizar traceroute para diagnosticar problemas de conexi\u00f3n de red<\/a>. Traceroute y las consultas DNS prueban diferentes partes de la conexi\u00f3n, por lo que son \u00fatiles en conjunto al reducir el alcance de un problema.<\/p>\n\n\n\n
Almacenamiento en cach\u00e9 negativo y resultados de \u201cRegistro no encontrado\u201d<\/h2>\n\n\n\n
Los resolvers pueden almacenar en cach\u00e9 el hecho de que un registro no existe. Esto se denomina almacenamiento en cach\u00e9 negativo. Si un resolver consult\u00f3 un nombre antes de que se creara el registro, puede continuar devolviendo temporalmente una respuesta de \u00abno encontrado\u00bb incluso despu\u00e9s de que el registro haya sido a\u00f1adido.<\/p>\n\n\n\n
El cach\u00e9 negativo tambi\u00e9n tiene un TTL, basado en la informaci\u00f3n del registro SOA de la zona y las reglas del resolutor. El comportamiento exacto puede variar. Si un subdominio reci\u00e9n creado no se resuelve inmediatamente, comprueba primero el servidor de nombres autoritativo. Si devuelve el nuevo registro, espera a que expire el cach\u00e9 negativo y compara con otros resolutores.<\/p>\n\n\n\n
Una respuesta de \u00abregistro no encontrado\u00bb tambi\u00e9n puede indicar que el registro se a\u00f1adi\u00f3 a la zona incorrecta, que el nombre de host se introdujo err\u00f3neamente o que el dominio utiliza servidores de nombres autorizados diferentes. Confirma el nombre de host completo, el tipo de registro y el proveedor de DNS antes de asumir que el problema se debe \u00fanicamente al retraso en la propagaci\u00f3n.<\/p>\n\n\n\n
C\u00f3mo planificar una migraci\u00f3n de DNS<\/h2>\n\n\n\n
Antes de modificar los registros para un servicio de producci\u00f3n, enumere cada nombre de host y registre los servicios en los que depende. Un sitio web puede utilizar registros A y AAAA, mientras que el correo electr\u00f3nico depende de registros MX, SPF, DKIM y DMARC. Las aplicaciones tambi\u00e9n pueden depender de registros de verificaci\u00f3n o de descubrimiento de servicios.<\/p>\n\n\n\n
Si el cambio est\u00e1 planificado, reduzca la TTL correspondiente de antemano y espere al menos el per\u00edodo de la TTL anterior antes de cambiar el destino. Prepare el nuevo servidor o proveedor antes de actualizar DNS. Pruebe directamente donde sea posible y confirme que los certificados, las reglas del firewall, la configuraci\u00f3n de la aplicaci\u00f3n y los servicios de correo est\u00e9n listos.<\/p>\n\n\n\n
Tras el cambio, verifique las respuestas autorizadas y varios resolutivos recursivos. Monitoree la disponibilidad del sitio web, la entrega de correos electr\u00f3nicos y los errores de la aplicaci\u00f3n. Mantenga el servicio antiguo disponible durante la transici\u00f3n cuando sea pr\u00e1ctico, ya que algunos usuarios pueden seguir accediendo a \u00e9l mientras expiran las respuestas en cach\u00e9.<\/p>\n\n\n\n
Una vez que la nueva configuraci\u00f3n sea estable, restaure un TTL adecuado. Mantener un TTL muy bajo de forma indefinida puede aumentar el volumen de consultas DNS sin aportar muchos beneficios a un servicio que cambia raramente.<\/p>\n\n\n\n
Malentendidos comunes sobre la propagaci\u00f3n de DNS<\/h2>\n\n\n\n
Un malentendido com\u00fan es que cada cambio de DNS tarda exactamente 24 o 48 horas. No existe una duraci\u00f3n universal fija. El retraso efectivo depende de los valores anteriores de TTL, la cach\u00e9 del resolvedor, los cambios de delegaci\u00f3n y la correcci\u00f3n de la configuraci\u00f3n autoritativa.<\/p>\n\n\n\n
Otro malentendido es que borrar la cach\u00e9 del navegador actualiza el DNS en todas partes. Puede limpiar la informaci\u00f3n almacenada en ese dispositivo, pero no puede borrar la cach\u00e9 de un resolutor recursivo remoto. Del mismo modo, reiniciar un router puede vaciar su cach\u00e9 local, pero no modifica los registros autoritativos.<\/p>\n\n\n\n
Un tercer malentendido es que un verificador de DNS que muestra respuestas diferentes demuestra que el dominio est\u00e1 roto. Diferentes respuestas pueden ocurrir durante una migraci\u00f3n planificada, especialmente cuando los resolvers tienen datos en cach\u00e9 en diferentes momentos. La pregunta importante es si los registros autoritativos son correctos y si las diferencias restantes son consistentes con el TTL anterior.<\/p>\n\n\n\n
Finalmente, la propagaci\u00f3n de DNS no configura el servicio de destino. Una direcci\u00f3n IP correcta a\u00fan puede dar lugar a un sitio web no disponible si el servidor, el firewall, el certificado TLS o la aplicaci\u00f3n no est\u00e1n listos.<\/p>\n\n\n\n
Preguntas frecuentes sobre la propagaci\u00f3n de DNS<\/h2>\n\n\n\n
\u00bfCu\u00e1nto tiempo tarda la propagaci\u00f3n de DNS?<\/h3>\n\n\n\n
No existe una duraci\u00f3n \u00fanica garantizada. Algunos cambios aparecen r\u00e1pidamente, mientras que otros permanecen inconsistentes hasta que caducan los registros en cach\u00e9. El TTL anterior, el comportamiento del resolvedor y si cambiaron los servidores de nombres afectan todos al tiempo de propagaci\u00f3n.<\/p>\n\n\n\n
\u00bfHacer que el TTL sea m\u00e1s bajo hace que el cambio sea instant\u00e1neo?<\/h3>\n\n\n\n
No. Reducir un TTL afecta al almacenamiento en cach\u00e9 futuro una vez que los resolvers obtienen el nuevo TTL. Los resolvers que ya ten\u00edan almacenado en cach\u00e9 el registro antiguo pueden seguir utiliz\u00e1ndolo hasta que expire su TTL anterior.<\/p>\n\n\n\n
\u00bfPor qu\u00e9 los verificadores de DNS muestran resultados diferentes?<\/h3>\n\n\n\n
Pueden consultar diferentes resolutores recursivos desde distintas ubicaciones. Esos resolutores pueden tener respuestas almacenadas en cach\u00e9 diferentes, actualizarse en momentos distintos o recibir respuestas diferentes debido a las pol\u00edticas de DNS geogr\u00e1ficas.<\/p>\n\n\n\n
\u00bfDeber\u00eda vaciar la cach\u00e9 DNS de mi computadora?<\/h3>\n\n\n\n
Puede ayudar cuando tu propio dispositivo ha almacenado en cach\u00e9 una respuesta antigua. No borra las cach\u00e9s mantenidas por tu proveedor de Internet, el resolver de la empresa o el servicio DNS p\u00fablico.<\/p>\n\n\n\n
\u00bfPor qu\u00e9 mi sitio web se resuelve pero sigue sin cargar?<\/h3>\n\n\n\n
Es posible que DNS est\u00e9 devolviendo la direcci\u00f3n correcta mientras el servidor o la aplicaci\u00f3n de destino presenta un problema. Comprueba por separado el servidor web, el cortafuegos, el certificado TLS y la configuraci\u00f3n del alojamiento.<\/p>\n\n\n\n
\u00bfPueden tardar m\u00e1s los cambios de nameserver que los cambios de registro?<\/h3>\n\n\n\n
Pueden incluir informaci\u00f3n de delegaci\u00f3n adicional en el registrador y en la zona DNS principal. El nuevo proveedor tambi\u00e9n debe servir una zona completa y correcta. Verifique tanto la delegaci\u00f3n como los registros en los nuevos servidores autorizados.<\/p>\n\n\n\n
Los cambios de DNS pueden aparecer en diferentes momentos porque los servidores de nombres autoritativos y los resolutores recursivos tienen funciones separadas, y los resolutores almacenan en cach\u00e9 las respuestas seg\u00fan los valores de TTL. Un usuario puede ver una direcci\u00f3n antigua mientras que otro ya recibe la nueva.<\/p>\n\n\n\n
Para investigar, compruebe primero los servidores de nombres autoritativos y luego compare las respuestas de varios resolutivos recursivos. Confirme el tipo de registro, el nombre de host, el TTL y la delegaci\u00f3n del servidor de nombres. Si DNS devuelve la direcci\u00f3n esperada pero el servicio sigue sin estar disponible, compruebe el servidor de destino y la aplicaci\u00f3n como partes independientes del problema.<\/p>\n\n\n\n
Comprender el funcionamiento del cach\u00e9 facilita la planificaci\u00f3n y resoluci\u00f3n de problemas de los cambios en DNS. Para m\u00e1s fundamentos de redes, contin\u00faa con nuestras gu\u00edas sobre Direcciones IP<\/a>, puertas de enlace predeterminadas<\/a>, y rastreo de ruta<\/a>.<\/p>","protected":false},"excerpt":{"rendered":"
You update a domain\u2019s DNS records, save the change, and expect the new website or mail service to work immediately. But a colleague still sees the old website, an online checker shows a different address, or email delivery behaves inconsistently. This delay is commonly called DNS propagation. The phrase can make it sound as though […]<\/p>\n","protected":false},"author":1,"featured_media":2344,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_seopress_titles_title":"What Is DNS Propagation? Why DNS Changes Take Time","_seopress_titles_desc":"Learn why DNS changes take time to appear, how caching and TTL affect updates, and how to check whether a domain is returning the expected records.","_seopress_robots_index":"","_seopress_robots_follow":"","_seopress_robots_imageindex":"","_seopress_robots_snippet":"","_seopress_robots_primary_cat":"","_seopress_robots_breadcrumbs":"","_seopress_robots_freeze_modified_date":"","_seopress_robots_custom_modified_date":"","_seopress_robots_canonical":"","_seopress_social_fb_title":"","_seopress_social_fb_desc":"","_seopress_social_fb_img":"","_seopress_social_fb_img_attachment_id":0,"_seopress_social_fb_img_width":0,"_seopress_social_fb_img_height":0,"_seopress_social_twitter_title":"","_seopress_social_twitter_desc":"","_seopress_social_twitter_img":"","_seopress_social_twitter_img_attachment_id":0,"_seopress_social_twitter_img_width":0,"_seopress_social_twitter_img_height":0,"_seopress_redirections_value":"","_seopress_redirections_enabled":"","_seopress_redirections_enabled_regex":"","_seopress_redirections_logged_status":"","_seopress_redirections_param":"","_seopress_redirections_type":0,"_seopress_analysis_target_kw":"","footnotes":""},"categories":[1],"tags":[],"class_list":["post-2342","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-article"],"_links":{"self":[{"href":"https:\/\/junglelabs.uk\/es\/wp-json\/wp\/v2\/posts\/2342","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/junglelabs.uk\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/junglelabs.uk\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/junglelabs.uk\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/junglelabs.uk\/es\/wp-json\/wp\/v2\/comments?post=2342"}],"version-history":[{"count":1,"href":"https:\/\/junglelabs.uk\/es\/wp-json\/wp\/v2\/posts\/2342\/revisions"}],"predecessor-version":[{"id":2343,"href":"https:\/\/junglelabs.uk\/es\/wp-json\/wp\/v2\/posts\/2342\/revisions\/2343"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/junglelabs.uk\/es\/wp-json\/wp\/v2\/media\/2344"}],"wp:attachment":[{"href":"https:\/\/junglelabs.uk\/es\/wp-json\/wp\/v2\/media?parent=2342"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/junglelabs.uk\/es\/wp-json\/wp\/v2\/categories?post=2342"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/junglelabs.uk\/es\/wp-json\/wp\/v2\/tags?post=2342"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}