Cómo cambiar de servidores de nombres sin interrupciones

Cambiar de servidores de nombres es una de las pocas operaciones de DNS que puede dejar fuera de servicio un dominio entero: sitio web, correo, API, todo. Rara vez sale mal por el cambio en sí. Sale mal porque la zona nueva estaba incompleta, porque un TTL era de una semana o porque DNSSEC seguía apuntando al proveedor antiguo.

Esta guía es el plan que seguiríamos nosotros mismos. Los ejemplos usan nombres reservados y direcciones de documentación.

Qué ocurre realmente al cambiar de servidores de nombres

Su dominio tiene registros NS en dos lugares:

En el padre (el registro de .com, .org, .com.tr…). Esto es la delegación. Se cambia en su registrador.
Dentro de su propia zona, servida por su proveedor de DNS. Estos deberían coincidir con la delegación.

Cuando un resolver necesita www.example.com y no tiene nada en caché, pregunta a la zona padre quién es responsable, obtiene la delegación y después pregunta a uno de esos servidores de nombres. Cambiar de servidores de nombres significa cambiar la delegación en el padre.

Nada se "empuja" a Internet. Los resolvers de todo el mundo siguen usando lo que tienen en caché hasta que expira; entonces vuelven a preguntar y reciben la respuesta nueva. Por eso la gente habla de "propagación", y por eso es una palabra engañosa: no hay ninguna ola que se extienda hacia fuera, solo cachés que expiran en momentos distintos.

Paso 1: inventario de la zona antigua

Exporte la zona completa del proveedor antiguo. Si hay un botón de exportación (formato BIND), úselo. Si no, liste cada registro a mano. Los registros que la gente olvida:

MX, y los registros TXT de SPF, de los selectores DKIM (selector._domainkey) y de _dmarc
registros TXT de verificación para consolas de búsqueda, herramientas SaaS y emisión de certificados
registros CAA
registros SRV (_sip, _autodiscover, _matrix…)
subdominios delegados a otro sitio con sus propios registros NS
registros comodín (*.example.com)

Una consulta pública solo muestra los nombres por los que se pregunta, así que no puede sustituir a la exportación. Aun así es una comprobación cruzada útil:

$ dig +short example.com MX
10 mx1.mail.example.
$ dig +short _dmarc.example.com TXT
"v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

Paso 2: construya la zona nueva y pruébela directamente

Cree todos los registros en el proveedor nuevo antes de tocar la delegación. Después consulte directamente los servidores de nombres nuevos, saltándose las cachés, y compare con los antiguos:

$ dig @ns1.olddns.example example.com A +short
192.0.2.10
$ dig @ns1.newdns.example example.com A +short
192.0.2.10

Repítalo para cada tipo de registro y cada nombre de host de su inventario. Las respuestas deben coincidir exactamente, salvo que esté cambiando algo a propósito. Resista la tentación de combinar un cambio de servidores de nombres con un cambio de servidor: cambie una sola cosa cada vez, para que un problema tenga una única causa posible.

Paso 3: baje los TTL con antelación

Importan dos TTL:

Los TTL de sus registros en el proveedor antiguo. Bájelos (300 segundos es habitual) al menos un TTL antiguo antes del cambio. Si el TTL antiguo era 86400, hágalo con un día o más de antelación.
El TTL de la delegación en el padre. Este no lo controla usted. En muchos TLD es de 48 horas (172800 segundos). Esa es la duración real de su ventana de migración.

Por el segundo punto, planifique que ambos conjuntos de servidores de nombres respondan correctamente durante al menos dos o tres días.

Paso 4: ocúpese primero de DNSSEC

Si el dominio está firmado, el padre guarda un registro DS que apunta a la clave del proveedor antiguo. Si cambia de servidores de nombres con ese DS todavía en su sitio y el proveedor nuevo firma con otra clave (o no firma), los resolvers validadores tratarán cada respuesta como falsa. El dominio se apaga para una gran parte de los usuarios, y bajar los TTL no le salvará.

Compruebe primero:

