Prctica 4: DNS

Introduccin
El protocolo DNS (Domain Name System protocol, RFC 1035) es el principal protocolo de 'resolucin de
nombres' usado en redes TCP/IP. Es decir, su misin principal ser convertir 'nombres de mquinas (hosts) de
Internet' a sus respectivas direcciones IP.

Conceptos previos:
Espacio de 'Nombres de Dominio' (Domain Name Space): Todas las mquinas (hosts) en Internet que
quieran usar el protocolo DNS, debern pertenecer a un 'dominio', normalmente llamado 'Nombre de
Dominio' (Domain Name). A su vez, los dominios tienen una dependencia jerrquica entre s,
conformando un gran rbol que es el 'Espacio de Nombres de Dominio'. La 'dependencia jerrquica'
quiere decir que los dominios son como conjuntos, de modo que un dominio puede englobar a otros
dominios, llamados comunmente 'subdominios'.

Los dominios se identifican con nombres de longitud variable, de modo que para identificar un dominio
desde la raz del arbol del 'Espacio de Nombres de Dominio', se separa cada subdomino del dominio al
que pertenece por un punto '.'
Ejemplos de nombres de dominio: 'uam.es' 'ii.uam.es'.
Recursos (Resources): Son los elementos, servicios o grupos que puede haber dentro un dominio. Se
diferencian varias 'clases' de recursos que se identifican por unas pocas letras:
'Direcciones de Mquinas' (conocidos como recursos de clase 'A')
'Servidores de Nombres' (conocidos como recursos de clase 'NS')
'Servidores de Correo' (conocidos como recursos de clase 'MX')
... y muchos otros especificados ms abajo

Cada recurso, al igual que los dominios, tienes un nombre cadena de longitud variable. Un host (
servidor) comn que posea un nombre y una direccin IP ser considerado como un recurso de clase 'A'.
Un ejemplo muy comn de recurso de clase 'A' son los servidores web, a los que se les asigna el nombre
'www'.

Ejemplo: La cadena 'www.ii.uam.es' hace referencia a un recurso clase 'A' llamado 'www' que se
encuentra en el dominio 'ii.uam.es' (en realidad existen 3 dominios: 'ii' que es un subdominio de 'uam.es',
el dominio 'uam' que en un subdominio de 'es' y el propio dominio 'es').



El servidor de nombres (Name Server 'NS')

El servidor de nombres es un 'recurso' dentro de un dominio que tiene una base de datos con informacin sobre
el resto de recursos del dominio.
El servidor de nombres realiza fundamentalmente dos tareas:
Responde a peticiones ('querys') de direccin que provienen de hosts de cualquier dominio (incluido el
suyo), solicitndole una varias direcciones IP para uno varios nombres de hosts. Si el nombre del
host que va en el 'query' es un recurso del dominio al que pertenece (es decir, est en su base de datos),
pues responde (mediante un mensaje tipo 'response') con la direccin IP correspondiente a ese recurso.
En caso de que el recurso (nombre del host del que se quiere saber su IP) no pertenezca al mismo
dominio del servidor de nombres, el propio servidor de nombres realiza una consulta a otro servidor de
nombres que s tiene dicho recurso en su base de datos.
A menudo, los servidores de nombres disponen de una cach con las direcciones de los recursos de otros
dominios, con el fin de evitar hacer consultas repetidamente para un mismo recurso de otro dominio.

Intercambia informacin de su base de datos de recursos con otro servidor de nombres (que puede
pertenecer o no a su dominio). De este modo un servidor de nombres puede tener informacin de otros
muchos servidores de nombres sin necesidad de realizar consultas, cada vez que un cliente le mande un
'query'.
Esta tarea recibe el nombre de 'Transferencia de Zona' y no tiene porqu realizarla un servidor de
nombres necesariamente.

Desde el punto de vista prctico, un servidor de nombres utilizar un protocolo para cada una de sus tareas:
Para responder a peticiones de direccin se usa el protocolo UDP, puerto 53.
Para realizar transferencias de zona se usa el protocolo TCP, puerto 53.



