Protocolo DNS Instituto Tecnológico de Informática Tecnicatura en Redes y Telecomunicaciones Año 2010 Pablo Volpe Nombre de Archivos: Dossier_DNS.docPresentacion_DNS.ppt

Protocolo DNS (Domain Name Service / System)(Servicio / Sistema de Nombre de Dominio)

IntroducciónEs un protocolo de la pila de protocolos TCP/IP, ubicado en la capa de aplicación del Modelo OSISu función principal es la de Resolver de nombres de dominio. Está definido en el RFC 1034 y RFC 1035 desde 1987.Utiliza los puertos 53 UDP y 53 TCP.

Reseña históricaDNS fue diseñado inicialmente, ante necesidad de recordar fácilmente los nombres de todos los servidores conectados a Internet. Antes de la implementación de DNS, Stanford Research Institute, utilizaba un archivo HOSTS para referenciar todos los nombres de dominios conocidos. Ante esto, en 1983 Paul Mockapetris desarrolló una primera versión de DNS (Definido en los RFCs 822 y 833), evolucionando en 1987 hacia el DNS actual. En 1984 se desarrolló la primera versión de un DNS bajo UNIX, al que se le denominó BIND.

Ubicación de DNS en la pila de protocolos TCP/IP

Teórico con respecto a la funcionalidad de DNS

El servicio de nombres de dominio, es una base de datos distribuida, con información que se usa para traducir los nombres de dominio, fáciles de recordar y usar por las personas, en direcciones IP que es la forma en la que las máquinas pueden encontrarse en Internet. Dicha información se almacena en forma de Registros (RR)

Nombres de dominio

El DNS basa su funcionamiento en un espacio de nombres que responde a una arquitectura jerárquica que se asemeja a la estructura jerárquica de los sistemas de archivos de UNIX, la cual se representa con un árbol invertido. El tope de esta jerarquía se representa por un punto “.” y cada nodo del árbol, en general, representa una partición de la base de datos. Cada una de estas particiones es llamada dominio, los cuales pueden a su vez ser divididos en subdomains subdominios.

Un nombre de dominio consiste en dos o mas etiquetas separadas por puntos cuando se las escribe en forma de texto. Por ejemplo, www.google.com.uy o maps. google . com

A la etiqueta ubicada más a la derecha se donomina Dominio de Nivel Superior (TLD). Ej.: .uy en www . google . com . uy o .com en maps . google .comExisten TLD de dos tipos: Territoriales (ccTLD - Country Code Top Level Domain): .uy - .ar - .brGlobales ( gTLD - Global Top Leve Domain): .com - .net - .tv - .org - .gub - .mil

Cada etiqueta a la izquierda especifica una subdivisión o subdominio.

El último nivel es denominado “Host Name”, que es el nombre de un host conformado por una sola "palabra" (formada por letras, números y guiones). Ej. "www".

Fully Qualified Host Name (FQHN): Es el “nombre completo” de un host. Está formado por el hostname, seguido de un punto y su correspondiente nombre de dominio. Por ejemplo, “maps.google.com“

En teoría, esta subdivisión puede tener hasta 127 niveles, y cada etiqueta contener hasta 63 caracteres, pero restringido 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.

En el DNS no existe una base de datos central con toda la información de los hosts de Internet. Por el contrario la información es distribuida entre cientos de servidores de nombres (name servers). Esto permite controlar por segmentos toda la base de datos en general, logrando que la información de cada uno de estos segmentos este disponible a través de toda la red utilizando un esquema cliente - servidor.Los programas llamados Name Servers (servidores de nombres) forma la parte del servidor en el mecanismo cliente - servidor de DNS. Los name servers contienen la información de un segmento de la base de datos y la ponen a disposición de los clientes.Los clientes son llamados Resolvers, los cuales son rutinas de librería que crean preguntas y las envían a través de la red a los servidores.

El DNS se utiliza para distintos propósitos. Los más comunes son:Resolución de nombres: Dado el nombre completo de un host obtener su dirección IP.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.Resolución de servidores de correo: Dado un nombre de dominio (por ejemplo gmail.com) obtener el servidor a través del cual debe realizarse la entrega del correo electrónico (en este caso, gmail-smtp-in.l.google.com).

