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éstola di

El sitrans

ceso DNS

El análisis qu

pueden aprecias primeros pasirección real d

iguiente paso sferencia de d

ue procedo a re

ar los 3 momensos que se refi

del servidor qu

Figura No

será analizar edatos.

ealizar es el si

Figura No.

ntos principalieren a la comue estoy buscan

. 3 Secuencia

el proceso de c

guiente:

2 Secuencia d

es del protocomunicación entr

ndo (para éste

de pasos para

conexión TCP

de pasos protoc

olo DNS en acre las aplicacioe caso el de la

establecer con

P entre cliente

colo DNS

ción, en ésta eones DNS clieuniversidad n

nexión protoc

y servidor par

etapa del análiente 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 aplicde enconuevamcliente.

Respon

licación (Serv

cación DNS bontrarla (a travmente por los s

nde que la ruta

Figura No.

vicios de Red a

Figura No. 5

busca ya sea quvés de la “autoservicios de to

a asociada al se

6 Secuencia D

a Aplicaciones

Respuesta del

ue tenga entre oridad”) y la endas las capas i

ervidor con el

DNS para enco

s)

l servidor DN

sus tablas al snvía desde la ainferiores para

dominio: ww

ontrar la ruta d

S.

servidor de la aplicación haca comunicarse

ww.unal.edu.co

de un dominio

nacional, o sincia el cliente pe directamente

o es: 168.176.5

.

no se encarga pasando e con el DNS

5.69

5.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, 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.

5.5 Capa Enlace (Direccionamiento físico, con unidad tramas)





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.

6.1 Capa Aplicación (Servicios de Red a Aplicaciones)

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.

6.2 Capa Sesión (Comunicación entre dispositivos de la red) 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).


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. 7.2 Capa Sesión (Comunicación entre dispositivos de la red)

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.




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 -.




Mi máquina es la que envía éste paquete (es evidente porque es quien requiere la conexión). 7.5 Capa Enlace (Direccionamiento físico, con unidad tramas)


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.

8.1 Capa Aplicación (Servicios de Red a Aplicaciones) TCP está ubicado en la capa de transporte. Sin embargo se tiene claro que la aplicación que solicita la conexión es HTTP.





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 -.






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 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.





10 TCP desde el servidor respondiendo el ACK del punto 8

Figura No. 10 Captura Wireshark del protocolo TCP desde el servidor.

10.1 Capa Aplicación (Servicios de Red a Aplicaciones) 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.





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.









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.





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).







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

Technology

Transcript of Protocolo dns analizado con wireshark