DNS

Domain Name System

Paula Cecilia Martinez

Emmanuel N. Millán
DNS: Definición
● El DNS (Domain Name System) es una base de datos distribuida y jerárquica que es
utilizada por aplicaciones TCP/IP para asociar nombres de máquinas y direcciones IP, y
para proveer información sobre servidores de correo.

● Es distribuida porque ningún sitio en Internet tiene toda la información.

● Cada sitio (universidad, empresa, institución, etc.) mantiene su propia base de datos y
ejecuta un servicio que otros sistemas desde Internet (clientes) pueden consultar.

● El DNS provee el protocolo que permite que los clientes y servidores se comuniquen
entre sí.
DNS: resolver
● Desde la capa aplicación, se accede al DNS a través del “resolver”. En Unix/Linux el
resolver se accede principalmente a través de dos funciones, gethostbyname y
gethostbyaddr, que se encuentran en las librerías básicas del SO.

● gethostbyname recibe el nombre del host como parámetro de entrada y devuelve la

dirección IP que le corresponde.

● gethostbyaddr recibe una dirección IP como parámetro de entrada y devuelve el

nombre del host.

● El resolver debe contactar a uno o más servidores DNS para poder realizar la
resolución.
DNS: resolver
● El resolver no es parte del kernel del SO, como si lo son los protocolos TCP/IP.

● La aplicación que desea realizar la comunicación debe convertir el nombre del

host a una dirección IP para poder abrir una conexión TCP o enviar un
datagrama UDP a la máquina destino.

● Los protocolos TCP/IP no tienen conocimiento de que es un nombre de

máquina o del DNS, solo se manejan con direcciones IP.
DNS: resolver 1 Nombre de Host
Nombre de Host
Resolver HTTP
1. El browser tiene un nombre de host Dirección IP
2 3 Establecer conexión
con el que debe iniciar una conexión, con dirección IP
solicita al Resolver que le provee la TCP
dirección IP que le corresponde.
Enviar paquete IP
4 a dirección IP
2. El Resolver utiliza el servicio de DNS
IP
para obtener la dirección IP que le 5 ARP
9
corresponde al host dado. 6
ARP request Driver Ethernet
3. El browser (a través del SO) inicia una
conexión TCP con la IP obtenida del
resolver. Driver 8 Driver
Ethernet Ethernet
4. El protocolo TCP solicita al SO enviar
un paquete IP al destino. ARP ARP IP
7 7
TCP
DNS: resolver 1
Nombre de Host
Nombre de Host

Resolver HTTP
5. Debido a que el destino es local, es Dirección IP
2 3 Establecer conexión
necesario obtener la dirección MAC del con dirección IP
destino, aquí interviene ARP.
TCP
6. Se enviar un ARP request tipo broadcast Enviar paquete IP
4 a dirección IP
Ethernet a toda la red local.
IP
7. Lo reciben las máquinas conectadas en la 5 ARP
9
red, las que no tienen asignado esa 6
Driver Ethernet
dirección IP descartan el pedido. ARP request

8. El equipo que tiene esa dirección IP

contesta con ARP reply hacia el emisor del Driver 8 Driver
ARP request con su dirección MAC. Ethernet Ethernet

9. Finalmente, la PC origen puede enviar el

ARP ARP IP
paquete IP encapsulado en Ethernet con IP
destino y MAC destino apropiadas. 7 7
TCP
DNS: ¿cómo funciona el resolver?
1. La máquina cliente ejecuta el lado cliente de la aplicación DNS (el resolver).
2. El navegador extrae el nombre de host, [Link], del URL y pasa el nombre
de host al lado del cliente de la aplicación DNS (al resolver).
3. El cliente DNS envía una consulta que contiene el nombre de host a un servidor DNS.
4. El cliente DNS recibe finalmente una respuesta, que incluye la dirección IP
correspondiente al nombre del host.
5. Una vez que el navegador recibe la dirección IP del servidor DNS (a través del resolver),
puede iniciar una conexión TCP con el proceso servidor HTTP localizado en el puerto
80 en esa dirección.