Tipos de servidores.Existen cuatro tipos diferentes de servidores de resolución de nombres:Máster (maestro). Aloja los registros autoritarios de una zona, responde las peticiones de resolución de nombres como servidor de autoridad y delega copias a los servidores esclavo.Slave (esclavo). Responde a las peticiones de resolución de nombres como servidor de autoridad, pero la información es distribuida por los servidores primarios. Se considera que como medida de seguridad, se requiere al menos uno de estos, preferentemente independiente de la infraestructura del primario (red, energia eléctrica y ubicación geográfica).Caching-only (sólo de cache). Responde a las peticiones de resolución de nombres pero no es servidor de autoridad, las respuestas las guarda en memoria por un período determinado.Forwarding (de reenvío). Reenvia las peticiones a una lista de servidores de nombres.

Arquitectura del DNSEl sistema DNS funciona principalmente en base al protocolo UDP . Los requerimientos se realizan a través del puerto 53.El sistema está estructurado en forma de "árbol". Cada nodo del árbol está compuesto por un grupo de servidores que se encargan de resolver un conjunto de dominios (zona de autoridad). Un servidor puede delegar en otro (u otros) la autoridad sobre alguna de sus sub-zonas (esto es, algún subdominio de la zona sobre la que él tiene autoridad). Un subdominio puede verse como una especialización de un dominio de nivel anterior. Por ejemplo, "google.com.uy" es un subdominio de "com.uy", que a su vez lo es del TLD "uy".El siguiente diagrama ilustra esto a través de un ejemplo:

Los servidores con autoridad sobre los TLD son los llamados "root servers" (o "servidores raíz") del sistema. Estos son fijos, ya que rara vez cambian, siendo actualmente 13 y se encuentran distribuidos en 229 sitios en todo el mundo.A continuación se detallan cada uno de los Root Servers:

Root Server AIPv4: 198.41.0.4IPv6: 2001:503:ba3e::2:30Nombre: ns . internic . net Empresa: VeriSignUbicación: Distrbuido en 6 localidades (uso de unicast) Los Angeles, New York, Frankfurt, Hong Kong, Palo Alto, AshburnSoftware: BIND

Root Server BIPv4: 192.228.79.201 IPv6: 2001:478:65::53 Nombre: ns 1. isi . edu Empresa: USC-ISIUbicación: Marina Del Rey , California , U . S . Software: BIND

Root Server CIPv4: 192.33.4.12Nombre: c . psi . net Empresa: Cogent CommunicationsUbicación: Distrbuido en 6 localidades (uso de unicast): Herndon, Los Angeles, New York, Chicago, Frankfurt, Madrid.Software: BIND

Root Server DIPv4: 128.8.10.90Nombre: terp . umd . edu Operador: University of MarylandUbicación: MarylandSoftware: BIND

Root Server EIPv4: 192.203.230.10Nombre: ns . nasa . gov Operador: NASAUbicación: Mountain Vi ewSoftware: BIND

Root Server FIPv4: 192.5.5.241IPv6: 2001:500:2f::fNombre: ns . isc . org Operador: Internet Systems ConsortiumUbicación: Distrbuido en 49 localidades (uso de unicast): Ottawa, Palo Alto, San Jose, New York, San Francisco, Madrid, Hong Kong, Los Angeles, Roma, Auckland, Sao Paulo, Beijing, Seoul, Moscow, Taipei, Dubai, Paris, Singapore, Brisbane, Toronto, Monterrey, Lisbon, Johannesburg, Tel Aviv, Jakarta, Munich, Osaka, Prague, Amsterdam, Barcelona, Nairobi, Chennai, London, Santiago de Chile, Dhaka, Karachi, Torino, Chicago, Buenos Aires, Caracas, Oslo, Panama, Quito, Kuala Lumpur, Suva, Cairo, Atlanta, Podgorica, St. Maarten.Software: BIND 9

Root Server GIPv4: 192.112.36.4Nombre: ns . nic . ddn . mil Operador: Defense Information Systems Agency Ubicación: Distrbuido en 6 localidades (uso de unicast) en Columbus, San Antonio, Honolulu, Fussa, Stuttgart-Vaihingen, Napoles.Software: BIND

