Servidor DNS bind9 debian wheezy

Introducción

En esta ocasión resuelvo los siguientes ejercicios sobre montar un servidor DNS en debian : http://josedom24.github.io/mod/serviciosgs/e_dns_8

Procedimiento

1. Instala el servidor dns dnsmasq en pandora.iesgn.org y configúralo para que los clientes puedan conocer los nombres necesarios.

Instalamos dnsmasq en la máquina pandora:

apt-get install dnsmasq

Editamos el fichero «/etc/dnsmasq.conf« y hacemos las siguiente modificaciones:

– Descomentamos la linea «strict-order« , con esto conseguimos que las peticiones DNS se realicen a los servidores que aparecen en el fichero «/etc/resolv.conf«.

– Descomentamos la linea «address« ¡ y añadimos la siguiente información:

address=/www.iesgn.org/10.0.0.50
address=/departamento.iesgn.org/10.0.0.50

Incluimos las interfaces de red que deben aceptar peticiones DNS:

interface=eth0

Incluimos direcciones IP que aceptan peticiones DNS:

listen-address=10.0.0.50
listen-address=127.0.0.1

Ahora procedemos a modificar el fichero «/etc/resolv.conf« y añadimos la linea «nameserver 10.0.0.50«, el fichero debe quedar así:

# Generated by NetworkManager
domain home
search home
nameserver 10.0.0.50

Modifica los clientes para que utilicen el nuevo servidor dns.

Modificamos el fichero «/etc/resolv.conf« de los clientes para que usen el servidor dns creado en pandora.

# Generated by NetworkManager
 domain home
 search home
 nameserver 127.0.0.1
 nameserver 10.0.0.50

En el cliente windows cambiamos la configuración de tal forma que quede así:

Realiza una consulta a www.iesgn.org, y a www.josedomingo.org.

Desde el cliente debian hacemos las consultas correspondientes, consulta a «www.josedomingo.org»:

root@debian:~# dig www.josedomingo.org
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> www.josedomingo.org

;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60401
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.josedomingo.org. IN A

;; ANSWER SECTION:
www.josedomingo.org. 101 IN A 134.0.11.146

;; Query time: 1 msec
;; SERVER: 10.0.0.50#53(10.0.0.50)
;; WHEN: Thu Nov 20 12:41:48 2014
;; MSG SIZE rcvd: 53

Consulta a «www.iesgn.org»:

root@debian:~# dig www.iesgn.org

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> www.iesgn.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22431
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.iesgn.org. IN A

;; ANSWER SECTION:
www.iesgn.org. 0 IN A 10.0.0.50

;; Query time: 4 msec
;; SERVER: 10.0.0.50#53(10.0.0.50)
;; WHEN: Thu Nov 20 12:42:17 2014
;; MSG SIZE rcvd: 47

Hacemos las mismas consultas desde el cliente windows xp:

EL servidor dns funciona correctamente.

Realiza una prueba de funcionamiento para comprobar que el servidor dnsmasq funciona como cache dns.

Para comprobar que el servidor dns funciona como cache hacemos una consulta a una dirección que no se haya resuelto, por ejemplo la web de spotify:

root@debian:~# dig www.spotify.com

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> www.spotify.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8709
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;www.spotify.com. IN A

;; ANSWER SECTION:
www.spotify.com. 300 IN CNAME lon.weblb.gslb.spotify.com.
lon.weblb.gslb.spotify.com. 180 IN A 194.132.198.244
lon.weblb.gslb.spotify.com. 180 IN A 194.132.196.178
lon.weblb.gslb.spotify.com. 180 IN A 194.132.198.115

;; AUTHORITY SECTION:
gslb.spotify.com. 900 IN NS ns3.p23.dynect.net.
gslb.spotify.com. 900 IN NS ns4.p23.dynect.net.
gslb.spotify.com. 900 IN NS ns1.p23.dynect.net.
gslb.spotify.com. 900 IN NS ns2.p23.dynect.net.

;; ADDITIONAL SECTION:
ns1.p23.dynect.net. 170240 IN A 208.78.70.23
ns2.p23.dynect.net. 170240 IN A 204.13.250.23
ns3.p23.dynect.net. 170240 IN A 208.78.71.23
ns4.p23.dynect.net. 170240 IN A 204.13.251.23

;; Query time: 302 msec
;; SERVER: 10.0.0.50#53(10.0.0.50)
;; WHEN: Thu Nov 20 12:52:31 2014
;; MSG SIZE rcvd: 260

Tras hacer la primera consulta comprobamos que el tiempo de respuesta ha sido de 302 msec. Ahora realizamos la consulta de nuevo:

root@debian:~# dig www.spotify.com

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> www.spotify.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5080
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.spotify.com. IN A

;; ANSWER SECTION:
www.spotify.com. 226 IN CNAME lon.weblb.gslb.spotify.com.
lon.weblb.gslb.spotify.com. 106 IN A 194.132.198.115
lon.weblb.gslb.spotify.com. 106 IN A 194.132.196.178
lon.weblb.gslb.spotify.com. 106 IN A 194.132.198.244

;; Query time: 5 msec
;; SERVER: 10.0.0.50#53(10.0.0.50)
;; WHEN: Thu Nov 20 12:53:45 2014
;; MSG SIZE rcvd: 121

Tras hacer la segunda consulta comprobamos que el tiempo de respuesta ha sido de 5msec, por lo que el servidor dns funciona como caché.

2. Desinstala el servidor dnsmasq del ejercicio anterior e instala un servidor dns bind9. Las características del servidor DNS que queremos instalar son las siguientes:

