Resolución de Nombres de Dominio: DNS
Cuando la navegación a internet no funciona o es demasiado lenta, puede que el problema, resida en la resolución de nombres de dominios DNS. Es solo una posibilidad, porque el problema puede radicar en otros componentes, ya sea con el hardware del equipo cliente, o con el software, problemas de infraestructura de red o con el proveedor de servicios...
En los centros utilizamos PowerDNS, con ldap como backend, en el servidor principal para realizar la resolución de nombres DNS. El paquete PowerDNS está formado por dos componentes:
- El servidor "autoritativo": pdns.
- Y el recursor: pdns-recursor.
Existen otros paquetes que combinan estas funcionalidades como bind9, pero en su día nos decantamos por Powerdns por la facilidad de su configuración y la integración con ldap. La función del servidor DNS "autoritativo" (pdns) es proporcionar información de resolución de nombres para un dominio en particular. Recordad que básicamente consiste en traducir nombres de dominio a IPs y viceversa. La función del recursor (pdns-recursor) es proporcionar un sistema de almacenamiento en caché para acelerar la resolución de nombres y un mecanismo para resolver las consultas recursivas que realizan nuestros clientes.
Existen dos tipos de consultas que un cliente puede hacer a un servidor DNS:
- Iterativa
- Recursiva
Las consultas iterativas, o resolución iterativa, consisten en la mejor respuesta que el servidor de nombres pueda dar. El servidor de nombres consulta sus datos locales (en nuestro caso la base de datos LDAP) y también consulta la caché (pdns-recursor) buscando los datos solicitados.
En las consultas recursivas el servidor DNS (pdns) no tiene una respuesta y repite el mismo proceso básico (consultar a un servidor remoto y seguir cualquier referencia) hasta que obtiene la respuesta a la pregunta. De esto último, se encarga el pdns-recursor.
Explicado todo lo anterior propongo una manera de configurar el servicio PowerDNS (algunas líneas) para aprovechar al máximo la funcionalidad que aporta:
El fichero /etc/powerdns/pdns.d/pdns-debian-edu.conf debe contener la línea:
recursor=127.0.0.1:1553
Con esto, le estamos diciendo a nuestro servidor DNS que utilice como recursor el servidor que escucha en la dirección IP 127.0.0.1 y en el puerto 1553, configuración por defecto de pdns-recursor.
Recordad que el recursor se encarga de mantener una cache para acelerar la resolución de nombres y un mecanismo para resolver las consultas recursivas. Si en lugar de eso, en el fichero /etc/powerdns/pdns.d/pdns-debian-edu.conf ponemos la siguiente línea:
recursor=8.8.8.8
Le estaríamos diciendo a nuestro servidor DNS que utilice como recursor el servidor de Google cuya IP es 8.8.8.8 y no estaríamos utilizando la ventaja que nos dá tener una caché local.
Para la configuración del recursor hay que tocar el fichero /etc/powerdns/recursor.conf y concretamente la línea:
forward-zones-recurse=.=172.21.8.8
En esta línea le estamos diciendo que para las consultas recursivas utilice el servidor 172.21.8.8.
Este servidor es el que nos ha recomendado utilizar el Servicio de Infraestructura.
Si tenemos en la anterior línea varios servidores separados por ; el recursor hace balanceo entre ellos.
Si en la configuración del recursor omitimos la línea “forward-zones-recurse=.=172.21.8.8”, (configuración por defecto) el recursor intenta resolver la consulta recursiva consultando a uno de los 13 servidores RAIZ (http://es.wikipedia.org/wiki/Servidor_ra%C3%ADz) que existen en internet. Esto desencadena un proceso de preguntas y respuestas que termina por obtener una respuesta por parte de un servidor DNS autorizado de la zona para el dominio buscado.
Documentacion PowerDNS: https://doc.powerdns.com/md/
Herramientas para chequear y monitorizar el sistema DNS:
Para testear el servicio PowerDNS, obtener estadísticas de uso e información almacenada en la caché, podemos utilizar dos herramientas incluidas en la instalación:
- pdns_control: lo utlizamos para obtener información sobre el servidor "autoritativo": pdns.
- rec_control: obtenemos estadísticas del recursor y estado de la caché (p.ej. rec_control get-all).
Algunas de las herramientas más utilizadas y que todos deben conocer para comprobar el funcionamiento del DNS son: dig, nslookup, host. Pero voy a comentar una herramienta que me parece muy interesante para utlizarla en nuestros servidores y comprobar cómo se está comportando nuestro centro a nivel de DNS.
Para monitorizar las consultas DNS en un servidor principal utilizo la herramienta Dnstop.
Es una herramienta de consola diseñada para analizar el trafico DNS saliente o entrante en un maquina. El comando genera unas tablas con información útil sobre las solicitudes de DNS realizadas. Soporta IPv4 y IPv6. Algunos de los datos que se muestran son:
Dirección IP de origen.
Dirección IP de destino.
Tipos de registros DNS solicitados.
Dominios de Primer, Segundo o tercer nivel.
Pagina del proyecto:
http://dns.measurement-factory.com/tools/dnstop/
Tenemos el paquete en los repositorios Debian y solamente basta con instalarlo en nuestro servidor con “apt-get install dnstop”.
Sintaxis:
dnstop [opciones] interfaz
Para realizar la prueba he utilizado un servidor principal de un centro con la configuración recomendaba para PowerDns:
#dnstop eth0
Queries: 20 new, 748 total Wed Jan 11 12:58:12 2017
Sources Count % cum%
------------- --------- ------ ------
172.23.36.2 190 25.4 25.4
172.23.36.87 130 17.4 42.8
Esta es la salida inicial de dnstop. Muestra estadística sobre los orígenes de las peticiones DNS, pero dnstop nos aporta mucha más información. Se puede lanzar con una opción particular o podemos ir cambiando las tablas durante la ejecución del programa utilizando la pulsación del teclado:
s - Sources list
d - Destinations list
t - Query types
o - Opcodes
r - Rcodes
1 - 1st level Query Names ! - with Sources
2 - 2nd level Query Names @ - with Sources
3 - 3rd level Query Names # - with Sources
4 - 4th level Query Names $ - with Sources
5 - 5th level Query Names % - with Sources
6 - 6th level Query Names ^ - with Sources
7 - 7th level Query Names & - with Sources
8 - 8th level Query Names * - with Sources
9 - 9th level Query Names ( - with Sources
^R - Reset counters
^X - Exit
? - this
Presionando el 1, ordena según el dominio de primer nivel mas solicitado.
Queries: 13 new, 408 total Wed Jan 11 13:09:56 2017
Query Name Count % cum%
------------ --------- ------ ------
com 213 52.2 52.2
santaeulalia 51 12.5 64.7
net 46 11.3 76.0
Presionando la tecla d, se ordena según la ip destino de la consulta:
Queries: 44 new, 14843 total Wed Jan 11 13:15:07 2017
Destinations Count % cum%
------------ --------- ------ ------
172.23.36.2 11453 77.2 77.2
172.21.8.8 3342 22.5 99.7
8.8.8.8 38 0.3 99.9
8.8.4.4 10 0.1 100.0
Cómo podéis ver en esta última captura, la caché está funcionando correctamente ya que un alto porcentaje de las consultas se quedan en el servidor principal.
En resumen, con estos dos paquetes, la sencilla configuracion que tienen y las herramientas que hemos presentado podemos y debemos tener bajo control la resolución de nombres de nuestros centros y los problemas que esta nos pueda generar (si no es así, siempre podemos decir que son las comunicaciones ;) ).
