PDF de programación - DNS

DNS

David Montero *

26 de octubre de 2009

*Si quieres hacer algún comentario o correción, por favor envíame un correo

1

3

3

4

5

6

7

7

8

8

9

9

Índice

1. Introducción

2. Estructura jerárquica

3. RR

4. Transferencia de zonas

5. Caché

6. Forwarders

7. Paquetes DNS

8. Peticiones DNS

9. Glue Records

10.NXDOMAIN

11.Seguridad

2

1.

Introducción

Antiguamente la resolución nombre host-IP se realizaba mediante el chero hosts.txt. Este chero estaba
situado en una máquina central, a la cual accedían el resto de hosts para descargarlo. Con el tiempo la
longitud del chero creció de forma desmesurada. Esto hizo inmanejable la gestión del mismo y condujo
a una sobrecarga del servidor. Fué entonces cuando surgió la necesidad de eliminar el servidor central y
apareció el protocolo DNS (Domain Name Service). Éste consiste en bases de datos distribuidas, de forma
que la resolución de nombre se realiza de forma descentralizada. El protocolo que se utiliza por defecto es
UDP 1 y el servidor escucha en el puerto 53.

La estructura de los DNS es jerárquica, de forma que los servidores raíz tienen conocimiento de los
servidores inferiores y así sucesivamente. En un cierto nivel de la jerarquía están los servidores DNS que
tienen autoridad sobre una zona. Son éstos los que se encargan de realizar la resolución de forma autoritativa.

Antes de seguir con la explicación es conveniente aclarar el concepto resolver, ya que se utilizará posteri-
ormente. El resolver es una librería que se encarga de realizar las peticiones DNS, y es utilizada por cualquier
aplicación que desee realizar una consulta. Cuando el resolver obtiene la respuesta de los servidores DNS se
la pasa a la aplicación de la que procede la consulta. Se diferencian entre los que no mantienen una caché
con las respuestas y los sí. Estos últimos utilizan las respuestas cacheadas para resolver próximas consultas.

2. Estructura jerárquica

Volviendo a la jerarquía en DNS, en la cúspide están los servidores raíz (rootservers) y después los TLD
(Top Level Domain). Éstos se dividen en ccTLD (country code TLD) y gTLD (generic TLD), y también
existe la combinación de ambos (.org.uk). Por debajo de éstos operan los servidores que tienen autoridad sobre
las zonas. Por tanto, si se pide resolver una zona a un servidor DNS sobre el que éste no tiene autoridad, se
reenvía la petición a un servidor raíz. Y desde allí se produce una serie de peticiones descendentes (TLD, etc)
hasta que se contacta con el servidor autoritativo. Puede darse el caso de que un servidor no tenga autoridad
sobre la zona pero la respuesta se encuentre en caché. Entonces se procede a resolver resolver la petición,
pero la respuesta no es autoritativa. Existen TLD que se han creado para hacer pruebas, y por tanto se ha
cuidado que no puedan entrar en conicto con TLD actuales. Los nombres de dominio que comprenden son:

.test

.example

.invalid

.localhost

1en determinados casos se utiliza TCP

3

Al igual que ocurre con los TLD, ocurre con nombres de dominio de segundo nivel. IANA ha reservado

los siguientes nombres:

example.com

example.net

example.org

Las respuestas de los servidores DNS pueden ser recursivas o iterativas. En las recursivas si el DNS no conoce
la respuesta preguntará a otros servidores hasta que obtenga la solución. Finalmente informa al cliente de la
respuesta. En cambio en las iterativas, si no conoce la respuesta avisa al cliente de los servidores DNS a los
que puede consultar. En ese momento acaba su responsabilidad, y es el cliente el que se encarga de lanzar la
petición a otro servidor. Las respuestas de los rootservers y TLD son iterativas para no sobrecargarlos.

3. RR

Un servidor DNS trabaja con registros que reciben el nombre de RR 2. Existen varios tipos:

SOA: información sobre la zona que el servidor DNS tiene autoridad.

A: resolución directa.

PTR: resolución inversa.

CNAME: alias sobre un nombre de máquina.

MX: servidor de correo que gestiona un dominio.

NS: DNS que tiene autoridad sobre una zona.

HWINFO: información sobre la CPU y el SO. No se recomienda dar esta información.

TXT: texto descriptivo.

Es importante evitar la conguración de niveles múltiples de alias. Esto produce falta de eciencia.

Un servidor que contenga un registro SOA es autoritativo sobre la zona, pero puede apuntar a otros

servidores DNS para que tengan autoridad sobre subdominios.

2

Resources Registers

4

El registro SOA se compone de los siguientes campos:

MNAME: nombre de dominio del servidor.

RNAME: correo de la persona responsable de la zona.

SERIAL: número de 32 bits. Si aumenta indica modicación en los cheros de zona.

REFRESH: indica cada cuanto tiempo se tiene que refrescar la zona.

EXPIRE: límite de tiempo durante el cual la información es autoritativa en el servidor

secundario.

