Blog

El PROTOCOLO DNS. Parte 1º

Hola a todos:

Vamos a comenzar una serie de artículos sobre redes, y hoy vamos a tratar uno de los protocolos más importantes de Internet, el  protocolo DNS, he elegido este protocolo/servicio por la gran importancia del mismo, pensad lo que seria de nosotros si el, y aparte de esto por que tiene una vulnerabilidad (envenenamiento de cache DNS), por que hay un protocolo actualizado que se esta implantando llamado DNSsec  para securizar este protocolo, etc …

Al lío, DNS, Domain name service o servicio de nombres de dominio, trabaja en los puertos 53 tanto de los protocolos TCP como UDP, aunque en realidad trabaja en el protocolo UDP salvo en circunstancias especiales, y queda definido por la Internet Engineering Task Force en las request for comments http://www.ietf.org//rfc/rfc1034.txt y http://www.ietf.org/rfc/rfc1035.txt las cuales definen sus características.

En todas las redes de comunicaciones, todos los dispositivos tienen una dirección única, personal e intransferible, que los identifica de manera inequívoca en la red, esto es, la dirección ip que habilita al equipo para que pueda participar en el envío y recepción de mensajes, pero que para que esta comunicación sea posible, se necesita entre otras cosas un traductor que nos lo facilite.

Al ser humano le resulta más sencillo recordar una palabra, que un conjunto de cifras, por tanto para facilitar la interacción, se desarrollo una traducción o equivalencia entre esas cifras y los llamados nombres de dominio, esto se consigue mediante una base de datos distribuida y jerárquica almacenada en los servidores DNS que proveen servicio de resolución de nombres, así como la localización de los servidores de correo electrónico de los distintos dominios.

Este protocolo/servicio fue el resultado de la imposibilidad de recordar fácilmente los nombres de todos los servidores conectados a Internet, en un principio la SRI alojaba un archivo llamado HOSTS que contenía todos los nombres de dominio conocidos, pero llego un punto  en el que auge de la red en los 70 demostró que ese método no era valido y en 1983, Paul Mockapetri  publicó los RFC 882 y RFC 883  obsoletos a día de hoy, los cuales definían la primera implementación de lo que resultaría ser DNS.

Los nombres de dominio llamados también FQDN (FullyQualifiedDomainName), son la parte amigable para el ser humano, que manejamos con habitualidad están compuestos habitualmente en dos o más partes separadas por puntos “a1.ejemplo.org” cada una de las cuales es llamada etiqueta, la etiqueta situada mas a la derecha se le denomina Dominio de nivel superior en este caso el “.org”, y  las situadas a la izquierda  se refieren a un subdominio  que estarán  registrados  en un archivo de zona “ejemplo”, ubicado en uno o más servidores de nombres, y finaliza en el nombre del host en este caso “a1”

Estos subdominios pueden tener hasta 127 niveles, son cadenas alfanuméricas (con ‘-‘ como único símbolo permitido),los cuales  deben contar con al menos un carácter y pueden contener hasta 63 caracteres con la limitación que el  nombre de dominio completo tiene que tener como máximo 255 caracteres.

DNS se basa en un conjunto de servidores los cuales como dijimos anteriormente almacenan  en una base de datos distribuida y jerárquica los nombres de cada maquina perteneciente a un dominio y sus respectivas direcciones ip, y se pueden realizar solicitudes de resolución tanto por el nombre del equipo como por la correspondiente ip de cada uno de ellos (llamada resolución inversa), y para realizar las peticiones de resolución, se utilizaran resoluciones iterativas o recursivas.

Las resoluciones iterativas resultan de la respuesta completa que el servidor de nombres pueda dar, consultando los datos alojados de manera local, realizando peticiones de resolución de manera iterativa a los diferentes servidores DNS de la jerarquía asociada al nombre que se desea resolver, descendiendo por la misma hasta llegar a la que le brinda la información sobre la zona autoritativa o SOA para el nombre que va a resolver.

En la resolución recursiva, el servidor primero observa en sus propios registros para ver si puede resolver el nombre, en caso de que no pueda resolver el nombre utilizando sus registros almacenados, contacta con un servidor raíz para resolver la petición, las peticiones de resolución pueden pasar por un número n de servidores raíz dependiendo si estos almacenan los registros solicitados o no, continuando esta solicitud hasta encontrar la mejor respuesta, lo que aumenta el ancho de banda consumido y el tiempo empleado.

Una vez que se encuentra una coincidencia y se devuelve al servidor solicitante original, el servidor almacena temporalmente en la caché la dirección numerada que coincide con el nombre.

Si volviese a solicitarse ese mismo nombre, el primer servidor (si tuviera habilitada la cache de nombres) devolvería la dirección utilizando el valor almacenado en el caché de nombres, que estaría guardada de la petición de resolución anterior, logrando con ello una reducción en el tráfico de la red de datos de consultas DNS así como una reducción de las cargas de trabajo de los servidores más altos de la jerarquía

Un servidor DNS proporciona la resolución de nombres utilizando el demonio nominado named, siendo este demonio DNS un servicio por sí mismo, el cliente DNS presta el servicio de resolución de nombre para otras aplicaciones de red y servicios que lo necesiten.

