// HERRAMIENTA GRATUITA · CALCULADORA DE TTL DE DNS
Calculadora y conversor de TTL de DNS
Escribe un TTL y obtienes el tiempo que representa y, sobre todo, el calendario que de verdad importa: antes de cambiar los DNS o mudar el alojamiento, baja el TTL de los registros a 300 segundos con al menos un TTL antiguo completo de antelación —si es de 3600, una hora antes; si es de 86400, un día antes—, luego haz el cambio, espera un TTL bajo a que todas las cachés te sigan y devuelve el valor original cuando esté estable. La calculadora también resuelve la caché negativa de la RFC 2308: cuánto tiempo sigue respondiendo NXDOMAIN un dominio ya reparado. Gratis, al instante, sin registro y todo dentro de tu navegador.
Segundos o una duración: 3600, 1h, 90min, 1d 12h, 04:00:00. Cualquier valor por encima de una semana se rechaza.
Valores habituales — haz clic en uno:
El TTL con el que trabajas mientras el cambio está en marcha. 300 segundos es lo habitual; por debajo de 60 solo compras consultas.
Los dos vienen en el SOA de la sección authority de una respuesta NXDOMAIN: dig SOA ejemplo.es. La RFC 2308 se queda con el menor de los dos. Vienen precargados los valores reales de la zona es. (86400 y 3600): leyendo solo el minimum dirías un día, y la respuesta es una hora.
Cómo usar la calculadora de TTL
Tres campos, sin cuenta, y la aritmética se hace en local: nada de lo que escribes sale de tu navegador.
- Escribe el TTL actual. El TTL que tienen ahora los registros que vas a tocar, en segundos o como duración tipo 1h. El conversor te dice a cuánto tiempo equivale y si es un valor de transición, equilibrado o estable.
- Lee el calendario del cambio. Te indica el TTL bajo que hay que usar durante el cambio, con cuánta antelación publicarlo, cuánto tardan las cachés en seguirte después y el valor al que volver cuando termine.
- Añade los números del SOA si el dominio devuelve NXDOMAIN. Ejecuta dig SOA ejemplo.es, coge el campo minimum y el TTL del propio registro SOA, y la calculadora te da la ventana de caché negativa de la RFC 2308: cuánto sobrevive la negación a la reparación.
Cambiar de DNS: cuándo bajar el TTL y cuándo hacer el cambio
Casi nadie consulta un TTL por curiosidad sobre los segundos. Se consulta porque hay una mudanza en marcha y se quiere que dure poco. La regla tiene una mitad que no es evidente:
Bajar el TTL solo sirve si lo publicas antes del cambio, y con al menos un TTL antiguo completo de antelación. Bajar un TTL de 24 horas a 300 segundos diez minutos antes del cambio no hace absolutamente nada, porque los resolutores que guardan la copia de ayer no volverán a preguntar —ni verán el valor nuevo— hasta mañana. El TTL antiguo tiene que caducar por sí solo primero. De ahí sale el calendario entero:
- Baja el TTL a 300 segundos un TTL antiguo antes del cambio; dos si quieres margen, porque hay resolutores que refrescan antes de tiempo y otros que no.
- Haz el cambio: cambia los servidores de nombres o reapunta los registros.
- Espera un TTL bajo —cinco minutos— y toda caché que respete las reglas ya tiene la respuesta nueva.
- Devuelve el TTL original cuando esté estable, para no pagar una consulta DNS en cada visita.
Lo único que no puedes bajar es el TTL de la propia delegación. Los registros NS que apuntan a tus servidores de nombres viven en la zona superior, los publica el registro y muchos los fijan en 24 o 48 horas: en es. son 86400 segundos y en com. 172800. Por eso un cambio de DNS tiene una cola larga aunque tus registros lleven días en 300 segundos, y por eso leer la delegación desde dos resolutores (en inglés) informa mucho más que mirar el reloj.
Los TTL que te vas a encontrar en el hosting en español (y los dos números de .es)
La respuesta a «¿cuánto tarda en propagarse?» no es la misma en todos los sitios, porque los valores por defecto cambian de un proveedor a otro y el registro pone los suyos por encima. Todo lo que viene a continuación está medido el 4 de septiembre de 2026 preguntando directamente a los servidores autoritativos, y lo puedes reproducir en un minuto.
Primero, el registro. La zona es. entrega los NS de tu dominio con un TTL de 86400 segundos, un día entero:
dig +norecurse NS tu-dominio.es @ns1.nic.es
tu-dominio.es. 86400 IN NS dns1.tu-hosting.com.Y aquí está la peculiaridad de .es, que además es el mejor ejemplo posible de por qué esta calculadora pide dos números y no uno. Cuando la zona es. responde NXDOMAIN, adjunta un SOA cuyo campo minimum vale 86400 pero cuyo propio TTL es 3600. Si lees solo el campo minimum —que es lo que hace casi todo el mundo— concluyes que un dominio .es inexistente se recuerda como inexistente durante 24 horas. La RFC 2308 dice que manda el menor de los dos, así que la respuesta real es una hora. Veinticuatro veces menos. Es exactamente el caso para el que sirven los campos «minimum del SOA» y «TTL del propio SOA» de la herramienta de arriba.
Segundo, los proveedores. Estos son los valores que cada uno sirve en su propia zona; no son necesariamente el valor por defecto de tu panel, pero sí el abanico con el que te vas a topar en este mercado:
| Proveedor | TTL del registro A | Minimum del SOA | Caché negativa real |
|---|---|---|---|
| Arsys | 60 s | 600 s | 600 s — 10 minutos |
| Webempresa | 60 s | 600 s | 600 s — 10 minutos |
| dinahosting | 300 s | 86400 s | 300 s — 5 minutos |
| cdmon | 60 s | 86400 s | 900 s — 15 minutos |
| Hostinger | 300 s | 1800 s | 1800 s — 30 minutos |
| Raiola Networks (Route 53) | 86400 s | 86400 s | 86400 s — 1 día |
Fíjate en la última columna, que es la que casi nunca se publica: la caché negativa real no es el campo minimum, sino min(minimum, TTL del SOA). En dinahosting el minimum dice un día y el resultado son cinco minutos, porque su SOA se sirve con TTL 300. En una zona de Route 53 sin tocar, en cambio, coinciden los dos valores en 86400 y sí que es un día entero: si escribes mal un subdominio, lo pruebas y luego lo creas, ese nombre puede seguir dando error durante 24 horas sin que nada esté roto. Antes de repetir el arreglo, calcula la ventana.
Caché negativa: por qué una caída sobrevive a su propio arreglo
Los resolutores guardan «este nombre no existe» igual que guardan una dirección, y ese recuerdo tiene su propio TTL. La RFC 2308 lo fija en el menor de dos valores: el campo minimum del registro SOA y el TTL del propio registro SOA. Los dos llegan en la sección authority de la respuesta NXDOMAIN, así que dig SOA ejemplo.es te los pone delante.
Ese número decide cuánto tiempo permanece invisible una reparación. En nuestra propia caída de delegación de junio de 2026 (en inglés), el registro quedó corregido a las 17:30 UTC del 30 de junio y los dominios no volvieron para buena parte de internet hasta el 1 y el 2 de julio: los resolutores que usaba la gente seguían dentro de la ventana negativa. De ahí salen dos costumbres útiles. No juzgues un arreglo de delegación antes de que esa ventana haya pasado. Y no lo arregles dos veces dentro de la ventana, que es la forma habitual de sustituir una configuración correcta por otra peor.
Valores de TTL habituales y para qué sirve cada uno
| Segundos | Se lee como | Para qué sirve |
|---|---|---|
60 | 1 minuto | Migración en curso o registro de failover. Cada visita cuesta una consulta; no lo dejes ahí. Es lo que sirven Arsys, cdmon y Webempresa en su propio registro A. |
300 | 5 minutos | El TTL de transición. Se publica antes de cambiar los DNS o el alojamiento y se restaura después. |
600 | 10 minutos | El minimum del SOA en Arsys y Webempresa: ahí la caché negativa es corta. |
1800 | 30 minutos | Minimum del SOA muy común, entre otros en las zonas servidas por Cloudflare. |
3600 | 1 hora | La respuesta más frecuente a «qué TTL pongo»: se cambia dentro de la jornada y sale barato de servir. También la caché negativa real de .es. |
14400 | 4 horas | El valor por defecto de la era cPanel. Sigue por todas partes y explica muchos cambios que tardan media jornada. |
43200 | 12 horas | Solo para registros estables. Un cambio urgente te llevará medio día de retraso. |
86400 | 1 día | MX, TXT y todo lo que llevas un año sin tocar. Es también el TTL de la delegación de .es. |
172800 | 2 días | TTL de la delegación en com. y net.: lo fija el registro, no tú. |
604800 | 1 semana | El techo práctico. Por encima estás confiando en cachés a las que ya no llegas. |
Para leer el TTL que un resolutor tiene ahora mismo, en vez del que tú configuraste: dig ejemplo.es +noall +answer lo imprime en la segunda columna y va bajando conforme envejece la copia. En Windows, nslookup -debug ejemplo.es enseña el mismo campo. Un TTL muy por debajo del que configuraste significa que el registro lo está sirviendo alguien distinto de quien crees; un TTL que no baja nunca significa que estás leyendo un servidor autoritativo directamente y no una caché.
// Preguntas frecuentes
¿Qué TTL debo poner antes de cambiar los DNS?
300 segundos, publicados con al menos un TTL antiguo completo de antelación. El orden es la parte que casi todo el mundo se salta: bajar un TTL de 24 horas una hora antes del cambio no cambia nada, porque los resolutores que tienen la copia antigua no la releerán hasta el día siguiente. Bájalo un día antes, haz el cambio, espera cinco minutos a que las cachés te sigan y restaura el valor original para no pagar una consulta en cada visita. En un dominio .es, además, la delegación lleva su propio TTL de 86400 segundos que tú no puedes bajar.
¿Cuánto es un TTL de 3600?
Una hora. Es el TTL más común en registros web: suficientemente largo para que la mayoría de las visitas se sirvan desde caché y suficientemente corto para que un cambio llegue a todo el mundo dentro de la jornada. Otros dos valores que verás mucho son 14400, que son cuatro horas y fue el valor por defecto de toda una generación de paneles de hosting, y 86400, que es un día y corresponde a registros que no piensas mover.
¿Cuánto tarda de verdad un cambio de DNS en un dominio .es?
Dos relojes, y ninguno es el TTL de tus registros. Primero el registro publica la nueva delegación. A partir de ahí, cada resolutor que ya se hubiera traído la delegación anterior arrastra su TTL, que en la zona es. son 86400 segundos, un día entero (compruébalo con dig +norecurse NS tu-dominio.es @ns1.nic.es). Bajar el TTL de tus registros A o MX no acorta ninguno de esos dos relojes: sirve para los cambios que ocurren dentro de los mismos servidores de nombres.
¿Qué es el TTL de caché negativa y cómo se calcula?
Es el tiempo que los resolutores recuerdan que un nombre no existe. La RFC 2308 lo define como el menor entre el campo minimum del registro SOA y el TTL del propio registro SOA; ambos llegan en la sección authority de una respuesta NXDOMAIN, así que se leen con dig SOA ejemplo.es. La zona es. es el ejemplo perfecto: su minimum vale 86400 pero su SOA se sirve con TTL 3600, de modo que la ventana real es de una hora, no de un día.
¿Bajar el TTL acelera la propagación del DNS?
Solo si lo bajas con antelación. No hay propagación en el sentido de datos que viajan de servidor en servidor: el registro y tus servidores de nombres tienen la respuesta nueva de inmediato, y lo que esperas son resolutores cuya copia en caché aún no ha caducado. Un TTL bajado antes del cambio acorta esas copias. Un TTL bajado a la vez que el cambio no acorta nada, porque las cachés que te importan siguen guardando el valor anterior con su duración anterior.
¿Es malo poner un TTL muy bajo?
Como estado permanente, sí: con 30 segundos casi cada visita cuesta una consulta DNS, lo que añade latencia al usuario y carga a tus servidores de nombres, y elimina el colchón que mantiene el sitio accesible si tu proveedor de DNS tiene diez minutos malos. Como estado temporal alrededor de un cambio es justo lo correcto. El patrón es bajar, cambiar, verificar y restaurar, no quedarse a vivir en 60 segundos porque una migración lo necesitó una vez.
El TTL que importa es el que viene en la respuesta.
Un comando lee tu dominio desde dos resolutores públicos con el TTL restante de cada registro y después comprueba la zona, la vinculación del nombre de host y el contenido que se sirve de verdad.
$ npm i -g @clize/clize && clize install $ clize domain check tu-dominio.es[ Agent Domains → ]