Seminario 1: Introducción a los

protocolos de comunicaciones
Tecnología de Redes

Escuela Técnica Superior de Ingeniería Informática de Granada (ETSIIT)

José Antonio Córdoba Gómez

4º Ingeniería Informática (1º Cuatrimestre)
Granada - 6 de octubre de 2018
Índice general

1. Introducción 3
1.1. Funcionales y servicios . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Mensajes y Codificación . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1. Estructura Mensaje DNS . . . . . . . . . . . . . . . . . . . . . 5
1.2.2. Sección de cabecera DNS . . . . . . . . . . . . . . . . . . . . . 6
1.2.3. Sección de Consulta . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.4. Sección de Respuesta . . . . . . . . . . . . . . . . . . . . . . . 8

2. Intercambio de datos. Análisis 10

3. Procolos más usados 15

A. Sesión de Captura Propia 17

B. Información adicional 20

1
Índice de figuras

1.1. Familia de protocolos TCP/IP . . . . . . . . . . . . . . . . . . . . . . 4

1.2. Estructura de la cabecera de un mensaje DNS . . . . . . . . . . . . . 5
1.3. Representación detallada de la cabecera de un mensaje DNS . . . . . 6
1.4. Formato de la sección de consulta de un mensaje DNS . . . . . . . . 7
1.5. Formato de la sección de respuesta de un mensaje DNS . . . . . . . . 8

2.1. Visión general tráfico . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2. Observando dns en el tráfico . . . . . . . . . . . . . . . . . . . . . . . 11
2.3. Analizando un conjunto discreto del tráfico . . . . . . . . . . . . . . . 12
2.4. Origen y destino del tráfico . . . . . . . . . . . . . . . . . . . . . . . 12
2.5. Información IP del tráfico . . . . . . . . . . . . . . . . . . . . . . . . 13
2.6. Información UDP del tráfico . . . . . . . . . . . . . . . . . . . . . . . 13
2.7. Información DNS del tráfico . . . . . . . . . . . . . . . . . . . . . . . 14

3.1. Tx/Rx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2. Estadísticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

A.1. Captura de búsqueda UGR . . . . . . . . . . . . . . . . . . . . . . . 17

A.2. Información física . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
A.3. Información IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
A.4. Información DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
A.5. Información DNS Respuesta . . . . . . . . . . . . . . . . . . . . . . . 19

B.1. Host y nslookup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2
Capítulo 1

Introducción

Para la resolución del seminario 1, Introducción a los protocolos de comunicacio-

nes, hemos propuesto analizar una traza del protocolo Domain Name Service,
denominado de aquí en adelante, DNS

Inicialmente la estandarización de este protocolo fue planteada en el RFC 881

[RFC 881], aunque a día de hoy se emplean variaciones sobre el RFC 1034 [RFC 881]
y 1035 [RFC 881].

Nació de la necesidad de recordar de una forma sencilla los nombres de todos los
servidores conectados a Internet. Una idea primitiva anterior a la consecución del
DNS es SRI, que consiste en un archivo que contenía todos los nombres de domi-
nio conocidos. El crecimiento explosivo de la red fue la causa de que un sistema de
nombres centralizado no resultara nada práctico, así que en 1983 se plantea el primer
RFC, el 881 y tras largas discusiones emitidas, definien lo que hoy ha evolucionado
hacia el DNS modeno.

1.1. Funcionalidades y servicios

Dentro de la familia de protocolos que conforman la internet que conocemos hoy
día 1.1, el protocolo DNS se encontraría la capa de aplicación del modelo TCP/IP.

El DNS es conocido también por Sistema de nombres de dominio y es un

sistema de bases de datos distribuidas y jerarquizadas que se emplea para poder
gestionar los nombres de los sistemas principales y sus direcciones IP asociadas. El
planteamiento de resolución es semejante a un listín telefónico común

3
 El uso de DNS implica que los usuarios puedan utilizar nombres sencillos, como
por ejemplo www.ugr.es para localizar un sistema, en lugar de emplear la dirección
IP (xxx.xxx.xxx.xxx).

Para llevar a cabo todas sus funciones usa por defecto el puerto 53 a nivel de ser-
vidor. Para mejorar el rendimiento, ya que es un protocolo muy usado, las consultas
utilizan como protocolo de transporte UDP.

Figura 1.1: Familia de protocolos TCP/IP

Podemos enumerar los servicios del DNS como

1. Resolución de nombres: Dado el nombre completo de un host (por ejemplo
www.ugr.es), obtener su dirección IP.
2. Resolución inversa de direcciones: Es el mecanismo inverso al anterior. Consiste
en, dada una dirección IP, obtener el nombre asociado a la misma.
3. Resolución de servidores de correo: Dado un nombre de dominio (por ejemplo
outlook.com) obtener el servidor a través del cual debe realizarse la entrega del
correo electrónico (imap-mail.outlook.com).

