Dns-infoadicional

De EDUC@REDES
Saltar a: navegación, buscar

Ejercicio práctico sobre DNS: CONFIGURACIÓN DETALLADA

Utilización de Ethereal para las redes virtuales del escenario

  • Para poder capturar en tiempo real (con Ethereal, por ejemplo) evitando guardar las capturas de las máquinas virtuales y copiarlas posteriormente de manera remota, se añade en la lan1 (red compuesta por todas las máquinas del escenario) un nuevo atributo en su especificación:
<net name="lan1" mode="uml_switch" uml_switch_binary="/usr/bin/uml_switch4capture" capture_dev="red1" />
De esta forma el tráfico de la red se podrá capturar a través de la interfaz red1.

Información general del escenario

  • En cada máquina virtual se arrancará un servidor de nombres con el servicio "bind".
  • Para el dominio "alfa" existe, además del servidor maestro, un servidor esclavo que se iniciará en el apartado 3.
  • Las informaciones de topología, jerarquía y autoridad pueden encontrase en el apartado "Descripción del Escenario" en dns: Enunciado.

Secuencias de comandos

  • Apartado 1:
NOTA: Se utilizará como ejemplo la secuencia necesaria para la máquina Root, siendo análoga la secuencia necesaria para la configuración del resto de las máquinas.
Los archivos necesarios para la configuración de cada servidor de nombres se encuentran en la carpeta dns_conf, con la estructura que se indica en el apartado dns: Archivos de configuración. Cada máquina tiene asociada una carpeta: ns1 para Root, ns2 para alfa, etc.
La secuencia descrita a continuación tendrá lugar en todas las máquinas virtuales del escenario:
  • En primer lugar se guarda en el directorio del servicio bind (/etc/bind) la carpeta que contiene todos los ficheros de configuración relativos a la máquina virtual:
<filetree when="aptdo1" root="/etc/bind">dns_conf/ns1</filetree>
  • Se realiza un borrado forzado de todos los archivos que hubiera a priori en ese directorio:
<exec seq="aptdo1" type="verbatim">rm -f /etc/bind/*</exec>
  • Se sacan todos los archivos de la carpeta ns1 en /etc/bind
<exec seq="aptdo1" type="verbatim">mv /etc/bind/ns1/* /etc/bind</exec>
  • Se eliminan todos los procesos dns que pudieran estar ejecutándose:
<exec seq="aptdo1" type="verbatim">killall named</exec>
  • Y se inicia el servidor de nombres indicando la ubicación de los archivos de configuración:
<exec seq="aptdo1" type="verbatim">/usr/sbin/named -c /etc/bind/named.conf</exec>
  • Apartado 2:
En este apartado no se lleva a cabo ninguna secuencia, puesto que la configuración necesaria para el uso de la utilidad rndc se carga al arrancar el servidor en el Apartado 1.
  • Apartado 3A:
En Root y alfa se cargan los ficheros de configuración necesarios. Estos ficheros son muy similares a los anteriores, salvo que incluyen las líneas necesarias para el reconocimiento del servidor esclavo. Esta es la secuencia seguida en la máquina "Root", siendo análoga para "alfa":
<filetree when="aptdo3A" root="/etc/bind">dns_conf/ns1_aptdo3</filetree>
NOTA: Recuerde que todas las líneas de "filetree" deben preceder a las líneas de "exec".
  • Se realiza un borrado forzado de todos los archivos que hubiera a priori en ese directorio:
<exec seq="aptdo3A" type="verbatim">rm -f /etc/bind/*</exec>
  • Se sacan todos los archivos de la carpeta ns1_aptdo3 en /etc/bind
<exec seq="aptdo3A" type="verbatim">mv /etc/bind/ns1_aptdo3/* /etc/bind</exec>
  • Se para el servidor de nombres que ya estaba ejecutándose:
<exec seq="aptdo3A" type="verbatim">killall named</exec>
  • Y se inicia el servidor de nombres indicando la ubicación de los archivos de configuración:
<exec seq="aptdo3A" type="verbatim">/usr/sbin/named -c /etc/bind/named.conf</exec>
En alfa2 se ejecutan los mismos comandos que se usaron en el apartado 1 para iniciar el resto de servidores de nombres:
<filetree when="aptdo3A" root="/etc/bind">dns_conf/ns12_aptdo3</filetree>
<exec seq="aptdo3A" type="verbatim">rm -f /etc/bind/*</exec>
<exec seq="aptdo3A" type="verbatim">mv /etc/bind/ns12_aptdo3/* /etc/bind</exec>
<exec seq="aptdo3A" type="verbatim">killall named</exec>
<exec seq="aptdo3A" type="verbatim">/usr/sbin/named -c /etc/bind/named.conf</exec>
<exec seq="stop" type="verbatim">killall named</exec>
  • Apartado 3B:
En alfa: se ejecutan los comandos necesarios para cargar un nuevo fichero db.alfa, en el que se ha incluido un nuevo host bajo el dominio alfa: h4.alfa (con dirección IPV4 10.13.0.4 y dirección IPV6 2001:db8:13::4). Después de recargar la configuración del servidor de nombres (con rndc reload), de manera automática se copiará el nuevo fichero en el servidor maestro de la zona: alfa2. Nótese que ha de aumentarse el número de serie del fichero en cuestión para que sea reconocido como una modificación del anterior.
La secuencia necesaria será:
<filetree when="aptdo3" root="/etc/bind">dns_conf/aptdo3</filetree>
En esta carpeta se encuentra el fichero modificado que se introducirá en la máquina alfa
NOTA: Recuerde que todas las líneas de "filetree" deben preceder a las líneas de "exec".
<exec seq="aptdo3" type="verbatim">rm /etc/bind/db.alfa</exec>
<exec seq="aptdo3" type="verbatim">mv /etc/bind/aptdo3/db.alfa /etc/bind</exec>
<exec seq="aptdo3" type="verbatim">rndc reload</exec>

Archivos de configuración del escenario

Para llevar a cabo la explicación de la configuración se comenzará con el análisis de los ficheros utilizados para el servidor raíz (Root). A continuación se estudiará la configuración del par de servidores maestro/esclavo: alfa/alfa2. Por último se detallarán los archivos utilizados en el tercer apartado de la práctica, que incluyen al servidor esclavo, con el fin de dar la visión más completa del escenario.

La configuración del resto de los servidores será análoga a la de la máquina alfa, puesto que todos ellos serán servidores primarios para su dominio.

  • Root:
Sus archivos de configuración se encuentran en /home/usuario/vnuml/dns/dns_conf/ns1/ns1.
  • named.conf
El archivo named.conf es una colección de declaraciones usando opciones anidadas rodeadas por caracteres de llaves, { }. Los administradores deben tener mucho cuidado cuando estén modificando named.conf para evitar errores sintácticos puesto que hasta el error más pequeño puede impedir que el servicio named arranque.
En primer lugar definimos el nombre del fichero y el dominio de autoridad del servidor de nombres en un comentario.
//
// Filename: 	named.conf
// Domain:	.
//
La declaración "options" define las opciones de configuración del servidor. En nuestro caso:
directory: define la localización del directorio de trabajo del servicio DNS (named).
port: define el puerto utilizado por el servicio.
pid-file: especifica la localización del fichero de identificador de proceso creado por named.
listen-on: especifica la interfaz de red en la named escucha solicitudes.
options {
         
        directory "/etc/bind";

	 port 53;

	 pid-file "named.pid";

	 listen-on { any; };

	 listen-on-v6 port 53 { any; };

	 notify yes;

};
Bind incluye la utilidad rndc para administración por línea de comandos. Para prevenir de accesos no autorizados al demonio named BIND utiliza un mecanismo de claves secretas compartidas. Esto implica que tanto en el fichero de configuración named.conf como en el fichero de configuración para rndc (rndc.conf) debe estar presente la misma clave (cadena de caracteres codificada en base64). Nuestra clave, cuyo nombre es rndc_key, se encuentra en el fichero rndc.key, por lo que debe referenciarse desde named.conf:
include "/etc/bind/rndc.key";
La declaración "controls" es necesaria para que rndc pueda conectarse al servidor named. En este caso se permite la entrada de comandos rndc desde el localhost:
controls {
  inet 127.0.0.1 allow { localhost; } keys { rndc_key; };
};
La declaración "zona" define la localización del archivo de configuración de la zona declarada y otras opciones específicas de zona. La estructura es la siguiente: zone "nombre_de_la_zona". Estas declaraciones son necesarias para resolución directa e inversa de los dominios sobre los que el servidor tiene autoridad o, en el caso de que el servidor no sea un servidor raíz, para indicar cómo contactar con el servidor raíz, cuando la consulta no se pueda resolver localmente.
Lo primero es declarar las zonas que resuelven el loopback, tanto para IPV4 como para IPV6:
//
// Inverse Resolution for IPv4 loopback
//
zone "1.0.0.127.in-addr.arpa" {
        type master;
        file "localhost";
};

//
// Inverse Resolution for IPv6 loopback
//
zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" {
        type master;
        file "localhost";
};
En el servidor raíz se realizan las siguientes declaraciones de zona: 
//
// Inverse Resolution for 0.0.0.0/0
//
zone "in-addr.arpa" {
        type master;
        file "db.in-addr.arpa";
};

//
// Inverse Resolution for ::/0
//
zone "ip6.arpa" {
       type master;
       file "db.ip6.arpa";
};

//
// Direct Resolution
//
zone "." {
	type master;
	file "root";
};
  • root
Los ficheros de zona contienen información de un espacio de nombres concreto. En este caso la información es sobre el dominio ".", la raíz del escenario.
En primer lugar definimos el nombre del fichero y el dominio de autoridad del servidor de nombres en un comentario.
;
; Domain:    .
; Filename:  root
;
Con la directiva TTL establecemos la cantidad del tiempo en que un registro de recurso de una zona es válido.
$TTL 300
Para declarar información autoritativa importante sobre un espacio de nombres utilizamos un registro SOA (Start Of Athority). Es el primer registro de recursos en un fichero de zona, definido tras las directivas.
@ 		IN 	SOA	ns.	hostmaster.ns. (
				1   		; serial
				3600         	; refresh (1hour)
				1800         	; retry (30 min)
				604800    	; expire (7 days)
	 			3600       	; minimum (1 hour)
				)
Definimos otros registros necesarios:
.		IN	NS	ns.
ns.		IN	A	10.1.1.1
ns.		IN	AAAA	2001:db8::1
Se indican los servidores de nombres con autoridad sobre los distintos subdominios de esta zona:
;
; Delegation of alfa subdomain
;	
alfa.		IN      NS	ns.alfa.
ns.alfa.	IN	A	10.1.1.2
ns.alfa.	IN	AAAA	2001:db8::2
alfa.		IN      NS	ns2.alfa.      ;también se delega al servidor esclavo    
ns2.alfa.	IN	A	10.1.1.12
ns2.alfa.	IN	AAAA	2001:db8::c

;
; Delegation of beta subdomain
;
beta.		IN      NS	ns.beta.
ns.beta.	IN	A	10.1.1.3
ns.beta.	IN	AAAA	2001:db8::3
  • db.in-addr.arpa
Este fichero de zona tiene la información necesaria para la resolución inversa en IPV4
En primer lugar definimos el nombre del fichero y el dominio de autoridad del servidor de nombres en un comentario.
;
; Domain:    .in-addr.arpa
;            Inverse resolution for prefix 0.0.0.0/0
; Filename:  db.in-addr.arpa
;
Con la directiva TTL establecemos la cantidad del tiempo en que un registro de recurso de una zona es válido.
$TTL    2d
Para declarar información autoritativa importante sobre un espacio de nombres utilizamos un registro SOA (Start Of Athority). Es el primer registro de recursos en un fichero de zona, definido tras las directivas.
@		IN	SOA	ns.	hostmaster.ns. (
				1 	; serial
				3H	; refresh (3 hours)
				15M	; retry   (15 min)
				1W	; expiry  (1 week)
				1D )	; minimum (1 day)
Definimos otros registros necesarios para todos los servidores de nombres:
;
		IN      NS      ns.      ; name server
;
; PTR records for name servers (addresses 10.1.1.X)
$ORIGIN 1.1.10.in-addr.arpa.
1          IN      PTR     ns.
2          IN      PTR     ns.alfa.
3          IN      PTR     ns.beta.
4          IN      PTR     ns.d1.alfa.
5          IN      PTR     ns.d2.alfa.
6          IN      PTR     ns.d1.beta.
7          IN      PTR     ns.d2.beta.
8          IN      PTR     ns.sd1.d1.alfa.
9          IN      PTR     ns.sd1.d2.alfa.
10         IN      PTR     ns.sd2.d2.alfa.
11         IN      PTR     ns.sd1.d2.beta.
12         IN      PTR     ns2.alfa.
Se indican los servidores de nombres con autoridad sobre los distintos subdominios de esta zona:
; Inverse prefix delegation of 10.0.0.0/8 to ALFA
10.in-addr.arpa.        	IN      NS      ns.alfa.
10.in-addr.arpa.        	IN      NS      ns2.alfa.      ;también se delega al servidor esclavo

; Inverse prefix delegation of 20.0.0.0/8 to BETA
20.in-addr.arpa.        	IN      NS      ns.beta.
Por último se declaran los hosts sobre los que este servidor de nombres tiene autoridad, acerca de los cuales podrá recibir solicitudes, puesto que conoce su información:
; Local hosts PTR records (under 30.0.0.0/8)
1.0.0.30		IN	PTR	h1.
2.0.0.30		IN	PTR	h2.
3.0.0.30		IN	PTR	h3.
  • db.ip6.arpa
Este fichero de zona tiene la información necesaria para la resolución inversa en IPV6
En primer lugar definimos el nombre del fichero y el dominio de autoridad del servidor de nombres en un comentario.
;
; Domain:    .ip6.arpa
;            Inverse resolution for prefix ::/0
; Filename:  db.ip6.arpa
;
Con la directiva TTL establecemos la cantidad del tiempo en que un registro de recurso de una zona es válido.
$TTL    2d
Para declarar información autoritativa importante sobre un espacio de nombres utilizamos un registro SOA (Start Of Athority). Es el primer registro de recursos en un fichero de zona, definido tras las directivas.
@		IN	SOA	ns.	hostmaster.ns. (
				1 	; serial
				3H	; refresh (3 hours)
				15M	; retry   (15 min)
				1W	; expiry  (1 week)
				1D )	; minimum (1 day)
Definimos otros registros necesarios para todos los servidores de nombres:
;
		IN      NS      ns.      ; name server

; PTR records for name servers (addresses 2001:db8::X)
$ORIGIN 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
1.0.0.0		IN	PTR	ns.
2.0.0.0		IN	PTR	ns.alfa.
3.0.0.0		IN	PTR	ns.beta.
4.0.0.0		IN	PTR	ns.d1.alfa.
5.0.0.0		IN	PTR	ns.d2.alfa.
6.0.0.0		IN	PTR	ns.d1.beta.
7.0.0.0		IN	PTR	ns.d2.beta.
8.0.0.0		IN	PTR	ns.sd1.d1.alfa.
9.0.0.0		IN	PTR	ns.sd1.d2.alfa.
a.0.0.0		IN	PTR	ns.sd2.d2.alfa.
b.0.0.0		IN	PTR	ns.sd1.d2.beta.
c.0.0.0		IN	PTR	ns2.alfa.
Se indican los servidores de nombres con autoridad sobre los distintos subdominios de esta zona:
; Inverse prefix delegation for ALFA (2001:db8::/32)
8.b.d.0.1.0.0.2.ip6.arpa.  IN      NS	ns.alfa.
8.b.d.0.1.0.0.2.ip6.arpa.  IN      NS	ns2.alfa.      ;también se delega al servidor esclavo

; Inverse prefix delegation for BETA (2002:db8::/32)
8.b.d.0.2.0.0.2.ip6.arpa.  IN      NS	ns.beta.
Por último se declaran los hosts sobre los que este servidor de nombres tiene autoridad, acerca de los cuales podrá recibir solicitudes, puesto que conoce su información:
;
; db.1.1.0.0.8.b.d.0.1.0.0.2.ip6.arpa. PTR records
; hosts under 2003:db8::/32
;
$ORIGIN 8.b.d.0.3.0.0.2.ip6.arpa.
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0		IN	PTR	h1.
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0		IN	PTR	h2.
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0		IN	PTR	h3.
  • localhost
Con el mismo formato que el resto de ficheros de zona, éste define la correspondencia entre la dirección del loopback y su nombre: "localhost"
;
; Domain:   0.0.127.in-addr.arpa
; 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa.
; Filename: localhost
;
; name        ttlclass  rr    name-server email-addr  (sn ref ret ex min)

$TTL    3600
@		IN	SOA	ns.	hostmaster.ns. (
				1 	; serial
				3H	; refresh (3 hours)
				15M	; retry   (15 min)
				1W	; expiry  (1 week)
				1D )	; minimum (1 day)
;
		IN      NS      ns.      ; name server
;
localhost.                      IN      A       127.0.0.1
1.0.0.127.in-addr.arpa.         IN      PTR     localhost.
;

localhost.                      IN      AAAA    ::1
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa.     IN      PTR	localhost.
;
  • rndc.conf
Este es el fichero de configuración necesario para permitir el uso de la utilidad rndc. En él debe figurar la misma clave que fue declarada en named.conf.
//
// Filename: 	rndc.conf
//

include "/etc/bind/rndc.key";

options {
     default-server 127.0.0.1;
     default-key    rndc_key;
};
  • rndc.key
Este fichero contiene la clave que deben incluir tanto named.conf como rndc.conf:
key rndc_key {
     algorithm "hmac-md5";
     secret "RXN0YSBlcyB1bmEgY2xhdmUgdmFsaWRhIGVuIEJhc2U2NCBwYXJhIGVsIEROUw==";
};
  • alfa:
Sus archivos de configuración se encuentran en /home/usuario/vnuml/dns/dns_conf/ns2/ns2.
  • named.conf
Sólo se describirán las declaraciones que difieran de las del archivo named.conf del servidor raíz.
//
// Filename: 	named.conf
// Domain:	alfa.
//

options {
        directory "/etc/bind";
	 port 53;
	 pid-file "named.pid";
	 listen-on { any; };
	 listen-on-v6 port 53 { any; };
	 notify yes;
};

include "/etc/bind/rndc.key";

controls {
  inet 127.0.0.1 allow { localhost; } keys { rndc_key; };
};

//
// Inverse Resolution for IPv4 loopback
//
zone "1.0.0.127.in-addr.arpa" {
        type master;
        file "localhost";
};
Las declaraciones de zona son las correspondientes a su posición en la jerarquía DNS (tanto para resolución inversa como directa).
//
// Inverse Resolution for IPv6 loopback
//
zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa"
{
        type master;
        file "localhost";
};


//
// Inverse Resolution for 10.0.0.0/8
//
zone "10.in-addr.arpa" {
        type master;
	 file "db.10.in-addr.arpa";
	 allow-transfer {
		10.1.1.12;     ;permite que el servidor esclavo realice transferencias de este fichero de zona
	 };
	 notify yes;
};

//
// Inverse Resolution for 2001:db8::/32
//
zone "8.b.d.0.1.0.0.2.ip6.arpa" {
        type master;
        file "db.8.b.d.0.1.0.0.2.ip6.arpa";
	 allow-transfer {
		10.1.1.12;     ;permite que el servidor esclavo realice transferencias de este fichero de zona
	 };
	 notify yes;
};


//
// Direct Resolution
//
zone "alfa" {
	 type master;
	 file "db.alfa";
	 allow-transfer {
		10.1.1.12;     ;permite que el servidor esclavo realice transferencias de este fichero de zona
	 };
	 notify yes;
};
La principal diferencia respecto a un servidor raíz está en la declaración de la zona ".". Cuando llega a un servidor de nombres una consulta DNS que no puede resolverse localmente, el servidor debe acudir al raíz para obtener las referencias de los servidores de nombres de los dominios de primer nivel. Por ello, en este caso el fichero de configuración "root.hint" contiene la información necesaria para encontrar al servidor raíz.
//
// Root hints
//
zone "." {
	 type hint;
	 file "root.hint";
};
  • root.hint
La información de este fichero se lee cuando una consulta no se puede resolver localmente. El fichero indica la ubicación del servidor raíz al que se debe acudir para hacer la primera consulta recursiva.
Su contenido es:
;
; root.hint
;

$TTL 999999
.			IN NS	ns.    
ns.      		IN A	10.1.1.1
ns.      		IN AAAA	2001:db8::1
  • db.alfa
Este fichero de zona recoge la información necesaria para la resolución directa del dominio alfa.
En primer lugar definimos el nombre del fichero y el dominio de autoridad del servidor de nombres en un comentario.
;
; Domain:    alfa.
; Filename:  db.alfa
;
Con la directiva TTL establecemos la cantidad del tiempo en que un registro de recurso de una zona es válido.
$TTL 60
Para declarar información autoritativa importante sobre un espacio de nombres utilizamos un registro SOA (Start Of Athority). Es el primer registro de recursos en un fichero de zona, definido tras las directivas.
@ 		IN 	SOA	ns.alfa. hotmaster.ns.alfa. (
				1   		; serial
				1M         	; refresh (1hour)
				1800         	; retry (30 min)
				604800    	; expire (7 days)
				3600       	; minimum (1 hour)
				)
Definimos otros registros necesarios, en este caso los correspondientes a los servidores de nombres con autoridad sobre este dominio (servidor maestro y esclavo):
alfa.		IN	NS	ns.alfa.            ; registros del servidor maestro
ns.alfa.		IN	A	10.1.1.2
ns.alfa.		IN	AAAA	2001:db8::2

alfa.		IN	NS	ns2.alfa.            ; registros del servidor esclavo
ns2.alfa.		IN	A	10.1.1.12
ns2.alfa.		IN	AAAA	2001:db8::c
Se indican los servidores de nombres con autoridad sobre los distintos subdominios de esta zona:
;
; Delegation of d1.alfa. subdomain
;
d1.alfa.		IN      NS	ns.d1.alfa.
ns.d1.alfa.	IN	A	10.1.1.4
ns.d1.alfa.	IN	AAAA	2001:db8::4

;
; Delegation of d2.alfa. subdomain
;
d2.alfa.		IN      NS	ns.d2.alfa.
ns.d2.alfa.	IN	A	10.1.1.5
ns.d2.alfa.	IN	AAAA	2001:db8::5


Por último se declaran los hosts sobre los que este servidor de nombres tiene autoridad, acerca de los cuales podrá recibir solicitudes, puesto que conoce su información:
;
; Host DNS records under alfa.
;
h1.alfa.	IN	A	10.13.0.1
      	IN	AAAA	2001:db8:13::1
h2.alfa.	IN	A	10.13.0.2
      	IN	AAAA	2001:db8:13::2
h3.alfa.	IN	A	10.13.0.3
      	IN	AAAA	2001:db8:13::3
  • db.10.in-addr.arpa
Este fichero de zona recoge la información necesaria para la resolución inversa del dominio 10.in-addr.arpa (IPV4).
En primer lugar definimos el nombre del fichero y el dominio de autoridad del servidor de nombres en un comentario.
;
; Domain:    10.in-addr.arpa
; Filename:  db.10.in-addr.arpa
;
Con la directiva TTL establecemos la cantidad del tiempo en que un registro de recurso de una zona es válido.
$TTL    2d
Para declarar información autoritativa importante sobre un espacio de nombres utilizamos un registro SOA (Start Of Athority). Es el primer registro de recursos en un fichero de zona, definido tras las directivas.
@       	IN      SOA     ns.alfa.   hostmaster.ns.alfa. (
				1 	; serial
				3H	; refresh (3 hours)
				15M	; retry   (15 min)
				1W	; expiry  (1 week)
				1D )	; minimum (1 day)
Definimos otros registros necesarios, en este caso los correspondientes a los servidores de nombres con autoridad sobre este dominio (servidor maestro y esclavo):
;
		IN      NS      ns.alfa.            ; registro del servidor maestro
		IN      NS      ns2.alfa.            ; registro del servidor esclavo
Se indican los servidores de nombres con autoridad sobre los distintos subdominios de esta zona:
; Delegation of 10.1.0.0/16 to D1.ALFA
1.10.in-addr.arpa.        	IN      NS      ns.d1.alfa.

; Delegation of 10.2.0.0/16 to D2.ALFA
2.10.in-addr.arpa.        	IN      NS      ns.d2.alfa.
Por último se declaran los hosts sobre los que este servidor de nombres tiene autoridad, acerca de los cuales podrá recibir solicitudes, puesto que conoce su información:
;
; db.10.in-addr.arpa PTR records
; Local hosts PTR records (under 10.0.0.0/8)
1.0.13		IN	PTR	h1.alfa.
2.0.13		IN	PTR	h2.alfa.
3.0.13		IN	PTR	h3.alfa.
  • db.8.b.d.0.1.0.0.2.ip6.arpa
Este fichero de zona recoge la información necesaria para la resolución inversa del dominio 8.b.d.0.1.0.0.2.ip6.arpa (IPV6).
En primer lugar definimos el nombre del fichero y el dominio de autoridad del servidor de nombres en un comentario.
;
; Domain:    8.b.d.0.1.0.0.2.ip6.arpa
;            Inverse resolution for prefix 2001:db8::/32
; Filename:  db.8.b.d.0.1.0.0.2.ip6.arpa
;
Con la directiva TTL establecemos la cantidad del tiempo en que un registro de recurso de una zona es válido.
$TTL    2d
Para declarar información autoritativa importante sobre un espacio de nombres utilizamos un registro SOA (Start Of Athority). Es el primer registro de recursos en un fichero de zona, definido tras las directivas.
@       	IN      SOA     ns.alfa.   hostmaster.ns.alfa. (
				1 	; serial
				3H	; refresh (3 hours)
				15M	; retry   (15 min)
				1W	; expiry  (1 week)
				1D )	; minimum (1 day)
Definimos otros registros necesarios, en este caso los correspondientes a los servidores de nombres con autoridad sobre este dominio (servidor maestro y esclavo):
;
		IN      NS      ns.alfa.            ; registro del servidor maestro
		IN      NS      ns2.alfa.            ; registros del servidor esclavo
Se indican los servidores de nombres con autoridad sobre los distintos subdominios de esta zona:
; Delegation of 2001:db8:1::/48 to D1.ALFA
1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.  IN      NS      ns.d1.alfa. 

; Delegation of 2001:db8:2::/48 to D2.ALFA
2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.  IN      NS      ns.d2.alfa.
Por último se declaran los hosts sobre los que este servidor de nombres tiene autoridad, acerca de los cuales podrá recibir solicitudes, puesto que conoce su información:
;
; db.8.b.d.0.1.0.0.2.ip6.arpa. PTR records
; Local hosts PTR records (under 2001:db8::/32)
;

1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.0.0.0	IN	PTR	h1.alfa.
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.0.0.0	IN	PTR	h2.alfa.
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.0.0.0	IN	PTR	h3.alfa.
  • localhost
Este fichero es el mismo para cualquier servidor de nombres.
  • rndc.conf
Este fichero es el mismo para cualquier servidor de nombres.
  • rndc.key
Este fichero es el mismo para cualquier servidor de nombres.
  • alfa2:
Sus archivos de configuración se encuentran en /home/usuario/vnuml/dns/dns_conf/ns1/ns1.
  • named.conf
Sólo se describirán las declaraciones que difieran de las del archivo named.conf del servidor maestro.
//
// Filename: 	named.conf
// Domain:	alfa.
//

options {
        directory "/etc/bind";
	port 53;
	pid-file "named.pid";
	listen-on { any; };
	listen-on-v6 port 53 { any; };
	notify yes;
};

include "/etc/bind/rndc.key";

controls {
  inet 127.0.0.1 allow { localhost; } keys { rndc_key; };
};

//
// Inverse Resolution for IPv4 loopback
//
zone "1.0.0.127.in-addr.arpa" {
        type master;
        file "localhost";
};

//
// Inverse Resolution for IPv6 loopback
//
zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa"
{
        type master;
        file "localhost";
};
En las zonas en las que éste es el servidor esclavo se indicará con la opción "type slave", y se declararán sus servidores maestros (en este caso sólo hay uno).
//
// Inverse Resolution for 10.0.0.0/8
//
zone "10.in-addr.arpa" {
        type slave;
	 masters { 10.1.1.2; } ;
        file "db.10.in-addr.arpa";
};

//
// Inverse Resolution for 2001:db8::/32
//
zone "8.b.d.0.1.0.0.2.ip6.arpa" {
        type slave;
	 masters { 10.1.1.2; } ;
        file "db.8.b.d.0.1.0.0.2.ip6.arpa";
};


//
// Direct Resolution
//
zone "alfa" {
	type slave;
	masters { 10.1.1.2; } ;
	file "db.alfa";
};


//
// Root hints
//
zone "." {
	type hint;
	file "root.hint";
};
NOTA: Para declarar un servidor esclavo también es necesario añadir en el servidor que esté por encima en la jerarquía (en este caso el raíz), una delegación a ellos también. Además, en los ficheros de zona compartidos entre servidor maestro y esclavo deben declararse los registros de ambos.
  • root.hint
Este fichero es el mismo para cualquier servidor de nombres que no sea el servidor raíz.
  • localhost
Este fichero es el mismo para cualquier servidor de nombres.
  • rndc.conf
Este fichero es el mismo para cualquier servidor de nombres.
  • rndc.key
Este fichero es el mismo para cualquier servidor de nombres.
  • El resto de ficheros de zona se cargarán automáticamente al arrancar en primer lugar el servidor maestro y a continuación el servidor esclavo. Las posibles modificaciones en los ficheros de zona en el servidor maestro se verán reflejadas también automáticamente en el servidor esclavo.
  • Para el resto servidores bastará con sustituir las declaraciones de las distintas zonas por las suyas propias, indicando además las delegaciones a subdominios, pero las estructura de ficheros es la misma. Nótese que solamente el nombre de los ficheros de zona varía dependiendo del servidor.

Parada de todos los servidores de nombres

Existe la posibilidad de parar el servicio named en todos los servidores de nombres, con el objeto de poder empezar de nuevo la práctica sin necesidad de reiniciar el escenario. De esta forma, si observa algún funcionamiento anómalo tras alguna prueba, podrá comenzar desde el principio escribiendo en su host: 

root@host:/home/usuario/vnuml/dns# vnumlparser.pl -x stop@dns.xml -v

Para ello se añade una nueva secuencia de comandos en cada máquina virtual: 

<exec seq="stop" type="verbatim">killall named</exec>

Otras configuraciones

A partir de la configuración aquí detallada puede estudiar otras funcionalidades añadiendo nuevas opciones a los archivos de configuración correspondientes. Para ello puede serle de ayuda el siguiente enlace: [1]

Otras fuentes se indican en el apartado: Escenario dns > dns: Configuración > dns: Fuentes

Obtenido de «https://web.dit.upm.es/educaredeswiki/index.php?title=Dns-infoadicional&oldid=27»