Protocolo dns analizado con wireshark

Practica Análisis del Protocolo de Configuración de
DNS – Domain Name System – con Wireshark
Por: José Francisco Parra Alvarado Cod.: 257689
1 Marco de Referencia
Domain Name System o DNS (en español: sistema de nombres de dominio) es un sistema de nomenclatura jerárquica
para computadoras, servicios o cualquier recurso conectado a Internet o a una red privada. Este sistema asocia información
variada con nombres de dominios asignado a cada uno de los participantes. Su función más importante, es traducir
(resolver) nombres inteligibles para las personas en identificadores binarios asociados con los equipos conectados a la red,
esto con el propósito de poder localizar y direccionar estos equipos mundialmente.
El servidor DNS utiliza una base de datos distribuida y jerárquica que almacena información asociada a nombres de
dominio en redes como Internet. Aunque como base de datos el DNS es capaz de asociar diferentes tipos de información a
cada nombre, los usos más comunes son la asignación de nombres de dominio adirecciones IP y la localización de los
servidores de correo electrónico de cada dominio.
La asignación de nombres a direcciones IP es ciertamente la función más conocida de los protocolos DNS. Por ejemplo, si
la dirección IP del sitio FTP de prox.mx es 200.64.128.4, la mayoría de la gente llega a este equipo especificando
ftp.prox.mx y no la dirección IP. Además de ser más fácil de recordar, el nombre es más fiable. La dirección numérica
podría cambiar por muchas razones, sin que tenga que cambiar el nombre.
Inicialmente, el DNS nació de la necesidad de recordar fácilmente los nombres de todos los servidores conectados a
Internet. En un inicio, SRI (ahora SRI International) alojaba un archivo llamado HOSTS que contenía todos los nombres de
dominio conocidos. El crecimiento explosivo de la red causó que el sistema de nombres centralizado en el archivo hosts no
resultara práctico y en 1983,Paul V. Mockapetris publicó los RFC 882 y RFC 883 definiendo lo que hoy en día ha
evolucionado hacia el DNS moderno. (EstosRFCs han quedado obsoletos por la publicación en 1987 de los RFCs 1034
y RFC 1035).
Para la operación práctica del sistema DNS se utilizan tres componentes principales:
 Los Clientes fase 1: Un programa cliente DNS que se ejecuta en la computadora del usuario y que genera peticiones
DNS de resolución de nombres a un servidor DNS (Por ejemplo: ¿Qué dirección IP corresponde a nombre.dominio?);
 Los Servidores DNS: Que contestan las peticiones de los clientes. Los servidores recursivos tienen la capacidad de
reenviar la petición a otro servidor si no disponen de la dirección solicitada.
 Y las Zonas de autoridad, porciones del espacio de nombres raros de dominio que almacenan los datos. Cada zona de
autoridad abarca al menos un dominio y posiblemente sus subdominios, si estos últimos no son delegados a otras zonas
de autoridad
Entendiendo las partes de un nombre de dominio
Un nombre de dominio usualmente consiste en dos o más partes (técnicamente etiquetas), separadas por puntos cuando se
las escribe en forma de texto. Por ejemplo, www.example.com o www.wikipedia.es

 A la etiqueta ubicada más a la derecha se le llama dominio de nivel superior (en inglés top level domain).
Como org enwww.ejemplo.org o es en www.wikipedia.es
 Cada etiqueta a la izquierda especifica una subdivisión o subdominio. Nótese que "subdominio" expresa dependencia
relativa, no dependencia absoluta. En teoría, esta subdivisión puede tener hasta 127 niveles, y cada etiqueta puede
contener hasta 63 caracteres, pero restringidos a que la longitud total del nombre del dominio no exceda los 255
caracteres, aunque en la práctica los dominios son casi siempre mucho más cortos.
 Finalmente, la parte más a la izquierda del dominio suele expresar el nombre de la máquina (en inglés hostname). El
resto del nombre de dominio simplemente especifica la manera de crear una ruta lógica a la información requerida. Por
ejemplo, el dominioes.wikipedia.org tendría el nombre de la máquina "es", aunque en este caso no se refiere a una
máquina física en particular.
El DNS consiste en un conjunto jerárquico de servidores DNS. Cada dominio o subdominio tiene una o más zonas de
autoridad que publican la información acerca del dominio y los nombres de servicios de cualquier dominio incluido. La
jerarquía de las zonas de autoridad coincide con la jerarquía de los dominios. Al inicio de esa jerarquía se encuentra
los servidores raíz: los servidores que responden cuando se busca resolver un dominio de primer y segundo nivel.
Domain Name System (DNS)
Familia de protocolos de Internet
Función Resolución de nombres de dominio
Puertos 53/UDP, 53/TCP
Estándares: RFC 1034 (1987) y RFC 1035 (1987)
Ubicación en la pila de protocolos
Aplicación DNS
Transporte TCP o UDP
Red IP (IPv4, IPv6)
Tomado de: http://es.wikipedia.org/wiki/Domain_Name_System