Objeto de la prctica

El objeto de esta prctica ser implementar:
1. Un pequeo cliente de DNS que permita obtener direcciones IP a partir de su nombre.
Para ello, nuestro cliente de DNS (haciendo uso de la librera) deber ser capaz de mandar 'queries' a un
servidor de nombres (DNS) y procesar las respuestas que devuelva. De esta manera nuestro cliente del DNS
ser capaz de convertir nombres de Internet (nombres de dominio) a direcciones IP.

Para realizar las peticiones ('queries') de direccin, deberemos utilizar el protocolo UDP que nos ofrece el
kernel del sistema operativo y mandar datagramas UDP con las 'queries DNS' al puerto 53 de un DNS
cualquiera.

Al final del guin de la prctica se especifica el API que deber tener este sencillo cliente de DNS.


Especificacin del protocolo

A continuacin se dan las especificaciones de las tramas usadas en el protocolo DNS:
Cabecera DNS:
0
0
0
1
0
2
0
3
0
4
0
5
0
6
0
7
0
8
0
9
1
0
1
1
1
2
1
3
1
4
1
5
16
1
7
1
8
1
9
2
0
21 22 23 24
2
5
26 27
2
8
2
9
3
0
3
1
Identification
Q
R
Opcode
A
A
T
C
R
D
R
A
Z
A
D
C
D
Rcode
Total Questions Total Answer RRs
Total Authority RRs Total Additional RRs
Questions []
:::
Answer RRs []
:::
Authority RRs []
:::
Additional RRs []
:::
Identification. 16 bits.
Used to match request/reply packets.
QR, Query/Response. 1 bit.
QR Description
0 Query.
1 Response.
Opcode. 4 bits.
Opcode Description References
0 QUERY, Standard query. RFC 1035
1 IQUERY, Inverse query. RFC 1035
2 STATUS, Server status request. RFC 1035
3 Reserved.
4 Notify. RFC 1996
5 Update. RFC 2136
6 Reserved.
-
15
AA, Authoritative Answer. 1 bit.
Specifies that the responding name server is an authority for the domain name in question section. Note that the
contents of the answer section may have multiple owner names because of aliases. This bit corresponds to the
name which matches the query name, or the first owner name in the answer section.
AA Description
0 Not authoritative.
1 Is authoritative.
TC, Truncated. 1 bit.
Indicates that only the first 512 bytes of the reply was returned.
TC Description
0 Not truncated.
1 Message truncated.
RD, Recursion Desired. 1 bit.
May be set in a query and is copied into the response. If set, the name server is directed to pursue the query
recursively. Recursive query support is optional.
RD Description
0 Recursion not desired.
1 Recursion desired.
RA, Recursion Available. 1 bit.
Indicates if recursive query support is available in the name server.
RA Description
0 Recursive query support not available.
1 Recursive query support available.
Z. 1 bit.
It must be set to zero (0).
AD. 1 bit.
It must be set to zero (0).
CD. 1 bit.
It must be set to zero (0).
Rcode, Return code. 4 bits.


Rcode Description References
0 No error. The request completed successfully. RFC 1035
1 Format error. The name server was unable to interpret the query. RFC 1035
2
Server failure. The name server was unable to process this query due to a problem with the
name server.
RFC 1035
3
Name Error. Meaningful only for responses from an authoritative name server, this code
signifies that the domain name referenced in the query does not exist.
RFC 1035
4 Not Implemented. The name server does not support the requested kind of query. RFC 1035
5
Refused. The name server refuses to perform the specified operation for policy reasons. For
example, a name server may not wish to provide the information to the particular requester,
or a name server may not wish to perform a particular operation (e.g., zone transfer) for
particular data.
RFC 1035
6 YXDomain. Name Exists when it should not. RFC 2136
7 YXRRSet. RR Set Exists when it should not. RFC 2136
8 NXRRSet. RR Set that should exist does not. RFC 2136
9 NotAuth. Server Not Authoritative for zone. RFC 2136
10 NotZone. Name not contained in zone. RFC 2136
11
-
15
Reserved.
Total Questions. 16 bits, unsigned.
Number of entries in the question list that were returned.
Total Answer RRs. 16 bits, unsigned.
Number of entries in the answer resource record list that were returned.
Total Authority RRs. 16 bits, unsigned.
Number of entries in the authority resource record list that were returned.
Total Additional RRs. 16 bits, unsigned.
Number of entries in the additional resource record list that were returned.
Questions[]. Variable length.
A list of zero or more Query structures.
Answer RRs[]. Variable length.
A list of zero or more Answer Resource Record structures.
Authority RRs[]. Variable length.
A list of zero or more Authority Resource Record structures.
Additional RRs[]. Variable length.
A list of zero or more Additional Resource Record structures.