Para proporcionar los servicios de resolución de nombres y funciones para los distintos hosts, hay distintos registros que son necesarios los cuales contienen el nombre, la dirección y el tipo de registro siendo entre otros:

  • A = Address – (Dirección) Este registro se usa para traducir nombres de servidores de alojamiento a direcciones IPv4.
  • AAAA = Address – (Dirección) Este registro se usa en IPv6 para traducir nombres de hosts a direcciones IPv6.
  • CNAME = Canonical Name – (Nombre Canónico) Se usa para crear nombres de servidores de alojamiento adicionales, o alias, para los servidores de alojamiento de un dominio. Es usado cuando se están corriendo múltiples servicios (como ftp y servidor web) en un servidor con una sola dirección ip. Cada servicio tiene su propia entrada de DNS (como ftp.ejemplo.com. y www.ejemplo.com.). esto también es usado cuando corres múltiples servidores http, con diferentes nombres, sobre el mismo host. Se escribe primero el alias y luego el nombre real.
  • NS = Name Server – (Servidor de Nombres) Define la asociación que existe entre un nombre de dominio y los servidores de nombres que almacenan la información de dicho dominio. Cada dominio se puede asociar a una cantidad cualquiera de servidores de nombres.
  • MX (registro) = Mail Exchange – (Registro de Intercambio de Correo) Asocia un nombre de dominio a una lista de servidores de intercambio de correo para ese dominio. Tiene un balanceo de carga y prioridad para el uso de uno o más servicios de correo.
  • PTR = Pointer – (Indicador) También conocido como ‘registro inverso’, funciona a la inversa del registro A, traduciendo IPs en nombres de dominio. Se usa en el archivo de configuración del Dns inversa.
  • SOA = Start of authority – (Autoridad de la zona) Proporciona información sobre el servidor DNS primario de la zona.
  • HINFO = Host INFOrmation – (Información del sistema informático) Descripción del host, permite que la gente conozca el tipo de máquina y sistema operativo al que corresponde un dominio.
  • TXT = TeXT – (Información textual) Permite a los dominios identificarse de modos arbitrarios.
  • LOC = LOCalización – Permite indicar las coordenadas del dominio.
  • WKS – Generalización del registro MX para indicar los servicios que ofrece el dominio. Obsoleto en favor de SRV.
  • SRV = SeRVicios – Permite indicar los servicios que ofrece el dominio. RFC 2782. Excepto Mx y Ns. Hay que incorporar el nombre del servicio, protocolo, dominio completo, prioridad del servicio, peso, puerto y el equipo completo. Esta es la sintaxis correspondiente:

              Servicio.Protocolo.Dominio-completo IN SRV Prioridad.Peso.Puerto.Equipo-Completo

  • SPF = SenderPolicy Framework – Ayuda a combatir el Spam. En este registro se especifica cual o cuales hosts están autorizados a enviar correo desde el dominio dado. El servidor que recibe, consulta el SPF para comparar la IP desde la cual le llega con los datos de este registro.
  • ANY = Toda la información de todos los tipos que exista.

Ejemplo archivo configuración BIND demonio named:

im3

 

Ejemplo archivo declaración servidor DNS primario de zona

im2

Como se realiza una resolución (practica)

Una vez hecho un somero resumen de cómo esta planteado el protocolo DNS, trataremos de ver que ocurre cuando se efectúa una petición de resolución, por ejemplo si solicitamos a nuestro navegador que se dirija a la pagina web del diario el mundo, introduciríamos http://www.google.es, y primeramente se desecharía para la petición el prefijo http:// ya que solo es una referencia para que el navegador sepa con que protocolo acceder a ese contenido , si  la dirección contuviera un sufijo por ejemplo “/deportes.php/id=2356” este también se desecharía ya que es un directorio de la pagina web, el cual habrá de solicitarse a esta cuando se tenga su dirección ip, por lo tanto solo se realizara la petición de resolución sobre “google.es” y aquí finaliza la parte visible del proceso para nosotros, y se resolvería la dirección utilizando las formas de resolución arriba nombradas.

Pero imaginemos el proceso, se enviaría un datagrama UDP solicitando la traducción del nombre (llamada resolución recursiva), y el servidor DNS de nuestro ISP  busca en su cache de nombres, si existe una petición previa de ese nombre, nos la serviría, y fin de la historia…

Pero si no existiera una petición  se debería realizar la petición de resolución iterativa bajando por la jerarquía en árbol hasta encontrar la resolución del nombre en este caso google.es, en este caso hasta llegar al dominio .es que se encuentra por debajo del dominio raíz.

La petición como observaremos en las capturas va identificada por un ID de transacción en la cabecera de la misma  que consiste en dos bytes que identifican el conjunto de consulta y respuesta ya que comparte el ID con la petición, también se observaran una serie de flags  que tendrán un significado según estén a 1 o 0, fácilmente identificables al igual que los campos siguientes.

peticion dns

 

La respuesta contiene como hemos visto en la petición el mismo ID de transacción, posteriormente los dos bytes de flags  que como vemos han cambiado al ser una respuesta, y el resto de campos fácilmente identificables como se observa en la captura.

respuesta dns

 

Y hasta aquí esta primera parte del Protocolo DNS…en la siguiente parte trataremos la parte teórica de un envenenamiento de la cache DNS, y el protocolo DNS sec, espero que os haya resultado interesante.

 

Un Saludo.

juancarlostirado@highsec.es

  1. Carlos
    Carlos06-12-2013

    Post muy educativo! 😉
    Hay una página que ha traducido los RFCs al Español, por si alguien quiere echarla un vistazo es la siguiente http://rfc-es.org; Muchas veces compensa leerlo en inglés, pero si tenéis un día cansado y no os apetece traducir mentalmente ahí lo teneis

Leave a Reply

*

    No Twitter Messages