Desinstalamos el servicio dnsmasq en la máquina «pandora«:

aptitude purge dnsmasq

Instalamos el servidor dns «bind9«:

aptitude install bind9

Ya tenemos instalado el servidor dns «bind9«, ahora procedemos a configurarlo.

El servidor DNS se llama pandora.iesgn.org y por supuesto, va a ser el servidor con autoridad para la zona iesgn.org..

Para crear las zonas de resolución vamos al directorio «/etc/bind« y modificamos el archivo «named.conf.local«, añadimos lo siguiente:

include "/etc/bind/zones.rfc1918";

zone "iesgn.org"{
type master;
file "db.iesgn.org;
};

zone "0.0.10.in-addr.arpa" {
type master;
file "db.10.0.0";
};

Una vez configurado el fichero procedemos a modificar el fichero «zones.rfc1918» para que las consultas DNS a direcciones IP privadas se responda con localhost, salvo para la dirección de red «10.0.0.0/24«, para ello debemos comentar la linea referida a dicha dirección de red:
El fichero tendrá el siguiente contenido:

//zone "10.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };

zone "16.172.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };
zone "17.172.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };
zone "18.172.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };
zone "19.172.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };
zone "20.172.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };
zone "21.172.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };
zone "22.172.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };
zone "23.172.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };
zone "24.172.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };
zone "25.172.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };
zone "26.172.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };
zone "27.172.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };
zone "28.172.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };
zone "29.172.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };
zone "30.172.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };
zone "31.172.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };

zone "168.192.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };

A continuación creamos los archivos indicados en el fichero «named.conf.local» modificado anteriormente. Para ello vamos al directorio «/var/cache/bind« y creamos dichos ficheros. Una vez creados cambiamos el propietario y sus permisos, para ello:

chown bind:bind /var/cache/bind/db.*
chmod 660 /var/cache/bind/db.*

Vamos a configurar la zona directa del servidor dns, para ello modificamos el fichero creado «db.iesgn.org» y le introducimos el siguiente contenido:

$ORIGIN iesgn.org.
$TTL 86400 ; 1 day
@       IN      SOA      pandora.iesgn.org.      admin.iesgn.org. (
        1 ; serial
        21600 ; refresh (6 hours)
        3600 ; retry (1 hour)
        604800 ; expire (1 week)
        21600 ; minimum (6 hours)
)
@            IN      NS      pandora.iesgn.org.
pandora      IN      A       10.0.0.50

Vamos a suponer que tenemos un servidor para recibir los correos que se llame correo.iesgn.org y que está en la dirección x.x.x.200 (esto es ficticio).

Para añadir el servidor de correo «correo.iesgn.org» añadimos estas 2 lineas al fichero creado:

iesgn.org.   IN      MX      10      correo.iesgn.org.
correo       IN      A       10.0.0.200

Vamos a suponer que tenemos un servidor ftp que se llame ftp.iesgn.org y que está en x.x.x.201 (esto es ficticio)

Para añadir el servidor ftp «ftp.iesgn.org» agregamos esta linea:

ftp          IN      A       10.0.0.201

Además queremos nombrar a los clientes.

Ahora nombramos a los clientes (asterix=cliente xp) , (obelix=cliente linux), añadimos esto:

asterix      IN      A      10.0.0.40
obelix       IN      A     10.0.0.20

También hay que nombrar a los virtual hosts de apache: www.iesgn.org y departementos.iesgn.org

Para nombrar los virtualhosts de apache añadimos lo siguiente:

www          IN      CNAME      pandora.iesgn.org.
departamento IN      CNAME      pandora.iesgn.org.

El fichero de resolución directa tendrá el siguiente contenido una vez configurado completamente:

$ORIGIN iesgn.org.
$TTL 86400 ; 1 day
@       IN      SOA       pandora.iesgn.org.       admin.iesgn.org. (
        1 ; serial
        21600 ; refresh (6 hours)
        3600 ; retry (1 hour)
        604800 ; expire (1 week)
        21600 ; minimum (6 hours)
)
@               IN       NS       pandora.iesgn.org.
pandora         IN       A        10.0.0.50

iesgn.org.      IN       MX       10 correo.iesgn.org.
correo          IN       A        10.0.0.200

ftp             IN       A        10.0.0.201
asterix         IN       A        10.0.0.40
obelix          IN       A        10.0.0.20

www             IN       CNAME    pandora.iesgn.org.
departamento    IN       CNAME    pandora.iesgn.org.

Se tienen que configurar la zona de resolución inversa.

Para configurar la zona inversa del servidor dns modificamos el fichero «db.10.0.0» e introducimos el siguiente contenido:

$ORIGIN 0.0.10.in-addr.arpa.
$TTL 86400 ; 1 day
@       IN      SOA     pandora.iesgn.org.      admin.iesgn.org. (
        1 ; serial
        21600 ; refresh (6 hours)
        3600 ; retry (1 hour)
        604800 ; expire (1 week)
        21600 ; minimum (6 hours)
)
@       IN      NS      pandora.iesgn.org.
50      IN      PTR     pandora.iesgn.org.
200     IN      PTR     correo.iesgn.org.
201     IN      PTR     ftp.iesgn.org.
40      IN      PTR     asterix.iesgn.org.
20      IN      PTR     obelix.iesgn.org.