Query. Variable length.
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Query Name
:::
Type Class

Resource Record. Variable length.
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Name
:::
Type Class
TTL
Rdata Length
Rdata
:::

Query Name. Variable length.
The query name corresponds to an Internet name where dots ('.') are suppressed and each word is preceded by
one byte containing its length:
Example: The name 'www.ii.uam.es' must be written in the field as following bytes:
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14
3 w w w 2 i i 3 u a m 2 e s 0


Please note that a zero (0) is added at the end, symbolizing the root at the Domain Name Space.
The maximum size for each domain name (word) is 63 bytes.
Type. 16 bits, unsigned.
Type Description References
1 A. IPv4 address. RFC 1035
2 NS. Authoritative name server. RFC 1035
3 MD. Mail destination. Obsolete use MX instead. RFC 1035
4 MF. Mail forwarder. Obsolete use MX instead. RFC 1035
5 CNAME. Canonical name for an alias. RFC 1035
6 SOA. Marks the start of a zone of authority. RFC 1035
7 MB. Mailbox domain name. RFC 1035
8 MG. Mail group member. RFC 1035
9 MR. Mail rename domain name. RFC 1035
10 NULL. Null resource record. RFC 1035
11 WKS. Well known service description. RFC 1035
12 PTR. Domain name pointer. RFC 1035
13 HINFO. Host information. RFC 1035
14 MINFO. Mailbox or mail list information. RFC 1035
15 MX. Mail exchange. RFC 1035
16 TXT. Text strings. RFC 1035
17 RP. Responsible Person. RFC 1183
18 AFSDB. AFS Data Base location. RFC 1183
19 X25. X.25 PSDN address. RFC 1183
20 ISDN. ISDN address. RFC 1183
21 RT. Route Through. RFC 1183
22 NSAP. NSAP address, NSAP style A record. RFC 1706
23 NSAP-PTR.
24 SIG. Security signature. RFC 2535, RFC 2931
25 KEY. Security key. RFC 2535
26 PX. X.400 mail mapping information. RFC 2163
27 GPOS. Geographical Position. RFC 1712
28 AAAA. IPv6 Address. RFC 1886
29 LOC. Location Information. RFC 1876
30 NXT. Next Domain. RFC 2535
31 EID. Endpoint Identifier.
32
NIMLOC. Nimrod Locator.
NB. NetBIOS general Name Service.

RFC 1002
33
SRV. Server Selection.
NBSTAT. NetBIOS NODE STATUS.
RFC 2052, RFC 2782
RFC 1002
34 ATMA. ATM Address.
35 NAPTR. Naming Authority Pointer. RFC 2168, RFC 2915
36 KX. Key Exchanger. RFC 2230
37 CERT. RFC 2538
38 A6. RFC 2874
39 DNAME. RFC 2672
40 SINK.
41 OPT. RFC 2671
42 APL. RFC 3123
43
-
99

100 UINFO.
101 UID.
102 GID.
103 UNSPEC.
104
-
247