Root Server HIPv4: 128.63.2.53IPv6: 2001:500:1::803f:235Nombre: aos.arl.army.milOperador: U.S. Army Research LabUbicación: Aberdeen Proving GroundSoftware: NSD

Root Server IIPv4: 192.36.148.17IPv6: 2001:7fe::53Nombre: nic . nordu . net Operador: AutonomicaUbicación: Distrbuido en 36 localidades (uso de unicast): Stockholm, Helsinki, Milan, London, Geneva, Amsterdam, Oslo, Bangkok, Hong Kong,

Root Server JIPv4: 192.58.128.30IPv6: 2001:503:C27::2:30Operador: VeriSign, Inc.Ubicación: Distrbuido en 70 localidades (uso de unicast): Dulles, Ashburn, Miami, Atlanta, Seattle, Chicago, New York, Honolulu, Mountain View, San Francisco, Dallas,

Brussels, Frankfurt, Ankara, Bucharest, Chicago, Washington, Tokyo, Kuala Lumpur, Palo Alto, Jakarta, Wellington, Johannesburg, Perth, San Francisco, Singapore, Miami, Ashburn, Mumbai, Beijing, Manila, Doha, Colombo, Vienna, Paris, Taipei, Porto Alegre, Yerevan.Software: BIND

Amsterdam, London, Stockholm, Tokyo, Seoul, Beijing, Singapore, Dublin, Kaunas, Nairobi, Montreal, Perth, Sydney, Cairo, Cairo, Warsaw, Brasilia, Sao Paulo, Sofia, Prague, Johannesburg, Toronto, Buenos Aires, Madrid, Fribourg, Hong Kong, Turin, Mumbai, Oslo, Brussels, Paris, Helsinki, Frankfurt, Riga, Milan, Rome, Lisbon, San Juan, Edinburgh, Tallin, Taipei, New York, Palo Alto, Anchorage, Moscow, Manila, Kuala Lumpur, Luxembourgo, Guam, Vancouver, Wellington.Software: BIND

Root Server KIPv4: 193.0.14.129IPv6: 2001:7fd::1Operador: RIPE NCCUbicación: Distrbuido en 18 localidades (uso de unicast): London, Amsterdam, Frankfurt, Athens, Doha, Milan, Reykjavik, Helsinki, Geneva, Poznan, Budapest, Abu Dhabi, Tokyo, Brisbane, Miami, Delhi, Novosibirsk, Dar es Salaam.Software: NSD

Root Server LIPv4: 199.7.83.42IPv6: 2001:500:3::42Operador: ICANNUbicación: Distrbuido en 28 localidades (uso de unicast): Ankara, Atlanta, Brisbane, Cape Town, Chicago, Crete, Copenhagen, Culpeper, Dammam, Denver, El Segundo, Istanbul, Jeddah, Johannesburg, Lyon, Marseille, Melbourne, Miami, Paris, Perth, Philadelphia, Prague, Riyadh, San Jose, Santiago de Chile, Sydney, Toronto.Software: NSD

Root Server MIPv4: 202.12.27.33IPv6: 2001:dc3::35Operador: WIDE ProjectUbicación: Distrbuido en 6 localidades (uso de unicast): Tokyo, Seoul, Paris, San Francisco.Software: BIND

Tipos de resolución de nombres de dominioConsulta RecursivaUna consulta recursiva se realiza cuando el cliente consulta directamente un nombre al servidor DNS.

Las únicas respuestas posibles son el nombre completo o que no se ha podido encontrar. Para que suceda esto último tiene que darse que esa dirección IP no está en la base de datos DNS y por tanto devuelve que no la ha encontrado. Una consulta recursiva nunca se redirecciona a otro servidor DNS.

Consulta Iterativa

En las consultas (o resoluciones) iterativas, el servidor no tiene la información en sus datos locales, por lo que busca un servidor raiz y repite el mismo proceso básico (consultar a un servidor remoto y seguir a la siguiente referencia) hasta que obtiene la respuesta a la pregunta.El proceso de resolución normal se da de la siguiente manera:El servidor DNS A recibe una consulta recursiva desde el cliente.El servidor DNS A envía una consulta iterativa al DNS B (Root Server).El DNS B refiere a DNS A otro servidor de nombres, incluyendo al DNS C.El servidor DNS A envía una consulta iterativa a DNS C.El servidor DNS C refiere a DNS A otro servidor de nombres, incluyendo a DNS D.El servidor DNS A envía una consulta iterativa a DNS D.El servidor DNS D responde.El servidor A regresa la respuesta al Cliente

