Configurar DNS

En esta serie de artículos, intentaré explicar lo mejor posible el funcionamiento de los servidores DNS, y cómo configurar el tuyo propio. Habrá una parte más teórica sobre el funcionamiento del sistema, que es una traducción de un artículo en how to forge.

Ya que los artículos están basados en distintas fuentes de información que he ido recopilando, no sé de cuantas partes estará formada esta serie, así que la lista de arriba irá cambiando hasta que estén completos todos los artículos.

Debo reconocer que el tema de los DNS me ha dado muchos problemas, es algo que para mí ha sido difícil de entender. A base de leer y releer muchos artículos por internet, aprendí a configurar un servidor DNS manualmente. Hoy voy a explicar cómo.

En Linux, BIND es el encargado de gestionar los DNS, como su página de ayuda indica (bind – bind a name to a socket), asocia un nombre a un socket. Es importante que antes de continuar compruebes que la versión de BIND es superior a la 4. Lo ideal sería tener la 8 o 9. Puedes comprobarlo con el siguiente comando:

$ nslookup -type=txt -class=chaos version.bind servidorServer: servidorAddress: IP#53 version.bind text = "VERSION"

BIND tiene tres componentes, el primero es llamado named o name-dee, es un demonio que ejecuta el lado servidor del DNS.

El segundo componente es llamado resolver library o biblioteca de resolución, encargada de realizar peticiones a servidores DNS para intentar traducir un nombre a una dirección IP. El archivo de configuración para este componente es resolv.conf.

El tercer y último componente de BIND proporciona herramientas para probar el servidor DNS. Entre estas herramientas se encuentran comandos como dig, que se verá más adelante.

¿Cual es tu responsabilidad como parte del sistema DNS?

DNS es una base de datos distribuida. Cuando pagas por un dominio, debes configurar dos servidores de nombres, y éstos deben ser registrados en el sistema DNS.

La base de datos del sistema DNS tiene tres niveles. Al primer grupo de servidores se les llama “servidores root”. Al segundo, “Top Level Domains (TLDs)” o dominios de primer nivel. Cuando se necesita conocer la dirección de una web, el segundo componente de BIND (resolver library) realiza una petición, (De aquí en adelante lo llamaremos resolver).

Por ejemplo, supongamos que quieres encontrar a google.com. Tu resolver pide a los servidores root que identifique la IP de google.com. El servidor root responde, “No lo sé, pero sí sé donde puedes encontrar la respuesta, comienza con los servidores TLD para COM”.

Así, el servidor root envia la petición a un servidor COM. Éste último servidor dice: “No tengo esa información, pero sé de un servidor de nombres que sí, tiene dirección 173.194.34.6 y nombre ns1.google.com. Dirígete a esa dirección y te dirá la dirección del sitio web google.com.”

En la figura de arriba, la parte superior izquierda representa los servidores root. En la jerga DNS, éstos servidores reprensentan el comienzo del camino en el sistema DNS. Suelen representarse con un punto (“.”). En los archivos de configuración, el mapeo entre IP y nombre acabará en un punto. A lo largo de esta series de artículos quedará más claro este concepto.

Los servidores root son los principales de la base de datos distribuida. Poseen información sobre los Top Level Domains (TLDs) o dominios de primer nivel. En los TLDs se incluyen com, net, org, mil, gov, edu etc. Al contratar un nombre de dominio, es necesario elegir qué TLD se desea, este blog se encuentra en el espacio de nombres COM y se llama elbauldelprogramador.com.

¿Cómo responde el servidor DNS a las peticiones?

En este punto es donde BIND entra en acción. El primer componente que mencionamos, named; está presente en todos los servidores de nombres y es el encargado de responder a las peticiones de los resolvers. Lee sus datos del archivo de configuración named.conf. Éste fichero obtiene su información de unos ficheros a los que se les suele llamar zone files ó ficheros de zona. Existen multidud de ellos, pero un archivo de zona en particular mantiene una base de datos de registros que proporciona named con la mayoría de sus respuestas.

En la figura 2, named ha recibido una petición. Busca en su fichero de configuración named.conf, que busca en el archivo de zona primaria y pasa la información solicitada al resolver desde el exterior.