Ahora modificamos el fichero «/etc/bind/named.conf.options« y en el apartado forwarders añadimos la IP del servidor dns de nuestro proveedor de internet (en mi caso añado la dirección del servidor DNS de mi casa). Esta directiva le indica a nuestro servidor que pase a otro servidor de nombres todas las peticiones para las cuales no es el autorizado o no tiene la respuesta en caché. En el caso de no especificarlos, se usarán los servidores raíz de DNS.

 forwarders {
         62.81.16.148;
 };

Realiza las consultas dig/neslookup desde los clientes preguntando por los siguientes:

Consultas desde el cliente debian:

Dirección de pandora.iesgn.org, www.iesgn.org, ftp.iesgn.org

Consulta a «pandora.iesgn.org»:

root@debian:~# dig pandora.iesgn.org

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> pandora.iesgn.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65440
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;pandora.iesgn.org. IN A

;; ANSWER SECTION:
pandora.iesgn.org. 86400 IN A 10.0.0.50

;; AUTHORITY SECTION:
iesgn.org. 86400 IN NS pandora.iesgn.org.

;; Query time: 1 msec
;; SERVER: 10.0.0.50#53(10.0.0.50)
;; WHEN: Sun Nov 23 17:18:07 2014
;; MSG SIZE rcvd: 65

Consulta a «www.iesgn.org»:

root@debian:~# dig www.iesgn.org

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> www.iesgn.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35917
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;www.iesgn.org. IN A

;; ANSWER SECTION:
www.iesgn.org. 86400 IN CNAME pandora.iesgn.org.
pandora.iesgn.org. 86400 IN A 10.0.0.50

;; AUTHORITY SECTION:
iesgn.org. 86400 IN NS pandora.iesgn.org.

;; Query time: 1 msec
;; SERVER: 10.0.0.50#53(10.0.0.50)
;; WHEN: Sun Nov 23 17:18:44 2014
;; MSG SIZE rcvd: 8

Consulta a «ftp.iesgn.org»:

root@debian:~# dig ftp.iesgn.org

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> ftp.iesgn.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29762
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;ftp.iesgn.org. IN A

;; ANSWER SECTION:
ftp.iesgn.org. 86400 IN A 10.0.0.201

;; AUTHORITY SECTION:
iesgn.org. 86400 IN NS pandora.iesgn.org.

;; ADDITIONAL SECTION:
pandora.iesgn.org. 86400 IN A 10.0.0.50

;; Query time: 1 msec
;; SERVER: 10.0.0.50#53(10.0.0.50)
;; WHEN: Sun Nov 23 17:19:11 2014
;; MSG SIZE rcvd: 85

El servidor DNS con autoridad sobre la zona del dominio iesgn.org

root@debian:~# dig -t soa iesgn.org

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> -t soa iesgn.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61256
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;iesgn.org. IN SOA

;; ANSWER SECTION:
iesgn.org. 86400 IN SOA pandora.iesgn.org. admin.iesgn.org. 1 21600 3600 604800 21600

;; AUTHORITY SECTION:
iesgn.org. 86400 IN NS pandora.iesgn.org.

;; ADDITIONAL SECTION:
pandora.iesgn.org. 86400 IN A 10.0.0.50

;; Query time: 4 msec
;; SERVER: 10.0.0.50#53(10.0.0.50)
;; WHEN: Sun Nov 23 17:29:57 2014
;; MSG SIZE rcvd: 107

El servidor de correo configurado para iesgn.org

root@debian:~# dig -t mx iesgn.org

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> -t mx iesgn.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55563
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; QUESTION SECTION:
;iesgn.org. IN MX

;; ANSWER SECTION:
iesgn.org. 86400 IN MX 10 correo.iesgn.org.

;; AUTHORITY SECTION:
iesgn.org. 86400 IN NS pandora.iesgn.org.

;; ADDITIONAL SECTION:
correo.iesgn.org. 86400 IN A 10.0.0.200
pandora.iesgn.org. 86400 IN A 10.0.0.50

;; Query time: 1 msec
;; SERVER: 10.0.0.50#53(10.0.0.50)
;; WHEN: Sun Nov 23 17:20:23 2014
;; MSG SIZE rcvd: 104

La dirección IP de www.josedomingo.org

root@debian:~# dig www.josedomingo.org

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> www.josedomingo.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41730
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 12

;; QUESTION SECTION:
;www.josedomingo.org. IN A

;; ANSWER SECTION:
www.josedomingo.org. 868 IN A 134.0.11.146

;; AUTHORITY SECTION:
org. 172768 IN NS b2.org.afilias-nst.org.
org. 172768 IN NS b0.org.afilias-nst.org.
org. 172768 IN NS a2.org.afilias-nst.info.
org. 172768 IN NS d0.org.afilias-nst.org.
org. 172768 IN NS a0.org.afilias-nst.info.
org. 172768 IN NS c0.org.afilias-nst.info.

;; ADDITIONAL SECTION:
a0.org.afilias-nst.info. 172768 IN A 199.19.56.1
a0.org.afilias-nst.info. 172768 IN AAAA 2001:500:e::1
a2.org.afilias-nst.info. 172768 IN A 199.249.112.1
a2.org.afilias-nst.info. 172768 IN AAAA 2001:500:40::1
b0.org.afilias-nst.org. 172768 IN A 199.19.54.1
b0.org.afilias-nst.org. 172768 IN AAAA 2001:500:c::1
b2.org.afilias-nst.org. 172768 IN A 199.249.120.1
b2.org.afilias-nst.org. 172768 IN AAAA 2001:500:48::1
c0.org.afilias-nst.info. 172768 IN A 199.19.53.1
c0.org.afilias-nst.info. 172768 IN AAAA 2001:500:b::1
d0.org.afilias-nst.org. 172768 IN A 199.19.57.1
d0.org.afilias-nst.org. 172768 IN AAAA 2001:500:f::1