En el ejemplo utilizamos un navegador como aplicación (HTTP), el proceso sería el mismo si

utilizáramos otro protocolo de la capa de aplicación como SMTP, POP3, IMAP, etc.
Clases de servidores DNS
Para poder ver como funciona el resolver, en fin, cómo funciona un cliente DNS y los servidores DNS, es
necesario primero describir cómo los servidores DNS están clasificados:

● Servidores DNS raíz. En Internet, existen 13 servidores DNS raíz (etiquetados como A hasta M, al 2009).
Aunque hemos hecho referencia a cada uno de los 13 servidores DNS raíz como si fueran un único servidor,
cada “servidor” es realmente una agrupación (cluster) de servidores replicados, tanto por propósitos de
seguridad como de fiabilidad.

● Servidores de dominio de nivel superior (TLD). Estos servidores son responsables de los dominios de nivel
superior, como son com, org, net, edu y gov, y todos los dominios de nivel superior correspondientes a los
distintos países, como por ejemplo, uk, fr, ca y jp.

● Servidores DNS autoritativos. Todas las organizaciones que tienen hosts accesibles públicamente a través
de Internet deben proporcionar registros DNS accesibles públicamente que establezcan la correspondencia
entre los nombres de dichos hosts y sus direcciones IP. Un servidor DNS autoritativo de una organización
alberga estos registros DNS. La mayoría de las universidades y de las empresas de gran tamaño
implementan y mantienen sus propios servidores DNS autoritativos principal y secundario (backup).
DNS: jerarquía
Interacción entre
servidores DNS

● El host [Link]
quiere conocer la direccion IP de
[Link].

● El servidor DNS local es

[Link]

● El servidor autoritativo de
[Link] es [Link]
Interacción entre
servidores DNS

1. El host labredes08 envía en primer lugar un mensaje

de consulta DNS a su servidor DNS local,
[Link]. El mensaje de consulta contiene
el nombre de host que debe ser traducido,
[Link]

2. El servidor DNS local reenvía la consulta a un servidor

DNS raíz,

3. el cual toma el sufijo .com y devuelve al servidor DNS

local una lista de las direcciones IP de los servidores
TLD responsables del dominio .com.

4. El servidor DNS local reenvía a continuación el

mensaje de consulta a uno de estos servidores TLD.
Interacción entre
servidores DNS
5. El servidor TLD toma nota del sufijo [Link] y
responde con la dirección IP del servidor DNS
autoritativo correspondiente a Google, es decir,
[Link].
6. Por último, el servidor DNS local reenvía la consulta
directamente a [Link]
7. El dns autoritativo de [Link] responde con la
dirección IP de [Link] al DNS local.
8. El DNS local [Link] responde a
labredes08 con la dirección IP de [Link].

En este ejemplo, para obtener la dirección correspondiente a

un nombre de host, se han envíado ocho mensajes DNS:
utilizamos un cache DNS para reducir el tráfico.
Resolver
● Para la aplicación que necesita obtener una dirección IP a partir de un nombre de host,
el resolver es una caja negra.

● Le envia un nombre de host y el resolver le devuelve una dirección IP.

● El funcionamiento del DNS puede involucrar comunicaciones entre varios equipos,

proceso que es transparente para la aplicación que solicitó la traducción de nombre de
host hacia dirección IP.

● La consulta DNS vista en las slides anteriores es tanto recursiva como iterativa

● El cliente DNS le pide a su servidor DNS local que le resuelva la consulta DNS
(recursiva), luego este servidor DNS local realiza consultas iterativas al resto de los
servidores DNS (Raíz, TLD y autoritativo).
 DNS recursivo