4
1.2. Mensajes y Codificación
El protocolo DNS usa un formato común de mensaje 1.2.1 para todas las tran-
sacciones que ocurren entre el cliente y el servidor. Los mensajes están encapsulados
sobre UDP o TCP usando un número de puerto.

1.2.1. Estructura de un mensaje DNS

Todas las comunicaciones dentro del protocolo de dominio se llevan a cabo en un
solo formato llamado mensaje. 1.2.1

El formato de mensaje de nivel superior está dividido en 5 secciones (algunas de

las cuales están vacías en ciertos casos) que se muestran en la figura 1.2.2

+---------------------+
| Header |
+---------------------+
| Question | the question for the name server
+---------------------+
| Answer | RRs answering the question
+---------------------+
| Authority | RRs pointing toward an authority
+---------------------+
| Additional | RRs holding additional information
+---------------------+

Figura 1.2: Estructura de la cabecera de un mensaje DNS

Los mensajes de DNS deben ser de una tamaño inferior a 512 bytes. Cuando es
necesario realizar transferencias de mayor tamaño, los mensajes se encapsulan direc-
tamente sobre TCP.

Un caso muy concreto en el que se puede necesitar un intercambio de mayor tama-

ño es en el proceso de transferencia de zona de DNS, en el cual se puede replicar
la base de datos a través de un conjunto de servidores DNS.

5
1.2.2. Sección de cabecera de un mensaje DNS
Los campos Identification, Flags, Number of question, Number of answers RR,
Number of authority RRs y Number of aditional RRs son de 16 bits de longitud
(2 bytes). Tal y como se representa en el diagrama 1.2.2, los seis primeros campos
ocuparía un total de 96 bits (12 bytes), formando así, la cabecera de un mensaje
DNS.

Figura 1.3: Representación detallada de la cabecera de un mensaje DNS

1. El campo de identificación de la cabecera lo asigna el programa que genera

todas las consultas dns en el servidor. Éste identificador es el mismo en el
mensaje de petición que en el de respuesta

2. El campo QR dentro de los flags sirve para especificar si el mensaje es una

consulta (0) o una respuesta (1).

3. El campo QPCode dentro de los flags sirve para especificar que tipo de consulta
se produce (una consulta estándar, inversa, de petición de estado, ...)

4. El campo AA (Authoritative Answer). Este bit es válido en las respuestas y

especifica que el servidor de nombres que responde es una autoridad para el
nombre de dominio en la sección de preguntas.

5. El campo TC (TrunCation). Especifica que este mensaje se truncó debido a

una longitud mayor que la permitida en el canal de transmisión.

6. El campo RD (Recursion Desired). Este bit se puede configurar en una consulta

y se copia en la respuesta. Si se establece RD, ordena al servidor de nombres
que realice la consulta recursivamente. El soporte de consultas recursivas es
opcional.

6
 7. El campo RA (Recursion Available). Esto se establece o borra en una respuesta,
y denota si el soporte de consultas recursivas está disponible en el servidor de
nombres
8. El campo Z. Campo reservado para uso futuro. Debe ser cero en todas las
consultas y respuestas.
9. El campo RCODE. Es un campo de 4 bits de longitud. Si su valor es 0 significa
que no hubo condición de error. Si su valor es 2. El servidor no fue capaz de
interpretar la consulta. Puedes consultar más valores RFC 1035 [RFC 881].
10. El campo QDCOUNT especifica el número de entradas en la sección de con-
sulta.
11. El campo ANCOUNT especifica el número de entradas en la sección de res-
puestas.
12. El campo NSCOUNT especifica el número de registros de recursos del servidor
de nombres en la sección de registros de autoridad.
13. El campo ARCOUNT especifica el número de registros de recursos en la sec-
ción de registros adicionales.

1.2.3. Sección de consulta de un mensaje DNS

La sección de consultas se usa para llevar la consulta en la mayoría de las consultas,
es decir, los parámetros que definen lo que se está preguntando.
La sección contiene QDCOUNT entradas (generalmente 1).
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ QNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QTYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QCLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Figura 1.4: Formato de la sección de consulta de un mensaje DNS

7
 1. El campo QNAME contiene el nombre de dominio a consultar

2. El campo QTYPE contiene el tipo de consulta a realizar

1.2.4. Sección de Respuesta

El resto de secciones tienen el mismo formato: un número variable de registros de
recursos, donde se especifica el número de registros en el campo de conteo correspon-
diente en el encabezado.