2 Proceso Realizado a través de una interfaz de Ubuntu y Wireshark:
2.1 El primer paso para el desarrollo del taller fue abrir una terminal de Linux y observar una captura por la
interfaz wlan0 a través de Wireshark, éste tenía un comportamiento extraño, ya que antes de terminar de
resolver el protocolo resolvía la dirección de la universidad.
2.2 Analizando éste comportamiento con otras páginas web encontré que era debido al proxy de la nacional que
tenía configurado en el sistema operativo, y que siempre al realizar el protocolo DNS además de consultar el
Servidor DNS de mi proveedor de internet, también le preguntaba al asociado al proxy. Borre esa
configuración y procedí a realizar el taller.
2.3 Antes de todo borre la cache del navegador con los historiales y ejecute el comando “/etc/init.d/dns-clean
start”, con lo cual me aseguro que se borren las tablas de los DNS almacenadas en mi computador.
2.4 Procedo a colocar a Wireshark a escuchar la interfaz Wlan0 y escribo en el navegador la ruta:
“http://www.unal.edu.co/”.
2.5 Reviso que éste bien la lectura de los paquetes y procedo al análisis.
Figura No. 1 Captura de Wireshark general

3 Proc
3.1
Se p
ésto
la di
El si
trans
ceso DNS
El análisis qu
pueden aprecia
s primeros pas
irección real d
iguiente paso
sferencia de d
ue procedo a re
ar los 3 momen
sos que se refi
del servidor qu
Figura No
será analizar e
datos.
ealizar es el si
Figura No.
ntos principal
ieren a la com
ue estoy buscan
. 3 Secuencia
el proceso de c
guiente:
2 Secuencia d
es del protoco
municación entr
ndo (para éste
de pasos para
conexión TCP
de pasos protoc
olo DNS en ac
re las aplicacio
e caso el de la
establecer con
P entre cliente
colo DNS
ción, en ésta e
ones DNS clie
universidad n
nexión protoc
y servidor par
etapa del análi
ente y servidor
nacional).
olo TCP
ra comenzar c
isis mostraré
r para encontr
on la
rar

4 DNS cliente
4.1 Capa Aplicación (Servicios de Red a Aplicaciones)
Éste hace referencia a la carga útil del datagrama que se enviará dentro de las tramas en la capa de enlace.
En éste capa del modelo OSI va el protocolo DNS que es emitido desde el cliente, y que busca
comunicarse con otro protocolo DNS en el servidor, para esto va a utilizar todas las capas inferiores para
lograr el empalme de la conexión entre aplicaciones DNS cliente y servidor.
El protocolo DNS no realiza una representación ni codificación de los mismos, ya que la carga útil es
generada por el protocolo DNS sin codificación.
Figura No. 4 Descripción detallada línea 4 de la trama DHCP Discover
 El propósito del envío DNS desde el cliente es recibir la dirección ip del dominio que se tiene a
través de un “query” estándar en el cual se coloca la dirección www.unal.edu.co.
4.2 Capa Sesión (Comunicación entre dispositivos de la red)
Para lograr la conexión con el servidor DNS del proveedor de internet, utiliza los puertos 46.140 para el
cliente y 53 para el servidor.
4.3 Capa Transporte (Conexión extremo a extremo)
 El protocolo de transporte (el mensaje se va a montar sobre UDP porque desconoce la conexión)
es UDP.
 Esté será el protocolo por el cual se transportará el Datagrama.
 Sin embargo hasta éste punto la capa no entiende, ni hace énfasis en IP, ni tampoco en redes ni
subredes, su razón es prestar el servicio de verificar la conexión extremo a extremo e incluye el
CRC respectivo para verificar que la integridad de la información en la conexión.
4.4 Capa Red (Determinar la ruta, con unidad paquete)
 IP, Se reconoce que es Internet Protocol v 4, dado el código (0x0800).
 Se tiene claro que el servidor DNS de destino (que provee la empresa UNE) es: 200.31.208.101.
 Se tiene clara la ip fuente 192.168.0.26 que es desde la cual se solicita.
4.5 Capa Enlace (Direccionamiento físico, con unidad tramas)
 Se identifica que el tipo de red es Ethernet.
 Se tiene clara la MAC tanto del equipo cliente y la mac destino es la de mi router quien no es
