Pertenece a Topic 207: Domain Name Server

• Weight: 3
• Description: Candidates should be able to configure BIND to function as a caching-only DNS server. This objective includes the ability to manage a running server and configuring logging.
• Key Knowledge Areas:
  • BIND 9.x configuration files, terms and utilities
  • Defining the location of the BIND zone files in BIND configuration files
  • Reloading modified configuration and zone files
  • Awareness of dnsmasq, djbdns and PowerDNS as alternate name servers.
• The following is a partial list of the used files, terms and utilities:
  • /etc/named.conf
  • /var/named/
  • /usr/sbin/rndc
  • kill
  • host
  • dig

Domain Name System (sistema de nombres de dominio) es un sistema que sirve para traducir los nombres de hosts a identificadores de red y viceversa.

En sus comienzos, mientras la cantidad de máquinas públicas en Internet era pequeña, todas las resoluciones se realizaban mediante un archivo llamado hosts que se descargaba a intervalos regulares para tener actualizadas las últimas novedades.

El DNS se creó como solución a los límites del archivo hosts descargado y tenía que cumplir con ciertos requisitos de diseño:

• El DNS es dinámico: los registros están rápidamente disponibles para todos.
• El DNS se replica.
• El DNS está jerarquizado: los datos se clasifican en una estructura de árbol que permite su organización. Cada nivel de la jerarquía se llama zona.
• El DNS es un sistema distribuido: cada zona se guarda en una “base de datos” y su conjunto compone la totalidad de registros DNS. Reparte la carga en miles de servidores.
• El DNS es seguro.

Es un modelo cliente-servidor.

Elemenos básicos de DNS:

• Clientes DNS
• Servidores DNS
• Zonas de autoridad (define qué dominios gestiona cierto servidor DNS)

El servidor DNS utiliza una base de datos distribuida y jerárquica en forma de árbol. Los servidores DNS no pueden tener todas las direcciones de Internet. Sería muy costoso porque las asociaciones entre IPs y dominios cambia constantemente.

La raíz de la jerarquía es la zona llamada “.” (punto) y contiene todos los tld (top level domain) como com, es, net, fr…

Cada servidor DNS conoce algunos tld y si no tiene la información cuando se le consulta, pregunta al servidor del nivel superior hasta que alguno tiene la respuesta.

Por razones de tolerancia a fallos, los datos de cada zona deben replicarse al menos una vez (2 copias de los datos).

Cada zona es la que comprende un dominio. Si tenemos registrado el dominio “mired.com”, esto sería la zona. Deberíamos tener una réplica de la información de esa zona en otro servidor para asegurarnos que si uno de los servidores DNS cae, las consultas para esa zona pueden ser respondidas.

Primario o Master:

• Tiene autoridad en la zona (SOA – Start Of Authority)
• Es el responsable de las actualizaciones.

Definimos la información de la zona, las asociociaciones entre direcciones IP y dominios de esa zona.

Secundario o Slave:

• Albergan una réplica de la zona.
• Se sincronizan con el servidor primario.

Local o Caché:

• Se limita a reenviar las peticiones a otros servidores.

Esto se hace para acelerar las peticiones a otra red. Si tenemos una red muy grande y todos los ordenadores tiene que hacer las peticiones fuera a Internet, el tráfico será muy grande. Contando con servidores internos que vayan haciendo caché de esas peticiones, se acelerarán las consultas ya que serán estos servidores internos los que den la respuesta.

Las peticiones de los clientes utilizan el puerto 53 UDP.

Cuando realizamos una consulta a un servidor DNS, se pueden producir dos situaciones:

• Si el servidor al que se ha preguntado tiene localmente la información, responde directamente (resolución iterativa).
• Si por el contrario, no dispone de la información, consultará la única zona que conoce, la zona “.” (punto) y se producirá el siguiente intercambio de información (resolución recursiva):