248 ADDRS.
249 TKEY. RFC 2930
250 TSIG. Transaction Signature. RFC 2845
251 IXFR. Incremental transfer. RFC 1995
252 AXFR. A request for a transfer of an entire zone. RFC 1035
253 MAILB. A request for mailbox-related records (MB, MG or MR). RFC 1035
254 MAILA. A request for mail agent RRs. Obsolete. RFC 1035
255 *. A request for all records. RFC 1035

Class. 16 bits, unsigned.
Class Description References
0 Reserved.
1 IN, Internet. RFC 1035.
2
3 CH, Chaos. RFC 1035.
4 HS, Hesiod. RFC 1035.
5
-
253

254 None. RFC 2136.
255 Any (QCLASS only). RFC 1035.
256
-
65534

65535 Reserved.

Name. Variable Length.
May be a name with same format as 'Query Name', or a 'Pointer' if a compression scheme is being used.
A compression scheme can be used if a same name is repeated several times inside a DNS response. In such
case (compression scheme begins to work), a 'pointer' will be used instead of the name.
Important Note: If two highest bits for the first byte are set to 1 (values between 0xC0 ~ 0xFF), it is a 'Pointer',
otherwise it is a name.
A pointer has a fixed size of 16 bits, but 4 highest bits must be set to 0 to work with it.
A pointer is the offset inside the DNS response, where the name can be found.
Names have same format as specified in 'Query Name' and have a variable length.

TTL. 32 bits.
When a "foreign" DNS record is kept in a DNS server's cache, the record's TTL is continuously reduced as time
go by, and when the TTL finally reaches zero the record is removed from the cache.
The returned TTL is current TTL of the DNS record on its cache.
Rdata Length. 16 bits.
Size for next field ('Rdata') in bytes.
Rdata. Size, in bytes, defined on 'Rdata Length'.
Response data depending on the 'query'.
This field, when queries are referred to internet address, will contain the IP address as 4 bytes.



Ejemplo

Para que nuestro cliente de DNS pueda conocer la direccin IP del host 'www.ii.uam.es' deber mandar el
siguiente 'query':








Tras procesar el servidor de nombres el 'query', nos devolver un mensaje UDP con la respuesta DNS:




Notas Importantes:
Para un nico nombre, el servidor de nombres puede devolver varias respuestas vlidas. Esto es debido a los
'alias' que puedan existir para un mismo nombre.
En el caso del host 'www.ii.uam.es', el host 'www' es un alias del host 'afrodita' (ya que los dos son el mismo
host), por lo que probablente tengamos dos respuestas, siendo el campo 'Name' de la segunda respuesta, el
nombre 'afrodita.ii.uam.es'.
La primera respuesta contiene directamente un puntero al nombre de la 'query' que va delante de ella, con ello
aplica el procedimiento de compresin y evita repetir el nombre. El valor del puntero ser 12, que coincide con
el tamao de la cabecera DNS.
Dependiendo del servidor de nombres al que se acceda, podra ocurrir que en la respuesta no nos incluyera el
'query' que le hicimos, por lo que la primera respuesta tendra en su primer campo el 'nombre' (con el formato
adecuado) que solicitamos y no habra un puntero.










Objetivos de la Prctica


El objetivo fundamental de esta prctica ser realizar
1. Un programa/ejecutable que servir de cliente de DNS. Este programa tendr un front-end conocido: el
de nslookup.

API a Implementar.

Se deber definir al menos una una nica funcin:
struct hostent *my_gethostbyname( const char *name );

donde 'name' un puntero a una cadena de caracteres que alberga el nombre que se quiere resolver.