1. El cliente labredes09 solicita a su servidor DNS local que
le de la dirección IP de [Link]
2. El DNS local le solicita a un servidor Raíz que este le
resuelva la consulta.
3. El DNS Raíz se comunica con el DNS TLD para que
resuelva el pedido.
4. El DNS TLD se comunica directamente con el DNS
autoritativo de [Link]
5. El DNS autoritativo responde la consulta al DNS TLD
6. El TLD le responde al DNS Raíz
7. El DNS Raíz le responde al DNS local
8. El DNS local le entrega la respuesta al cliente labredes09
Iterativo vs Recursivo
● Iterativo:
○ si un servidor DNS tiene la respuesta a una consulta (porque está en su cache) o es el servidor
autoritativo de la zona consultada, contesta directamente con la respuesta.

○ si el servidor DNS no tiene la respuesta, devuelve información acerca de a cual servidor DNS
se le tiene que preguntar, ej. DNS Raiz devuelve el IP del servidor DNS TLD, este ultimo
devuelve el IP del servidor DNS de Google.

● Recursivo:
○ Estos servidores DNS devuelven dos tipos de mensajes:
■ la respuesta a la consulta solicitada
■ un mensaje de error.
Iterativo vs Recursivo
¿Porque existen consultas iterativas y recursivas?
● Veamos nuevamente la imagen anterior….

● ¿qué particularidad tiene la consulta recursiva con respecto a la iterativa?

● ¿Que pasa cuando el servidor DNS RyT hace una consulta en el caso iterativo al servidor Raíz? y qué
pasa cuando lo hace en el caso recursivo?

● La sobrecarga que implica para un servidor DNS recursivo puede ser excesiva si recibe muchos
pedidos.

● Por este motivo, los servidores Raíz y TLD no trabajan de forma recursiva, solo lo hacen de forma
iterativa.

● Un servidor DNS local (dentro de la red de una empresa/institución) suele funcionar de forma
recursiva hacia sus clientes internos, recibe pedidos de resolución de nombres y se encarga de todo
el proceso de resolución, entregando a sus clientes la dirección IP solicitada.
Iterativo vs Recursivo
DNS: Arquitectura
● El sistema DNS funciona principalmente en base al protocolo UDP en el puerto 53.

● El sistema está estructurado en forma de "árbol". Cada nodo del árbol está compuesto
por un grupo de servidores que se encargan de resolver un conjunto de dominios (zona
de autoridad).

● Un servidor puede delegar en otro (u otros) la autoridad sobre alguna de sus sub-zonas
(esto es, algún subdominio de la zona sobre la que él tiene autoridad).

● Un subdominio puede verse como una especialización de un dominio de nivel anterior.

DNS: jerarquía
● Cada nodo tiene una etiqueta de hasta 63 caracteres. La raíz del árbol tiene una
etiqueta especial nula.

● No hay distinción entre mayúsculas y minúsculas en las etiquetas.

● El nombre del dominio de cualquier nodo en el árbol es su lista de etiquetas,

comenzando desde el nodo y hasta la raíz, utilizando un punto para separar las
etiquetas.

● Cada nodo del árbol debe tener un nombre de dominio único, pero la misma etiqueta se
puede utilizar en distintos puntos del árbol.

● Un nombre de dominio que termina con un punto se lo denomina un nombre de dominio

absoluto o “fully qualified domain name” (FQDN).
DNS: jerarquía
● Una característica importante del DNS es la delegación de responsabilidad dentro del
árbol DNS.
● Ninguna entidad administra todas las etiquetas del árbol.
● Una sola entidad (la organización NIC) mantiene una porción del árbol (los dominios del
nivel superior) y delega la responsabilidad a otros servidores/organizaciones para
zonas específicas.
● Una zona es una rama del árbol DNS que es administrada separadamente.
● Una zona común es un dominio de segundo nivel o tercer nivel, por ejemplo,
[Link].
● Muchos dominios de segundo o tercer nivel dividen su zona en zonas más pequeñas.
● Por ejemplo: [Link], [Link], fi[Link], [Link].
DNS: funcionamiento
● Una vez que la autoridad para una zona fue delegada, es responsabilidad de la persona
a cargo de la zona proveer de múltiples servidores DNS para esa zona.