;; Query time: 7 msec
;; SERVER: 10.0.0.50#53(10.0.0.50)
;; WHEN: Sun Nov 23 17:25:12 2014
;; MSG SIZE rcvd: 455

Un resolución inversa

root@debian:~# dig -x 10.0.0.40

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> -x 10.0.0.40
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53336
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

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

;; ANSWER SECTION:
40.0.0.10.in-addr.arpa. 86400 IN PTR asterix.iesgn.org.

;; AUTHORITY SECTION:
0.0.10.in-addr.arpa. 86400 IN NS pandora.iesgn.org.

;; ADDITIONAL SECTION:
pandora.iesgn.org. 86400 IN A 10.0.0.50

;; Query time: 4 msec
;; SERVER: 10.0.0.50#53(10.0.0.50)
;; WHEN: Tue Nov 25 20:50:31 2014
;; MSG SIZE rcvd: 148

Consultas desde el cliente windows:

Dirección de pandora.iesgn.org, www.iesgn.org, ftp.iesgn.org

Dirección de «pandora.iesgn.org»:

Dirección de «www.iesgn.org»:

Dirección de «ftp.iesgn.org»:

El servidor DNS con autoridad sobre la zona del dominio iesgn.org

El servidor de correo configurado para iesgn.org

La dirección IP de www.josedomingo.org

Un resolución inversa

3. El servidor DNS actual funciona como DNS maestro. Vamos a instalar un nuevo servidor DNS que va a estar configurado como DNS esclavo del anterior, donde se van a ir copiando periódicamente las zonas del DNS maestro. Suponemos que el nombre del servidor DNS esclavo se va llamar afrodita.iesgn.org.

Creamos una nueva máquina llamada «afrodita» con ip 10.0.0.60.

En el servidor maestro modificamos el archivo «/etc/bind/named.conf.options« y añadimos esto al final del fichero para identificar al servidor esclavo:

acl slaves {
10.0.0.60;
 };

También vamos a indicar que por defecto no este permitido la transferencia completa de zonas, para ello utilizamos la directiva allow-transfer. Añadimos también al mismo fichero dentro de «options« lo siguiente:

allow-transfer { none; };

En el archivo de configuración de resolución directa añadimos la resolución del servidor esclavo (fichero «/var/cache/bind/db.iesgn.org«):

@               IN       NS       afrodita.iesgn.org.
afrodita        IN       A        10.0.0.60

Hacemos lo mismo en el archivo de resolución inversa:

@               IN       NS       afrodita.iesgn.org.
60              IN       PTR      afrodita.iesgn.org.

Modificamos el archivo «/etc/bind/named.conf.local» y dejamos la configuración asi:

include "/etc/bind/zones.rfc1918";
zone "iesgn.org" {
 type master;
 file "db.iesgn.org";
 allow-transfer { slaves; };
 notify yes;
};

zone "0.0.10.in-addr.arpa" {
 type master;
 file "db.10.0.0";
 allow-transfer { slaves; };
 notify yes;
};

En la nueva máquina «afrodita» instalamos bind9 y procedemos a modificar la configuración dns. Definimos las zonas donde se encuentra el DNS maestro, en el archivo «/etc/bind/named.conf.local«:

zone "iesgn.org" {
 type slave;
 masters { 10.0.0.50; };
 file "db.iesgn.org";
};

zone "0.0.10.in-addr.arpa" {
 type slave;
 masters { 10.0.0.50; };
 file "db.10.0.0";
};

Reiniciamos el servicio bind9 en la máquina «afrodita» y comprobamos el log para ver que todo esta configurado correctamente:

Nov 24 20:57:57 afrodita named[4166]: zone iesgn.org/IN: Transfer started.
Nov 24 20:57:57 afrodita named[4166]: transfer of 'iesgn.org/IN' from 10.0.0.50#53: connected using 10.0.0.60#41478
Nov 24 20:57:57 afrodita named[4166]: zone iesgn.org/IN: transferred serial 1
Nov 24 20:57:57 afrodita named[4166]: transfer of 'iesgn.org/IN' from 10.0.0.50#53: Transfer completed: 1 messages, 11 records, 294 bytes, 0.002 secs (147000 bytes/sec)

La transferencia de zona se ha realizado correctamente como podemos ver en el log.

Comprueba si las zonas definidas en el maestro tienen algún error con el comando adecuado.

Con la orden «named-checkzone [zona] [fichero]» podemos comprobar si la zona esta bien configurada. En esta ocasión comprobamos las 2 zonas creadas:

root@pandora:~# named-checkzone 0.0.10.in-addr.arpa /var/cache/bind/db.10.0.0
zone 0.0.10.in-addr.arpa/IN: loaded serial 1
OK

root@pandora:~# named-checkzone iesgn.org /var/cache/bind/db.iesgn.org
zone iesgn.org/IN: loaded serial 1
OK

Ambas zonas están creadas correctamente.

Comprueba si la configuración de named.conf tiene algún error con el comando adecuado.

Con la orden «named-checkconf» comprobamos si tenemos algún error en la configuración:

root@pandora:~# named-checkconf

No obtenemos ningun error.

Reinicia los servidores y comprueba en los logs si hay algún error. No olvides incrementar el número de serie en el registro SOA si has modificado la zona en el maestro.

Incrementamos el número de serie en los archivos de configuración de las zonas y reiniciamos los servidores:

rndc reload iesgn.org

Comprobamos el log:

