Guion Bind9

GUÍA PARA LAS ACTIVIDADES SOBRE EL SERVIDOR DNS BIND 9
Lo primero es modificar el archivo resolv.conf de los clientes. Allí escribiremos lo siguiente:
domain mydominio.com
nameserver a.b.c.d ;; donde a.b.c.d es la ip de nuestra DNS.
NOTA: Si estamos en Windows debemos cambiar la configuración de red y agregar también estos datos.
Los archivos de configuración que tendremos que modificar en el servidor DNS son los siguientes:
• /etc/bind/named.conf
• /etc/bind/named.conf.options
• /etc/bind/named.conf.local
• /etc/bind/db.midominio.com
• /etc/bind/db.192.168.1
NOTA: cambia midominio por el nombre de dominio real
El fichero principal es el llamado named.conf que llama al resto de ellos, y es en éste donde
nosotros tomaremos el control creando otros ficheros para establecer nuestra configuración local,
por lo que comenzaremos por editar el fichero named.conf. El contenido debe ser el siguiente:
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.defaultzones";
En realidad lo que hacemos es distribuir las diferentes configuraciones por diferentes ficheros, para
organizar mejor la configuración, y que sea más comprensible (aunque al principio parezca lo
contrario).
Named.conf.options: contiene la configuración del demonio named.
Named.conf.local: contiene la configuración de las zonas.
Named.conf.defaultzones: contiene la configuración de zonas por defecto, como las raíces o el
host local.
En named.conf.local, declararemos la zona directa de nuestro dominio ‘midominio.com’ y su zona
inversa (para resolver el nombre de dominio a partir de una IP). Así pues el script de configuración
que llamaremos “named.conf.local” debe quedar como sigue:
zone "midominio.com" {
type master;
file "/etc/bind/db.midominio";
};
// Zona inversa DNS
zone "1.168.192.inaddr.arpa" {
type master;
file "/etc/bind/zones/db.192";
};
Como podemos ver, hemos definido el fichero db.midominio.com para escribir en él la
configuración de la zona. Debemos indicar el TTL, el inicio de autoridad y los registros de recurso
de la zona. Su contenido debería quedar como lo siguiente:
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.midominio.com. root.localhost. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.midominio.com.
@ IN NS ns2.midominio.com.
ns1 IN A 192.168.1.250
ns2 IN A 192.168.1.251
@ IN A 192.168.1.250
@ IN MX 10 midominio.com.
www IN A 192.168.1.250
ftp IN CNAME www
// Cambia las direcciones IP y los nombres para cada una
// de las máquinas locales que tengas en la red local.
pc1 IN A 192.168.1.10
pc2 IN A 192.168.0.11
pc3 IN A 192.168.0.12
En el fichero “named.conf.local” habíamos definimos la zona directa del dominio y su zona inversa,
hemos configurado la zona directa del dominio, por lo que ahora es el turno de la zona inversa.
Vamos a crear el fichero “db.192″. Su contenido debe quedar como sigue:
;
; BIND reverse data file for local loopback interface
;
$TTL 604800 ; Absolute TTL
@ IN SOA midominio.com. root.midominio.com. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.mydominio.com.
250.0.168 IN PTR ns1.mydominio.com.
El significado de los parámetros del RR SOA es el siguiente:
Absolute TTL: Es el tiempo que el fichero de zona se da por bueno (no caducado). Una vez transcurrido este tiempo, el
servidor esclavo debe volver a solicitar la transferencia de zona.
Serial: es un identificador del archivo, puede tener un valor arbitrario pero se recomienda que tenga la fecha con una
estructura AAAAMMDD y un consecutivo.
Refresh: número de segundos que un servidor de nombres secundario debe esperar para comprobar de nuevo los
valores de un registro.
Retry: número de segundos que un servidor de nombres secundario debe esperar después de un intento fallido de
recuperación de datos del servidor primario.
Expire: Cantidad de tiempo que un esclavo debería intentar contactar con el maestro antes de que los datos que
contiene caduquen. Indica el tiempo que el servidor DNS puede manejar los datos caducados.
Negative Cache TTL: Significa Time To Live y es el número de segundos por defecto que los RR que no especifican
su propio ttl, se mantienen activos en los servidores NS caché antes de volver a preguntar su valor real.
Y nos queda configurar Bind propiamente dicho, en named.conf.options
options {
directory "/var/cache/bind";
forwarders {
1.2.3.4;
1.2.3.4;
};
authnxdomain no; # conform to RFC1035
listenonv6 { any; };
};
Esta es una configuración muy básica. Sin embargo, hay muchas configuraciones adicionales que se
pueden hacer.
PLANTILLAS PARA ACTIVIDADES
CASO1: El servidor ns1.ejemplo.com (maestro) hace transferencias de zona a
ns2.ejemplo.com (esclavo).
ns1.ejemplo.com → 192.168.1.250
ns2.ejemplo.com → 192.168.1.251
www.ejemplo.com → 192.168.1.2
pc.ejemplo.com → 192.168.1.3
SERVIDOR MAESTRO: ns1.ejemplo.com
named.conf.local
zone "ejemplo.com" {
type master;
file "/etc/bind/db.ejemplo.com";
};
type master;
file "/etc/bind/db.192.168.1";
};
named.conf.options
options {
forwarders {
80.58.32.33;
80.58.0.33;
};
allowtransfer { 192.168.1.251; }; # Permitir las transferencias de zona al serv. DNS esclavo.
};
db.ejemplo.com
$TTL 604800
@ IN SOA ns1.ejemplo.com. root.localhost. (
2
604800
86400
2419200
604800 )
NS ns1.ejemplo.com.
NS ns2.ejemplo.com. ;; servidor esclavo.
ns1 IN A 192.168.1.250
ns2 IN A 192.168.1.251
www IN A 192.168.1.2
pc IN A 192.168.1.3
db.192.168
$TTL 604800
1
604800
86400
2419200
604800 )
250 IN NS ns1.ejemplo.com.
2 IN PTR www.ejemplo.com.
3 IN PTR pc.ejemplo.com.
SERVIDOR ESCLAVO: ns2.dominio.com
named.conf.local
zone "ejemplo.com” {
type slave;
file "sec.ejemplo.com";
masters { 192.168.1.250; }; // IP DEL SERVIDOR PRIMARIO / MAESTRO
};
zone "168.192.inaddr.arpa" {
type slave
file "sec.192.168.1";
masters { 192.168.1.250;};
};
Para comprobar la transferencia de zona, se puede probar con el suguiente comando ejecutado en el
servidor esclavo:
dig @192.168.1.250 ejemplo.com axfr
Si todo es correcto, se realizará la transferencia de zona.
Además es conveniente consultar el fichero /var/log/syslog, donde bind vuelca sus logs.
CASO 2: El servidor ns1.ejemplo.com realiza una delegación de autoridad sobre el
subdominio subdominio.ejemplo.com al servidor ns2.subdominio.ejemplo.com.
ns1.ejemplo.com → 192.168.1.250
ns2.subdominio.ejemplo.com → 192.168.1.251
www.ejemplo.com → 192.168.1.2
www.subdominio.ejemplo.com → 192.168.1.3
SERVIDOR AUTORITATIVO EN ejemplo.com: ns1.ejemplo.com
named.conf.local
zone "ejemplo.com" {
type master;
file "/etc/bind/db.ejemplo.com";
};
type master;
};
named.conf.options
options {
forwarders {
80.58.32.33;
80.58.0.33;
};
};
db.ejemplo.com
$TTL 604800
2
604800
86400
2419200
604800 )
@ IN NS ns1.ejemplo.com.
subdominio.ejemplo.com. IN NS ns2.subdominio.ejemplo.com.
ns1 IN A 192.168.1.250
ns2.subdominio.ejemplo.com. IN A 192.168.1.251
www IN A 192.168.1.2
# En la primera línea resaltada, definimos la delegación de autoridad de zona. Decimos que sobre el
# dominio subdominio.ejemplo.com es autoritativo el servidor DNS ns2.subdominio.ejemplo.com.
#
#En la segunda línea resaltada, decimos cuál es la IP de dicho servidor DNS.
db.192.168.1
$TTL 604800
1
604800
86400
2419200
604800 )
2 IN PTR www.ejemplo.com.
SERVIDOR DELEGADO: ns2.subdominio.ejemplo.com
named.conf.local
zone "subdominio.ejemplo.com" {
type master;
file "/etc/bind/db.subdominio.ejemplo.com";
};
zone "168.192.inaddr.arpa" {
type master;
};
named.conf.options
options {
forwarders {
192.168.1.250; # Muy importante para subir al servidor autoritativo en el
# dominio padre las consultas no resueltas
};
};
db.ejemplo.com
$TTL 604800
@ IN SOA ns2.subdominio.ejemplo.com. root.localhost. (
2
604800
86400
2419200
604800 )
NS ns2.subdominio.ejemplo.com.
ns2 IN A 192.168.1.251
www IN A 192.168.1.3
ACTIVIDADES CON BIND 9
NOTA SOBRE LAS ACTIVIDADES:
– Debes entregar los ficheros de bind que hayas modificado.
– Para cada ejercicio utilizarás una carpeta diferente. Las carpetas se llamarán
“Actividad básica”, “Maestro esclavo” y “Delegación de autoridad”.
– Como mínimo debes realizar la actividad básica.
– Además de los ficheros de configuración, debes mostrar las pruebas de resolución que
hagas, ya sea mediante el uso de ping o de dig.
– Comandos que pueden serte útiles para las pruebas. Supón el dominio 1asi.com
$ rndc reload 1asi.com // recarga de nuevo el dominio sin reiniciar el servidor.
$ dig 1asi.com // recupera el registro de recurso relativo a la máquina 1asi.com
$ dig x www.1asi.com // hace resolución inversa para el host www.
$ dig @192.168.1.1 www.1asi.com // recupera el registro de recurso relativo al host www del
// dominio 1asi.com, preguntando al servidor DNS en
// 192.168.1.1
Rndc:
$ rndc reload 1asi.com // recarga el dominio sin parar el servidor.
$ rndc retransfer 1asi.com // fuerza transferencia de zona aunque no haya cambio de serial.
1. Actividad básica.
1. Inventa un nombre de dominio y un subdominio.
2. Configura en una máquina virtual un servidor DNS bind9 como servidor primario del
dominio padre.
1. Define la zona.
2. Configura la zona de búsqueda directa, creando al menos un registro de tipo SOA, NS, A
y CNAME.
1. TTL absoluto: 12 horas.
2. Parámetros del registro SOA:
▪ Serial: número que indica año, més, día, hora y minuto.
▪ Refresco cada hora
▪ Reintentos cada media hora
▪ Los datos expiran en un día
▪ El TTL por defecto de los RR es de 12 horas.
3. Utiliza un RR de tipo A para definir el host www que apunta a tu máquina física.
4. Utiliza un RR de tipo NS para definir al servidor ns1
5. Utiliza un RR de tipo CNAME para definir el host ssh que apunta a www
3. Configura la zona de búsqueda inversa, creando un RR de tipo PTR para los host
definidos anteriormente, esto es, ns1, www y ssh.
3. Reinicia BIND. Configura tu máquina para que utilice la DNS que has configurado.
4. Comprueba que las consultas se resuelven correctamente.
2. Actividad avanzada 1.
1. Con otro compañero que ya haya acabado la actividad inicial, inventa un nombre de
dominio.
2. Crea una configuración maestro esclavo para un cierto dominio que os inventeis.
1. Uno de los servidores será el maestro. Se llamará ns1.
1. Define la zona en named.conf.local.
2. Crea el fichero de zona.
2. El otro servidor será esclavo. Se llamará ns2.
1. Define la zona (como esclavo) en named.conf.local.
3. Comprueba que se realizan las transferencias de zona. Para ello, puedes ubicarte en el
servidor esclavo y ejecutar el comando siguiente:
dig @<ipdnsmaestro> <nombredominio> axfr
si todo es correcto, podrás ver los RR volcados en pantalla. En caso contrario, verás
“Transfer failed”.
3. Realiza pruebas de resolución de nombres mediante ping empleando uno y otro servidor.
3. Actividad avanzada 2.
1. Con otro compañero que ya haya acabado la actividad avanzada 1, inventa un nombre de
dominio y un subdominio.
2. Uno de los servidores será llamado ns1, y será el servidor raíz del dominio.
3. El otro servidor, será llamado ns2, y será el servidor autoritativo del subdominio.
4. Crea una delecación de autoridad del servidor ns1 sobre el servidor ns2 para el subdominio.
5. Realiza pruebas de resolución de nombres en uno y otro subdominio. El cliente puede estar
usando tanto uno y otro servidor sin problemas.

Guion Bind9

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Guion Bind9

Diunggah oleh

Hak Cipta:

Format Tersedia

GUÍA PARA LAS ACTIVIDADES SOBRE EL SERVIDOR DNS BIND 9

Anda mungkin juga menyukai