Configuración de un servidor DNS de reenvío

El motivo principal para configurar un servidor DNS de reenvío, como ya se explicó, es el de minimizar el tráfico sobre redes con conexiones externas lentas, caras o congestionadas. Se diferencia de un servidor DNS solo caché en que un DNS de reenvío no hace consultas recursivas sino simplemente le pasa la consulta a otro servidor DNS, es aquí donde radica la ventaja para minimizar el trabajo del servidor DNS.

Tras la configuración del servidor tendremos lo siguiente:

• El servidor no tendrá ninguna zona, mas allá de las zonas por defecto. La que más nos va a interesar es la zona localhost.
• Un servidor caché para todos los dominios.
• Un servidor sin el servicio de consultas recursivas. Se consigue con los estamentos recursion no; y forward only;.
• El servidor reenviará todas las consultas a un servidor DNS remoto que es quien aporta el servicio de consultas recursivas. Esto se consigue con el estamento foward anterior y también con el estamento forwarders.

La configuración del fichero named.conf la vamos a distribuir de la misma forma que en la configuración del servidor maestro.

# cat /etc/bind/named.conf
include "/etc/bind/named.conf.acl";
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.logging";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";

Como no vamos a utilizar ninguna lista acl, el fichero named.conf.acl lo dejaremos vacío. Y en cuanto al mecanismo de los mensajes log de BIND, mantendremos el mismo sistema.

# cat /etc/bind/named.conf.logging 
logging {
    category default { mi_canal_log; };
    channel mi_canal_log {
        file "/var/log/bind/bind.log" versions 3 size 100k;
        print-time yes;
        print-severity yes;
        print-category yes;
    };
};

La configuración global de BIND será así:

# cat /etc/bind/named.conf.options 
options {
  directory "/var/cache/bind";

  version "No disponible";

  listen-on port 53 { any; };   # valor por defecto, pero es mejor ponerlo para saber que lo hemos tenido en cuenta

  forward only;
  forwarders { 8.8.8.8; 8.8.4.4; };

  allow-query { localnets; };  

  allow-transfer { none; };
};

Las líneas nuevas que se han introducido son las siguientes:

    forward only;
    forwarders { 8.8.8.8; 8.8.4.4; };

Con los dos estamentos anteriores obligamos al servidor a desactivar el comportamiento recursivo y a reenviar las consultas (forward), además de indicar a qué IP haremos el reenvío (forwarders).

También se ha añadido la siguiente línea con el objetivo de que solo los equipos de las redes locales a las que está conecto el servidor DNS puedan hacerle consultas. Esto es una medida de seguridad contra usuarios malintencionados que utilicen el servicio DNS para lanzar ataques, por defecto, el valor asociado a allow-query es any.

  allow-query { localnets; };  

El fichero /etc/bind/named.conf.local lo dejaremos vacío, pues no se creará ninguna zona. Y el fichero /etc/bind/named.conf.default-zones se dejará como está, para que se carguen las zonas por defecto.

Por último reiniciamos el servicio:

# /etc/init.d/bind9 restart

y lo utilizamos en la configuración de los DNS de los equipos (resolv.conf, etc.).

Comprobemos ahora que nuestro servidor funciona ejecutando el comando dig desde un equipo:

# dig www.uca.es

; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> www.uca.es
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1837
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.uca.es.            IN    A

;; ANSWER SECTION:
www.uca.es.        7772    IN    A    150.214.80.25

;; Query time: 55 msec
;; SERVER: 172.16.0.1#53(172.16.0.1)
;; WHEN: Mon Jun 15 19:12:13 CEST 2016
;; MSG SIZE  rcvd: 55

Si ejecutamos la misma orden a continuación, observamos que la caché está funcionando pues el tiempo de respuesta es mucho menor:

# dig www.uca.es

; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> www.uca.es
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16511
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.uca.es.            IN    A

;; ANSWER SECTION:
www.uca.es.        7770    IN    A    150.214.80.25

;; Query time: 3 msec
;; SERVER: 172.16.0.1#53(172.16.0.1)
;; WHEN: Mon Jun 15 19:12:17 CEST 2016
;; MSG SIZE  rcvd: 55

Y si utilizamos el programa Wireshark para capturar en el servidor el tráfico generado por las dos órdenes anteriores, veremos que es mínimo, en comparación con el tráfico que generan las consultas recursivas en las otras configuraciones que hemos visto.

Puede verse claramente, que el primer dig generó dos paquetes, uno en cada sentido, pregunta y respuesta, y el segundo dig lo mismo.