tail /var/log/syslog
 
Nov 25 18:31:13 pandora named[3703]: received control channel command 'reload iesgn.org' 
Nov 25 18:31:13 pandora named[3703]: zone iesgn.org/IN: loaded serial 2 
Nov 25 18:31:13 pandora named[3703]: zone iesgn.org/IN: sending notifies (serial 2

No obtenemos errores.

Muestra la salida del log donde se demuestra que se ha realizado la transferencia de zona.

Nov 25 18:31:13 pandora named[3703]: client 10.0.0.60#56057: transfer of 'iesgn.org/IN': AXFR-style IXFR started
Nov 25 18:31:13 pandora named[3703]: client 10.0.0.60#56057: transfer of 'iesgn.org/IN': AXFR-style IXFR ended

Realiza una consulta con dig tanto al maestro como al esclavo para comprobar que las respuestas son autorizadas. ¿En qué te tienes que fijar?

Realizamos la consulta al servidor maestro, podemos ver que las respuestas son autorizadas por las flags «aa«:

root@debian:~# dig +norec @10.0.0.50 iesgn.org. soa

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> +norec @10.0.0.50 iesgn.org. soa
 ; (1 server found)
 ;; global options: +cmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31257
 ;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
 ;iesgn.org. IN SOA

;; ANSWER SECTION:
 iesgn.org. 86400 IN SOA pandora.iesgn.org. admin.iesgn.org. 2 21600 3600 604800 21600

;; AUTHORITY SECTION:
 iesgn.org. 86400 IN NS pandora.iesgn.org.
 iesgn.org. 86400 IN NS afrodita.iesgn.org.

;; ADDITIONAL SECTION:
 pandora.iesgn.org. 86400 IN A 10.0.0.50
 afrodita.iesgn.org. 86400 IN A 10.0.0.60

;; Query time: 4 msec
 ;; SERVER: 10.0.0.50#53(10.0.0.50)
 ;; WHEN: Tue Nov 25 21:08:44 2014
 ;; MSG SIZE rcvd: 146

Consulta al servidor esclavo:

root@debian:~# dig +norec @10.0.0.60 iesgn.org. soa

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> +norec @10.0.0.60 iesgn.org. soa
 ; (1 server found)
 ;; global options: +cmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38516
 ;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
 ;iesgn.org. IN SOA

;; ANSWER SECTION:
 iesgn.org. 86400 IN SOA pandora.iesgn.org. admin.iesgn.org. 2 21600 3600 604800 21600

;; AUTHORITY SECTION:
 iesgn.org. 86400 IN NS afrodita.iesgn.org.
 iesgn.org. 86400 IN NS pandora.iesgn.org.

;; ADDITIONAL SECTION:
 pandora.iesgn.org. 86400 IN A 10.0.0.50
 afrodita.iesgn.org. 86400 IN A 10.0.0.60

;; Query time: 1 msec
 ;; SERVER: 10.0.0.60#53(10.0.0.60)
 ;; WHEN: Tue Nov 25 21:09:12 2014
 ;; MSG SIZE rcvd: 146

Ambas respuestas son autorizadas.

Configura un cliente para que utilice los dos servidores como servidores DNS.

Añadimos al archivo «/etc/resolv.conf» de nuestro cliente debian la siguiente linea:

nameserver 10.0.0.60

Solicita una copia completa de la zona desde el cliente ¿qué tiene que ocurrir?. Solicita una copia completa desde el esclavo ¿qué tiene que ocurrir?

Desde el cliente solicitamos una copia completa de la zona y nos da error ya que no lo tenemos permitido:

root@debian:~# dig @10.0.0.50 iesgn.org. axfr

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @10.0.0.50 iesgn.org. axfr
 ; (1 server found)
 ;; global options: +cmd
 ; Transfer failed.

No se realiza la transferencia ya que no está permitida, sólo está permitida para los servidores esclavos. Si hacemos la solicitud desde el esclavo obtenemos la siguiente respuesta:

root@afrodita:~# dig @10.0.0.50 iesgn.org. axfr

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @10.0.0.50 iesgn.org. axfr
 ; (1 server found)
 ;; global options: +cmd
 iesgn.org.              86400 IN SOA   pandora.iesgn.org. admin.iesgn.org. 2 21600 3600 604800 21600
 iesgn.org.              86400 IN NS    pandora.iesgn.org.
 iesgn.org.              86400 IN NS    afrodita.iesgn.org.
 iesgn.org.              86400 IN MX    10 correo.iesgn.org.
 afrodita.iesgn.org.     86400 IN A     10.0.0.60
 asterix.iesgn.org.      86400 IN A     10.0.0.40
 correo.iesgn.org.       86400 IN A     10.0.0.200
 departamento.iesgn.org. 86400 IN CNAME pandora.iesgn.org.
 ftp.iesgn.org.          86400 IN A     10.0.0.201
 obelix.iesgn.org.       86400 IN A     10.0.0.20
 pandora.iesgn.org.      86400 IN A     10.0.0.50
 www.iesgn.org.          86400 IN CNAME pandora.iesgn.org.
 iesgn.org.              86400 IN SOA   pandora.iesgn.org. admin.iesgn.org. 2 21600 3600 604800 21600
 ;; Query time: 5 msec
 ;; SERVER: 10.0.0.50#53(10.0.0.50)
 ;; WHEN: Tue Nov 25 18:47:29 2014
 ;; XFR size: 13 records (messages 1, bytes 333)

La copia se realiza correctamente.

Realiza una consulta desde el cliente y comprueba que servidor está respondiendo.

Realizamos una consulta desde el cliente a la web de nba:

root@debian:~# dig www.nba.com

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> www.nba.com
 ;; global options: +cmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28822
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 13, ADDITIONAL: 8

;; QUESTION SECTION:
 ;www.nba.com. IN A

;; ANSWER SECTION:
 www.nba.com. 190 IN CNAME www.nba.com.edgesuite.net.
 www.nba.com.edgesuite.net. 663 IN CNAME a1570.gd.akamai.net.
 a1570.gd.akamai.net. 11 IN A 92.122.188.27
 a1570.gd.akamai.net. 11 IN A 92.122.188.32

;; AUTHORITY SECTION:
 net. 172800 IN NS j.gtld-servers.net.
 net. 172800 IN NS c.gtld-servers.net.
 net. 172800 IN NS m.gtld-servers.net.
 net. 172800 IN NS a.gtld-servers.net.
 net. 172800 IN NS h.gtld-servers.net.
 net. 172800 IN NS l.gtld-servers.net.
 net. 172800 IN NS b.gtld-servers.net.
 net. 172800 IN NS i.gtld-servers.net.
 net. 172800 IN NS k.gtld-servers.net.
 net. 172800 IN NS f.gtld-servers.net.
 net. 172800 IN NS g.gtld-servers.net.
 net. 172800 IN NS d.gtld-servers.net.
 net. 172800 IN NS e.gtld-servers.net.

;; ADDITIONAL SECTION:
 a.gtld-servers.net. 172799 IN A 192.5.6.30
 a.gtld-servers.net. 172799 IN AAAA 2001:503:a83e::2:30
 b.gtld-servers.net. 172799 IN A 192.33.14.30
 b.gtld-servers.net. 172799 IN AAAA 2001:503:231d::2:30
 c.gtld-servers.net. 172799 IN A 192.26.92.30
 d.gtld-servers.net. 172799 IN A 192.31.80.30
 e.gtld-servers.net. 172799 IN A 192.12.94.30
 f.gtld-servers.net. 172799 IN A 192.35.51.30

;; Query time: 1659 msec
 ;; SERVER: 10.0.0.50#53(10.0.0.50)
 ;; WHEN: Tue Nov 25 18:48:29 2014
 ;; MSG SIZE rcvd: 503

Comprobamos que el servidor que responde es «10.0.0.50» es decir, «pandora«.

Posteriormente apaga el servidor maestro y vuelve a realizar una consulta desde el cliente ¿quién responde?

Apagamos el servidor dns en la máquina «pandora» :

 /etc/init.d/bind9 stop

Volvemos a realizar la consulta:

root@debian:~# dig www.nba.com

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> www.nba.com
 ;; global options: +cmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46346
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 8, ADDITIONAL: 8

;; QUESTION SECTION:
 ;www.nba.com. IN A

;; ANSWER SECTION:
 www.nba.com. 177 IN CNAME www.nba.com.edgesuite.net.
 www.nba.com.edgesuite.net. 778 IN CNAME a1570.gd.akamai.net.
 a1570.gd.akamai.net. 20 IN A 92.122.188.27
 a1570.gd.akamai.net. 20 IN A 92.122.188.32

;; AUTHORITY SECTION:
 gd.akamai.net. 3878 IN NS n0gd.akamai.net.
 gd.akamai.net. 3878 IN NS n2gd.akamai.net.
 gd.akamai.net. 3878 IN NS n3gd.akamai.net.
 gd.akamai.net. 3878 IN NS n4gd.akamai.net.
 gd.akamai.net. 3878 IN NS n1gd.akamai.net.
 gd.akamai.net. 3878 IN NS n6gd.akamai.net.
 gd.akamai.net. 3878 IN NS n7gd.akamai.net.
 gd.akamai.net. 3878 IN NS n5gd.akamai.net.

;; ADDITIONAL SECTION:
 n0gd.akamai.net. 3878 IN A 80.149.168.85
 n1gd.akamai.net. 5878 IN A 130.206.192.38
 n2gd.akamai.net. 7878 IN A 212.106.219.30
 n3gd.akamai.net. 3878 IN A 88.221.81.195
 n4gd.akamai.net. 5878 IN A 80.149.168.84
 n5gd.akamai.net. 7878 IN A 80.149.168.86
 n6gd.akamai.net. 3878 IN A 80.149.168.79
 n7gd.akamai.net. 5878 IN A 80.149.168.78

;; Query time: 97 msec
 ;; SERVER: 10.0.0.60#53(10.0.0.60)
 ;; WHEN: Tue Nov 25 18:50:32 2014
 ;; MSG SIZE rcvd: 410

Esta vez vemos la respuesta la ha dado el servidor dns esclavo «afrodita» ya que el server es «10.0.0.60«.

4. Tenemos un servidor DNS que gestiona la zona correspondiente al nombre de dominio iesgn.org, en esta ocasión queremos delegar el subdominio informatica.iesgn.org para que lo gestione otro servidor DNS. Por lo tanto tenemos un escenario con dos servidores DNS:

pandora.iesgn.org, es servidor DNS autorizado para la zona iesgn.org.
ns.informatica.iesgn.org, es el servidor DNS para la zona informatica.iesgn.org y, está instlado en otra máquina.

Creamos una nueva máquina virtual amerix con ip 10.0.0.70 e instalamos en ella el servidor dns bind9.

Si tenemos en nuestro servidor bind9 activada la opción forwarders debemos desactivarla. Definimos en «pandora» la nueva máquina «amerix» dentro de la nueva zona «informatica.iesgn.org.» .
Modificamos el fichero «/var/cache/bind/db.iesgn.org« y añadimos al final del archivo estas 3 lineas:

$ORIGIN informatica.iesgn.org.
@      IN      NS      amerix.informatica.iesgn.org.
amerix IN      A       10.0.0.70

En la máquina amerix procedemos a configurar el servidor dns bind9, modificamos el archivo «/etc/bind/named.conf.local» y añadimos la siguiente configuración:

zone "informatica.iesgn.org" {
        type master;
        file "db.informatica.iesgn.org";
};

Creamos el archivo y le cambiamos el propietario y los permisos necesarios:

root@amerix:~# touch /var/cache/bind/db.informatica.iesgn.org
root@amerix:~# chown bind:bind /var/cache/bind/db.*
root@amerix:~# chmod 660 /var/cache/bind/db.*

Los nombres que vamos a tener en ese subdominio son los siguientes:

www.informatica.iesgn.org corresponde a un sitio web que está alojado en el servidor web del departamento de informática.
Vamos a suponer que tenemos un servidor ftp que se llame ftp.informatica.iesgn.org y que está en la misma máquina.
Vamos a suponer que tenemos un servidor para recibir los correos que se llame correo.informatica.iesgn.org.

Modificamos el fichero de resolución directa y le introducimos el siguiente contenido, en el que indicaremos los nombres de subdominio como «CNAME» ya que vamos a suponer que se encuentran en la misma máquina. Para la resolución del sitio web, suponemos que el servidor web del departamento de informática se aloja en pandora por lo que usamos la dirección «10.0.0.50«:

$ORIGIN informatica.iesgn.org.
$TTL    86400
@       IN      SOA     amerix.informatica.iesgn.org. admin.informatica.iesgn.org$
                3 ;serial
                21600 ; refresh (6 hours)
                3600 ; retry (1 hour)
                604800 ; expire (1 week)
                21600 ; minimum (6 hours)
)
@       IN      NS      amerix.informatica.iesgn.org.
amerix  IN      A       10.0.0.70
www     IN      A       10.0.0.50
ftp     IN      CNAME   amerix.informatica.iesgn.org.
@       IN      MX      10      correo.informatica.iesgn.org.
correo  IN      CNAME   amerix.informatica.iesgn.org.