La estructura 'hostent' est definida en la cabecera 'netdb.h' como:
struct hostent
{
char *h_name;
char **h_aliases;
int h_addrtype;
int h_length;
char **h_addr_list;
}
Descripcin de los campos de la estructura:
h_name: Puntero al nombre oficial/cannico.
h_aliases: Puntero a un array de punteros a cadenas de caracteres. El ltimo puntero del array deber ser
siempre NULL. El tamao del array es variable. Cada cadena ser un alias del nombre de dominio
solicitado.
h_addrtype: Tipo de direccin del nombre solicitado.
Deber ser siempre 2.
h_length: Longitud (en bytes) de cada direccin IP del campo 'h_addr_list' respecto al nombre
solicitado.
Deber ser siempre 4.
h_addr_list: Puntero a un array de punteros a direcciones IP. El ltimo puntero del array deber ser
siempre NULL. El tamao del array es variable. Cada direccin IP estar formada por cuatro BYTES.
Nota:: En ningn caso el alumno deber definir esta estructura, porque que YA est definida en la cabecera
<netdb.h>.
El alumno simplemente deber incluir dicha cabecera en cualquier programa que haga uso de su librera.


TAREAS QUE DEBERA HACER LA FUNCION 'my_gethostbyname':
1. Leer la variable de entorno RESOLV_HOST_CONF mediante la funcin getenv().
Dicha variable tendr el path completo a un fichero de texto:
Ejemplo: /home/alumno/resolv.conf

2. Abrir el fichero indicado por la variable y leerlo hasta encontrar una linea que tenga el formato:
nameserver x.x.x.x
Donde 'x.x.x.x' representa la direccin IP de un servidor de nombres de dominio (DNS)

3. A partir del parmetro de entrada 'name', se deber formar una QUERY de acuerdo al protocolo DNS
que se ha explicado anteriormente.

4. La funcin enviar la 'query' de DNS usando el protocolo UDP a la direccin IP del servidor de nombres
especificado en el fichero de texto.
Para ello deber usar la funcin sendto() del API de sockets del sistema operativo.

Este API ser explicado en clase, aunque se puede descargar un simple programa que explica como
enviar y recibir datagramas UDP de un modo sencillo: sock.c

5. Habr que esperar a la contestacin (si es que hay alguna) del DNS.
Para ello se llamarn a las funciones recv() recvfrom() del API de socket (ver el ejemplo sock.c)

6. En caso de recibirse respuesta del DNS, habr que parsear (procesar) la respuesta recibida. Este 'reply'
tendr la estructura de una respuesta de DNS segn lo explicado en la seccin anterior.

7. En base al contenido de la respuesta del DNS, habr que generar una estructura hostent que ser
devuelta.
Si no se hubiese recibido respuesta alguna del DNS, la respuesta no hubiera tenido contenido til
alguno, la funcin deber devolver NULL.
La funcin my_gethostbyname() que deber implementarse es prima hermana de una funcin de la
librera estandar llamada gethostbyname().
! Ambas funciones debern hacer prcticamente lo mismo !


El siguiente programa de C, es un sencillo ejemplo de uso de la funcin 'estandar': dnr_ex.c

Este sencillo programa deber funcionar de un modo similar utilizando la nueva funcin implementada
El alumno puede descomentar una linea para hacer que el programa utilice la funcin que hay que implementar.


Cliente de DNS

El alumno deber implementar un sencillo programa de prueba de su librera esttica.
Este programa ser un cliente de DNS y deber llamarse nslookup.

El cliente de DNS que hay que realizar deber tener la misma apariencia que la utilidad nslookup del sistema
operativo. Cuando esta utilidad es ejecutada se queda esperando comandos que el usuario podr escribir.

Los comandos que deber admitir son:
ADD &ltdirI P>: Para cambiar la direccin IP del servidor de DNS al que se realizan las consultas.
&ltnombre de host>: Para obtener informacin de dicho nombre de host mediante una consulta al
servidor seleccionado de DNS.
Cuando se realice una consulta al servidor de DNS (por peticin del usuario mediante el comando
correspondiente), se har una llamada a la funcin my_gethostbyname() implementada en la librera esttica y
se mostrar por pantalla la respuesta (si la hubiere) con el mismo formato que lo hace la utilidad nslookup.

