Un registro SOA describe la autoridad de una zona DNS. Indica el servidor primario autoritativo y la dirección de contacto. Proporciona un número de serie así como temporizaciones para la sincronización de los servidores secundarios.
Un registro SOA contiene un nombre, un tipo, un servidor primario, un contacto, un número de serie y cinco duraciones. El TTL indica cuánto tiempo permanece la respuesta en caché en el resolutor local.
| Nombre | Tipo | Servidor primario MNAME | Contacto RNAME | Serial | Refresh | Retry | Expire | Minimum TTL | TTL en segundos |
|---|
| @ | SOA | ns1.ejemplo.net. | hostmaster.ejemplo.com. | 2025090301 | 7200 | 900 | 1209600 | 3600 | 3600 |
En este ejemplo el nombre @ apunta al ápex de la zona. El servidor primario debe resolver a A o AAAA. El contacto se escribe como una dirección de correo electrónico con un punto en lugar de la arroba. Por ejemplo hostmaster.ejemplo.com corresponde a hostmaster@ejemplo.com. El serial progresa con cada modificación de la zona. Los valores refresh, retry, expire y minimum TTL están en segundos.
El servidor primario MNAME designa el host de referencia para la zona.
El contacto RNAME recibe los mensajes relacionados con la zona.
El serial permite a los secundarios saber si existe una versión más reciente.
Refresh indica cuándo un secundario verifica el primario.
Retry indica la espera entre dos intentos después de un fallo.
Expire indica después de cuánto tiempo un secundario abandona una zona que se ha vuelto imposible de actualizar.
Minimum TTL sirve para el caché negativo. Fija la duración durante la cual una ausencia de respuesta permanece en caché. El TTL por defecto de los registros se configura en otra parte de la zona.
Bueno saber
Solo existe un SOA por zona. Se publica en el ápex junto a los registros NS. El campo minimum TTL no define el TTL por defecto de otros registros. Sirve para el caché negativo.
El TTL del SOA controla la duración del caché de la respuesta SOA del lado del resolutor. Un TTL demasiado largo puede retrasar la consideración de un cambio de serial. Un TTL razonable mejora la reactividad sin sobrecargar los servidores autoritativos.
En el ápex de la zona. Siempre. Los subdominios delegados poseen su propio SOA en su zona dedicada. Un CNAME no debe aparecer en el ápex porque la zona ya debe publicar SOA y NS.
A evitar
Olvidar aumentar el serial después de una modificación de la zona.
Poner un servidor primario que no resuelve a A o AAAA.
Invertir refresh y retry.
Usar un expire demasiado corto que hace caer la zona en los secundarios.
Una búsqueda DNS en línea permite introducir un nombre de dominio. El resultado muestra el SOA tal como se ve desde Internet. Se lee el servidor primario, el contacto, el serial y las temporizaciones. Luego realizar una prueba local desde su máquina.
Windows proporciona nslookup. Se puede usar en modo interactivo.
nslookup
set q=soa
ejemplo.com
nslookup
set q=soa
server 1.1.1.1
ejemplo.com
La primera parte consulta según la configuración de red de la máquina. La segunda fuerza el uso de un resolutor de terceros, aquí el de Cloudflare.
En estos sistemas el comando dig es práctico y fácil de usar.
dig SOA ejemplo.com
dig SOA ejemplo.com @1.1.1.1
Un serial más antiguo en un servidor secundario indica un retraso de transferencia.
Un refresh muy largo retrasa la propagación de los cambios.
Un expire demasiado corto puede provocar el abandono de la zona por un secundario.
Un contacto mal formado impide la recepción de mensajes útiles.
- Preparar la actualización de la zona.
- Aumentar el serial.
- Recargar la zona en el servidor primario.
- Dejar que los secundarios se actualicen o desencadenar una transferencia si la herramienta lo permite.
- Verificar el nuevo serial desde varias redes y luego validar.
Consejo práctico
Adoptar un formato de serial predecible. Un formato de fecha seguido de un contador facilita el seguimiento. Por ejemplo 2025090301 para la primera modificación del día.
Configurar la zona en el nuevo servicio. Verificar SOA y NS. Cambiar la delegación cuando todo esté listo.
Permitir la transferencia de zona en el primario. Verificar que el secundario recupera bien la zona y muestra el serial correcto.
Actualizar RNAME. Probar que los mensajes llegan al destinatario correcto.
- Si el SOA difiere según los servidores autoritativos esperar un ciclo de refresh y luego verificar nuevamente.
- Si un secundario permanece bloqueado en un serial antiguo verificar el acceso de red y los derechos de transferencia de zona.
- Si la zona desaparece en un secundario aumentar expire y verificar la salud del primario.
- Si la respuesta permanece antigua a pesar de la actualización esperar la expiración del TTL y purgar la caché del resolutor local si es posible.
En resumen, un registro SOA define la autoridad de una zona. Indica el servidor primario, el contacto, el serial y las temporizaciones que regulan la sincronización. Solo un SOA en el ápex. Valores consistentes aseguran una propagación confiable. La verificación pasa por una herramienta en línea luego por nslookup y por dig.
Con estas referencias la gestión permanece clara. Los cambios se desarrollan sin estrés. Los servicios DNS responden como se espera.