Mecanismos de cachéCada vez que un servidor de nombres envía una respuesta, lo hace adjuntando el tiempo de validez de la misma (TTL o "tiempo de vida"). Esto posibilita que el receptor, antes la necesidad de volver a resolver la

misma consulta, pueda utilizar la información previamente obtenida en vez de realizar un nuevo requerimiento.Esta es la razón por la cual los cambios realizados en el DNS no se propagan instantáneamente a través del sistema. Dependiendo de la naturaleza de los mismos (y de la configuración de cada servidor), la propagación puede tardar desde algunos minutos hasta varios días.Tipos de registro en un servidor de nombresUn servidor de nombres puede almacenar distinta información. Para ello, en cada zona de autoridad dispondrá de entradas de distinto tipo. Entre los más importantes se encuentran:A (Address): Este registro se utiliza para traducir nombres de hosts del dominio en cuestión a direcciones IP.CNAME (Canonical Name): El nombre canónico es un alias para un host determinado. (No define una dirección IP, sino un nuevo nombre.)NS (Name Server): Especifica el servidor (o servidores) de nombres para un dominio.MX (Mail Exchange): Define el servidor encargado de recibir el correo electrónico para el dominio.PTR (Pointer): Especifica un "registro inverso", a la inversa del registro A, permitiendo la traducción de direcciones IP a nombres.TXT (Text): Permite asociar información adicional a un dominio. Esto se utiliza para otros fines, como el almacenamiento de claves de cifrado, "DomainKeys" o "Sender Policy Framework ".

Mensajes DNS Un formato de mensaje DNS se utiliza para las consultas y respuestas de este protocolo. Este formato de mensaje contiene cinco campos que ofrecen un lugar para la consulta planteada por el cliente, la respuesta o respuestas proporcionadas por el servidor, y la información del encabezado que controla todo el proceso. La tabla a continuación describe el formato DNS mensaje general, proporcionando un breve resumen de cada una de sus campos y cómo se utilizan.

Header (Cabecera)Contiene campos que describen el tipo de mensaje y aportan información importante al respecto.También contiene los campos que indican el número de entradas en las otras secciones del mensaje.

Identificador: Es un campo de 16 bits de identificación, generados por el dispositivo que crea el DNS. Este identificador se copia en la respuesta correspondiente del servidor de nombres y se puede usar para diferenciar respuestas cuando concurren múltiples consultas. Esto se utiliza en una forma similar a cómo el identificador de campo se utiliza en muchos de los tipos de mensajes ICMP .

Banderas

Consulta / respuesta (QR) (1 bit)Diferencia entre las consultas y respuestas. Se establece en 0 cuando la consulta se genera; cambiado a 1 cuando dicha consulta se cambia a una respuesta de un servidor de responder.

Código de operación (4 bits)0 - QUERY - Consulta estandar1 - IQUERY - Consulta inversa2 - STATUS - Solicitud de estado del servidor3 - Reservado4 - NOTIFY - Notificación de transferencia de zona5 – UPDATE

Respuesta Autoritativa(AA) (1 bit)

Flag de respuesta autoritativa. Si está activo en una respuesta, especifica que el servidor de nombres que responde tiene autoridad para el nombre de dominio enviado en la consulta.Truncamiento (TC) (1 bit): Cuando se establece a 1, indica que el mensaje se ha truncado debido a su longitud que es más largo que el máximo permitido para el tipo de mecanismo de transporte utilizado. Recursividad (RD) (1bit):Este bit indica al servidor de nombres que se pide resolución recursiva. El bit se copia en la respuesta.Recursividad disponibles (AR) (1 bit): Indica si el servidor de nombres soporta resolución recursiva.Zero (Z) (3 bits) Tres bits reservados a cero.Código de respuesta (RCODE) (4 bits)Del 0 al 5 se utilizan para DNS regulares (RFC 1035), mientras que del 6 - 10 se implementan en DNS dinamicios (RFC 2136)0 - NO ERROR - Sin errores1 - FORMAT ERROR - Error de formato2 - SERVER FAILURE - Falla del servidor3 - NAME ERROR - El nombre no existe en el dominio4 - NOT IMPLEMENTED - La consulta no es soportada por el servidor5 - REFUSED - El servidor rechazó la consulta6 - YX Domain - Existe un nombre cuando no debe.7 - YX RR Set - Existe un conjunto de registros fuentes que no debería existir.8 - NX RR Set - Un conjunto de registros fuentes debería existir.9 - Not Auth - El servidor que recibe la consulta no está autorizado para la zona específica.10 - Not Zone - el nombre especificado en el mensaje no está dentro de la zona especificada en el mensaje