1. El cliente pregunta al servidor al que hace referencia su configuración (proveedor de acceso o servidor local): ¿cuál es la dirección para el nombre www.abcd.es?
2. El servidor local solicita a un servidor raíz: dame la dirección de un servidor que conozca la zona es.
3. Este, el servidor con dirección 193.176.144.6, podrá informarte. Tiene toda la información de la zona es.
4. El servidor local solicita al servidor de la zona es: dame la dirección de un servidor que conozca la zona abcd.es.
5. Este servidor, cuya dirección es 213.41.120.195, podrá informarte.
6. El servidor local pregunta al servidor de la zona abcd.es: ¿tienes un registro www en tu dominio abcd.es?
7. Sí, su dirección IP: 62.193.202.6.
8. El servidor local a la estación cliente: me has solicitado www.abcd.es y su dirección IP es 62.193.202.6.

Las zonas solo tienen una función estructural, para proporcionar la resolución de nombres habrá que crear registros que harán corresponder un nombre a una dirección IP o a otro dato.

Los Registros de Recursos (Resources Records, RR), constituyen la información fundamental de un DNS. Se conocen comúnmente como entradas DNS.

Los registros PTR son útiles para comprobaciones. Por ejemplo, se utiliza en servidores de correos para saber si los mensajes que se envían entre servidores provienen de quienes dicen ser.

Con un registro tipo CNAME podríamos tener prueba.abcd.es apuntando a www.paquito.org. Una entrada que controlamos (prueba.abdc.es) en realidad apunta a un dominio diferente. Estamos haciendo un alias de un dominio.

Una entrada MX determina los servidores de correo de ese dominio. Siempre tienen que ser nombres de dominio, no IP.

La entrada SOA marca que el servidor DNS tiene autoridad sobre cierta zona.

Una entrada NS indica qué servidores de DNS gestionarán cierto dominio.

Antes de hablar de la configuración de un servidor DNS (bind), debemos instalarlo previamente. Dicho proceso podemos realizarlo utilizando la paquetería existente, dependiendo de la distribución:

Debian:

apt-get install bind9

Red Hat:

yum install bind

El servidor DNS BIND se basa en:

• Un daemon llamado bind9 / named.
• El fichero de configuración /etc/bind/named.conf.
• También puede utilizar otros ficheros de configuración a los que se hace referencia mediante “includes”:

Ejemplo de named.conf:

include "/ruta/archivo";

options {
    directory "/ruta/directoriodetrabajo";
    forwarders { A.B.C.D };
    };

zone "NOMBREDEZONA1" {
    type tipo;
    file "/ruta/nombrearchivo1";
    };    
    
zone "NOMBREDEZONA2" {
    type tipo;
    file "/ruta/nombrearchivo2";
    };    

El fichero named.conf tiene varias partes:

• include: Indica el nombre de un «subarchivo» de configuración. Evita tener un archivo named.conf demasiado grande para administrarlo cómodamente.
• options: Es donde se definen las opciones principales del servidor.
  • directory: donde se almacena la caché del servidor
  • forwarders: los servidores DNS externos que consulta (los de Google, por ejemplo).
  • version: opcion que permite mostrar u ocultar la version del servidor.
• zone: define una zona DNS gestionada por el servidor.
  • type: Indica el tipo de zona almacenada. Los valores principales son hint (servidores raíz), master (servidor maestro de una zona) y slave (réplica de un servidor master).
  • file: Indica el fichero que contendrá la información de la zona.
• Logging: especifica el modo del que el servidor DNS enviará mensajes a los logs del sistema

Según la distribución, algunas zonas se proporcionan por defecto en la instalación del servidor, para habilitar un funcionamiento estándar.

Ejemplo de /etc/bind/named.conf.default-zones (Debian 10):

// prime the server with knowledge of the root servers
// Servidores raíz de Internet
zone "." {
        type hint;
        file "/usr/share/dns/root.hints";
};

// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912

zone "localhost" {
        type master;
        file "/etc/bind/db.local";
};

// Zonas de resolución inversa (PTR)
zone "127.in-addr.arpa" {
        type master;
        file "/etc/bind/db.127";
};

zone "0.in-addr.arpa" {
        type master;
        file "/etc/bind/db.0";
};

zone "255.in-addr.arpa" {
        type master;
        file "/etc/bind/db.255";
};

En Debian, en el fichero /etc/bind/named.conf.options se definen las opciones del servidor DNS bind.

También se incluye el fichero /etc/bind/zones.rfc1918 donde está definida la resolución inversa (PTR) de los diferentes rangos de redes locales (10.x.x.x, 172.16.x.x, 192.168.x.x…). Al definir una zona, siempre hay que definir su zona de resolución inversa.