1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Figura 1.5: Formato de la sección de respuesta de un mensaje DNS

1. El campo NAME contiene el nombre de dominio de respuesta a la petición.

2. El campo TYPE. Este campo especifica el significado de los datos en el campo

RDATA.

3. El campo CLASS. Este campo especifica el tipo o clase de dato en el campo

RDATA.

8
4. El campo TTL. Es un entero sin signo de 32 bits que especifica el intervalo de
tiempo (en segundos) que el registro de recursos puede almacenarse en caché
antes de descartarse. Los valores cero se interpretan en el sentido de que el RR
solo se puede usar para la transacción en curso, y no se deben almacenar en
caché.

5. El campo RDLENGTH especifica la longitud en octetos del campo RDATA.

6. El campo RDATA es una cadena de longitud variable de octetos que describe

el recurso.

9
Capítulo 2

Análisis comentado de una captura

de intercambio de datos con
Wireshark

Figura 2.1: Visión general de una captura sobre el tráfico generado por Sky-
pe. Puede obtenerse aquí https://wiki.wireshark.org/SampleCaptures?action=
AttachFile&do=get&target=SkypeIRC.cap

10
Figura 2.2: Aplicamos el filtro sobre el tipo de tráfico que queremos, en nuestro caso,
sobre el protocolo dns

Tal y como podemos observar en la figura 2, se produce una transacción con

origen 192.168.1.2 y destino 192.168.1.1, que tal y como nos indica Wireshark, es
una consulta con el identificador: 0x9bb6. Podemos ver también información como
que el tipo de encapsulación es ethernet, la fecha y hora de la petición, y los protocolos
usados en la transmisión del paquete.

11
 Figura 2.3: Transacción 396 - 400

Figura 2.4: Información física sobre el origen y la fuente de la transmisión.

12
Figura 2.5: Información a nivel IP. Versión del Protocolo de Internet, direcciones
origen y destino, flags, cheksum, ...

Figura 2.6: Información a nivel UDP: puerto origen, puerto destino y longitud. Los
mensajes DNS están encapsulados sobre UDP. Un paquete UDP pesa menos que
un paquete TCP y DNS se beneficia de ello, ya que aún pudiendo existir perdidas y
errores, éstos se gestionan a nivel de aplicación.

13
Figura 2.7: Información DNS. Aquí podemos observar como dicho paquete tiene el
flag questions activo, lo que significa que dicho paquete es una contiene una consulta
y no una respuesta. También contiene el identificador y los flags. También podemos
sacar que la consulta requiere de recursividad para su resolución gracias al valor de
los flags (0x0100)

Recomendamos leer Appendix A

14
Capítulo 3

Protocolos más usados

Hemos analizado un tramo de 10 minutos con wireshark para visualizar los proto-
colos más usados en un momento de navegación común. Tras ello, podemos observar
como durante un tramo de navegación común, se realizan transferencias de paquetes
que no podríamos ni haber imaginado.

Figura 3.1: Paquetes transmitidos y recibidos durante la navegación web

15
 Figura 3.2: Estadísticas de protocolos más usados

Podemos observar que la lista de protocolos más usado es:

1. UDP

2. TCP

3. SSL

4. HTTP

5. ICMP

6. DNS

7. DHCP

8. ARP

9. TLS

10. IGMP

16
Apéndice A

Captura propia con Wireshark

Figura A.1: Mientras inciamos una sesión de captura de paquetes con wireshark bus-
camos en el navegador la dirección oficial de la universidad. El paquete 175 es un
mensaje DNS con identificador 0xb3df

17
Figura A.2: Podemos ver información física del paquete, como la dirección MAC de
origen y destino

Figura A.3: Podemos observar información a nivel del protocolo de internet del pa-
quete

18
Figura A.4: Podemos observar información a nivel DNS del paquete como por ejemplo:
el identificador, la resolución recurisiva y que es un mensaje de consulta y no de
respuesta.

Figura A.5: En esta captura se puede apreciar como el cuerpo del mensaje cambia
completamente y Wireshark nos confirma que se trata de un mensaje dns de respuesta,
y no de consulta, como el justo anterior.

19
Apéndice B

Información adicional

Figura B.1: Ejecución de host y nslookup para averiguar si el servidor dns está fun-
cionando correctamente

20
Bibliografía

[Capturas Wireshark] https://wiki.wireshark.org/SampleCaptures

[RFC 881] https://tools.ietf.org/html/rfc881

[RFC 881] https://tools.ietf.org/html/rfc1034

[RFC 881] https://tools.ietf.org/html/rfc1035

[1] DNS https://es.wikipedia.org/wiki/Sistema_de_nombres_de_dominio

21