Cuenta de preguntas (QDCOUNT) (2 bytes)Indica el número de preguntas en la pregunta la sección del mensaje.

Respuesta Número de registros (ANCOUNT) (2 bytes)Especifica el número de registros (RRs) en el campo Respuesta (Answer) del mensaje DNS.

Autoridad de Registro de Cuenta (NSCOUNT) (2 bytes)Especifica el número de registros (RRs) en el campo Autoridad (Authority) del mensaje DNS

Adicional Número de registros (ARCOUNT) (2 bytes)Especifica el número de registros (RRs) en el campo Adicional (Additional) del mensaje DNS.

Question (Pregunta)Lleva uno o más "preguntas", es decir, las consultas de información que se envía a un servidor de nombres DNS.

Las consultas DNS siempre contienen al menos una entrada en el campo “Question” que especifica lo que el cliente en está tratando de averiguar.

Nombre de la pregunta (QNAME) (Tamaño variable): Contiene el objeto, dominio o nombre de la zona que es objeto de la consulta, codificados usando la notación estándar de nombre DNS .

Tipo de pregunta (QTYPE) (2 bytes)1 - A - Dirección2 - NS - Servidor de Nombre5 - CNAME - Nombre canónico6 - SOA - Inicio de Autoridad12 - PTR - Puntero15 - MX - Mail16 - TXT - Texto

Clase de pregunta1 - IN - Internet

Answer (Respuesta)Campo lleva uno o varios registros que responden a la pregunta del campo “Question”

Authority (Autoridad)Contiene uno o más registros que apunten a los servidores de nombres autorizados que se pueden utilizar para continuar con el proceso de resolución.

Additional (Adicional)Transmite uno o más registros que contienen información adicional relacionada con la consulta que no es estrictamente necesario para responder a las preguntas (preguntas) en el mensaje.

Los campos Answer, Authority y Additional son los lugares en el mensaje, donde los servidores DNS colocan los registros (RR) para ser enviado de vuelta a un cliente que haya realizado una solicitud. Cada campo consta de cero o más registros, y en teoría, cualquier registro se puede colocar en cualquier sección.

Nombre (Name) (Tamaño Variable)Contiene el objeto, dominio o nombre de la zona al que el registro RR pertenece

Tipo (TYPE) (2 bytes)Código correspondiente al registro RR1 - A - Dirección2 - NS - Servidor de Nombre5 - CNAME - Nombre canónico6 - SOA - Inicio de Autoridad12 - PTR - Puntero15 - MX - Mail16 - TXT - Texto

Tiempo de vida (TTL) (4 bytes)Especifica el número de segundos que el registro debe ser retenido en la memoria caché del dispositivo de lectura del disco.

Resource Data Lenght (RDLenght) (2 bytes) Indica el tamaño en bytes del campo RDATA

Resource Data (RDATA) (Tamaño Variable) Datos correspóndientes al registro RR, el formato varía segun el tipo de RR

DemoniosNamed Named es un demonio (daemon en ingles) que implementa un servidor DNS (Domain Name System).Es parte de BIND (Berkeley Internet Name Domain), una implementación de los protocolos del sistema de nombres de dominio (DNS).

Archivos involucrados

Archivo de configuración de BIND - named.conf

Es el archivo de arranque, que es leído por el demonio named cuando arranca para saber a qué dominios va a servir y dónde encuentra las tablas de máquinas y direcciones IP.

