Qué es el registro SOA de DNS y por qué es importante para su dominio
¿Qué es un registro SOA?
El registro SOA (Start of Authority, inicio de autoridad) es el primer registro de toda zona DNS y el único que debe existir exactamente una vez. Indica el servidor de nombres primario de la zona, la dirección de contacto del administrador y un conjunto de temporizadores que dicen a los servidores de nombres secundarios cómo mantener su copia de la zona sincronizada.
A diferencia de un registro A o MX, el SOA no está ahí para responder consultas de usuarios. Son metadatos sobre la propia zona: quién es autoritativo para ella, qué versión de la zona es esta y durante cuánto tiempo otros servidores pueden confiar en esa versión o guardarla en caché. Si el SOA es incorrecto, la zona puede seguir resolviendo hoy — pero dejará de actualizarse, no expirará o cacheará errores durante demasiado tiempo.
Puede ver el registro SOA de cualquier dominio con dig:
dig SOA example.com +shortUna respuesta típica tiene este aspecto:
ns1.example.com. hostmaster.example.com. 2026082601 3600 900 1209600 300Los siete valores son el servidor de nombres primario, el buzón responsable y cinco números — el serial y cuatro temporizadores — que se explican a continuación.
Los siete campos del SOA explicados
Todo registro SOA lleva los mismos siete campos, en este orden:
MNAME — el servidor de nombres primario de la zona. Los secundarios envían sus consultas de refresco a este host y esperan de él los mensajes NOTIFY. Debe ser un nombre de host que resuelva, no una dirección IP.
RNAME — el buzón de la persona responsable de la zona, escrito con un punto en lugar de la @: hostmaster.example.com significa [email protected]. Si la parte local contiene un punto, se escapa con una barra invertida.
Serial — el número de versión de la zona. Los secundarios lo comparan con el de su propia copia para decidir si la zona ha cambiado. Es el campo más importante para mantener actualizados los servidores de nombres secundarios.
Refresh — con qué frecuencia, en segundos, un secundario pide al primario el serial actual. 3600 (una hora) es un valor habitual. Con NOTIFY configurado, este temporizador es solo una red de seguridad.
Retry — cuánto espera un secundario antes de volver a preguntar tras un intento de refresco fallido. Debe ser menor que refresh; 900 (15 minutos) es lo típico.
Expire — durante cuánto tiempo un secundario sigue sirviendo la zona después de la última vez que consiguió comunicarse con el primario. Cuando este temporizador se agota, el secundario deja de responder por la zona por completo. 1209600 (dos semanas) es el valor habitual.
Minimum — históricamente el TTL por defecto de los registros; desde el RFC 2308 define el TTL de cacheo negativo: cuánto tiempo pueden los resolutores cachear el hecho de que un nombre no existe (NXDOMAIN). El TTL negativo efectivo es el menor entre este campo y el TTL del propio registro SOA. Un rango razonable es de 300 a 3600.
Cómo usan el SOA los servidores de nombres secundarios
El registro SOA es el contrato entre su servidor de nombres primario y cada secundario que sirve su zona. Un secundario sigue este ciclo:
1. Cada refresh segundos, consulta al primario el registro SOA. 2. Compara el serial de la respuesta con el serial de su propia copia. 3. Si el serial del primario es mayor, solicita una transferencia de zona (AXFR o IXFR) e instala la copia nueva. 4. Si la consulta falla, vuelve a intentarlo pasados retry segundos. 5. Si no consigue comunicarse con el primario durante expire segundos, descarta la zona y devuelve SERVFAIL hasta que el primario vuelva.
La mayoría de los primarios también envían un mensaje NOTIFY en el momento en que la zona cambia, de modo que el secundario comprueba el serial de inmediato en lugar de esperar al temporizador de refresco. Los temporizadores siguen importando: un NOTIFY puede perderse, ser bloqueado por un cortafuegos o simplemente no estar configurado, y entonces refresh y retry son lo único que mantiene las copias sincronizadas.
Por eso un servicio de DNS secundario gestionado puede mantener su dominio en línea mientras el primario está caído: ya tiene una copia completa y actual de la zona y sigue respondiendo por ella hasta que expire se agota. Vea Redundancia DNS para la visión general y Entender las transferencias de zona AXFR para saber cómo funciona la transferencia en sí.
El número de serial: formatos y errores clásicos
El serial es un entero sin signo de 32 bits, y la única regla que impone el protocolo es que una zona más nueva debe llevar un serial mayor que la anterior. Los secundarios no miran fechas ni marcas de tiempo de archivos — solo este número.
Seriales basados en fecha son la convención más común: YYYYMMDDnn, por ejemplo 2026082601 para el primer cambio del 26 de agosto de 2026. Los dos últimos dígitos permiten hasta 100 ediciones al día, y el número sigue siendo legible en la salida de dig.
Seriales con marca de tiempo Unix los usan muchos proveedores de DNS gestionado y BIND cuando se configura con serial-format unixtime. Aumentan automáticamente y nunca colisionan.
Contadores simples (1, 2, 3, …) también son perfectamente válidos. El formato es una convención, no un requisito.
Los errores que realmente rompen zonas:
- Olvidar incrementar el serial. Edita el archivo de zona, recarga el primario y este responde con los datos nuevos — pero todos los secundarios siguen viendo el serial antiguo, deciden que nada ha cambiado y siguen sirviendo registros obsoletos indefinidamente. Es la causa más común, con diferencia, de "el cambio funciona en ns1 pero no en ns2".
- Ir hacia atrás. Pasar de un serial grande con marca de tiempo a uno pequeño basado en fecha, o restaurar un archivo de zona antiguo, deja al secundario con un serial mayor que el del primario. No volverá a transferir nunca hasta que el serial del primario lo supere. La aritmética de seriales (RFC 1982) ofrece una salida: sume 2^31 − 1 (2147483647) al serial, deje que todos los secundarios lo recojan y luego fije el valor que realmente quiere — el segundo paso vuelve a verse como un incremento.
- Editar el serial en un secundario. Los secundarios nunca deben editarse a mano; la siguiente transferencia sobrescribe la copia y el cambio manual desaparece.
Elegir los valores de refresh, retry, expire y minimum
El RFC 1912 ofrece la guía clásica, y sigue siendo válida. Valores por defecto razonables para una zona que tiene NOTIFY configurado:
Refresh — 1 hora (3600) Retry — 15 minutos (900) Expire — 2 semanas (1209600) Minimum — de 5 minutos a 1 hora (300 – 3600)
Las dos reglas que importan más que los números exactos:
Retry debe ser menor que refresh, e idealmente una pequeña fracción de este — de lo contrario, un refresco fallido simplemente espera al siguiente programado y el temporizador de retry no hace nada.
Expire debe ser mayor que la caída más larga que pueda imaginar en el primario. Si el primario se cae el viernes por la tarde y nadie lo nota hasta el lunes, un expire de 86400 (un día) significa que todos los secundarios dejaron de responder el sábado — y se pierde todo el sentido de tener secundarios. Dos semanas es la elección habitual y también el mínimo para una zona en producción; el RFC 1912 sugiere de dos a cuatro semanas.
Para minimum (cacheo negativo), los valores más cortos permiten que un registro recién creado sea visible antes si se consultó mientras aún no existía; los valores más largos reducen la carga de búsquedas repetidas de nombres que nunca existirán. No lo fije por encima de unas pocas horas — de lo contrario, una errata en un nombre de host se cachearía como inexistente durante un día entero.
Diagnosticar un secundario desactualizado con dig
Cuando un cambio de DNS es visible en un servidor de nombres pero no en otro, el serial del SOA le dice dónde está el problema. Pregunte directamente a cada servidor autoritativo:
dig @ns1.example.com example.com SOA +short
dig @ns2.example.com example.com SOA +shortTres resultados posibles:
El mismo serial en ambos — la zona está sincronizada. Si un registro sigue pareciendo incorrecto, el problema es el cacheo en el resolutor, no la replicación; espere al TTL del registro o consulte directamente al servidor autoritativo.
Serial más bajo en el secundario — el secundario conoce la zona pero no ha recogido la última versión. Compruebe que el serial del primario se incrementó realmente, que el primario permite transferencias desde la IP del secundario (allow-transfer / allow-axfr-ips), que el puerto TCP 53 está abierto entre ambos y si el primario envía NOTIFY siquiera.
SERVFAIL o REFUSED desde el secundario — la zona nunca se transfirió o ha expirado. Revise el registro del secundario en busca de la última transferencia correcta; si es anterior al valor de expire, el secundario ha descartado la zona correctamente y necesita que el primario vuelva antes de poder recargarla.
Un secundario que debería estar sincronizado y no lo está es un fallo silencioso: sigue respondiendo, solo que con datos antiguos. Monitorizar el serial en todos los servidores de nombres — no solo su accesibilidad — es la única forma de detectarlo antes que los usuarios.
Ejemplo de registro SOA para una zona típica
Un registro SOA completo en sintaxis de archivo de zona, con los temporizadores de la tabla anterior:
example.com. 3600 IN SOA ns1.example.com. hostmaster.example.com. (
2026082601 ; serial (YYYYMMDDnn)
3600 ; refresh (1 hour)
900 ; retry (15 minutes)
1209600 ; expire (2 weeks)
300 ) ; minimum (negative caching TTL, 5 minutes)El 3600 que precede a IN es el TTL del propio registro SOA — cuánto tiempo pueden cachearlo los resolutores. También limita el TTL de cacheo negativo: con 3600 aquí y un minimum de 300, los resolutores cachean las respuestas NXDOMAIN durante 300 segundos, el menor de los dos.
Si usa un panel de hosting o la interfaz web de un proveedor de DNS, el SOA normalmente se genera por usted, y el serial se incrementa automáticamente en cada guardado. Aun así, conviene comprobar una vez los valores de los temporizadores: algunos paneles vienen con un expire de un día, lo que anula silenciosamente cualquier secundario que añada después.
Guías relacionadas
El registro SOA es el mecanismo; estas guías explican para qué sirve:
- Redundancia DNS: por qué es importante y cómo lograrla - Entender las transferencias de zona AXFR - Cómo configurar un servidor DNS secundario