Registro SOA: pieza clave del archivo de zona
Todo usuario de Internet tiene claro que, introduciendo un URL concreto en el navegador, puede acceder a la página que desee. Lo que no es tan obvio es que el ordenador en realidad establece la conexión mediante una dirección IP. Esto es posible gracias al sistema de nombres de dominio (DNS) y a su función de resolución de nombres, es decir, de traducir los nombres de dominio a las series de cifras correspondientes. Para que el sistema funcione, los servidores de nombres disponen de archivos de zona. En estos sencillos archivos de texto se guardan, a su vez, numerosos registros DNS (DNS records), que son los que hacen posible el DNS en sí.
El DNS abarca más de 100 tipos diferentes de registros. En nuestro detallado artículo sobre los registros DNS los resumimos todos y explicamos el principio en el que se basan.
Los más conocidos son probablemente los registros A, ya que principalmente a través de ellos se produce la resolución de nombres. También existen, por ejemplo, los registros PTR, que permiten búsquedas DNS inversas, y los registros MX, que se ocupan de la comunicación por correo electrónico. ¿Qué función realizan entonces los registros SOA?
¿Cómo funcionan los registros SOA?
El DNS es un sistema jerárquico descentralizado. Los servidores de nombres no dan información sobre cualquier servidor de Internet, sino solo sobre los que se encuentran dentro de la zona que les corresponde. Con este fin, los servidores DNS utilizan archivos de zona, que son simples archivos de texto en los que se enumeran todos los registros DNS de la zona. Para delimitar las responsabilidades, cada archivo de zona tiene, obligatoriamente, un registro SOA o DNS SOA record, cuyas iniciales derivan de Start of Authority. Esto quiere decir que el registro contiene información acerca de si el servidor consultado es el responsable de la solicitud o no.
El registro SOA tiene una importancia especial en el contexto de los server clusters (unión de servidores que trabajan como uno solo), en los que, en lugar de poner la carga de todas las solicitudes en un mismo ordenador, se reparten entre distintos servidores. Para que los archivos de zona se mantengan actualizados en todos los servidores, debe producirse regularmente una transferencia de zona. En ella, los llamados slaves o esclavos (servidores inferiores en la jerarquía) comparan sus archivos con los del master (servidor superior). El registro SOA regula cómo debe llevarse a cabo dicha transferencia y para ello dispone de distintas informaciones.
Estructura del registro
Los registros DNS se componen, básicamente, de diferentes campos en los que, a su vez, se encuentra la información relevante. El SOA record tiene muchos campos, en comparación con otros registros:
- <name>: nombre de la zona
- <class>: clase de red
- <type>: tipo de registro
- <mname>: nombre del master (servidor maestro)
- <rname>: dirección de correo electrónico del administrador encargado
- <serial>: número de serie del archivo de zona, que aumenta con cada actualización
- <refresh>: tiempo en el que un servidor esclavo tiene que solicitar al servidor maestro una actualización
- <retry>: tiempo en el que un esclavo ha de repetir el intento tras una solicitud fracasada
- <expire>: tiempo a partir del cual un esclavo deja de dar información al exterior si el master sigue sin dar respuesta
- <minimum>: tiempo durante el cual la información puede ser almacenada en la memoria caché
Los tres primeros campos son típicos de los registros DNS. El nombre de la zona es un nombre de dominio en formato de nombres de dominio totalmente calificados (FQDN), lo cual significa que la información, a diferencia de lo que ocurre en los URL, acaba con un punto. La razón es que un FQDN presenta la estructura jerárquica completa del dominio, cuya última parte es el certificado raíz. Este, sin embargo, está vacío, por lo que el último carácter es el punto que lo separa del segmento anterior. Este tipo de notación aparece en todos los nombres de dominio del DNS, también en los campos MNAME y RNAME.
El campo class, referido a la clase de red, solo tiene relevancia histórica, por lo que en muchos casos simplemente se omite. Cuando se desarrolló el DNS, además de Internet, existían dos otros proyectos de red: Hesiod (HS) y Chaosnet (CH), ambos ya obsoletos. Puesto que actualmente solo queda Internet, también se puede rellenar este campo con la abreviación IN. El campo type, referido al tipo de registro, es en este caso SOA.
El campo MNAME, también llamado primary master, indica qué servidor se encuentra sobre el esclavo. Así se define a qué servidor de nombres tiene que dirigir su solicitud de transferencia de zona el servidor inferior (esclavo). En el campo RNAME hay que formatear la dirección de correo electrónico teniendo en cuenta algunas particularidades: no se permiten arrobas (@) en la notación, sino que es un punto el que separa la parte local (el nombre de usuario, por ejemplo) del dominio. Si en la dirección original aparece un punto antes de la arroba, este se indica mediante una barra invertida (\).
El número de serie del archivo de zona debe aumentar con cada actualización del archivo. Existen dos maneras de hacerlo. Por un lado, un proceso sencillo puede empezar con 1 y aumentar el número en una cifra con cada actualización. Esta opción permite saber, a partir del número de serie, cuántos cambios ha habido.
La segunda opción es escoger un formato de fecha: AAAAMMDDVV. Se empieza con un año de cuatro cifras, luego aparecen el mes y el día (cada uno con dos cifras) y por último aparece un número de versión, también de dos cifras. Este formato permite, por su parte, saber en qué fecha se creó la versión. Con cada cambio en un mismo día, el número de versión aumenta en una cifra. Al día siguiente cambia el número de serie y el número de versión vuelve a ponerse a 00.
El SOA record acaba con tres o cuatro campos temporales, todos dados en segundos. El primero de ellos, refresh, indica el tiempo que espera un servidor esclavo antes de solicitar al servidor maestro la versión actual del archivo de zona. Si dicha solicitud no recibe respuesta, el campo retry establece cuándo debe realizarse un nuevo intento. Es importante que este último valor sea menor que el anterior.
Si el servidor inferior en la jerarquía (esclavo) ya no recibe respuesta en absoluto, el tercer campo temporal (expire) se encarga de indicar durante cuánto tiempo el archivo de zona puede seguir usándose antes de que el servidor deje de ofrecer informaciones DNS. Si el servidor continuase respondiendo a solicitudes de clientes con datos del antiguo archivo de zona, estos ya no serían válidos, lo que daría lugar a problemas de conexión y a riesgos de seguridad.
El último campo, minimum, es el correspondiente al “time to live” del resto de registros DNS. Indica durante cuánto tiempo el cliente puede guardar la información solicitada en la memoria caché antes de que sea necesario enviar una nueva solicitud. El TTL, sin embargo, suele establecerse para una zona entera mediante la orden $TTL y no aparece entonces en cada uno de los registros. El nombre de la zona también puede indicarse al principio del archivo con la orden $ORIGIN.
El registro aparece siempre al comienzo del archivo de zona.
<name> <class> <type> <mname> <rname> <serial> <refresh> <retry> <expire> <minimum>
Los campos pueden ordenarse simplemente uno detrás de otro en una línea, pero, mientras que en el caso de otros tipos de registro esta estructura es bastante simple, en el caso del registro SOA es algo más compleja. Para ganar legibilidad, los campos se suelen ordenar en grupos y unos debajo de otros.
$ORIGIN
$TTL
@ <class> <type> <mname> <rname> (
<serial>
<refresh>
<retry>
<expire>
<minimum>
)
En este tipo de notación, el TTL y el nombre del dominio se establecen previamente. La arroba (@) al principio del registro hace referencia a la orden ORIGIN. Para agrupar los valores temporales y repartirlos en varias líneas se utilizan paréntesis.
Ejemplo de un SOA record
Ningún archivo de zona es válido si no contiene un registro SOA al principio. En la práctica, los registros SOA tienen la siguiente forma:
$ORIGIN example.org.
$TTL 1750
@ IN SOA master.example.org admin\.master.example.org (
2019040502 ; serial
86400 ; refresh
7200 ; retry
3600000 ; expire
1750 ; minimum
)
IN NS a.iana-servers.net.
www IN A 93.184.216.34
En este segmento de un archivo de zona, a modo de ejemplo, se han añadido más datos aparte del registro SOA, para ilustrar mejor la posición de los registros. El archivo comienza con los datos referentes al nombre del dominio (en este caso example.org) y el TTL. A continuación, aparece el SOA record. Puesto que ya hemos determinado la zona con la orden $ORIGIN, aquí basta con la arroba como indicación.
El servidor maestro (ficticio) para la zona aparece justo después de los datos sobre la clase de red y el tipo de registro. Luego viene la dirección de correo electrónico del administrador. El punto puede ponerse con ayuda de la barra invertida, que en este caso sirve como marca. El siguiente punto es el que sustituye a la arroba (@) de la dirección real; y el que le sigue separa, como siempre, el dominio de nivel superior (TLD). El paréntesis sirve para marcar el comienzo de un grupo de datos que se reparte en varias líneas. No obstante, también es posible escribir todos los valores uno tras otro y separarlos simplemente con espacios.
En este ejemplo hemos escrito una definición tras cada valor individual, que es simplemente un comentario que puede modificarse o directamente omitirse. En los registros DNS, tales comentarios pensados para usuarios humanos se marcan con punto y coma.
Al final del registro SOA hay que cerrar el paréntesis.
Finalmente se ha añadido un registro NS y un registro A al ejemplo de archivo de zona, de manera que se pueda observar que el registro SOA debe aparecer ante todos los demás, sin contar las indicaciones relativas al dominio y el TTL.
SOA-record check
Para comprobar el registro SOA de una página web se puede utilizar software especializado o, simplemente, hacer uso de un servicio web. Con Google Public DNS, el servidor DNS del gran motor de búsqueda, realizar un SOA-record check es rápido y sencillo. Basta con introducir el dominio en cuestión en la página de inicio del servicio. En la página siguiente aparecen directamente los resultados referidos al registro A, de forma que luego hay que escoger, en el campo correspondiente, la opción SOA y clicar para buscar de nuevo.
Public DNS ofrece muchas otras opciones. La función EDNS Client Subnet sirve para establecer conexiones DNS más eficientes y actualmente solo es implementada por Google y OpenDNS. Por su parte, DNSSEC garantiza que las informaciones obtenidas mediante el DNS provengan realmente del creador, ya que los datos que se envían sin dichas medidas de seguridad podrían haber sido manipulados por terceros. Ambas funciones pueden dejarse tal y como están al realizar un SOA-record check.
La solicitud realizada aparece bajo Question, mientras que los resultados de la solicitud se encuentran bajo Answer. En el campo data de la respuesta se puede ver el servidor maestro, la dirección de correo electrónico del administrador y los valores temporales. Hay que destacar que el último valor (minimum) solo se diferencia en un segundo del valor del TTL. Este segundo probablemente haya transcurrido desde que se realizó la solicitud, dando lugar a una mínima discrepancia.
El contenido del campo type tiene una peculiaridad. En lugar de la denominación SOA, está el valor 6, tanto en la solicitud como en los resultados. La autoridad de números asignados en Internet (IANA) ha asignado a cada tipo de registro DNS un valor que lo identifica. Incluso los tipos de registro obsoletos tienen un valor asignado, de forma que existe una lista numerada, casi sin excepción, de todos los tipos diferentes. Al registro SOA le corresponde, como se puede ver, el número 6.
Si prefieres no usar un servicio de Google, existen muchas otras opciones. Una de ellas es el servicio de DNS Queries, disponible también en español y con el que también se pueden consultar registros SOA.