Figura 2 – Respondiendo a una petición

Usando Named.conf

El proceso named escucha en el puerto 53 en los sitemas Linux. Al recibir una petición para una dirección, busca en el primer archivo de configuración que conoce, named.conf. Tal y como se aprecia en la figura 2.

El fichero tiene la siguiente estructura:

// This is the primary configuration file for the BIND DNS server named.//// Please read /usr/share/doc/bind9/README.Debian.gz for information on the // structure of BIND configuration files in Debian, *BEFORE* you customize // this configuration file.//// If you are just adding zones, please do that in /etc/bind/named.conf.local include "/etc/bind/named.conf.options";include "/etc/bind/named.conf.local";include "/etc/bind/named.conf.default-zones";

Veamos el contenido de los tres archivos que incluye:

named.conf.options

options {directory "/var/cache/bind";

};

Aquí se definen el directorio por defecto para named.

named.conf.default-zones

zone "." {

type hint;file "/etc/bind/db.root";

}; zone "localhost" {

type master;file "/etc/bind/db.local";

}; zone "127.in-addr.arpa" {

type master;file "/etc/bind/db.127";





};

zone “.” contiene los nombres y direcciones de los servidores root. Como se mencionó arriba, éstos servidores saben en qué servidores autorizados existe tu dominio — Siendo el primero los TLD (com, org, net etc) y el segundo el servidor autorizado para tu dominio.

zone “localhost”. Cada servidor de nombres administra su propio dominio loopback (127.0.0.1). El motivo de crear una zona para localhost es reducir tráfico y permitir que el mismo software funcione en el sistema como lo hace en internet.

El resto de las zonas son archivos de zonas inversas. Es una copia invertida de la base de datos definida en los otros archivos. Es decir, asocia una IP a un nombre, al contrario. Se pueden indentificar por la extensión in-addr.arpa.

En el siguiente artículo ser verá en detalle la estructura del archivo named.conf.local, en el que se definen nuevas zonas que corresponden a dominios que resolverá el servidor DNS. Así como a los archivos pri.nombredominio.com asociados a cada zona.

Siguiendo con los artículos de cómo configurar un servidor DNS. En el anterior artículo dejamos pendiente echar un vistazo al archivo named.conf.local, que contiene información sobre los dominios que serán resueltos por el servidor DNS. Veamos el contenido:

zone "elbauldelprogramador.com" { type master; allow-transfer {DNS_SECUNDARIO}; file "/etc/bind/pri.elbauldelprogramador.com";};

El contenido de /etc/bind/pri.elbauldelprogramador.com:

$TTL 3600