destino, y solo se encargará de enrutar los datagramas hasta la ip asociada en la capa de
transporte.
4.6 Capa Física (Define el medio físico)
 La información de capa física no es analizada a través del analizador Wireshark, sin embargo
para ilustrar el elemento de éste será la tarjeta de red que se conectará a través del medio
(transmisión por radiofrencuencias).

5 DNS
5.1
S servidor
Capa Apl
 La aplic
de enco
nuevam
cliente.
 Respon
licación (Serv
cación DNS b
ontrarla (a trav
mente por los s
nde que la ruta
Figura No.
vicios de Red a
Figura No. 5
busca ya sea qu
vés de la “auto
servicios de to
a asociada al se
6 Secuencia D
a Aplicaciones
Respuesta del
ue tenga entre
oridad”) y la en
das las capas i
ervidor con el
DNS para enco
s)
l servidor DN
sus tablas al s
nvía desde la a
inferiores para
dominio: ww
ontrar la ruta d
S.
servidor de la
aplicación hac
a comunicarse
ww.unal.edu.co
de un dominio
nacional, o sin
cia el cliente p
e directamente
o es: 168.176.5
.
no se encarga
pasando
e con el DNS
5.69

Para lograr la conexión con el servidor DNS del proveedor de internet, utiliza los puertos 46.140 para el
cliente y 53 para el servidor, y para éste momento el servidor es quien envía el paquete de respuesta.
5.3 Capa Transporte (Conexión extremo a extremo)
 El protocolo de transporte es UDP.
 Esté será el protocolo por el cual se transportará el Datagrama.
 Prestar el servicio de verificar la conexión extremo a extremo e incluye el CRC respectivo para
verificar que la integridad de la información en la conexión.
 Se tiene claro que el servidor (que provee la empresa UNE) es: 200.31.208.101, repito éste
servidor es la fuente.
 Se tiene clara la ip a quien se dirige 192.168.0.26 que es la de mi máquina.
transporte.

6 TCP, Solicitud Sync.
El protocolo DNS ya cumplió su objetivo que era traducir el dominio en una dirección que para este ejemplo es:
168.176.5.69.
Como se tiene la dirección ahora se procede a intentar una conexión con esa dirección a través del protocolo TCP como
mostré en la figura No. 3.
Figura No. 7 Captura Wireshark del protocolo TCP para intentar una conexión.
 TCP está ubicado en la capa de transporte.
 Sin embargo la aplicación que solicita la conexión es HTTP, ya que la estoy realizando a través de un
navegador de internet.
 La aplicación quiere comenzar a recibir información, y solicita a la capa de transporte que la efectue, por
tanto ésta capa en éste paquete no aplica.
El puerto de conexión de mi máquina para ésta conexión será 52.298 y el del servidor de páginas web será
el 80.
6.3 Capa Transporte (Conexión extremo a extremo, con unidad segmento)
 El protocolo de transporte es TCP, el cuál es orientado a la conexión, y lo que vamos a buscar es
realizar una conexión con el servidor de la universidad nacional para enviar y recibir segmentos
para la capa de aplicación –al unir los segmentos formo los paquetes-.
 En éste momento envío un SYN, que se refiere a que solicita una conexión con el servidor.
 Se tiene claro que el servidor de la UNAL es: 168.176.5.69, y la ip de mi máquina es:
192.168.0.26.
 Mi máquina es la que envía éste paquete (es evidente porque es quien requiere la conexión).

transporte.

7 TCP Respuesta Sync, ACK
Figura No. 8 Captura Wireshark del protocolo TCP respondiendo el Sync.
 TCP está ubicado en la capa de transporte.
 Sin embargo se responde a la aplicación que solicita la conexión HTTP.
el 80.
 En éste momento envío un ACK SYN, que se refiere a que le reconoce la sincronización que
solicito – lo que quiere decir es que está disponible para prestarle el servicio que solicita en el
servidor de páginas web -.
192.168.0.26.
 Se tiene clara la MAC tanto del equipo cliente y la mac de mi router quien no es fuente, y solo se
encargará de enrutar los datagramas hasta la ip asociada en la capa de transporte.

8 TCP Respuesta ACK desde el cliente
Figura No. 9 Captura Wireshark del protocolo TCP respondiendo el ACK del servidor.
TCP está ubicado en la capa de transporte.
Sin embargo se tiene claro que la aplicación que solicita la conexión es HTTP.
el 80.
 En éste momento envío un ACK, que se refiere a que le reconoce el “reconocimiento” que hizo el
servidor – lo que quiere decir es que acepta que el servidor está disponible y que ahora se tiene la
conexión y el servidor de páginas web estará dispuesto a responder cuando la aplicación http
cliente solicite información -.
192.168.0.26.
 Se tiene clara la MAC tanto del equipo cliente y la mac de mi router quien no es destino, y solo