Named.conf es el archivo de configuración principal de DNS ya que contiene la ubicación y parámetros de los demás archivos de configuración. Este archivo contiene dos tipos de secciones:Opciones " options ": Indica el directorio donde se encuentran otros archivos de configuración y algunas otras opciones.Zonas " zone ": Pueden existir varias zonas por archivo,estas zonas definen los dominios (osmosislatina.com) y redes "networks" (192.168.1.0) sobre los que semantiene información

Ubicación:

En RedHat/etc/named.conf

En Debian/etc/bind/named.conf

Archivos de zonaLos archivos de zona se suelen almacenar en el directorio /etc/bind/zones (aunque no es obligatorio). Su escritura se realiza siguiendo la sintaxis adecuada para los registros de recursos que se deseen incluir.Si el archivo de zona es un archivo de zona directo, el nombre de dicho archivo suele ser dominio.zone donde dominio es el nombre de la zona que se está definiendo sin el punto final; si es un archivo de resolución inversa, el nombre del archivo será direcciondered.in-addr.arpa donde direcciondered serán los octetos de la Direccion de Red de las direcciones IP del dominio de manera invertida.

Directivas

Los archivos de configuración de Bind contienen además una serie de líneas o directivas (a veces comentadas e ignoradas por el servidor, a veces descomentadas y efectivas) donde se indican los parámetros de funcionamiento del mismo. Las más importantes son:

directoryCon esta directiva se indica el directorio de trabajo de named. En él es donde se almacena, entre otras cosas, los archivos de zona que copia del servidor DNS primario (en el caso de que el servidor esté funcionando como servidor secundario).

forwardersEn esta directiva se indican las direcciones IP de los servidores DNS a quien consultará nuestro servidor en caso de no saber dar respuesta a una consulta.

zoneEstas directivas permiten declarar las zonas que tiene almacenadas el servidor. Por defecto, el servidor cuenta con una serie de zonas que no se deben modificar. En caso de querer añadir nuestras propias zonas, debemos hacerlo manualmente al final del archivo. Se declaran de la siguiente forma:zone "DOMINIO" { type TIPO; file "RUTA_ARCHIVO_ZONA"; masters { IP }; };

donde:DOMINIO: se especifica el nombre de la zona que estemos definiendo. Se escribe sin el punto final y entre comillas.TIPO: se especifica master si es una zona de un servidor primario o slave si es un servidor secundario.RUTA_ARCHIVO_ZONA: indica la ruta completa hasta el archivo de zona que contiene los datos relativos a la zona indicada en DOMINIO. Se escribe entre comillas y solo se utiliza si el servidor es un servidor primario.IP: especifica la dirección IP del servidor DNS primario del que solicitar una transferencia de zona. Sólo se utiliza si el servidor es una servidor DNS secundario.

Comandos utilizados

DIGdig es una herramienta de linea de comandos disponible en prácticamente cualquier distribución Linux (aunque también hay alguna versión para Windows) que permite hacer consultas a un servidor DNS.

Permite comprobar tanto el mapeo de nombres a IPs como el mapeo inverso de IPs a nombres, pero sólo sirve para Internet, ya que no mira en /etc/hosts (sólo utiliza /etc/resolv.conf).

Su uso es:dig opciones nombre tipo @servidor_dns

donde:servidor_dns: nombre o IP del servidor DNS al que queremos dirigir nuestra consulta, por ejemplo @dns1.nrc.ca. Si no especificamos este parámetro, dig utilizará los servidores DNS listados en /etc/resolv.conf.opciones: no es obligatorio utilizarlas. La más utilizada es +short que devuelve una respuesta más corta o no devuelve nada si no encuentra respuesta. La opción -x se utiliza para indicar a dig que queremos hacer una resolución inversa.nombre: es el nombre de dominio que se quiere resolver.tipo: especifica el tipo de consulta. Valores posibles serían A (IP del servidor que aloja al dominio; es la usada si no se especifica nada), NS (servidores DNS) o MX (servidores de correo).

NSLOOKUP

nslookup es un programa utilizado para saber si el servidor DNS que tenemos configurado está resolviendo correctamente los nombres de dominio y las IP. Se utiliza con el comando nslookup, que funciona tanto en Windows como en UNIX/Linux para obtener la dirección IP conociendo el nombre, y viceversa.

Su uso esnslookup google . com nslookup 200..40.0.83