Instalación y

configuración del
DNS
Domain Name System

Para la comunidad de Administradores de red

del
Municipio Boyeros.

Autor: Emilio Fernández Rodríguez

Email: emifr@infomed.sld.cu
emifr@prb.sld.cu
GNU/Linux User #514729 (http://counter.li.org)

Creado el 27 de mayo del 2010

 ADMINREDSL
COMUNIDAD DE ADMINISTRADORED DE RED Y SOFTWARE LIBRE

Información de Derechos reservados de esta publicación.

Reconocimiento-NoComercial-CompartirIgual 2.1
Usted es libre de:
· Copiar, Distribuir y Comunicar públicamente la obra

Bajo las condiciones siguientes:

Reconocimiento. Debe reconocer y citar al autor original.

No comercial. No puede utilizar esta obra para fines comerciales.

Compartir bajo la misma licencia. Si altera o transforma esta obra, o genera

una obra derivada, sólo puede distribuir la obra generada bajo una licencia
idéntica a ésta.

· Al reutilizar o distribuir la obra, tiene que dejar bien claro los términos de la
licencia de esta obra.
· Alguna de estas condiciones puede no aplicarse si se obtiene el permiso del
titular de los derechos de autor

Los derechos derivados de usos legítimos u otras limitaciones no se ven afectados por lo
anterior.
Reconocimiento-NoComercial-CompartirIgual 2.1
 Índice

1- Introduccíon a la historia del DNS

2- Instalación de bind9.
3- DNS local o de solo cache.
4- DNS maestros primarios.
5- DNS maestros secundarios.
6- Comprobación de los servicios
 1- Introduccíon a la historia del DNS

A mediados de los 70, la ARPANET era una comunidad pequeña y amistosa de