$ dig +short example.com DS

Si hay un registro DS, elija un enfoque:

Quedarse sin firmar durante la mudanza. Retire el DS en el registrador, espere a que expire el TTL del DS en el padre (a menudo 24 horas o más), cambie los servidores de nombres y después active DNSSEC en el proveedor nuevo y publique el DS nuevo.
Hacer una migración con varios firmantes si ambos proveedores la admiten: cada proveedor publica la clave pública del otro antes del cambio. Así el dominio se mantiene firmado en todo momento, pero hace falta la cooperación de las dos partes.

Los fundamentos están en DNSSEC explicado.

Paso 5: cambie la delegación

En el registrador, sustituya los servidores de nombres antiguos por el conjunto nuevo. Introdúzcalos exactamente como los indica el proveedor nuevo. Algunos registros hacen comprobaciones técnicas y rechazan el cambio si los servidores nuevos no responden con autoridad para la zona; es otra razón para completar antes el paso 2.

Mantenga la zona antigua en funcionamiento y sin cambios. Durante los próximos días, algunos resolvers seguirán preguntando a los servidores antiguos. Si tiene que cambiar un registro durante esta ventana, cámbielo en los dos sitios.

Paso 6: verifique desde varios lugares

Compruebe directamente la vista del padre:

$ dig +trace example.com NS

Después pregunte a varios resolvers públicos y compare. Espere respuestas mezcladas durante un tiempo. Es normal y no significa que nada esté roto, siempre que ambas zonas sirvan los mismos datos.

Qué buscar:

¿Qué conjunto de NS devuelve cada ubicación, el antiguo o el nuevo? Un conjunto parcial (uno antiguo, uno nuevo) no es un éxito.
¿Coinciden las respuestas A, AAAA y MX entre el antiguo y el nuevo?
¿Sigue presentando HTTPS un certificado válido, y sigue llegando el correo?

Desconfíe de afirmaciones como "85 % propagado". Ninguna herramienta puede medir todos los resolvers de Internet. Una afirmación honesta es más estrecha: "9 de 12 ubicaciones monitorizadas devuelven los servidores de nombres nuevos, 2 devuelven todavía los antiguos, 1 no se pudo comprobar".

Paso 7: retire lo antiguo con cuidado

Espere al menos el TTL de la delegación del padre más un margen de seguridad (tres días es un mínimo razonable, una semana es cómodo) antes de borrar la zona antigua. Después suba de nuevo los TTL de sus registros a valores normales (3600 o más) para reducir la carga de consultas y mejorar la resistencia.

Plan de marcha atrás

Antes de empezar, anote los nombres de los servidores de nombres antiguos y conserve intacta la zona antigua. Si algo va mal después del cambio:

Corrija el registro en el proveedor nuevo si el problema es un registro ausente o incorrecto. Casi siempre es la solución más rápida.
Si es el propio proveedor nuevo el que falla, devuelva la delegación a los servidores de nombres antiguos. Recuerde que la marcha atrás está sujeta al mismo almacenamiento en caché, así que tampoco es instantánea.

Errores frecuentes

Cambiar primero y volver a crear los registros después.
Olvidar los selectores DKIM, con lo que el correo empieza a fallar DMARC días más tarde.
Dejar un registro DS en su sitio al pasar a un proveedor que no firma con la misma clave.
Borrar la zona antigua el mismo día.
Tomar una única consulta correcta desde el propio portátil como prueba de que la mudanza está completa. La caché explica por qué: véase qué es el TTL en DNS.

Compruébelo con OrbitProbe

Use la consulta DNS para ver los registros y los servidores de nombres que los resolvers públicos devuelven ahora mismo para su dominio, y la consulta WHOIS para confirmar los servidores de nombres y el estado de DNSSEC anotados en el registro. En el espacio de trabajo de OrbitProbe también puede crear una vigilancia para el conjunto exacto de servidores de nombres que espera; informa de cuántas ubicaciones monitorizadas coinciden, cuáles muestran todavía el valor antiguo y cuáles no se pudieron comprobar.