Realiza las consultas dig/neslookup desde los clientes preguntando por los siguientes:

Dirección de www.informatica.iesgn.org.

root@debian:~# dig www.informatica.iesgn.org

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> www.informatica.iesgn.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17982
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;www.informatica.iesgn.org.    IN    A

;; ANSWER SECTION:
www.informatica.iesgn.org. 86364 IN    A    10.0.0.50

;; AUTHORITY SECTION:
informatica.iesgn.org.    86400    IN    NS    amerix.informatica.iesgn.org.

;; Query time: 2 msec
;; SERVER: 10.0.0.50#53(10.0.0.50)
;; WHEN: Thu Nov 27 18:26:05 2014
;; MSG SIZE  rcvd: 80

Dirección de ftp.informatica.iesgn.org.

root@debian:~# dig ftp.informatica.iesgn.org

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> ftp.informatica.iesgn.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31966
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;ftp.informatica.iesgn.org. IN A

;; ANSWER SECTION:
ftp.informatica.iesgn.org. 86400 IN CNAME amerix.informatica.iesgn.org.
amerix.informatica.iesgn.org. 86267 IN A 10.0.0.70

;; AUTHORITY SECTION:
informatica.iesgn.org. 86400 IN NS amerix.informatica.iesgn.org.

;; Query time: 3 msec
;; SERVER: 10.0.0.50#53(10.0.0.50)
;; WHEN: Wed Nov 26 22:18:03 2014
;; MSG SIZE rcvd: 94

