Antes de que Googlebot pueda enviar la primera petición HTTP a una URL, tiene que resolver el nombre de dominio a una dirección IP, exactamente igual que cualquier navegador. Es un paso tan rutinario que rara vez se piensa en él como parte del SEO técnico, pero una configuración de DNS deficiente puede introducir errores de rastreo, ralentizar cada petición, o convertir una migración bien planificada en una serie de fallos intermitentes durante días.
Cómo encaja el DNS en el pipeline de rastreo
La resolución DNS es la primera fase, antes incluso del establecimiento de la conexión TCP, de cualquier petición que haga un rastreador o un navegador, como se detalla en el desglose completo de fases de la guía de velocidad de servidor y TTFB. Si esa resolución falla, el dominio no responde, el servidor de nombres no contesta a tiempo, o devuelve un error, Googlebot lo registra como un error de rastreo específico, distinto de un error de servidor o de un 404, precisamente porque ocurre antes de que exista siquiera una conexión con el servidor de origen. Fallos de DNS repetidos y sostenidos en el tiempo pueden hacer que Google reduzca su crawl rate limit para el dominio, igual que haría ante errores 5xx recurrentes, como se explica en la guía de rastreo e indexación.
TTL: el ajuste que decide entre velocidad de propagación y carga de consultas
El TTL (Time To Live) de un registro DNS especifica, en segundos, durante cuánto tiempo puede un resolutor, el de un proveedor de internet, el de un navegador, el de Googlebot, reutilizar la respuesta ya obtenida sin volver a consultar el servidor autoritativo. Es un ajuste con un trade-off real, y no existe un valor universalmente correcto.
Un TTL bajo (300 segundos, por ejemplo) permite que un cambio de IP se propague rápido, útil de cara a un cambio de servidor o de proveedor de hosting, pero implica que los resolutores consultan el servidor autoritativo con mucha más frecuencia, lo que añade una carga de consultas constante y, en el caso de resoluciones no cacheadas, un pequeño coste de latencia añadido que se paga en cada resolución nueva. Un TTL alto (86.400 segundos, un día, o más) reduce drásticamente esa carga y aprovecha mejor la caché de los resolutores, pero significa que cualquier cambio en el registro tarda hasta ese tiempo completo en llegar a todos los resolutores que ya tenían la respuesta anterior en caché.
Qué pasa durante una migración de DNS o un cambio de nameservers
La palabra "propagación" es engañosa: no existe un momento único en el que un cambio de DNS se sincroniza globalmente, sino un periodo en el que distintos resolutores en distintas partes del mundo siguen sirviendo la respuesta anterior hasta que expira su copia en caché, determinada por el TTL que tenía el registro antes del cambio, no por el TTL nuevo, que solo aplica a partir de que se consulta de nuevo. Durante ese periodo, es perfectamente posible que Googlebot resuelva el dominio a la IP antigua mientras un usuario real, con un resolutor distinto, ya vea la IP nueva, o al revés.
La práctica que evita la mayoría de problemas es bajar el TTL del registro afectado, a 300 segundos o menos, varios días antes de la migración, para que cuando llegue el cambio real, la copia en caché anterior expire mucho más rápido en todos los resolutores. Igual de importante es mantener el servidor antiguo funcionando y respondiendo correctamente durante todo el periodo de transición, no apagarlo en el momento del cambio, precisamente porque una parte del tráfico (humano y de rastreo) seguirá llegando ahí durante horas o días.
DNSSEC: qué añade y el error de configuración que puede tumbar un dominio entero
DNSSEC añade una cadena de firmas criptográficas a las respuestas DNS, permitiendo a un resolutor verificar que la respuesta recibida no ha sido manipulada por un intermediario, un ataque de envenenamiento de caché DNS, por ejemplo, que podría redirigir a usuarios y rastreadores hacia un servidor malicioso sin que el dominio en sí haya cambiado. No es, en sí mismo, un factor de posicionamiento, pero protege contra un vector real de compromiso que, si llega a materializarse, sí tiene consecuencias de SEO graves, como se explica en la guía de seguridad comprometida y recuperación del índice.
El riesgo técnico real de DNSSEC no está en activarlo sino en desactivarlo o rotarlo mal: si la cadena de firmas se rompe, una clave rotada en el dominio sin actualizar el registro DS correspondiente en el registrador, por ejemplo, los resolutores que validan DNSSEC, que son la mayoría de los grandes resolutores públicos, dejan de resolver el dominio por completo para cualquiera que dependa de ellos. Es un fallo que se manifiesta como si el dominio hubiera desaparecido, no como un simple error de servidor, y que puede pasar semanas sin detectarse si nadie revisa específicamente el estado de la cadena de confianza.
CDN y DNS: anycast, geo-routing y la ubicación percibida del servidor
Un CDN moderno normalmente no resuelve el dominio a una única IP fija, sino que usa anycast: la misma dirección IP se anuncia simultáneamente desde múltiples ubicaciones físicas distintas mediante el protocolo de enrutamiento BGP, y es la propia infraestructura de red la que dirige a cada usuario o rastreador hacia el nodo físicamente más cercano, sin que el DNS tenga que devolver IPs distintas según la ubicación de quien pregunta. Es una capa adicional sobre el geo-routing basado en DNS tradicional, donde el propio servidor de nombres calcula y devuelve una IP distinta según la región del resolutor que pregunta, y explica por qué, en un sitio servido por un CDN grande, la pregunta de dónde está físicamente el servidor deja de tener una respuesta única: está, en la práctica, en todas partes a la vez, y eso es precisamente lo que reduce la latencia percibida, y por tanto el TTFB, para audiencias distribuidas geográficamente, como se explica en la guía de velocidad de servidor y TTFB.
Preguntas frecuentes
¿Cuánto tarda realmente en "propagarse" un cambio de DNS?
Depende exclusivamente del TTL que tenía el registro antes del cambio: puede ser cuestión de minutos con un TTL bajo, o de hasta 24-48 horas, el límite práctico que suelen citar los registradores, si el TTL anterior era alto o si algún resolutor concreto ignora el TTL declarado, algo que ocurre ocasionalmente pero no es la norma.
¿Es obligatorio activar DNSSEC?
No es obligatorio y la mayoría de dominios funcionan perfectamente sin él, pero cuando se activa hay que gestionarlo con cuidado, sobre todo en rotaciones de clave, porque un fallo de configuración es más disruptivo que no tenerlo activado en absoluto.
¿El proveedor de DNS afecta al SEO más allá de la disponibilidad?
Indirectamente sí: un proveedor de DNS lento en resolver, aunque el registro esté bien configurado, añade latencia a cada primera resolución no cacheada, y un proveedor con baja disponibilidad genera exactamente los errores de rastreo "DNS no encontrado" descritos en esta guía.
¿Debo mantener siempre el TTL muy bajo por si acaso?
No es necesario ni recomendable de forma permanente: un TTL bajo constante genera una carga de consultas innecesaria sin ningún beneficio si no hay cambios previstos. La práctica habitual es mantener un TTL moderado, una hora, por ejemplo, y bajarlo temporalmente solo en los días previos a un cambio planificado.
¿Puede un cambio de DNS afectar a las cookies o la sesión de los usuarios?
No directamente: el DNS solo resuelve el nombre a una IP, no participa en la gestión de cookies ni de sesión, que dependen del servidor al que finalmente se conecta el navegador tras la resolución.