En el fichero /etc/bind/named.conf.default-zones están las zonas por defecto: zona “.” (consulta a los servidores raíz), localhost, y las zonas de resolución inversa para nuestra propia máquina.

Cada zona de resolución inversa tiene asociado un fichero: db.local, db.127, db.0.… Ahí se definen los datos de cada zona

# db.local
$TTL    IN    SOA    localhost. root.localhost. (
@                           2   ; Serial (podemos poner lo que queramos, es para identificar al servidor DNS)
                       604800   ; Refresh 
                        86400   ; Retry
                      2419200   ; Expire
                       604800 ) ; Negative Cache TTL
;
@       IN    NS     localhost. # Indicamos cuál es el servidor de nombres de este dominio
@       IN    A      127.0.0.1
@       IN    AAAA   ::1

• TTL (Time To Live) es el tiempo de actualización de la zona.
• @: nos referimos al propio dominio
• SOA: indica que se gestiona el dominio.
• localhost.: zona (siempre se termina con un punto)
• root.localhost.: cuenta de correo del administrador del dominio. Aunque lleve un punto en medio, es como si llevase una arroba.

• Proporciona la resolución de nombre, pero no contiene ningún dato de resolución local.
• Se limita a reenviar las peticiones a otros servidores.

Un servidor BIND recién instalado, funciona como un servidor caché por defecto. Cuando tiene que resolver una IP, se dirigirá a los únicos servidores que conoce: servidores raíz.

Un servidor de caché no alberga de forma local registros de recursos. Si tiene que hacer una resolución, se dirigirá a los únicos servidores que conoce, que son los servidores raíz.

Este método de resolución obviamente no es el más rápido y se podría desear aprovechar la caché de servidores ya en funcionamiento, como los de un servicio de hospedaje o de un ISP. Para ello, hay que indicar a nuestro servidor la dirección de otros servidores a los que podrá redirigir sus peticiones. Este tipo de redirección se llama incondicional, ya que se redirigen todas las resoluciones no pesadas.

Debemos indicarle la dirección de otros servidores a los que redirigir las peticiones en el fichero named.conf:

options {
    forwarders {
        A.B.C.D;
    };
}

Se puede especificar que utilicen esos servidores como primera opción (forward first, es la opcion por defecto) o usarlos exclusivamente (forward only)

remote name daemon control: comando de control que permite transmitir al servidor una gran variedad de instrucciones.

Sintaxis:

rndc accion [parámetro]

Para configurarlo hay que tener un fichero /etc/rndc.key (se crea con la instalación de bind) y añadir la clave en el named.conf

Es una herramienta que nos permite chequear la sintaxis de los archivos de configuracion del servidor DNS.

Si queremos controlar el comportamiento del servidor DNS, podemos usar el comando kill:

kill -HUP 127

Este ejemplo envia una señal SIGHUP al proceso 127 (que en el ejemplo corresponde a named) y hace que vuelva a cargar el archivo named.conf y todas las bases de datos.

Tambien podemos usar las herramientas correspondientes al sistema de gestión de procesos que tengamos en nuestro sistema como service o systemctl

• Dnsmasq
• Djbdns
• PowerDNS

Las máquinas Linux disponen de forma nativa de un cliente DNS llamado resolver. Toda aplicación que esté funcionando en Linux y necesite realizar una petición DNS utilizará este componente.

Este componente usa el archivo de configuración /etc/resolv.conf, que tiene una estructura muy sencilla:

search dominio
domain dominio
nameserver A.B.C.D

• search: (Opcional) indica el sufijo de búsqueda que hay que emplear en la máquina Linux. Evita tener que escribir la totalidad del FQDN en las aplicaciones. El archivo /etc/resolv.conf admite varios dominios de búsqueda especificados con search
• domain: Opcional y obsoleto: expresa el sufijo de búsqueda empleado en la máquina Linux.
• dominio: El FQDN del dominio que forma el sufijo de búsqueda.
• nameserver: Indica la dirección IP del servidor DNS que proporcionará las resoluciones. El archivo /etc/resolv.conf admite varios servidores DNS especificados por nameserver.