El servidor DNS que tiene configurado la zona del dominio informatica.iesgn.org. ¿Es el mismo que el servidor DNS con autoridad para la zona iesgn.org?

root@debian:~# dig -t ns informatica.iesgn.org

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> -t ns informatica.iesgn.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54326
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;informatica.iesgn.org. IN NS

;; ANSWER SECTION:
informatica.iesgn.org. 86372 IN NS amerix.informatica.iesgn.org.

;; ADDITIONAL SECTION:
amerix.informatica.iesgn.org. 86200 IN A 10.0.0.70

;; Query time: 1 msec
;; SERVER: 10.0.0.50#53(10.0.0.50)
;; WHEN: Wed Nov 26 22:19:11 2014
;; MSG SIZE rcvd: 76

El servidor no es el mismo ya que el servidor con autoridad sobre la zona «iesgn.org» son «pandora» y «afrodita» como esclavo:

root@debian:~# dig -t soa iesgn.org

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> -t soa iesgn.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51724
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;iesgn.org.            IN    SOA

;; ANSWER SECTION:
iesgn.org.        86400    IN    SOA    pandora.iesgn.org. admin.iesgn.org. 3 21600 3600 604800 21600

;; AUTHORITY SECTION:
iesgn.org.        86400    IN    NS    pandora.iesgn.org.
iesgn.org.        86400    IN    NS    afrodita.iesgn.org.

;; ADDITIONAL SECTION:
pandora.iesgn.org.    86400    IN    A    10.0.0.50
afrodita.iesgn.org.   86400    IN    A    10.0.0.60

;; Query time: 4 msec
;; SERVER: 10.0.0.50#53(10.0.0.50)
;; WHEN: Thu Nov 27 18:33:30 2014
;; MSG SIZE  rcvd: 146

El servidor de correo configurado para informatica.iesgn.org