unas cientos de máquinas. Un solo archivo, HOSTS.TXT, contenía toda la
información que se necesitaba saber sobre esas máquinas: contenía un mapeo
de nombre a dirección para cada máquina en la ARPANET.
El archivo /etc/hosts se obtenía entonces del archivo HOSTS.TXT (el cual
tenía información adicional que no era necesaria).
Sin embargo, cuando la ARPANET se cambió a los protocolos TCP/IP, la
población de la red explotó, y con ello se presentaron los siguientes problemas:
• La carga y el tráfico de red para la máquina que contenía las tablas que
hacían posible el mapeo de nombres a direcciones IP se volvió inmanejable.
• Colisiones de nombres. El NIC (organismo encargado de administrar la
creación de nombres) no podía garantizar que alguien asignara el mismo
nombre a máquinas distintas (Esto se debe a que con el método del
HOSTS.TXT se tenía un dominio plano, es decir, sin jerarquías).
• Consistencia: Mantener la consistencia del archivo a lo largo de una red en
crecimiento se hacía cada vez más difícil (Por ejemplo, cuando el archivo
HOSTS.TXT llegaba a una máquina muy lejana ya era obsoleto).
Este método se tornaba ineficiente a medida que aumentaban el número de
máquinas. Es allí donde entra DNS (Domain Name System, Sistema de
Dominios de Nombres). DNS es una base de datos distribuida. DNS permite un
control local sobre los segmentos de la base de datos general, logrando que
cada segmento esté disponible a lo largo de toda la red utilizando un esquema
cliente servidor. La robustez y un desempeño adecuado se lograba gracias a la
duplicidad de servidores y el caching (almacenamiento temporal).
Los programas llamados servidores de nombres (name servers) comprenden la
mitad del mecanismo cliente - servidor de DNS. Los servidores de nombres
contienen información acerca de un segmento de la base de datos y la ponen a
disposición de los clientes, llamados resolvers.
Los resolvers son solo biblioteca de rutinas que crean preguntas y las envían a
lo largo de la red hacia el servidor de nombres.
La estructura de una base de datos DNS se asemeja mucho a un árbol invertido
(Es decir, un árbol cuyo tronco esta hacia arriba y no abajo, como es común).
Cada "hoja" o "nodo" de ese árbol es un dominio, comenzando todos los
dominios desde el dominio root (el cual se denota con un punto "."). Cada uno
de esos dominios a su vez pueden subdividirse en más subdominios. ¡ Existen
muchos dominios (com, edu, gov) y debajo de ellos hay aun más subdominios!
Cada máquina en la red pertenece a un dominio, cuyo servidor de nombres
contiene la información acerca de la máquina. Esta información puede
incluir direcciones IP, información acerca de enrutamiento de correo, etc. (Una
máquina también puede tener uno o más aliases de dominio, lo cual quiere
decir que existen 2 referencias hacia la máquina, una de ellas es un apuntador
de un dominio (alias) a su nombre canónico (u oficial).
DNS con su estructura (aparentemente complicada) permite eliminar los
problemas que presentaba la existencia de un archivo de datos planos :
• Elimina el problema de nombres repetidos (a cada organización se le asigna
un dominio único, por lo que pueden existir dos máquinas con el mismo
nombre mientras estén en dominios separados).
• Elimina el problema de carga y tráfico de red en una sola máquina ya que la
información esta distribuida. (Y esta disponible de manera redundante).
• Finalmente hay consistencia, ya que la actualización de la información se
hace de manera automática, sin intervención del administrador de la red (al
menos no de la manera tradicional).
En esta práctica trabajaremos con la implementación de UNIX de DNS: BIND
(Berkeley Internet Name Domain), la cual es la implementación más popular de
DNS hasta la fecha .

Dominios:
En realidad un dominio es sólo un índice dentro de la base de datos de DNS. Un
dominio puede ser una máquina o puede ser un nodo del cual pueden partir
otros dominios (o ambas cosas a la vez). Por ejemplo, el siguiente árbol
invertido nos muestra algunos dominios típicos de DNS:

2- Instalación de bind9.

- Actualizamos el repositorio de paquetes, por si hay alguna versión nueva.

# apt-get update

- Instalamos bind9

# apt-get install bind9

 3- DNS local o de solo cache.

El servidor DNS local o de solo cache no es mas que un servidor cache que
corre en nuestro servidor, pero no tiene archivos de base de datos (db).
Aprende las respuestas de otros servidores de nombres, la guarda y la usa para
responder preguntas futuras sobre esa misma información. Solamente requiere
de un archivo de cache (Con información acerca de los root servers a los cuales
debe preguntar). Se dice que este tipo de servidor no es autoritario ya que la
información que obtiene es de segunda mano.

Edita el archivo /etc/bind/named.conf.options,

# nano /etc/bind/named.conf.options

Y para los que pertenece a la red de infomed, les debe quedar así.

options {
directory "/var/cache/bind";
forwarders {
201,220,222,131;
201,220,222,132;
};
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};

En forwarders, van las direcciones IP de los root servers a los cuales debe
preguntar tu server local.

Edita /etc/resolv.conf

# nano /etc/resolv.conf

Así nos debe quedar el fichero resolv.conf.

search midominio.sld.cu
nameserver 127.0.0.1

En donde search indica el dominio de nuestra red. Reemplaza

midominio.sld.cu por el dominio correspondiente a tu institución.
Reinicia el daemon de BIND con,

# /etc/init.d/bind9 restart

y luego reinicia la red,

# /etc/init.d/networking restart

4- DNS maestros primarios.

El servidor DNS maestros primarios es la fuente autoritaria de toda la

información referente a un dominio. Carga la información de archivos
mantenidos localmente por el administrador del dominio. Este archivo (el
archivo de zona) contiene la información acerca de una pieza de la jerarquía
del dominio sobre la cual el servidor tiene autoridad. Un servidor maestros
primario requiere un conjunto completo de archivos: archivos de zonas para el
dominio regular (db.midominio.sld.cu) y el zonas inverso (db.192,168,1.in-
addr.arpa).

Editamos el fichero "/etc/bind/named.conf.local".

# nano /etc/bind/named.conf.local

//Zona directa
zone "midominio.sld.cu" IN { // Cambie “midominio.sld.cu” por el que use.
type master; // Tipo de maestro (master o slave).
file "/etc/bind/db.midominio.sld.cu"; // Base de datos (hay que crearla).
allow-transfer { 192.168.1.2; }; // Servidor maestro secundario.
};

//Zona inversa
zone "1.168.192.in-addr.arpa" IN { // Cambie por el segmento de red que use.
type master; // Tipo de maestro (master o slave).
file "/etc/bind/db.192.168.1.in-addr.arpa"; // Base de datos (hay que crearla).
allow-transfer { 192.168.1.2; }; // Servidor maestro secundario.
};
Creamos las bases de datos para la zonas regular o directa.

# nano /etc/bind/db.midominio.sld.cu

;-------------- MIDOMINIO.SLD.CU ----------------

;----------------------------------------------------------
$TTL 1d ; tiempo de vida de la zona en memoria.
$ORIGIN midominio.sld.cu. ; nombre de dominio base
@ IN SOA ns1.midominio.sld.cu. admin.midominio.sld.cu. (
2010072301 ; se = Fecha con numero serial
12h ; ref = tiempo para refrescar
15m ; ret = tiempo de reintento para actualización
3w ; ex = tiempo de expiración
2h ; min = mínimo
)
;-------------- Servidores DNS ----------------
;-----------------------------------------------------
@ IN NS ns1.midominio.sld.cu.
@ IN NS ns2.midominio.sld.cu.
ns1 IN A 192.168.1.1
ns2 IN A 192.168.1.2
;--------------- Servidores ----------------------
;-----------------------------------------------------
alpha IN A 192.168.1.1
delta IN A 192.168.1.2
;----- Descripción de los equipos --------
;-----------------------------------------------------
alpha IN HINFO "DELL" "Linux Debian Lenny"
delta IN HINFO "Pentium ASUS" "Linux Debian Lenny"
;--------------- Servidores MX ----------------
;-----------------------------------------------------
delta IN MX 0 mx.midominio.sld.cu.
delta IN TXT "v=spf1 a:mx.midominio.sld.cu -all"
;-------------- HOSTS - ALIAS -----------------
;-----------------------------------------------------
www IN CNAME alpha
proxy IN CNAME delta
Creamos las bases de datos para la zonas inversa

# nano /etc/bind/db.192.168.1.in-addr.arpa

;---------- MIDOMINIO.SLD.CU --------------

;-----------------------------------------------------
$TTL 1d ; tiempo de vida de la zona en memoria.
$ORIGIN 1.168.192.IN-ADDR.ARPA. ; rango de la red
@ IN SOA ns1.midominio.sld.cu. admin.midominio.sld.cu. (
2010072301 ; se = Fecha con numero serial
12h ; ref = tiempo para refrescar
15m ; ret = tiempo de reintento para actualización
3w ; ex = tiempo de expiración
2h ; min = mínimo
)
;-------------- Servidores DNS ---------------
;-----------------------------------------------------
@ IN NS ns1.midominio.sld.cu.
@ IN NS ns2.midominio.sld.cu.
;------------------- IP - Host --------------------
;-----------------------------------------------------
1 IN PTR alpha.midominio.sld.cu.
2 IN PTR delta.midominio.sld.cu.
2 IN PTR mx.midominio.sld.cu.
3 IN PTR admin.midominio.sld.cu.

Reinicia el daemon de BIND con,

# /etc/init.d/bind9 restart
 5- DNS maestros secundarios.

Un servidor maestros secundario transfiere un conjunto completo de

información de dominio desde el servidor maestros primario. El archivo de zona
es transferido desde el servidor primario y es guardado como un archivo local
de disco (a esta operación se le llama transferencia de zona). Solamente se
requieren editar los archivos named.conf.local y named.conf.options. Un
servidor maestros secundario es considerado también maestros primario ya
que tiene una copia exacta del los archivos del servidor maestros primario (Lo
cual lo hace autoritario).

Editamos el fichero "/etc/bind/named.conf.local", en el servidor secundario.

# nano /etc/bind/named.conf.local

//Zona directa
zone "midominio.sld.cu" IN { // Cambie “midominio.sld.cu” por el que use.
type slave; // Tipo de maestro (master o slave).
file "/etc/bind/db.midominio.sld.cu"; // Base de datos (hay que crearla).
masters { 192.168.1.1; }; // Servidor maestro primario.
};

//Zona inversa
zone "1.168.192.in-addr.arpa" IN { // Cambie por el segmento de red que use.
type slave; // Tipo de maestro (master o slave).
file "/etc/bind/db.192.168.1.in-addr.arpa"; // Base de datos (hay que crearla).
masters { 192.168.1.1; }; // Servidor maestro primario.
};

El usuario de sistema bind en el DNS secundario necesita permisos para

modificar archivos en el directorio /etc/bind.

# chmod g+ws /etc/bind

Edita el archivo /etc/bind/named.conf.options,

# nano /etc/bind/named.conf.options
Y para los que pertenece a la red de infomed, les debe quedar así.

options {
directory "/var/cache/bind";
forwarders {
201,220,222,131;
201,220,222,132;
};
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};

En forwarders, van las direcciones IP de los root servers a los cuales debe
preguntar tu server local.

Edita /etc/resolv.conf

# nano /etc/resolv.conf

Así nos debe quedar el fichero resolv.conf.

search midominio.sld.cu
nameserver 127.0.0.1

En donde search indica el dominio de nuestra red. Reemplaza

midominio.sld.cu por el dominio correspondiente a tu institución.

Reinicia el daemon de BIND con,

# /etc/init.d/bind9 restart

y luego reinicia la red,

# /etc/init.d/networking restart
 6- Comprobación de los servicios

Existen algunos programas para la comprobacón de nuestros servidores de

nombre, Uno de ellos son [dig] y [nslookup]. Ejemplo:

1- Comprobamos con la herramienta dig la zona directa.

$ dig www.midominio.sld.cu

; <<>> DiG 9.5.1-P3 <<>> www.midominio.sld.cu

;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40192
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;www.midominio.sld.cu. IN A

;; ANSWER SECTION:
www.midominio.sld.cu. 86400 IN CNAME alpha.midominio.sld.cu.
alpha.midominio.sld.cu. 86400 IN A 192.168.1.1

;; AUTHORITY SECTION:
midominio.sld.cu. 86400 IN NS ns2.midominio.sld.cu.
midominio.sld.cu. 86400 IN NS ns1.midominio.sld.cu.

;; ADDITIONAL SECTION:
ns1.midominio.sld.cu. 86400 IN A 192.168.1.1
ns2.midominio.sld.cu. 86400 IN A 192.168.1.2

;; Query time: 1 msec

;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jan 1 00:35:20 2002
;; MSG SIZE rcvd: 142
2- Comprobamos con la herramienta dig la zona inversa:

$ dig -x 192.168.1.2

; <<>> DiG 9.5.1-P3 <<>> -x 192.168.1.2

;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43280
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;2.1.168.192.in-addr.arpa. IN PTR

;; ANSWER SECTION:
2.1.168.192.in-addr.arpa. 86400 IN PTR delta.midominio.sld.cu.

;; AUTHORITY SECTION:
1.168.192.in-addr.arpa. 86400 IN NS ns2.midominio.sld.cu.
1.168.192.in-addr.arpa. 86400 IN NS ns1.midominio.sld.cu.

;; ADDITIONAL SECTION:
ns1.midominio.sld.cu. 86400 IN A 192.168.1.1
ns2.midominio.sld.cu. 86400 IN A 192.168.1.2

;; Query time: 1 msec

;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jan 1 00:43:23 2002
;; MSG SIZE rcvd: 146
3- Comprobamos con la herramienta nslookup la zona directa :

$ nslookup proxy.midominio.sld.cu

Server: 127.0.0.1
Address: 127.0.0.1#53

proxy.midominio.sld.cu canonical name = delta.midominio.sld.cu.

Name: delta.midominio.sld.cu
Address: 192.168.1.2

4- Comprobamos con la herramienta nslookup la zona inversa:

$ nslookup 192.168.1.3

Server: 127.0.0.1
Address: 127.0.0.1#53

3.1.168.192.in-addr.arpa name = admin.midominio.sld.cu.