En el caso de que se llame al comando ADD, el cliente de DNS deber crear un fichero temporal e introducir
una linea con la palabra 'nameserver' y la direccin IP del DNS que ha introducido el usuario mediante el
comando ADD.
A continuacin deber crear una variable de entorno RESOLV_HOST_CONF, mediante la funcion putenv(),
de modo que dicha variable albergue la ruta completa y el nombre del fichero temporal creado.
De este modo, cuando se ejecute la funcin my_gethostbyname() se mande el 'query' de DNS al servidor que el
usuario haya dictaminado.



Objetivos:
Implementar una librera esttica 'dnr.a' que albergue la funcin my_gethostbyname(), similar a la funcin
gethostbyname() de la librera estandar, que permita hacer queries a un DNS y procesar la respuesta que nos
enve un DNS.
Implementar un pequeo cliente de DNS, con la apariencia del nslookup, que permita al usuario introducir la
direccin IP de un DNA cualquiera y el nombre de un host del que quiere obtener la IP. Llamar a la funcin
my_gethostbyname() y mostrar la informacin recibida (si fue posible obtenerla).
En caso de haber encontrado algn problema en cualquiera de los protocolos, deber mostrar qu error impidi
obtener la direccin IP deseada.
Estudiar la eficiencia del metodo de compresin. El alumno deber entregar un fichero TXT con el anlisis de
la compresin que se consigue al solicitar al DNS una IP con alias como por ejemplo www.ii.uam.es, cul es el
ratio de compresin conseguida para esta Query ?
Implementar funciones adicionales en la librera, que permitan obtener informacin extra del servidor DNS
(servidores de correo MX, informacin de la mquina HINFO, localizacin LOC, etc...)
Estas funciones son de libre especificacin y diseo del alumno, aunque deber entregar un sencillo programa
que muestre su uso.
Implementar funciones adicionales en la librera, que permitan obtener los nombres de host a partir de
direcciones IP (es decir, resolucin inversa) Estas funciones son de libre especificacin y diseo del alumno,
aunque deber entregar un sencillo programa que muestre su uso.




Notas y ayudas al desarrollo
No es un objetivo de esta prctica explicar cmo funcionan cmo se usan los sockets de LINUX. Sin
embargo te ofrecemos un pequeo programa de ejemplo que manda y recibe datagramas UDP a/desde el
servidor de DNS de la UAM. Sin tocar una sola linea de cdigo podris comprobar al menos, la
respuesta de error que os devuelve el DNS: sock.c

IMPORTANTE: El ejemplo incluye todo lo necesario sobre 'sockets' para implementar la prctica,
incluidos los 'timeouts'.
Un servidor de nombres que puedes utilizar para probar las prcticas puede ser: 150.244.9.200
Se trata de un servidor DNS real y muy usado dentro de la UAM.
Si tienes alguna duda sobre cmo funciona el programa nslookup, simplemente ejectalo y vers como
es fcil de usar. De todos modos siempre puedes consultar la ayuda del linux: man nslookup
Si tienes dudas sobre cmo funciona la funcin my_gethostbyname(), consulta la ayuda sobre la
funcion gethostbyname(): man gethostbyname.
Un sencillo programa de ejemplo puede ser: dnr_ex.c
Es importante volver a sealar, que al usarse ahora el interfaz de sockets, ya no es necesario ejecutar el
programa ethd utilizado en prcticas anteriores. Cuidado: Si ejecutis el demonio ethd, se activarn los
filtros de TCP/IP, y los sockets no mandarn ni recibirn datagrama alguno.
Aquellos que queris desarrollar la prctica en casa necesitaris tener acceso a Internet a un servidor
de DNS. Como configurar en casa un servidor de DNS es una tarea bastante compleja, por favor
consulta a tu profesor de prcticas.

En caso de que dispongis de acceso a Internet, lo nico que deberis saber es cmo conectaros a
Internet y cul es el servidor de DNS ms cercano a vuestro host (para evitar latencias en las respuestas).
De cualquier modo, una vez que tengis acceso a Internet, podis utilizar cualquier servidor de DNS
disponible en la red, entre ellos el 150.244.9.200 (por lo que os podis asegurar el mismo
comportamiento que desde los laboratorios).