● Cuando un nuevo sistema es instalado en una zona, el administrador del DNS para la
zona debe agregar el nombre y dirección IP del sistema en la base de datos del DNS.

● Se dice que un servidor de nombres tiene autoridad o responsabilidad sobre una zona
o múltiples zonas.

● La persona responsable de una zona debe proveer un servidor de nombres primario

para la zona y uno o más servidores de nombres secundarios.

● El servidor primario y los secundarios deben ser independientes y redundantes para

que la disponibilidad del servicio de nombres no se vea afectada por un solo punto de
fallas.
DNS: funcionamiento
● La diferencia principal entre el servidor primario y secundario es que el primario carga
toda la información de la zona desde archivos del disco.

● Mientras que los servidores secundarios obtienen toda la información desde el primario.

● Cuando un serv. secundario obtiene la información de la zona se denomina una

transferencia de zona.

● Cuando se agrega un nuevo host en el archivo de zona del serv. primario, se debe
reiniciar el serv. primario.

● Los serv. secundarios deben consultar al serv. primario (normalmente cada 3 horas) y si
el primario tiene datos nuevos, el secundario solicita la transferencia de zona.
DNS: funcionamiento
● Cuando un servidor es consultado por un dominio y este no sabe la respuesta, se debe consultar a otro
servidor (por esto es distribuido).
● No todos los servidores de nombres deben saber como contactar a todos los servidores de nombres.
● Cada servidor de nombres debe saber cómo (a través de la dirección IP) contactar a los servidores raíz
(root), actualmente hay 13 servidores raíz,
● Cada servidor raíz debe conocer el nombre e IP de cada servidor de nombres autoritario para todos los
dominios de segundo nivel.
● Esto implica un proceso iterativo: el serv. de nombres que necesita saber el IP de un dominio consulta a
un servidor raíz, este contesta con el IP de otro servidor de segundo nivel, y así sucesivamente
● Los servidores de DNS también almacenan en caché. Cuando un serv. de nombres recibe información
acerca del IP de un dominio, la guarda para poder entregarla nuevamente cuando sea solicitada y no
realizar nuevamente la consulta.
DNS: formato del mensaje

● El mensaje tiene un encabezado fijo de 12

bytes seguido por cuatro campos de
tamaño variable.

● El identificador es seteado por el cliente y

devuelto por el servidor. Le permite al
cliente asociar las respuestas a las consultas
realizadas.

● El campo flags de 16 bits está dividido en

varias partes.
DNS: flags QR
1
opcode
4
AA
1
TC
1
RD
1
RA
1
(zero)
3
rcode
4

Comenzando desde el bit de la izquierda:

● QR campo de un bit: 0 significa que es una consulta, 1 una respuesta.

● opcode tiene 4 bits: 0 consulta estándar, 1 consulta inversa y 2 pedido de estado del
servidor.

● AA tiene un bit y significa “respuesta autoritativa”: el servidor de nombres es

autoritativo para el dominio de la sección de pregunta.

● TC tiene un bit y significa “truncado”: con UDP significa que el tamaño total de la
respuesta excede los 512 bytes y solo los primeros 512 fueron contestados.
DNS: flags
QR opcode AA TC RD RA (zero) rcode
1 4 1 1 1 1 3 4

● RD tiene un bit y significa “se desea recursión”: este bit puede ser seteado en una consulta y luego
devuelto en la respuesta. Este flag le dice al servidor de nombres que gestione la consulta el mismo
(consulta recursiva). Si el bit no está seteado, y el servidor no tiene una respuesta autoritativa, el
servidor consultado devuelve una lista de otros servidores a los cuales el cliente debe consultar
(consulta iterativa).

● RA tiene un bit y significa “se dispone de recursión”. Este bit está seteado en la respuesta si el
servidor soporta recursión.

● Tres bits que deben ser 0.

