¿Qué es un registro SOA en DNS?

Si alguna vez has explorado los registros DNS de un dominio con dig o una herramienta online, probablemente te hayas encontrado un registro SOA sin saber muy bien para qué sirve. Es uno de los registros más importantes de cualquier zona DNS: define quién tiene autoridad sobre esa zona, cómo deben sincronizarse los servidores DNS secundarios y cuánto tiempo siguen siendo válidos los datos si el primario cae.

Qué contiene un registro SOA

SOA significa Start of Authority. Cada zona DNS debe contener obligatoriamente un único registro SOA. Siempre está en la cima de la zona y tiene siete campos distintos. Así se ve un registro SOA típico:

example.com.  3600  IN  SOA  ns1.example.com. admin.example.com. (
                          2025052901  ; Serial
                          7200        ; Refresh
                          3600        ; Retry
                          1209600     ; Expire
                          86400 )     ; Minimum TTL

Veamos cada campo:

• MNAME (ns1.example.com.): el servidor DNS primario autoritativo de la zona. Es el servidor al que los secundarios contactan para obtener actualizaciones
• RNAME (admin.example.com.): la dirección de correo del administrador de la zona, pero con un punto en lugar de @. Aquí corresponde a [email protected]. Si la parte local contiene un punto, hay que escaparlo con barra invertida (nombre\.apellido.example.com.)
• Serial (2025052901): un número de versión de la zona. Cada modificación debe incrementar este número, si no los secundarios no detectarán el cambio. El formato habitual es YYYYMMDDNN (fecha más contador diario)
• Refresh (7200): el intervalo en segundos entre comprobaciones de los servidores secundarios. Aquí, cada 2 horas
• Retry (3600): el tiempo antes de reintentar si la comprobación Refresh falla. Aquí, 1 hora
• Expire (1209600): el tiempo tras el cual un secundario deja de responder por la zona si ya no consigue contactar al primario. Aquí, 14 días. Pasado ese plazo, el secundario considera sus datos caducados y deja de servir la zona
• Minimum TTL (86400): desde la RFC 2308, este campo define cuánto tiempo se cachean las respuestas negativas (NXDOMAIN). Aquí, 24 horas. Si alguien consulta un subdominio inexistente, el resolutor guardará esa respuesta "no existe" en caché durante 24 horas

Por qué el número de serie importa tanto

El serial es probablemente el campo que más problemas causa en la práctica. Cuando un servidor secundario contacta al primario durante un ciclo de Refresh, compara el número de serie de su copia con el del primario. Si el del primario es más alto, el secundario lanza una transferencia de zona (AXFR o IXFR) para actualizarse. Si no ha cambiado, no hace nada.

El error clásico: modificar un registro DNS en el primario sin incrementar el serial. Resultado, el primario tiene la versión correcta pero los secundarios siguen sirviendo la antigua durante horas o días. Los usuarios obtienen respuestas diferentes según el servidor que consulten, y el problema es difícil de diagnosticar si nadie piensa en revisar el SOA.

El formato YYYYMMDDNN es una convención, no una obligación. El serial es un entero de 32 bits, así que cualquier valor entre 0 y 4.294.967.295 funciona. Pero el formato de fecha es recomendable porque hace los errores visibles: un serial de 2025052901 es claramente el primer cambio del 29 de mayo de 2025.

Cómo interactúan Refresh, Retry y Expire

Estos tres valores forman un sistema de resiliencia para las zonas DNS. Refresh marca el ritmo normal de sincronización. Retry entra en juego cuando el Refresh falla. Expire es la última barrera: pasado ese tiempo sin contacto con el primario, el secundario prefiere dejar de responder del todo antes que servir datos potencialmente obsoletos.

Para un dominio estándar, la RFC 1912 recomienda:

• Refresh: 3.600 a 86.400 segundos (1 hora a 24 horas)
• Retry: 600 a 3.600 segundos (10 minutos a 1 hora)
• Expire: 1.209.600 a 2.419.200 segundos (2 a 4 semanas)
• Minimum TTL: 3.600 a 86.400 segundos (1 hora a 24 horas)

Si tu zona cambia frecuentemente (por ejemplo un CDN o una infraestructura con balanceo dinámico), reduce el Refresh a 300 o 600 segundos. Si es estable, 86.400 va perfecto y reduce la carga en el servidor primario.

Cómo consultar el registro SOA de un dominio

En Linux y macOS, el comando dig es el más práctico:

dig SOA example.com

En Windows, usa nslookup:

nslookup -type=SOA example.com

La respuesta muestra los siete campos del SOA. Presta atención especial al serial: si parece antiguo o congelado, suele ser la razón por la que los cambios DNS no se propagan correctamente.

Errores frecuentes en el SOA

Algunos problemas que aparecen con regularidad en la práctica:

• El RNAME usa un @ en lugar de un punto, lo que rompe la sintaxis. [email protected] debe escribirse como admin.example.com. en el SOA
• El serial se decrementa accidentalmente tras restaurar una copia de seguridad. Los secundarios se negarán a sincronizarse hasta que el serial del primario vuelva a estar por encima de su valor local
• El Expire es demasiado corto (unas pocas horas). Si el primario cae un fin de semana, los secundarios dejan de responder antes de que alguien pueda intervenir
• El Minimum TTL está a 0, lo que significa que los resolutores no cachean las respuestas negativas. Cada consulta a un subdominio inexistente genera un viaje de ida y vuelta completo, lo que puede sobrecargar tus servidores DNS durante un escaneo o ataque

El registro SOA rara vez es lo primero que se edita al configurar un dominio, pero suele ser lo que explica por qué "los DNS no se propagan". Antes de buscar causas complejas, comprueba que el serial se incrementó correctamente y que los valores de Refresh y Expire se ajustan a tu uso.