@ IN SOA ks3277174.kimsufi.com. correo.electronico.com. ( 2013011703 ; serial, todays date + todays serial # 7200 ; refresh, seconds 540 ; retry, seconds 604800 ; expire, seconds 86400 ) ; minimum, seconds; elbauldelprogramador.com. 3600 A 5.39.89.44elbauldelprogramador.com. 3600 MX 10 mail.elbauldelprogramador.com.elbauldelprogramador.com. 3600 NS ks3277174.kimsufi.com.elbauldelprogramador.com. 3600 NS ns.kimsufi.com.mail 3600 A 5.39.89.44www 3600 A 5.39.89.44

SOA es el acrónimo para “Start Authority”. Si recuerdas la figura 1 del artículo anterior, recordarás que DNS es una base de datos distrubuida. Comenzando en los root servers, las peticiones se van desplazando hasta llegar a su destino, en este caso, hasta llegar al servidor DNS que estamos configurando. Por esa razón, en el fichero de zona es necesario indicar dónde comienza su autoridad(authority). Ésta autoridad comienza precisamente en el fichero de zona. Los servidores TLD (Top Level Domain ó Dominios de primer nivel) esperan del servidor DNS que realice su parte del trabajo.

El registro SOA consta de varios campos. Es necesario proporcionar datos a esos campos para que otros servidores en internet puedan llevar a cabo sus peticiones. Los campos son:

Nombre

Define el nombre principal de la zona. El @ es una abreviatura a la zona actual, es decir, para /pri.elbauldelprogramador.com en este ejemplo. El nombre del servidor maestro para esta zona es ks3277174.kimsufi.com. Esto significa que en el archivo named.conf existe una entrada que apunta y este archivo vuelve apunta a su vez a la entrada en el archivo de configuración.

Clase

Existen varios tipos de clases DNS. En nuestro caso solo se usará la clase IN o Internet, usadas para definir el mapeo entre la dirección IP y BIND.

Tipo

El tipo de registro para el recurso DNS, en el ejemplo de arriba, el tipo es SOA.

Nombre del servidor

Nombre completo del servidor de nombres primario. Debe acabar en un punto.

Dirección de correo

Dirección de correo de la persona responsable del dominio. Nota cómo se sustituye el símbolo @ por un punto.

Número de serie

Normalmente tiene el formato YYYYMMDD con dos dígitios más al final que indican el número de serie del día. El número de serie es útil para indicarle a servidor DNS secundario cuando debe actualizarse. Si el servidor esclavo al comprobar el número de serie ha cambiado, realizará una trasnferencia de zona (zone transfer).

Refresh o actualización

En este campo indica al servidor DNS esclavo o secundario con qué frecuencia debería comprobar el estado del maestro. El valor está representado en segundos. En cada ciclo de refresco, el esclavo realiza la comprobación para saber cuando es necesaria una transferencia de zona (zone transfer). En el ejemplo el valor es 7200

Retry o reintento

Frecuencia con la que el esclavo debería conectarse al maestro en caso de una conexión fallida.

Expiry o expiración

Cantidad total de tiempo en la que el esclavo debería reintentar ponerse en contacto con el maestro antes de que expiren los datos que contiene. Referencias futuras serán dirigidas a los servidores root.

TTL mínimo

Este campo define el tiempo de vida (Time To Live) para el dominio en segundos. Sirve para responder a peticiones de subdominios que no existen en los registros. Cuando esté configurado, el servidor DNS responderá con una respuesta del tipo no domain o NXDOMAIN. Dicha respuesta será cacheada. El TTL establece la duración del cacheo para la respuesta.

Después de estos campos, se especifican los servidores de nombres para el dominio. NS es el acrónimo de Name Server. Como se ha visto un poco más arriba, el servidor de nombres principal del ejemplo es ks3277174.kimsufi.com. También se define el sevidor DNS secundario o esclavo, en este caso ns.kimsufi.com.

Además de los registros NS, se definen los registros MX, que identifican el servidor de correo para el dominio, el número 10 define la prioridad del servidor de correo. Así como el registro de tipo A, que asocia un nombre a una dirección ip.

En el ejemplo existe un único registro MX, pero puede haber más. Por ejemplo:

MX 10 mail.elbauldelprogramador.com.

MX 20 mail.otrodominio.com.

Si se envia un email al dominio, el servidor de correo que envía el email intenta conectarse a mail.elbauldelprogramador.com ya que tiene prioridad 10, si no puede establecer conexión, lo intentará con mail.otrodominio.com.

El último tipo de registro que vamos a ver es el de tipo CNAME (Canonical Name). Se suele referir a ellos como registros alias del tipo A. Por ejemplo:

ftp CNAME www

significa que ftp.elbauldelprogramador.com es un alias de www.elbauldelprogramador.com. Es decir, ftp.elbauldelprogramador.com apunta al mismo servidor que www.elbauldelprogramador.com. Un registro CNAME debe apuntar a un registro de tipo A y solo de tipo A.

En el siguiente artículo se verá el archivo de zona inversa y la configuración del servidor DNS secundario, así como el uso del comando dig.

secundario)

Ya se ha visto que existe una base de datos centralizada que asocia nombres de dominios a direccines IP, también se mencionó el caso inverso, una copia inversa de dicha base de datos, que asocia IP’s a nombres de dominios. Ésta búsqueda inversa es usada por muchos programas, que rechazarán establecer una conexión si la búsqueda inversa y la búsqueda directa (Dominio»IP) no coinciden. Muchos proveedores de correo usan la búsqueda inversa para clasificar correos como spam.

Con objetivo de que los emails enviados desde el dominio que se está configurando no sean clasificados como spam, es necesario crear la zona inversa en el archivo named.conf.local:

zone "89.39.5.in-addr.arpa" {type master;file "pri.89.39.5.in-addr.arpa";

};

Los números son la dirección ip del servidor escritos en orden inverso. Es decir, la ip es 5.89.39.x, así pues, la zona ha de llamarse 89.39.5.in-addr.arpa.

Es necesario crear el archivo de zone inversa también, pri.89.39.5.in-addr.arpa. Este archivo es necesario crearlo en el mismo directorio en el que se encuentra el archivo de zona primario (pri.elbauldelprogramador.com).

El principio de este archivo es exáctamente igual que pri.elbauldelprogramador.com:

@ IN SOA ks3277174.kimsufi.com. contacto.elbauldelprogramador.com. ( 2013021001 ; serial, todays date + todays serial #

7200 ; refresh, seconds 540 ; retry, seconds 604800 ; expire, seconds 86400 ) ; minimum, seconds;

NS ks3277174.kimsufi.com.NS ns.kimsufi.com.

A continuación, es necesario añadir un registro del tipo PTR. Los registros PTR son punteros. Apuntan a un nombre de dominio. Quedaría así:

44 PTR elbauldelprogramador.com.

El 44 es el último valor de la dirección IP del servidor.

Eso es todo, en este punto usaremos el comando dig para comprobar la configuración.

$ dig elbauldelprogramador.com ; <<>> DiG 9.8.4-P1 <<>> elbauldelprogramador.com;; global options: +cmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10156;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION:;elbauldelprogramador.com. IN A ;; ANSWER SECTION:elbauldelprogramador.com. 532 IN A 5.39.89.44 ;; Query time: 50 msec;; SERVER: 80.58.61.250#53(80.58.61.250);; WHEN: Mon Feb 11 21:09:28 2013;; MSG SIZE rcvd: 58

Así, estamos buscando la ip del dominio. Como se aprecia, devuelve el valor correcto en la sección ANSWER SECTION.

$ dig -x 5.39.89.44 ; <<>> DiG 9.8.4-P1 <<>> -x 5.39.89.44;; global options: +cmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50347;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION:;44.89.39.5.in-addr.arpa. IN PTR ;; ANSWER SECTION:44.89.39.5.in-addr.arpa. 84513 IN PTR elbauldelprogramador.com. ;; Query time: 52 msec;; SERVER: 80.58.61.250#53(80.58.61.250);; WHEN: Mon Feb 11 21:10:09 2013;; MSG SIZE rcvd: 76

Esta vez, se está realizando la petición inversa, preguntamos por el dominio.

El servidor DNS secundario

En caso de disponer de otro servidor DSN propio, para configurarlo de modo que haga las veces de servidor DNS secundario es necesario añadir otra zona al archivo named.conf.local en el servidor secundario

zone "DOMINIO" { type slave; file "sec.DOMINIO.COM"; masters { DIRECCION IP SERVIDOR PRIMARIO; };};

Esta vez, se declara la zona como slave o esclava y se especifica la dirección IP del servidor maestro. En el fichero indicado en file se almacenarán los datos de la zona esclava. Basta con reiniciar named y dicho fichero será creado al ponserse en contacto con el servidor primario y habiendo realizado una transferencia de zona.

Por último, por razones de seguridad es recomendable agregar una línea adicional en archivo de zona del servidor principal que únicamente permita al servidor secundario realizar la transferencia de zona:

zone "elbauldelprogramador.com" { type master; allow-transfer {IP SERVIDOR DNS SECUNDARIO;}; file "/etc/bind/pri.elbauldelprogramador.com";};

En mi caso, la ip corresponde al servidor DNS secundario que proporciona la compañia en la que tengo contratado el servidor.

Con éste último artículo doy por terminada este conjunto de artículos que pretendían dar a conocer al lector el funcionamiento de DNS. Habiendo adquirido este conocimiento, será mucho más fácil usar las distintas herramientas que proporcionan los paneles de administración web para configurar los DNS.

Para finalizar, reiterar que todos los artículos están basados en un How to de la web que se menciona en las referencias.

Documents

Configurar DNS