● rcode es un campo de 4 bits con el código de retorno. Los valores comunes son 0 (sin error) y 3 (error
de nombre). Un error de nombre es solo retornado por el servidor de nombres autoritativo y significa
que el dominio solicitado en la consulta no existe.
DNS: encabezado
● Luego de los flags hay cuatro campos de 16 bits
que especifican el número de entradas en los
cuatro campos de tamaño variable que
completan el mensaje (en celeste).

● Para una consulta, el número de preguntas

normalmente es 1 y los otros tres campos son 0.

● Para una respuesta, el número de respuestas es 1

y los restantes dos pueden ser 0 o distintos de 0.
 0 15 16 31

DNS: mensaje query name

sección preguntas
query type query class

● El formato de cada pregunta en la sección preguntas del mensaje se ve en la imagen.

● Normalmente hay una sola pregunta.
● Query name es el nombre o dominio que se está buscando (ej: [Link]). Es una secuencia de
una o más etiquetas.
● Cada pregunta tiene un query type (tipo de pregunta, llamada registro de recurso) y a cada respuesta le
corresponde un tipo.
● Hay 20 tipos distintos, algunos obsoletos. Los más comunes son: A para solicitar el IP que le
corresponde a un nombre, PTR para solicitar los nombres que le corresponden a una IP.
● Query class es normalmente 1, para solicitar direcciones IP. En algunos casos se permiten devolver
otros valores que no sean direcciones IP.
 DNS: mensaje - sección respuestas
Los tres últimos campos del mensaje DNS,
respuestas, autoridad y información adicional, 0 15 16 31
comparten un formato común llamado resource domain name
record o RR (registro de recursos).
type class
● Domain name es el nombre al cual los time-to-live
siguientes datos de recurso resource data length
corresponden. resource data

● Type especifica uno de los códigos RR de

tipos (A, PTR, CNAME, NS, MX, etc).
DNS: mensaje - sección respuestas

● Class es 1 para datos IP.

0 15 16 31
● El campo Time-to-live es el número de
domain name
segundos que el RR puede ser almacenado
por el cliente, generalmente tienen un TTL type class
de 2 días.
time-to-live
● El campo resource data length especifica resource data length

la cantidad de datos de recurso (resource resource data

data). Para un tipo 1 (registro A) el dato de
recurso es una dirección IP (4 bytes).
 DNS: ejemplo
● Se realiza un ping a un dominio.
# ping [Link]

● Con el sniffer tcpdump se pueden ver los mensajes DNS:

# tcpdump -n

[Link].071137 IP [Link].37169 > [Link].53: 32554+ A? [Link]. (32)

[Link].150141 IP [Link].53 > [Link].37169: 32554 4/0/0 CNAME [Link]., A
[Link], A [Link], A [Link] (102)
[Link].234940 IP [Link] > [Link]: ICMP echo request, id 4320, seq 1, length 64
[Link].844236 IP [Link] > [Link]: ICMP echo reply, id 4320, seq 1, length 64

● El sniffer muestra en el primer mensaje la solicitud del registro A (address o dirección) del dominio
[Link] al DNS de google ([Link]) al puerto destino 53.
● Luego el DNS de google contesta desde el puerto 53 hacia el IP que originó la consulta con un registro CNAME
(Canonical Name o nombre canónico) y todos los registros A (dirección) con los IPs que le corresponde para ese
nombre de dominio.
DNS: ejemplo
● El comando host permite realizar consultas a servidores DNS:

# host [Link]
[Link] is an alias for [Link].
[Link] has address [Link]
[Link] has address [Link]
[Link] has address [Link]
[Link] has IPv6 address [Link]
[Link] has IPv6 address [Link]

# host [Link]
[Link].[Link] domain name pointer [Link].
DNS: consultas inversas

● Una consulta DNS inversa es la búsqueda de un nombre de dominio a partir de una dirección IP.

● Para realizar las consultas inversas se utiliza la rama del árbol DNS [Link].

