Registro SOA: pieza clave del archivo de zona

Todo usuario de Internet tiene claro que, in­tro­du­cie­n­do 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 re­so­lu­ción de nombres, es decir, de traducir los nombres de dominio a las series de cifras co­rre­s­po­n­die­n­tes. Para que el sistema funcione, los se­r­vi­do­res 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í.

Los más conocidos son pro­ba­ble­me­n­te los registros A, ya que pri­n­ci­pa­l­me­n­te a través de ellos se produce la re­so­lu­ció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 co­mu­ni­ca­ción por correo ele­c­tró­ni­co. ¿Qué función realizan entonces los registros SOA?

El DNS es un sistema je­rá­r­qui­co de­s­ce­n­tra­li­za­do. Los se­r­vi­do­res de nombres no dan in­fo­r­ma­ción sobre cualquier servidor de Internet, sino solo sobre los que se en­cue­n­tran dentro de la zona que les co­rre­s­po­n­de. Con este fin, los se­r­vi­do­res 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 re­s­po­n­sa­bi­li­da­des, cada archivo de zona tiene, obli­ga­to­ria­me­n­te, un registro SOA o DNS SOA record, cuyas iniciales derivan de Start of Authority. Esto quiere decir que el registro contiene in­fo­r­ma­ción acerca de si el servidor co­n­su­l­ta­do es el re­s­po­n­sa­ble de la solicitud o no.

El registro SOA tiene una im­po­r­ta­n­cia especial en el contexto de los server clusters (unión de se­r­vi­do­res que trabajan como uno solo), en los que, en lugar de poner la carga de todas las so­li­ci­tu­des en un mismo ordenador, se reparten entre distintos se­r­vi­do­res. Para que los archivos de zona se mantengan ac­tua­li­za­dos en todos los se­r­vi­do­res, debe pro­du­ci­r­se re­gu­la­r­me­n­te una tra­n­s­fe­re­n­cia de zona. En ella, los llamados slaves o esclavos (se­r­vi­do­res in­fe­rio­res en la jerarquía) comparan sus archivos con los del master (servidor superior). El registro SOA regula cómo debe llevarse a cabo dicha tra­n­s­fe­re­n­cia y para ello dispone de distintas in­fo­r­ma­cio­nes.

Los registros DNS se componen, bá­si­ca­me­n­te, de di­fe­re­n­tes campos en los que, a su vez, se encuentra la in­fo­r­ma­ción relevante. El SOA record tiene muchos campos, en co­m­pa­ra­ció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 ele­c­tró­ni­co del ad­mi­ni­s­tra­dor encargado
• <serial>: número de serie del archivo de zona, que aumenta con cada ac­tua­li­za­ción
• <refresh>: tiempo en el que un servidor esclavo tiene que solicitar al servidor maestro una ac­tua­li­za­ció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 in­fo­r­ma­ción al exterior si el master sigue sin dar respuesta
• <minimum>: tiempo durante el cual la in­fo­r­ma­ción puede ser al­ma­ce­na­da 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 to­ta­l­me­n­te ca­li­fi­ca­dos (FQDN), lo cual significa que la in­fo­r­ma­ción, a di­fe­re­n­cia de lo que ocurre en los URL, acaba con un punto. La razón es que un FQDN presenta la es­tru­c­tu­ra je­rá­r­qui­ca completa del dominio, cuya última parte es el ce­r­ti­fi­ca­do 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 re­le­va­n­cia histórica, por lo que en muchos casos si­m­ple­me­n­te se omite. Cuando se de­sa­rro­lló el DNS, además de Internet, existían dos otros proyectos de red: Hesiod (HS) y Chaosnet (CH), ambos ya obsoletos. Puesto que ac­tua­l­me­n­te solo queda Internet, también se puede rellenar este campo con la abre­via­ció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 tra­n­s­fe­re­n­cia de zona el servidor inferior (esclavo). En el campo RNAME hay que formatear la dirección de correo ele­c­tró­ni­co teniendo en cuenta algunas pa­r­ti­cu­la­ri­da­des: 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 ac­tua­li­za­ció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 ac­tua­li­za­ció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: AAAA­M­M­D­D­VV. 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 te­m­po­ra­les, 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 rea­li­zar­se un nuevo intento. Es im­po­r­ta­n­te 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 in­fo­r­ma­cio­nes DNS. Si el servidor co­n­ti­nua­se re­s­po­n­die­n­do a so­li­ci­tu­des 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 co­rre­s­po­n­die­n­te al “time to live” del resto de registros DNS. Indica durante cuánto tiempo el cliente puede guardar la in­fo­r­ma­ción so­li­ci­ta­da en la memoria caché antes de que sea necesario enviar una nueva solicitud. El TTL, sin embargo, suele es­ta­ble­ce­r­se 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.

Los campos pueden ordenarse si­m­ple­me­n­te uno detrás de otro en una línea, pero, mientras que en el caso de otros tipos de registro esta es­tru­c­tu­ra es bastante simple, en el caso del registro SOA es algo más compleja. Para ganar le­gi­bi­li­dad, los campos se suelen ordenar en grupos y unos debajo de otros.

En este tipo de notación, el TTL y el nombre del dominio se es­ta­ble­cen pre­via­me­n­te. La arroba (@) al principio del registro hace re­fe­re­n­cia a la orden ORIGIN. Para agrupar los valores te­m­po­ra­les y re­pa­r­ti­r­los en varias líneas se utilizan pa­ré­n­te­sis.

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:

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 re­fe­re­n­tes al nombre del dominio (en este caso example.org) y el TTL. A co­n­ti­nua­ción, aparece el SOA record. Puesto que ya hemos de­te­r­mi­na­do la zona con la orden $ORIGIN, aquí basta con la arroba como in­di­ca­ció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 ele­c­tró­ni­co del ad­mi­ni­s­tra­dor. 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 pa­ré­n­te­sis 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 se­pa­rar­los si­m­ple­me­n­te con espacios.

En este ejemplo hemos escrito una de­fi­ni­ción tras cada valor in­di­vi­dual, que es si­m­ple­me­n­te un co­me­n­ta­rio que puede mo­di­fi­car­se o di­re­c­ta­me­n­te omitirse. En los registros DNS, tales co­me­n­ta­rios pensados para usuarios humanos se marcan con punto y coma.

Al final del registro SOA hay que cerrar el pa­ré­n­te­sis.

Fi­na­l­me­n­te 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 in­di­ca­cio­nes relativas al dominio y el TTL.

La solicitud realizada aparece bajo Question, mientras que los re­su­l­ta­dos de la solicitud se en­cue­n­tran bajo Answer. En el campo data de la respuesta se puede ver el servidor maestro, la dirección de correo ele­c­tró­ni­co del ad­mi­ni­s­tra­dor y los valores te­m­po­ra­les. Hay que destacar que el último valor (minimum) solo se di­fe­re­n­cia en un segundo del valor del TTL. Este segundo pro­ba­ble­me­n­te haya tra­n­s­cu­rri­do desde que se realizó la solicitud, dando lugar a una mínima di­s­cre­pa­n­cia.

El contenido del campo type tiene una pe­cu­lia­ri­dad. En lugar de la de­no­mi­na­ción SOA, está el valor 6, tanto en la solicitud como en los re­su­l­ta­dos. La autoridad de números asignados en Internet (IANA) ha asignado a cada tipo de registro DNS un valor que lo ide­n­ti­fi­ca. 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 di­fe­re­n­tes. Al registro SOA le co­rre­s­po­n­de, como se puede ver, el número 6.