se encargará de enrutar los datagramas hasta la ip asociada en la capa de transporte.

9 HTTP desde el cliente inmediatamente después de realizar la conexión con el servidor
Figura No. 9 Captura Wireshark del protocolo HTTP después de asegurarse que ya existe la conexión.
 HTTP – Hipertext Tranfer Protocol –
 Acepta la conexión que se acabó de realizar y ahora se pretende comunicar directamente con el servidor
de páginas web “de tú a tú”.
 Envía información adicional como el tipo de navegador desde el que se conecta, la versión del mismo, el
método de transferencia de información por el protocolo http que será GET.
 No se analizará la respuesta a este segmento, pero la respuesta a este protocolo se realizará en el paquete
No. 18.
 Es importante notar que no se espera respuesta a este segmento, sino que se realiza de una vez el envio de
información entre cliente y servidor ya que se considera que la conexión ya fue realizada.
 Ahora está capa reconoce el tipo de codificación que será transportada como: gzip, txt, html, xml y xhtml
entre otros.
el 80.
 El protocolo de transporte es TCP.
 No envía un número de segmento, ya que éste envío es para finalizar la negociación de conexión
entre cliente y servidor y confirmar el tipo de datos.
192.168.0.26.

10 TCP desde el servidor respondiendo el ACK del punto 8
Figura No. 10 Captura Wireshark del protocolo TCP desde el servidor.
HTTP – Hipertext Tranfer Protocol –
Ésta es la última etapa de la negociación y reconoce el reconocimiento que le hizo el cliente para desde el
siguiente paquete empezar a enviar información.
No hay carga útil en este paquete.
el 80.
 Reconoce el ACK que le hizo el cliente en el paquete No. 5, la única diferencia es que le
reconoce hasta el ACK 313, antes estaba en 1 significa que tiene 312 bits con la información del
tamaño en bits que se manejará por cada transmisión de segmentos.
192.168.0.26.

11 TCP desde el servidor comenzando a enviar carga útil
Figura No. 11 Captura Wireshark del protocolo TCP comenzando a enviar carga útil desde el servidor.
 HTTP – Hipertext Tranfer Protocol –
 El servidor de páginas web está comunicándose “de tú a tú” con el cliente en la aplicación HTTP y utiliza
los servicios de las capas inferiores para mantener ésto.
 Se enuncia por primera vez el PDU – Protocolo de Unidad de Datos -.
 Ahora está capa reconoce el tipo de codificación que será transportada como: gzip, txt, html, xml y xhtml
entre otros.
el 80.
 Va el contador de ACK del servidor en 313 y el cliente va acomenzar a recibir carga útil, en el
cliente para el siguiente paquete pasará de un ACK 1 a un ACK 1.369 dado el tamaño de la carga
útil en caso de ser exitosa.
 Comienza a enviar carga útil de tamaño 1.368 por cada segmento enviado (TCP segment data).
192.168.0.26.

12 Conclusiones
12.1 El protocolo DNS cumple a perfección el facilitar el memorizar los nombres de dominio a los usuarios y
no una dirección IP.
12.2 Se debe resaltar el paso en la capa de transporte que va desde UDP a TCP para poder servir tanto a DNS
como a HTTP respectivamente
12.3 Interesante que nunca cambio el número de la MAC de mi enrutador y siempre se realizaron todas las
operaciones con éste.
12.4 Es el primer momento en que veo en acción la capa de presentación.
12.5 Toda ésta serie de protocolos ocurrieron en unos milisegundos.
12.6 La negociación de TCP para poder prestarle servicio a HTTP fue interesante, ya que hasta que éste no se
dio HTTP no envió ningún tipo de carga útil.
12.7 Fue complejo realizar el laboratorio ya que el servidor de la nacional le hacían pruebas y no comprendía
porque no respondía las solicitudes y el número de los paquetes no se analizaba claramente.
12.8 El proxy de la nacional complico el análisis, ya que se encontraba configurado en mi equipo y siempre se
colocaba intermedio a los paquetes iniciales DNS y el análisis resultaba bastante confuso.

13 Bibliografía:
13.1 http://alsofidesworld.blogspot.com/2012/09/tcp-transmission-control-protocol.html
13.2 http://es.wikipedia.org/wiki/Domain_Name_System
13.3 http://wiki.wireshark.org/SampleCaptures
13.4 http://en.wikipedia.org/wiki/Transmission_Control_Protocol

Protocolo dns analizado con wireshark

Más contenido relacionado

La actualidad más candente (20)

Destacado (13)

Similar a Protocolo dns analizado con wireshark (20)

Último (20)

Protocolo dns analizado con wireshark