● Cuando una organización obtiene la autoridad para una porción del espacio de nombres DNS (un
dominio, ej: [Link].), también obtiene autoridad sobre una porción del espacio de nombres
[Link].

● Por ejemplo: el FQDN [Link] resuelve a la IP [Link], y su dirección inversa es

[Link].[Link].

● Si uno buscara el FQDN de una IP determinada con el comando host [Link], la búsqueda se
realiza en el árbol DNS desde arpa -> in-addr -> 190 -> 220 -> 130 -> 50 y se devuelve el FQDN que le
corresponde.
 DNS: ejemplo consulta inversa
# host [Link]
[Link].[Link] domain name pointer [Link].

# tcpdump -n
[Link].534079 IP [Link].50513 > [Link].53: 3125+ PTR? [Link].[Link]. (45)
[Link].711307 IP [Link].53 > [Link].50513: 3125 1/0/0 PTR [Link]. (77)
DNS: Resource Records - RR
Hay diversos registros de recursos los más comunes son:
● A: un registro A define una dirección IP (Address).
● PTR: registro puntero (PoinTeR, PTR) utilizado para consultas inversas.
● CNAME: Nombre canónico (Canonical Name), representa un nombre de dominio,
también se lo llama “alias”. Por ejemplo: [Link] es un CNAME de
[Link].
● MX: registro de intercambio de correo (Mail eXchange). Se utiliza para indicar que
sistema tiene servicio de correo SMTP. También para proveer un servidor de entrega de
correos alternativo, entre otros usos.
● NS: Servidor de Nombres (Name Server), especifica los servidores DNS para un dominio
autoritativo.
 DNS: caching
● Para reducir el tráfico DNS en Internet, todos los servidores de nombres utilizan una cache.

● En la implementación estándar de Unix/Linux la cache se encuentra en el servidor, no en el

resolver. Lo cual hace que la caché esté disponible para todas las aplicaciones del sistema.

● Por ejemplo, al ejecutar el comando dig hacia un DNS que tenga la cache activada:
dig @IPServidorDNS [Link]

El comando dig mostrará todos los registros encontrados y un tiempo de ejecución de la consulta, por
ejemplo
;; Query time: 1640 msec

Si se ejecuta el mismo comando dig nuevamente, el tiempo de ejecución de la consulta debería ser
considerablemente más bajo, por ejemplo:
;; Query time: 1 msec
DNS: TCP y UDP
DNS utiliza ambos protocolos, TCP y UDP.

● Las consultas en general se realizan con UDP, cuando una respuesta tiene activado el
bit TC (truncado), significa que el tamaño de la respuesta excede los 512 bytes, con lo
cual el resolver (cliente) deberá realizar una nueva consulta ya que la primer consulta
solo devolvió los primeros 512 bytes y no la respuesta completa. Esta nueva consulta se
realiza con TCP en lugar de UDP.

● El segundo caso de uso que hace DNS del protocolo TCP es durante la transferencia de
zona desde un servidor primario a un secundario.
DNS: TCP y UDP
● Debido a que DNS utiliza principalmente UDP, el resolver y el servidor de nombres
deben realizar controles de tiempo de espera y retransmisión.

● También, a diferencia de otros protocolos que utilizan UDP (TFTP, BOOTP y SNMP) que
operan en redes locales, las operaciones DNS generalmente atraviesan redes de área
amplia.

● La tasa de pérdida de paquetes y la variabilidad de los tiempos de transmisión son

normalmente más altos en redes WAN que LAN, aumentando la importancia de buenos
algoritmos de retransmisión y tiempo de espera en los clientes DNS.
Referencias
● TCP/IP Illustrated, Stevens y Fall, 2nd Edition.

● Redes de computadoras, un enfoque descendente, James Kurose, Keith Ross. Pearson, quinta edición.

● Unix and Linux System Administration Handbook. Evi Nemeth et al. Fourth/Fifth Edition. Prentice Hall.