RETRY: tiempo que tiene que pasar antes de volver a refrescar la zona cuando se produce

un fallo.

4. Transferencia de zonas

Las peticiones de los servidores secundarios a los primarios vienen determinadas por los parámetros
REFRESH, RETRY y EXPIRE. Cuando una zona se carga en el servidor secundario, se espera los
segundos indicados en el campo REFRESH antes de comprobar de nuevo el campo SERIAL. Si la consulta
falla por algún motivo, lo intentará pasado el tiempo indicado en RETRY. Si se ha producido un cambio en
los cheros de zona del servidor primario se realiza una transferencia entre ambos servidores. Si al servidor
secundario le resulta imposible hacer una comprobación antes del tiempo indicado en EXPIRE, se asume
que su copia de los cheros de zona están obsoletos y los descarta.

La información DNS se transmite mediante datagramas UDP debido a su baja sobrecarga y alto rendimien-
to. Un caso en el que se usa TCP es la transferencia de zonas. Esto es debido a que es una operación delicada
en la que no se pueden consentir pérdidas de paquetes. Por eso se utiliza un protocolo able (TCP) para la
transferencia.

Existen servidores primarios y secundarios. Ambos tienen autoridad sobre la zona, la diferencia consiste en
que los secundarios funcionan de copia de respaldo y alivian la carga del primario. La repartición de la carga se
debe al resolver, ya que las peticiones DNS son de tipo round robin. Por tanto las consultas serán aleatorias y
prácticamente en la misma cantidad para los servidores tanto primarios como secundarios. De todas formas,
depende de la implementación del resolver. Aunque tanto el servidor primario como el secundario tienen
autoridad sobre la zona, los cheros de conguración sólo constan en el primario y el secundario obtiene la
información de éste. La información se puede obtener de dos formas. Antiguamente el servidor secundario
preguntaba al primario en el momento que expiraba el tiempo que determina la frecuencia de consulta 3. Más

3típicamente cuatro horas

5

tarde se documentó la posibilidad de que fuera el servidor primario el que informara de los cambios de sus
cheros de zona. En este caso se puede obtener la información actualizada más rápidamente. Ambos métodos
de actualización pueden funcionar al mismo tiempo sin mayores problemas. En el primer caso para realizar
la transferencia de zona, el servidor secundario interroga al primario para obtener el registro SOA. Cuando
lo consigue, comprueba que el campo SERIAL 4 ha aumentado. Sólo en ese caso se realiza la transferencia.
En caso de que no se haya actualizado el SERIAL nos ahorramos la transferencia. Existen dos tipos de
transferencia de zona:

completa (axfr ).

incremental (ixfr ).

En el segundo caso sólo se envía la información que se ha modicado. Por lo tanto nos permite ahorrar ancho
de banda.

5. Caché

Los servidores DNS pueden tener como nalidad servir las zonas sobre las que tienen autoridad, o sim-
plemente realizar funciones de caché. En este caso no es necesario congurar nada, sólo poner a funcionar
el DNS. Conforme los clientes lanzan peticiones, el DNS las resuelve y cachea. La utilidad de ésto es que el
tiempo de respuesta en las siguientes consultas es muy bajo, ya que tiene la mayoría de la información en
caché. La información almacenada no perdura eternamente, sino que expirará después de un tiempo 5; super-
ado éste el DNS tendrá que volver a resolver la petición. Esto permite que en el caso de que la información
almacenada en caché sea incorrecta, una vez excedido el TTL se consulta la información actualizada. Un caso
de información incorrecta se produce cuando se han realizado cambios en los RR del servidor autoritativo,
pero todavía perdura la información anterior en la caché de otros servidores.

EL campo TTL es un valor de 32 bits que indica el tiempo en segundos que se mantienen en caché
los RR. Lo utilizan los resolvers para saber cuanto tiempo pueden mantener los RR en memoria antes de
descartarlos. Si la caché de un DNS es consultada por otro DNS, éste le devuelve el TTL decrementado de
forma que se respeta el TTL del servidor autoritativo.

Es útil tener en cuenta que si los clientes son Windows, a pesar de que el servidor DNS cachee las
respuestas, el resolver de Windows también lo hará. De forma que si consta en ella la respuesta no hará uso
del servidor. La caché del resolver de Windows almacena las entrada durante un día independientemente
del TTL indicado. Esto puede perjudicarnos en caso de que la información esté desactualizada. En ese caso
tendríamos que vaciar la caché a mano. Existen casos en los que se establece a 0 el TTL de forma que no
se pueda cachear la información obtenida. Esto se puede utilizar, por ejemplo, con los registros SOA. Este
valor sólo lo conguraremos con datos extremadamente volátiles.

4el que determina si se ha producido una actualización
5TTL

6

6. Forwarders

Se puede acelerar la velocidad de las resoluciones mediante los forwarders. Éstos son hosts a los que
un servidor DNS puede reenviar las consultas en caso que no tenga autoridad sobre la zona y tampoco la
respuesta en caché. Al realizar la c