Vas a cambiar de hosting o a apuntar tu dominio a un servidor nuevo, y en todas partes lees la misma frase: \u00ablos cambios de DNS pueden demorar entre 24 y 48 horas en propagarse\u00bb.<\/p>\n
Esa frase es un redondeo de seguridad. No hay ninguna regla t\u00e9cnica que diga 48 horas. El tiempo real de un cambio de DNS lo decide un n\u00famero que t\u00fa controlas, y que se puede leer en un comando.<\/p>\n
La palabra \u00abpropagaci\u00f3n\u00bb sugiere que el cambio se expande por internet como una onda, de a poco, pa\u00eds por pa\u00eds. No es lo que pasa.<\/p>\n
Lo que pasa es que los servidores DNS del mundo guardan en memoria las respuestas que ya consultaron, para no preguntar lo mismo mil veces. Cuando t\u00fa cambias un registro, el cambio queda hecho de inmediato en tu servidor autoritativo. Lo que demora es que expiren las copias guardadas<\/strong> en los resolutores que ya hab\u00edan preguntado antes.<\/p>\n No es una onda que avanza. Son cach\u00e9s que vencen. Y saben exactamente cu\u00e1ndo vencer, porque t\u00fa se lo dijiste.<\/p>\n Cada registro DNS lleva un valor llamado TTL (time to live<\/em>). Est\u00e1 definido en el RFC 1035 como un entero de 32 bits que indica segundos<\/strong>.<\/p>\n Cuando un resolutor guarda tu registro, empieza a descontar ese n\u00famero. Al llegar a cero bota la copia y vuelve a preguntar. Eso es todo el mecanismo.<\/p>\n As\u00ed que la respuesta correcta a \u00abcu\u00e1nto demora mi cambio de DNS\u00bb es: lo que dure el TTL que ten\u00eda el registro antes de que lo cambiaras<\/strong>.<\/p>\n Si tu registro ten\u00eda TTL de 3600, tu cambio est\u00e1 completo en el mundo en una hora. Nadie espera 48 horas por un TTL de una hora.<\/p>\n Esto hay que decirlo fuerte, porque es el error m\u00e1s caro de todos.<\/p>\n Bajar el TTL despu\u00e9s<\/strong> de hacer el cambio no sirve absolutamente de nada. Los resolutores que ya guardaron tu registro guardaron tambi\u00e9n el TTL viejo, y van a respetarlo hasta que se les venza. Tu TTL nuevo reci\u00e9n lo van a ver cuando vuelvan a preguntar, o sea, despu\u00e9s de la espera que quer\u00edas evitar.<\/p>\n El TTL se baja antes<\/strong>. La secuencia correcta es: bajas el TTL a 300, esperas a que se venza el TTL antiguo (si era 14400, esperas cuatro horas), y reci\u00e9n ah\u00ed haces el cambio real. El cambio queda listo en cinco minutos.<\/p>\n Ac\u00e1 est\u00e1 la parte contraintuitiva, y es la que explica los casos raros.<\/p>\n Los resolutores no solo guardan las respuestas positivas. Tambi\u00e9n guardan las negativas. Si alguien consulta un nombre que no existe, el resolutor guarda ese \u00abno existe\u00bb \u2014la respuesta NXDOMAIN\u2014 durante un rato. El RFC 2308 define cu\u00e1nto: el menor entre el campo MINIMUM del registro SOA de la zona y el propio TTL del SOA.<\/p>\n La consecuencia pr\u00e1ctica es rara pero muy real:<\/p>\n Por eso pasa la escena t\u00edpica: t\u00fa ves el sitio ca\u00eddo y el t\u00e9cnico lo ve andando. No es que uno de los dos tenga mal el computador. Es que t\u00fa consultaste antes de tiempo y te quedaste con el \u00abno existe\u00bb guardado.<\/p>\n La moraleja es inc\u00f3moda pero \u00fatil: no consultes el dominio antes de haber terminado la configuraci\u00f3n<\/strong>. Cada consulta prematura te alarga tu propia espera.<\/p>\n Dos matices que conviene tener claros antes de prometerle a alguien \u00abcinco minutos\u00bb:<\/p>\n Hay un piso.<\/strong> Google Public DNS aplica un m\u00ednimo de 30 segundos. Si tu registro declara TTL de 0 o de 10 segundos, Google lo trata como 30. Poner un TTL absurdamente bajo no acelera nada.<\/p>\n Hay un techo informal.<\/strong> Algunos resolutores de proveedores de internet suben por su cuenta los TTL muy cortos para reducir consultas. Es poco frecuente, no est\u00e1 documentado y contradice el est\u00e1ndar, pero existe. Por eso conviene dejar un margen sobre el TTL te\u00f3rico en lugar de prometer el minuto exacto.<\/p>\n El 21 de agosto de 2026 delegamos un dominio El dominio respond\u00eda y el sitio cargaba esa misma ma\u00f1ana<\/strong>, no al d\u00eda siguiente. Ayud\u00f3 una condici\u00f3n concreta: ese dominio no ten\u00eda servidores de nombres delegados antes, as\u00ed que no hab\u00eda ninguna respuesta antigua guardada en ninguna parte esperando a vencer.<\/p>\n Ese es exactamente el escenario del cach\u00e9 negativo al rev\u00e9s: cuando no hay nada previo que expirar, el cambio se ve al tiro.<\/p>\n Durante la ventana en que unos resolutores tienen la respuesta vieja y otros la nueva, conviven dos versiones de tu servicio. Esto es lo que importa:<\/p>\n El orden completo, con el correo incluido, lo detallamos en c\u00f3mo apuntar tu dominio a tu hosting sin quedarte sin correo<\/a>.<\/p>\n Los sitios de \u00abcomprobar propagaci\u00f3n\u00bb que muestran un mapa con banderitas sirven para una vista r\u00e1pida, pero confunden: consultan resolutores p\u00fablicos repartidos por el mundo, y lo que t\u00fa necesitas saber es qu\u00e9 ve tu<\/em> resolutor y qu\u00e9 dice el servidor autoritativo.<\/p>\n Tres comandos que s\u00ed responden la pregunta:<\/p>\n Ese TTL que aparece en la respuesta es el contador en vivo: son los segundos que le quedan a la copia guardada. Cuando llegue a cero, tu resolutor vuelve a preguntar.<\/p>\n En Windows, Si te da lo mismo el detalle y solo quieres que tu sitio cambie de casa sin sustos, la gu\u00eda de migraci\u00f3n<\/a> tiene el resto del procedimiento, incluida la parte de archivos y base de datos.<\/p>\n La propagaci\u00f3n DNS no demora 48 horas. Demora lo que dure el TTL del registro que cambiaste, y ese n\u00famero lo decides t\u00fa con un d\u00eda de anticipaci\u00f3n. Las esperas eternas casi siempre son una de tres cosas: un TTL alto que nadie baj\u00f3 a tiempo, un cach\u00e9 negativo que se gener\u00f3 por consultar antes de tiempo, o un registro que qued\u00f3 mal escrito y nunca fue un tema de espera.<\/p>\nEl TTL: el n\u00famero que manda<\/h2>\n
\n
\n TTL configurado<\/th>\n Espera m\u00e1xima real<\/th>\n Cu\u00e1ndo se usa<\/th>\n<\/tr>\n \n 300 (5 minutos)<\/td>\n 5 minutos<\/td>\n Durante una migraci\u00f3n<\/td>\n<\/tr>\n \n 1800 (30 minutos)<\/td>\n 30 minutos<\/td>\n D\u00edas previos a un cambio<\/td>\n<\/tr>\n \n 3600 (1 hora)<\/td>\n 1 hora<\/td>\n Valor por defecto de muchos paneles<\/td>\n<\/tr>\n \n 14400 (4 horas)<\/td>\n 4 horas<\/td>\n Valor por defecto de cPanel<\/td>\n<\/tr>\n \n 86400 (24 horas)<\/td>\n 24 horas<\/td>\n Registros que no cambian nunca<\/td>\n<\/tr>\n<\/table>\n El error cl\u00e1sico: bajar el TTL despu\u00e9s del cambio<\/h2>\n
El cach\u00e9 negativo: lo que casi nadie explica<\/h2>\n
\n
Los resolutores no siempre respetan tu TTL<\/h2>\n
Un caso medido<\/h2>\n
.cl<\/code> a un servidor nuevo. El titular public\u00f3 los servidores de nombres a las 10:20 de la ma\u00f1ana.<\/p>\nQu\u00e9 se cae y qu\u00e9 no durante el cambio<\/h2>\n
\n
C\u00f3mo comprobarlo de verdad<\/h2>\n
\n
dig tudominio.cl +noall +answer<\/code> \u2014 qu\u00e9 te responde tu resolutor, con el TTL que le queda.<\/li>\ndig @8.8.8.8 tudominio.cl<\/code> \u2014 qu\u00e9 responde un resolutor p\u00fablico concreto.<\/li>\ndig tudominio.cl +trace<\/code> \u2014 el recorrido completo desde la ra\u00edz, que te muestra qu\u00e9 dice el servidor autoritativo sin ning\u00fan cach\u00e9 en el medio.<\/li>\n<\/ul>\nnslookup tudominio.cl 8.8.8.8<\/code> hace la versi\u00f3n corta. Y si quieres ver el estado real sin cach\u00e9 local, ipconfig \/flushdns<\/code> limpia el tuyo.<\/p>\nLa receta para cambiar de hosting sin ca\u00edda<\/h2>\n
\n
En resumen<\/h2>\n