Capítulo 4. Gestión de los Datos de Zona
Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com
Con los servidores DNS tradicionales, como BIND, los administradores suelen gestionar los datos de la zona primaria como archivos. Más recientemente, los servidores DNS han empezado a admitir la carga de datos de zona primaria desde otras fuentes, como las bases de datos.
CoreDNS admite diversos métodos para gestionar los datos de zona. Algunos serán muy familiares para los administradores DNS, como los archivos de datos de zona; otros son más modernos, como el uso de Git; mientras que algunos son francamente retro (¿alguien quiere tablas de hosts?). En este capítulo los cubrimos todos.
Juntas, estas opciones proporcionan a los administradores flexibilidad y, en algunos casos, funcionalidad avanzada en el mecanismo que utilizan para gestionar los datos de zona. Las tablas de host, por ejemplo, proporcionan una forma sencilla de añadir asignaciones de nombre a dirección y de dirección a nombre sin la sobrecarga de crear y mantener un archivo de datos de zona completo. Git, por otro lado, proporciona capacidades de control de versiones distribuidas.
Empecemos con el complemento file, que admite archivos de datos de zona. En realidad, esto ya lo tratamos en el Capítulo 3, pero aquí lo veremos con más detalle.
El archivo Plug-in
Para un administrador con experiencia en la gestión de archivos de datos de zona, el complemento file es probablemente el mecanismo más familiar que ofrece CoreDNS. file configura CoreDNS como servidor DNS primario para una o más zonas. En su forma más simple, el complemento file tiene la sintaxis que se muestra en el Ejemplo 4-1.
Ejemplo 4-1. Sintaxis simple de un complemento de archivo
file DBFILE [ZONES...]
DBFILE es un archivo de datos de zona que contiene registros de recursos. Puedes especificar DBFILE como un nombre de ruta completo o como un nombre de ruta relativo; los nombres de ruta relativos se interpretan como relativos a cualquier ruta establecida con la directiva root.
ZONES es una lista opcional de una o más zonas descritas por los registros de recursos en DBFILE. Si se omite ZONES, CoreDNS utiliza las zonas del bloque de configuración.
El Ejemplo 4-2 presenta un ejemplo sencillo de un complemento file, y el Ejemplo 4-3 muestra el archivo de datos de zona al que hace referencia.
Ejemplo 4-2. Ejemplo sencillo de complemento de archivo
foo.example {
file db.foo.example
}
Ejemplo 4-3. db.foo.ejemplo
@ 3600 IN SOA ns1.foo.example. root.foo.example. ( 2019041900 3600 600 604800 600 ) 3600 IN NS ns1.foo.example. 3600 IN NS ns2.foo.example. ns1 IN A 10.0.0.53 IN AAAA 2001:db8:42:1::53 ns2 IN A 10.0.1.53 IN AAAA 2001:db8:42:2::53 www IN A 10.0.0.1 IN AAAA 2001:db8:42:1:1
Como los registros de recursos del archivo de datos de zona db.foo.example están todos unidos a nombres de dominio relativos (por ejemplo, ns1 y www en lugar de nombres de dominio totalmente cualificados terminados en punto), se puede cargar el archivo para describir varias zonas, como se muestra en el Ejemplo 4-4.
Ejemplo 4-4. Utilizar un único archivo de datos de zona para varias zonas
. {
file db.foo.example foo.example bar.example
}
Esto supone que quieres que los contenidos de foo.ejemplo y bar.ejemplo sean idénticos, por supuesto; por ejemplo, que quieres que tanto www.foo.example como www.bar.example se asignen a la dirección IPv4 10.0.0.1.
El complemento file también admite una sintaxis más amplia que te permite especificar a qué servidores DNS se les permite transferir la(s) zona(s) y con qué frecuencia comprobar si se han producido cambios en el archivo de datos de zona, como se muestra en el Ejemplo 4-5.
Ejemplo 4-5. Sintaxis más detallada del complemento de archivo
file DBFILE [ZONES... ] {
transfer to ADDRESS...
reload DURATION
upstream [ADDRESS...]
}
Sin una directiva transfer, CoreDNS no permitirá las transferencias de zona de la zona o zonas descritas por el complemento file. Para enviar mensajes NOTIFY a un servidor DNS secundario concreto, así como para permitir transferencias de zona a ese secundario, especifica la dirección IP del secundario. Para varios secundarios, puedes enumerar sus direcciones IP en una única directiva transfer o utilizar varias directivas. También puedes especificar una red en notación Classless Inter-Domain Routing (CIDR) para permitir transferencias de zona desde cualquier dirección IP de esa red, o * para permitir transferencias de zona desde cualquier lugar, como se muestra en el Ejemplo 4-6.
Ejemplo 4-6. Ejemplo detallado del complemento de archivo
foo.example {
file db.foo.example {
transfer to 10.0.1.53
transfer to *
}
}
reload te permite especificar la frecuencia con la que CoreDNS comprueba el archivo de datos de zona para determinar si el número de serie del registro de inicio de autoridad (SOA) ha cambiado. Cuando CoreDNS detecta un nuevo número de serie, recarga el archivo (como una o más zonas) y envía mensajes NOTIFY a los servidores DNS secundarios designados en las directivas transfer. El valor por defecto de reload es de un minuto; un valor de 0 desactiva la comprobación periódica. Los valores válidos son un número seguido de "s" para segundos, "m" para minutos y "h" para horas; por ejemplo, 30s para 30 segundos.
El complemento file está bien si configuras CoreDNS como servidor DNS primario para unas pocas zonas. Pero, ¿y si quieres que CoreDNS sea primario para cientos de zonas? En ese caso, necesitas el complemento auto.
El autoenchufable
El complemento auto proporciona una forma inteligente de cargar un gran número de zonas desde varios archivos de datos de zona a la vez. Esto minimiza la longitud y complejidad del Corefile y ofrece la posibilidad de configurar automáticamente CoreDNS como primario para las nuevas zonas. El Ejemplo 4-7 muestra la sintaxis.
Ejemplo 4-7. Sintaxis del complemento auto
auto [ZONES...] {
directory DIR [REGEXP ORIGIN_TEMPLATE]
transfer to ADDRESS...
reload DURATION
}
auto indica a CoreDNS que busque en el directorio archivos que coincidan con el patrón db.*. Cada archivo se interpreta como un archivo de datos de zona cuyo origen es lo que sigue a db.. Ese origen debe estar dentro de la zona o zonas indicadas en ZONES, si se especifica.
Supongamos que el directorio /etc/coredns/zones contiene los archivos de datos de zona db.foo.example y db.bar.example, que describen las zonas foo.example y bar.example, respectivamente. El complemento auto que se muestra en el Ejemplo 4-8 ordenaría a CoreDNS que leyera todo el directorio y cargara las zonas foo.example y bar. example a partir de esos archivos.
Ejemplo 4-8. Un complemento automático
auto example {
directory /etc/coredns/zones
}
Además, puedes crear otra zona (en cualquier caso, bajo el dominio de ejemplo ) simplemente creando un nuevo archivo de datos de zona con el nombre apropiado en /etc/coredns/zones.
También puedes especificar una expresión regular además de db.* para que CoreDNS la busque en el directorio, y dar a CoreDNS instrucciones sobre cómo crear el origen (y el nombre de dominio de la zona) a partir del nombre de archivo. Si, por ejemplo, nombraras tus archivos de datos de zona <dominio>.zona, podrías utilizar el complemento auto que se presenta en el Ejemplo 4-9.
Ejemplo 4-9. Otro complemento automático
auto example {
directory /etc/coredns/zones (.*)\.zone {1}
}
Se espera que la expresión regular (regex) incorpore lo que es esencialmente un grupo de captura Perl: los paréntesis alrededor de ".*" indican la parte del nombre de archivo que contiene el origen (en este caso, todo lo que hay antes de .zone); el {1} es una referencia retrospectiva a esa parte de la regex. Por supuesto, puedes utilizar otras referencias, como {2} para el segundo grupo de captura.
Por último, puedes utilizar las directivas file transfer , reload, y upstream para controlar qué servidores DNS pueden realizar transferencias de zona de estas zonas (y recibir mensajes NOTIFY de CoreDNS), con qué frecuencia se escanea el directorio en busca de archivos de datos de zona modificados y qué servidores DNS utilizar para resolver nombres de dominio externos.
Utilizar el complemento auto con Git
Los usuarios ávidos del sistema distribuido de control de versiones Git pueden combinar fácilmente el complemento auto con un script como git-sync para extraer periódicamente archivos de datos de zonas de un repositorio Git a un directorio. CoreDNS escanea entonces el directorio y carga las zonas nuevas y modificadas. El uso de Git permite que varios administradores gestionen conjuntamente un conjunto de archivos de datos de zona controlados por versiones, de modo que los administradores puedan realizar un seguimiento de los cambios en los datos de zona.
git-sync se implementa, como es lógico, como un contenedor. He aquí un ejemplo de uso de git-sync para escanear periódicamente un repositorio de GitHub en busca de nuevos archivos de datos de zona, como se demuestra en el Ejemplo 4-10.
Ejemplo 4-10. git-sync en acción
docker run -d \ -v /etc/coredns/zone:/tmp/git \ registry/git-sync \ --repo=https://github.com/myzonedata --branch=master --wait=30
Este comando utiliza el contenedor git-sync para sincronizar los archivos del repositorio https://github.com/myzonedata con /etc/coredns/zone y para comprobar si hay cambios en el repositorio cada 30 segundos.
¿Y si tienes el problema contrario al que resuelve auto, es decir, que sólo quieres cargar unos cuantos registros de recursos en CoreDNS sin la sobrecarga de un archivo de datos de zona? Entonces, el complemento hosts te resultará muy útil.
El Plug-in de los anfitriones
El complemento hosts se utiliza para configurar CoreDNS para que genere datos de zona a partir de una tabla de hosts (por ejemplo, /etc/hosts). La tabla de hosts debe tener el formato de tabla de hosts estándar:
<IP address> <canonical name> [aliases...]
La dirección IP puede ser una dirección IPv4 o IPv6. El nombre canónico y cualquier alias deben ser nombres de dominio. Una vez leída la tabla de hosts, hosts genera lo siguiente:
- Un registro para cada entrada con una dirección IPv4, asignando el nombre canónico y cualquier alias a la dirección IPv4 especificada
- registros AAAA para cada entrada con una dirección IPv6, asignando el nombre canónico y cualquier alias a la dirección IPv6 especificada
- Un registro PTR para una dirección IPv4 o IPv6, asignando la dirección al nombre canónico
Ten en cuenta que los alias se convierten en registros A o AAAA, no en registros de nombre canónico (CNAME).
El ejemplo 4-11 presenta la sintaxis del complemento hosts.
Ejemplo 4-11. Sintaxis del complemento anfitriones
hosts [FILE [ZONES...]] {
[INLINE]
ttl SECONDS
no_reverse
reload DURATION
fallthrough [ZONES...]
}
FILE especifica el nombre del archivo hosts que hay que leer y analizar; por defecto, CoreDNS lee /etc/hosts. Si FILE es una ruta relativa, se interpreta en relación al directorio especificado en la directiva ROOT.
ZONES es una lista opcional de una o más zonas que se cargan desde la tabla de hosts. Si no se especifica ZONES, CoreDNS utiliza las zonas del bloque de servidores que lo contiene. Los nombres de dominio sólo se cargarán en las zonas de las que formen parte. En otras palabras, si cargas la tabla host mostrada en el Ejemplo 4-12 como foo.ejemplo y bar.ejemplo, acabarás con host1.foo.ejemplo en la zona foo.ejemplo y host2.bar.ejemplo en bar.ejemplo.
Ejemplo 4-12. Ejemplo de tabla de hosts
10.0.0.1 host1.foo.example 10.0.1.1 host2.bar.example
Las zonas cuyos datos se leen mediante el complemento hosts no son realmente zonas completas; por ejemplo, no tienen registros SOA, por lo que no pueden transferirse a otro servidor DNS. En consecuencia, hosts no suele utilizarse para gestionar una zona completa, sino para cargar nombres de dominio concretos. Por ejemplo, algunas personas cargan una tabla de hosts que incluye nombres de dominio utilizados para servir anuncios y que asigna esos nombres de dominio a la dirección IP 0.0.0.0.
[INLINE] te permite especificar una o varias líneas en formato de tabla de host directamente en la directiva, como se muestra en en el Ejemplo 4-13.
Ejemplo 4-13. Entradas en línea de la tabla de hosts
foo.example {
hosts {
10.0.0.1 host1.foo.example
10.0.1.1 host2.foo.example
}
}
TTL establece el valor del tiempo de vida (TTL) para los registros sintetizados a partir de entradas de la tabla de hosts; por defecto, el TTL se establece en 3600 segundos, o 1 hora. El valor debe especificarse como un número entero (en otras palabras, no especifiques unidades como "s" para los segundos).
no_reverse inhibe la creación de registros PTR a partir de entradas de la tabla de hosts.
Por defecto, CoreDNS recarga la tabla de hosts cada 5 segundos. reload te permite cambiar este intervalo especificando un valor escalado (es decir, un número seguido de una unidad de tiempo) con las siguientes unidades:
- ns para nanosegundos
- us o µs para microsegundos
- ms para milisegundos
- s por segundos
- m para minutos
- h de horas
No estoy seguro de que realmente necesites poder especificar un intervalo de recarga de 500.000.000 nanosegundos (con 500000000 ns), pero con CoreDNS, ¡puedes hacerlo!
Por último, fallthrough controla si las consultas de las zonas gestionadas por el complemento hosts pasan a otro complemento si no se encuentra respuesta. Por ejemplo, puede que quieras que las consultas de foo.ejemplo pasen del complemento hosts a un complemento file si no se encuentra la respuesta en la tabla de hosts. Por defecto, al especificar fallthrough se indica a CoreDNS que realice todas las consultas gestionadas por el complemento hosts. Para pasar sólo a un subconjunto de esas consultas, puedes especificar una lista de zonas como argumento.
A continuación, veremos una forma de cargar datos de zona desde el servicio Route 53 de Amazon.
El complemento route53
Muchas organizaciones utilizan el servicio Amazon Route 53 para proporcionar servicios DNS autoritativos desde la nube de Amazon Web Services (AWS). CoreDNS proporciona un plug-in, route53, que le permite sincronizar los datos de zona de Route 53, de forma similar a como un servidor DNS secundario transferiría los datos de zona de un servidor DNS maestro. CoreDNS puede entonces responder autoritativamente a las consultas de nombres de dominio de la zona sincronizada.
Ejemplo 4-14. Sintaxis del complemento route53
route53 [ZONE:HOSTED_ZONE_ID...] {
[aws_access_key AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY]
upstream
credentials PROFILE [FILENAME]
fallthrough [ZONES...]
}
Para sincronizar la zona, CoreDNS debe proporcionar el nombre de dominio de la zona y un "ID de zona alojada" especial que se utiliza en AWS como, así como las credenciales que autentican a CoreDNS en Route 53.1 Para obtener el ID de zona, inicia sesión en el Panel de control de AWS, ve al servicio Route 53 y haz clic en "Zonas hospedadas". Esto debería mostrar una tabla de zonas que incluya el ID de Zona Alojada de cada zona.
El complemento route53 requiere que especifiques el nombre de dominio de la zona y el ID de la Zona Alojada en un formato particular (y particularmente inflexible): el nombre de dominio de la zona, terminado con un punto, seguido de dos puntos y, a continuación, el ID de la Zona Alojada. El ejemplo 4-15 muestra este formato.
Ejemplo 4-15. El complemento route53
route53 foo.example.:Z3CDX6AOCUSMX3 {
fallthrough
}
Puedes especificar varias zonas si quieres que CoreDNS las sincronice todas desde Route 53.
Por defecto, CoreDNS determina las credenciales AWS a utilizar a partir de variables de entorno o de un archivo de credenciales AWS. Puedes anular este comportamiento especificando las credenciales directamente dentro del complemento route53, como se ilustra en el Ejemplo 4-16.
Ejemplo 4-16. Complemento route53 con credenciales explícitas
route53 foo.example.:Z3CDX6AOCUSMX3 {
aws_access_key AKIAIMSX7F33X4MOVBZA SnA4XxFPx/BDEMbty3EKVze7Xi3DkQ5a8akRO9j9
}
También puedes especificar un archivo de credenciales de AWS distinto del predeterminado utilizando la subdirección credentials que se muestra en el Ejemplo 4-17.
Ejemplo 4-17. Complemento route53 con archivo de credenciales
route53 foo.example.:Z3CDX6AOCUSMX3 {
credentials default .awscredentials
}
defaulten este caso, especifica un perfil concreto en el archivo de credenciales.
Al igual que hosts, el complemento route53 admite fallthrough a otros complementos, para todas o un conjunto especificado de zonas sincronizadas desde Route 53. Y, como file, route53 admite la especificación de un servidor DNS upstream para resolver referencias a nombres de dominio externos en los datos de zona de Route 53.
Este es el último de los plug-ins para gestionar los datos de zona en CoreDNS. Esperemos que, entre las cuatro opciones (cinco si cuentas el uso del complemento auto con Git), encuentres una que satisfaga tus necesidades.
Aunque CoreDNS es un servidor DNS primario flexible y capaz, su punto fuerte, por supuesto, es soportar el descubrimiento de servicios basado en DNS. Lo veremos en el Capítulo 5.
1 El ID de la Zona Alojada identifica de forma única la zona para AWS. El nombre de dominio de la zona por sí solo no siempre es suficiente, porque AWS puede tener Zonas Alojadas Públicas y Zonas Alojadas Privadas con el mismo nombre de dominio.
Get Aprender CoreDNS now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