root@debian:~# dig -t mx informatica.iesgn.org

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> -t mx informatica.iesgn.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31499
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;informatica.iesgn.org.        IN    MX

;; ANSWER SECTION:
informatica.iesgn.org.    86379    IN    MX    10 correo.informatica.iesgn.org.

;; AUTHORITY SECTION:
informatica.iesgn.org.    86317    IN    NS    amerix.informatica.iesgn.org.

;; ADDITIONAL SECTION:
amerix.informatica.iesgn.org. 86145 IN    A    10.0.0.70

;; Query time: 3 msec
;; SERVER: 10.0.0.50#53(10.0.0.50)
;; WHEN: Wed Nov 26 22:20:05 2014
;; MSG SIZE  rcvd: 99

Consultas desde windows con «nslookup»:

Dirección de www.informatica.iesgn.org.

Dirección de ftp.informatica.iesgn.org.

El servidor DNS que tiene configurado la zona del dominio informatica.iesgn.org.

El servidor de correo configurado para informatica.iesgn.org

Introducción

En esta ocasión resuelvo los siguientes ejercicios sobre montar un servidor DNS en debian : http://josedom24.github.io/mod/serviciosgs/e_dns_8

Procedimiento

1. Instala el servidor dns dnsmasq en pandora.iesgn.org y configúralo para que los clientes puedan conocer los nombres necesarios.

Modifica los clientes para que utilicen el nuevo servidor dns.

Realiza una consulta a www.iesgn.org, y a www.josedomingo.org.

Realiza una prueba de funcionamiento para comprobar que el servidor dnsmasq funciona como cache dns.

2. Desinstala el servidor dnsmasq del ejercicio anterior e instala un servidor dns bind9. Las características del servidor DNS que queremos instalar son las siguientes:

El servidor DNS se llama pandora.iesgn.org y por supuesto, va a ser el servidor con autoridad para la zona iesgn.org..

Vamos a suponer que tenemos un servidor para recibir los correos que se llame correo.iesgn.org y que está en la dirección x.x.x.200 (esto es ficticio).

Vamos a suponer que tenemos un servidor ftp que se llame ftp.iesgn.org y que está en x.x.x.201 (esto es ficticio)

Además queremos nombrar a los clientes.

También hay que nombrar a los virtual hosts de apache: www.iesgn.org y departementos.iesgn.org

Se tienen que configurar la zona de resolución inversa.

Realiza las consultas dig/neslookup desde los clientes preguntando por los siguientes:

Dirección de pandora.iesgn.org, www.iesgn.org, ftp.iesgn.org

El servidor DNS con autoridad sobre la zona del dominio iesgn.org

El servidor de correo configurado para iesgn.org

La dirección IP de www.josedomingo.org

Un resolución inversa

Dirección de pandora.iesgn.org, www.iesgn.org, ftp.iesgn.org

El servidor DNS con autoridad sobre la zona del dominio iesgn.org

El servidor de correo configurado para iesgn.org

La dirección IP de www.josedomingo.org

Un resolución inversa

Comprueba si las zonas definidas en el maestro tienen algún error con el comando adecuado.

Comprueba si la configuración de named.conf tiene algún error con el comando adecuado.

Reinicia los servidores y comprueba en los logs si hay algún error. No olvides incrementar el número de serie en el registro SOA si has modificado la zona en el maestro.

Muestra la salida del log donde se demuestra que se ha realizado la transferencia de zona.

Realiza una consulta con dig tanto al maestro como al esclavo para comprobar que las respuestas son autorizadas. ¿En qué te tienes que fijar?

Configura un cliente para que utilice los dos servidores como servidores DNS.

Solicita una copia completa de la zona desde el cliente ¿qué tiene que ocurrir?. Solicita una copia completa desde el esclavo ¿qué tiene que ocurrir?

Realiza una consulta desde el cliente y comprueba que servidor está respondiendo.

Posteriormente apaga el servidor maestro y vuelve a realizar una consulta desde el cliente ¿quién responde?

4. Tenemos un servidor DNS que gestiona la zona correspondiente al nombre de dominio iesgn.org, en esta ocasión queremos delegar el subdominio informatica.iesgn.org para que lo gestione otro servidor DNS. Por lo tanto tenemos un escenario con dos servidores DNS:

pandora.iesgn.org, es servidor DNS autorizado para la zona iesgn.org.

ns.informatica.iesgn.org, es el servidor DNS para la zona informatica.iesgn.org y, está instlado en otra máquina.

Los nombres que vamos a tener en ese subdominio son los siguientes:

www.informatica.iesgn.org corresponde a un sitio web que está alojado en el servidor web del departamento de informática.

Vamos a suponer que tenemos un servidor ftp que se llame ftp.informatica.iesgn.org y que está en la misma máquina.

Vamos a suponer que tenemos un servidor para recibir los correos que se llame correo.informatica.iesgn.org.

Realiza las consultas dig/neslookup desde los clientes preguntando por los siguientes:

Dirección de www.informatica.iesgn.org.

Dirección de ftp.informatica.iesgn.org.

El servidor DNS que tiene configurado la zona del dominio informatica.iesgn.org. ¿Es el mismo que el servidor DNS con autoridad para la zona iesgn.org?

El servidor de correo configurado para informatica.iesgn.org

Dirección de www.informatica.iesgn.org.

Dirección de ftp.informatica.iesgn.org.

El servidor de correo configurado para informatica.iesgn.org

Comparte esta entrada:

Me gusta esto:

Relacionado

Deja un comentario Cancelar respuesta