Curso
Administrador Linux
Módulo 4
DNS
Universidad Tecnológica Nacional – Facultad Regional Buenos Aires
Página 1 de 19
Presentación
En esta unidad se introducirá a los participantes en la puesta en marcha y configuración de
un servidor de nombres (DNS).
Objetivos
Los participantes al finalizar la Unidad:
Comprenderán que es un servidor de DNS.
Entenderán la estructura de los archivos de configuración.
Comprenderán cómo funcionan los tipos de registros.
Podrán configurar tanto un servidor DNS como un cliente.
Temario
4.1 Servidor DNS
4.2 Tipos de Servidores
4.3 Configuración del servidor
4.4 Archivo de Zona
4.5 Tipos de registros
4.6 Configuración del cliente
Actividad de aplicación del conocimiento
Los participantes encontraran la actividad de aplicación en un archivo por separado en
caso de ser requerida.
Examen
Los participantes deberán rendir el examen online o presentar el material solicitado según
corresponda.
Universidad Tecnológica Nacional – Facultad Regional Buenos Aires
Página 2 de 19
4.1 Servidor DNS
La primera implementación del sistema de nombres de dominio se llamaba JEEVES y fue
realizada por Paul Mockapetris. Una implementación posterior fue BIND (Berkeley Internet
Name Domain) escrita originalmente para el sistema operativo BSD Unix de Berkeley, por
Kevin Dunlap. Hoy en día BIND es mantenido por Paul Vixie bajo el auspicio de la ISC
(Internet Software Consortium).
BIND es el servidor de DNS más popular. Ha sido portado para múltiples
plataformas basadas en Unix (incluyendo a Linux) así como también para
Windows.
Las versiones de BIND han evolucionado continuamente tal y como lo ha hecho el sistema
DNS en sí. Particularmente se destacan las series de las versiones 4, 8, y más
recientemente la 9, cada una con sus variantes. La documentación que existe acerca de la
versión 4 (fundamentalmente de las variantes 4.8 y 4.9) no se puede descartar del todo pues
muchos conceptos y mecanismos básicos de BIND se mantienen.
El DNS es una base de datos que brinda a los clientes que la consultan, información sobre
direcciones IP, nombres de maquinas, etc.
Universidad Tecnológica Nacional – Facultad Regional Buenos Aires
Página 3 de 19
El sistema base de DNS es jerárquico, hay una raíz o root definida por un punto “.”. Por
debajo de este están los Top Level Domains (TLD) que son los .org, .com, .gov, etc.
En el caso de la distribución Debian, el servidor BIND se empaqueta bajo el nombre bind.
Existen además dos paquetes relacionados con el DNS: bind-utils y caching-nameserver. El
primero consta de varias utilidades para consultar un servidor de DNS, tales como host,
nslookup y dig descriptas más adelante; y el segundo, caching-nameserver, agrupa los
archivos de la configuración mínima para un servidor de DNS que sólo consulte a otros
servidores de dominio.
Para instalar ejecutamos la siguiente sentencia:
# apt-get install bind9 dnsutils bind9-doc bind9-host bind9utils
Una vez instalado BIND, el daemon encargado de brindar el servicio se llama named o bind9
(dependiendo de la versión). Este se puede manipular utilizando el script /etc/init.d/bind9.
Ejemplos:
# /etc/init.d/bind9 start
Starting domain name service…: bind9.
# /etc/init.d/bind9 stop
Stopping domain name service…: bind9.
# /etc/init.d/bind9 reload
Reloading domain name service…: bind9.
Para ver la versión de Bind que estamos ejecutando:
# named –v
BIND 9.5.1-P1
Además existe una herramienta nombrada rndc que sustituye a ndc (Name Server Control),
y que permite a los administradores controlar el funcionamiento de servidor de nombres de
dominio a través de una conexión TCP. Si se invoca rndc sin argumentos mostrará todas sus
facilidades.
Universidad Tecnológica Nacional – Facultad Regional Buenos Aires
Página 4 de 19
4.2 Tipos de Servidores
Existen varios tipos de DNS. A saber los DNS primarios, los DNS secundarios, los DNS
maestros y los DNS de caché.
Servidores primarios (primary name servers): Estos servidores guardan la
información de su zona en una base de datos local, son los considerados como
únicos autorizados para ese o esos dominios. Son los que mantienen la información
actualizada. Todo cambio debe ser informado a este tipo de DNS.
Servidores secundarios (secundary name servers): Son aquellos que obtienen los
datos de su zona desde otro servidor que tenga autoridad para esa zona. El paso de
esta información se llama transferencia de zona.
Servidores maestros (master name servers): Los servidores maestros son los que
transfieren las zonas a los servidores secundarios. Cuando un servidor secundario
inicializa, busca un servidor maestro para realizar la transferencia de zona. Estos
servidores extraen la información desde el servidor primario de la zona evitando de
esta forma que los servidores secundarios sobrecarguen al servidor primario con
transferencias de zonas.
Servidores locales (caching-only servers): Los servidores locales no tienen autoridad
sobre ningún dominio, solo limitan su actividad a contactar con otros servidores para
resolver las peticiones de los clientes DNS. Mantienen una memoria caché con las
últimas consultas. Cada vez que un cliente realiza una consulta, primero consulta en
su memoria caché, en caso de no encontrarla, consulta a otros servidores, guarda la
respuesta en su memoria caché y le comunica la respuesta al cliente. Este tipo de
servidores no tiene archivos de configuración de ningún dominio.
Universidad Tecnológica Nacional – Facultad Regional Buenos Aires
Página 5 de 19
Cabe aclarar que BIND, es por defecto un servidor local o de caché.
Además los servidores DNS actúan como servidores de caché ya sean
primarios o secundarios de dominios.
Por otro lado debemos entender que un servidor DNS puede configurarse para que sea DNS
primario para un dominio y secundario para otro.
Tipos de Resolución
Resolución directa:
Es cuando se resuelve de nombre de host a dirección IP.
Es la más común dado que permite conocer la dirección IP consultando el nombre.
Tiene una estructura jerárquica.
Resolución inversa:
Tiene la misma jerarquía que la resolución directa y nos permite conocer el FQDN “Fully
Qualified Domain Name” de un host.
El siguiente es un ejemplo donde se ve la estructura jerárquica:
Universidad Tecnológica Nacional – Facultad Regional Buenos Aires
Página 6 de 19
4.3 Configuración del servidor
La configuración básica de BIND se encuentra en el archivo /etc/named.conf. Este archivo
fundamentalmente describe las zonas de los dominios que controlará BIND (más adelante
profundizaremos en su sintaxis). Para cada una de estas zonas se indica, entre otras
características: el nombre del archivo que almacena sus datos. Es en estos archivos donde
se colocan todos los registros del DNS y como se mencionó anteriormente se conocen como
archivos “db” (database files). Por defecto se agrupan en el directorio /var/named.
La información presente en un archivo db puede especificarse en letras mayúsculas o
minúsculas indistintamente, pues las consultas al DNS son case-insensitive. Se pueden
incluir además comentarios precedidos por el carácter “;” y líneas en blanco.
El archivo de configuración named.conf
Como bien se expresó anteriormente el archivo de configuración básico de BIND se nombra
named.conf y por defecto se instala en el directorio /etc a través del paquete caching-
nameserver. En versiones anteriores de BIND este archivo se nombraba named.boot, poseía
una sintaxis más simple pero mucho menos expresiva. Actualmente se instala una versión
equivalente a la named.conf y los que lo prefieran pueden seguir utilizándolo, pues existe un
shell script llamado named-bootconf que permite su transformación en named.conf.
El archivo /etc/bind/named.conf por defecto posee un contenido similar a este:
Universidad Tecnológica Nacional – Facultad Regional Buenos Aires
Página 7 de 19
Las posibilidades de configuración que brinda este archivo son enormes, basta con mirar
rápidamente el “man page” del mismo para percibir esto. Sin embargo, se puede decir que
está formado por un conjunto de sentencias y de comentarios. Las sentencias se terminan
con el carácter “;” y pueden contener dentro de sí a otras sentencias, en estos casos el
contenido de la sentencia va encerrado entre {}. Los comentarios pueden ser de varios
estilos similares a los lenguajes de programación C, C++, Perl y Shell.
Ejemplos de comentarios son:
Existen muchos tipos de sentencias. De ellas las principales se explican a continuación:
acl: Es una sentencia que permite definir listas de direcciones IP con el objetivo de
utilizarlas para indicar reglas de acceso en otras sentencias. Su nombre significa Access
Control List.
Por defecto existen cuatro acl definidas como:
any: acceso permitido a todos los host.
none: acceso denegado a todos los host.
localhost: acceso permitido sólo a las direcciones IP locales.
localnets: acceso permitido a todos los host de todas las redes con las cuales el sistema
tenga al menor una interfaz.
El siguiente es un ejemplo que define una lista de acceso con nombre “danger” y que
incluye a todos los host pertenecientes a las redes 192.100.5.0 y 192.200.010.12 así como
al host independiente 192.168.2.5
Universidad Tecnológica Nacional – Facultad Regional Buenos Aires
Página 8 de 19
options: Esta sentencia controla toda la configuración del servidor y define las opciones por
defecto de otras sentencias. Sólo debe aparecer una vez en el archivo de configuración. En
el ejemplo que se da a continuación se muestran y comentan otras opciones.
4.4 Archivo de zona
Continuando con las sentencias nos encontramos con aquellas que sirven específicamente
para definir la zona.
zone: Es una de las sentencias más importantes pues permite definir las zonas y describir
sus respectivas configuraciones. Existen cinco tipos de zonas:
master zone: Es aquella donde el servidor tiene la copia primaria o principal de los datos de
la zona y es capaz de dar respuestas autorizadas acerca de está.
slave zone: Es la zona cuyos datos son resultado de la réplica de la información de una
zona master.
hint zone: Es la zona que contiene la información del conjunto inicial de servidores del
dominio raíz.
stub zone: Es una zona igual a la de tipo slave excepto que en esta sólo se replica la
información de los servidores de la zona primaria y no el resto de la información.
Universidad Tecnológica Nacional – Facultad Regional Buenos Aires
Página 9 de 19
forward zone: Es el tipo de zona, donde las consultas acerca de sus datos se reenvían a
otros servidores.
En versiones anteriores de BIND las zonas master, slave y hint se conocían
como primary, secondary y cache respectivamente.
A continuación se muestra a través de un ejemplo como se definen las zonas
ejemplo.com.ar, 100.168.192.in-addr.arpa y 200.168.192.in-addr.arpa.
Los siguientes atributos pueden ser indicados al configurar una zona:
type: indica el tipo de la zona.
file: para el caso de las zonas cuya información se almacene localmente indica el nombre
del archivo donde esta se encuentra.
allow-update: indica los hosts autorizados a hacer actualizaciones dinámicas a la zona.
allow-transfer: indica los hosts autorizados a transferir la información de la zona. Este
atributo también se puede especificar de forma global en la sentencia options.
Universidad Tecnológica Nacional – Facultad Regional Buenos Aires
Página 10 de 19
allow-query: indica los hosts autorizados a hacer consultas sobre la zona. Este atributo
también se puede especificar de forma global en la sentencia options.
forward: es un atributo aplicable sólo a las zonas de tipo fordward. Puede tomar dos valores
first u only, el primero (que es el por defecto) indica que primero se consulte a los hosts
especificados en el atributo forwarders y si estos fallan entonces se busque la respuesta
localmente, y el segundo sólo consulta a los hosts en fordwarders. Ambos atributos se
pueden especificar de forma global en la sentencia options.
Otras sentencias son logging, server, key, trusted-keys, include y controls.
A partir de la versión 9 de BIND se incluyen dos herramientas para chequear la sintaxis de
los archivos que describen a las zonas y el archivo de configuración principal named.conf.
Ellas son: named-checkzone y named-checkconf respectivamente. Ejemplos de cómo
pueden ser utilizadas son:
# named-checkconf
/etc/bind/named.conf:16: parse error near options
# named-checkzone ejemplo.com.ar /var/named/disaic.zone
dns_master_load: /var/named/disaic.zone:8: unknown RR type ´NY´
# named-checkzone ejemplo.com.ar /var/named/disaic.zone
OK
4.5 Tipos de registros
Los registros presentes en los archives db pueden ser de varios tipos, los principales se
listan y describen a continuación:
SOA (Start Of Authority): Este registro es el que indica que el servidor de nombres está
autorizado para la zona correspondiente. Se ubica al comienzo de cada archivo db y
contiene información acerca del funcionamiento del DNS.
A (Address): Es uno de los registros más importantes, pues permite definir la
correspondencia entre nombres y direcciones IP.
CNAME (Canonical Name): Se utiliza para definir alias para los nombres ya definidos.
NS (Name Server): Permite indicar cuáles son los servidores de nombres de dominio de la
zona correspondiente.
PTR (Domain name Pointer): Junto a los address records es uno de los más importantes
pues define las correspondencias inversas: de direcciones IP a nombres.
MX (Mail Exchanger): Permite indicar para un nombre de dominio determinado quien es el
host que se encarga de manipular la mensajería dirigida a este.
HINFO (Host Information): Se emplea para almacenar dos características, procesador y
sistema operativo de un host del dominio.
Universidad Tecnológica Nacional – Facultad Regional Buenos Aires
Página 11 de 19
TXT (Text): Permite guardar un comentario textual acerca de un host perteneciente al
dominio.
RP (Responsible Person): Es un registro que permite indicar los datos de la(s) persona(s)
responsable(s) de la zona en cuestión. Consta de dos campos: uno contiene la dirección de
correo electrónico y el otro, un nombre de dominio válido que a su vez debe poseer un
registro TXT donde se indican otros datos tales como: dirección, teléfono, etc.
WKS (Well Known Services): Aunque es un registro poco utilizado tiene cierta
funcionalidad pues permite indicar para un host los servicios (telnet, FTP, Web, finger, DNS)
que brinda y a través de que interfaces de red y protocolo lo hace (TCP o UDP).
Los registros en un archivo db presentan la siguiente sintaxis:
<dominio>[ttl] [clase] <tipo> <datos>
Donde:
dominio: puede ser el carácter ´.´ cuando se refiere al dominio raíz, @ para el origen actual,
o un dominio estándar. Si el nombre de dominio no termina con un punto entonces se le
adicionará el origen actual, de tener un punto al final se mantendrá invariable.
ttl: indica el tiempo de vida del registro. Si no se coloca se asume el especificado en la
última directiva $TTL (más adelante se explica que son las directivas) y de no existir esta se
asumirá el valor mínimo especificado en el registro SOA (más adelante se describirá la
estructura de este).
clase: se utiliza para definir la clase del registro. Por defecto se asume la clase
correspondiente a las redes tipo Internet basadas en TCP/IP, nombrada IN.
tipo: indica el tipo de registro descripto. Puede ser cualquiera de los especificados
anteriormente: A, NS, CNAME, SOA, etc.
datos: constituye la información asociada al registro y que es totalmente dependiente de
este.
Universidad Tecnológica Nacional – Facultad Regional Buenos Aires
Página 12 de 19
Un registro puede estar definido completamente en una línea terminando al final de esta o
puede abarcar varias si se emplean paréntesis. Los registros que emplean en mayor medida
esta posibilidad son el SOA y el WKS dada la cantidad de información que contienen.
Directivas
Además de varios registros, en un archivo db se pueden incluir algunas directivas (variables)
que modifican la interpretación de los registros que se definan posteriormente a su inclusión.
Estas directivas son: INCLUDE, ORIGIN y TTL. Se indican precedidas por el signo $.
A continuación se describe y ejemplifica la utilización de cada una:
INCLUDE: Permite incluir otro archivo db, especificando su nombre y la zona que describe
opcionalmente.
Universidad Tecnológica Nacional – Facultad Regional Buenos Aires
Página 13 de 19
Sintaxis: $INCLUDE <archivo> [dominio]
Ejemplo: $INCLUDE uucphost.zone uucp.ejemplo.com.ar
ORIGIN: Se utiliza para cambiar el origen por defecto de la zona. El origen inicial se
corresponde con el nombre de la zona que describe el archivo.
Sintaxis: $ORIGIN <dominio>
Ejemplo: $ORIGIN uucp.ejemplo.com.ar
TTL: Permite indicar el tiempo de vida por defecto de todos los registros del archivo.
El TTL se indica en segundos.
Sintaxis: $TTL <ttl>
Ejemplo: $TTL 3600
Universidad Tecnológica Nacional – Facultad Regional Buenos Aires
Página 14 de 19
Este tema es mucho más amplio que lo expresado, y es posible utilizar abreviaturas, en la
sintaxis de BIND, como así también configurar dominios esclavos y hasta dinámicos.
4.6 Configuración del cliente
Hasta ahora vimos como se configura el servidor de DNS, a partir de aquí vemos como
configurar el cliente de DNS.
Encontraremos dos archivos de importancia, estos son:
/etc/host.conf
En este archivo se define el orden en el que se recurrirá a la resolución de nombres (por
ejemplo primero bind y luego el archivo local host), si soportaremos múltiples IP por
maquina, etc.
En el archivo /etc/resolv.conf se indican los servidores de DNS que se utilizaran para
realizar la consulta y en qué orden serán consultados, a que dominio pertenece la maquina,
la lista de búsqueda para buscar nombres de host, etc.
Prueba de funcionamiento
Para realizar las pruebas podemos recurrir a dos utilidades, nslookup y dig. Verifiquemos el
archivo /etc/resolv.conf y lo modificaremos para utilizar nuestro servidor DNS.
Universidad Tecnológica Nacional – Facultad Regional Buenos Aires
Página 15 de 19
Verificamos la configuración actual de /etc/resolv.conf
debían:/# cat /etc/resolv.conf
domain localdomain
search localdomain
nameserver 192.168.153.2
debian:/#
Probamos la resolución de nombres en forma directa, consultaremos directamente un
nombre mediante nslookup y dig.
Universidad Tecnológica Nacional – Facultad Regional Buenos Aires
Página 16 de 19
Ahora vamos a hacer una búsqueda de dominio apelando a la jerarquía. En nuestro caso
buscaremos llegar al host www.adistancia.frba.utn.edu.ar
Entramos a nslookup en modo interactivo y, en principio, fijamos la consulta solo a
servidores de nombre (mediante set q=NS). Consultamos entonces por la jerarquía “ar.”
(tener en cuenta el punto).
debian:/# nslookup
>
> set q=ns
> ar.
Server 127.0.0.1
Address: 127.0.0.1#53
Non-authoritative answer:
ar nameserver=ns.UU.NET.
ar nameserver=uucp-gw-2.pa.DEC.COM.
ar nameserver=athea.ar.
ar nameserver=merapi.switch.ch.
ar nameserver=uucp-gw-1.pa.DEC.COM.
ar nameserver=ctina.ar.
ar nameserver=ns1.retina.ar.
ar nameserver=ns-ar.ripe.NET.
Authoritative answers can be found from:
>
Cambiamos de servidor de nombres mediante el commando server y consultamos ahora por
“edu.ar.”
>server athea.ar
Default server: athea.ar
Address: 200.16.98.2#53
>
>edu.ar.
Server: athea.ar
Address: 200.16.98.2#53
edu.ar nameserver = merapi.switch.ch.
edu.ar nameserver = noc.uncu.edu.ar.
edu.ar nameserver = ns1.riu.edu.ar.
edu.ar nameserver = ns1.uba.ar.
edu.ar nameserver = ns2.uba.ar.
edu.ar nameserver = unlp.unlp.edu.ar.
edu.ar nameserver = athea.ar.
edu.ar nameserver = ctina.ar.
>
Universidad Tecnológica Nacional – Facultad Regional Buenos Aires
Página 17 de 19
Cambiamos nuevamente de servidor y consultamos por utn.edu.ar
>server ns1.riu.edu.ar
Default server: ns1.riu.edu.ar
Address: 170.210.0.18#53
>
>utn.edu.ar.
Server: ns1.riu.edu.ar
Address: 170.210.0.18#53
utn.edu.ar nameserver = ns1.riu.edu.ar.
utn.edu.ar nameserver = panda.utn.edu.ar.
>
Cambiamos nuevamente de servidor y consultamos por frba.utn.edu.ar
>server ns1.riu.edu.ar
Default server: ns1.riu.edu.ar
Address: 170.210.0.18#53
>
>frba.utn.edu.ar.
Server: ns1.riu.edu.ar
Address: 170.210.0.18#53
Non-authoritative answer:
*** Can´t find frba.utn.edu.ar.: No answer
Authoritative answer can be found from:
frba.utn.edu.ar nameserver = ns2.frba.utn.edu.ar.
frba.utn.edu.ar nameserver = mta-int.frba.utn.edu.ar.
frba.utn.edu.ar nameserver = ns1.frba.utn.edu.ar.
ns1.frba.utn.edu.ar internet address = 170.210.18.246
ns2.frba.utn.edu.ar internet address = 200.47.7.104
mta-int.frba.utn.edu.ar internet address = 200.47.7.98
>
Cambiamos de servidor, esta vez cambiamos el tipo de consulta a todos los tipos (mediante
set q=any) y consultamos por el dominio complete www.adistancia.frba.utn.edu.ar
>server ns1.frba.utn.edu.ar
Default server: ns1.frba.utn.edu.ar
Address: 170.210.18.246#53
>set q=any
>
>www.adistancia.frba.utn.edu.ar
Server: ns1.frba.utn.edu.ar
Address: 170.210.18.246#53
Universidad Tecnológica Nacional – Facultad Regional Buenos Aires
Página 18 de 19
www.adistancia.frba.utn.edu.ar canonical name = campusvirtual.frba.utn.edu.ar
> campusvirtual.frba.utn.edu.ar
Server: ns1.frba.utn.edu.ar
Address: 170.210.18.246#53
Name: campusvirtual.frba.utn.edu.ar
Address: 200.43.193.70
>
Universidad Tecnológica Nacional – Facultad Regional Buenos Aires
Página 19 de 19
