DNS Domain Name Server

Transcripción

1 DNS Domain Name Server Servicio ofrecido en red para realizar el mapeo necesario entre el nombre de una máquina y su dirección IP. Base de datos distribuida usada por aplicaciones TCP/IP. Intercambio Cliente - Servidor. Al principio archivo hosts que contenía todos los nombres de dominio conocidos (la mayoría de los sistemas operativos actuales todavía pueden ser configurados para consultar un archivo hosts). En 1983 RFC 882 y RFC 883 definieron lo que luego evolucionó hacia lo que hoy se conoce como DNS. En 1987 RFC 1034 y RFC 1035, actuales. DNS funciona principalmente apoyado sobre protocolo UDP. Los requerimientos se realizan a través del puerto 53.

2 DNS Direcciones y Nombres Dirección web, también conocida como URL o Uniform Resource Locater. Sirve para localizar dónde se encuentra la página web. Por ejemplo: " le dice al SO qué protocolo debe usar para poder comunicarse con ese sitio. HTTP significa HyperText Transfer Protocol. Otro podría ser "ftp://" o File Transfer Protocol. " también es muy usado, significando que la conexión con el servidor es segura (está encriptada), por ejemplo para trabajar protegido en el caso de intercambiar un número de tarjeta de crédito. "onlyonecreations.com" es el domain name. "www" significa servidor web, pero actualmente puede estar o no. "/pages/wood-gift-pen.htm" le dice al servidor web que busque en el directorio "pages" y presente el archivo "wood-gift-pen.htm" al browser del Cliente. La dirección IP en este caso es " , pero es más fácil recordar

3 DNS Utilización Usos más comunes: Resolución de nombres: A partir del nombre completo de un host, por ejemplo obtener su dirección IP, Resolución inversa de direcciones: Mecanismo inverso del anterior, 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, gmail-smtp-in.l.google.com. Por tratarse de un sistema muy flexible, puede ser utilizado también para muchas otras funciones, tales como la obtención de claves públicas de cifrado asimétrico y la validación de envío de s (a través de mecanismos como SPF, Security Policy Framework).

4 DNS Requerimientos de la Aplicación Para poder acceder a DNS en un SO tipo Unix, los programas de aplicación deben recurrir a un resolver propio, al cual se accede mediante dos funciones de librería: gethostbyaddress(): toma una dirección IP y devuelve un nombre. gethostbyname(): toma un nombre y devuelve una dirección IP. El resolver contacta al Servidor de nombres para poder hacer el mapeo. El resolver generalmente es parte de la aplicación, no del SO, y se comunica con los servidores de nombre fundamentalmente mediante el protocolo de transporte UDP.

5 DNS Software Prácticamente el único software utilizado en los servidores de nombres de Internet es BIND (Berkeley Internet Name Domain). Este programa es utilizado en prácticamente todos los sistemas Unix del mundo. BIND se divide en tres componentes: El propio servidor, también conocido como demonio named. Este servidor escucha en el port 53 UDP. La librería del resolver. El resolver puede pensarse como el lado cliente de BIND, cuyo código realiza las preguntas a los servidores DNS. Las herramientas necesarias para testear el funcionamiento del servidor BIND. Se trata de un conjunto de utilidades de línea de comando tales como dig.

6 DNS Estructura jerárquica

7 DNS Estructura jerárquica El espacio de nombres de DNS es jerárquico, similar a la estructura del sistema de archivos de Unix. La organización es similar al sistema de particiones de disco. Jerarquía tipo árbol donde cada nodo se identifica por una etiqueta o nombre de hasta 63 caracteres, sin distinción entre mayúsculas y minúsculas. El root de este árbol es un nodo especial cuya etiqueta es nula pero las referencias a dicho dominio pueden ser expresadas por un punto (.). El nombre de dominio de cualquier nodo en el árbol es la concatenación de etiquetas separadas por puntos, empezando desde el nodo, hacia arriba hasta el root. Cualquier nodo del árbol debe tener un nombre distintivo y único, asociado a una dirección IP, pero la misma etiqueta puede aparecer en distintas partes. Se llama nombre totalmente calificado (FQDN, Fully Qualified Domain Name) al que finaliza con un punto, de no ser este el caso, necesita ser completado y esto se suele realizar de manera local. Es decir, según como esté configurado el sistema, ofrece la posibilidad al usuario de referirse a una máquina dentro de su dominio (comparte con la propia la misma sucesión de etiquetas) sin tener que escribirlo completamente. Un ejemplo de FQDN para un servidor de nombre filesystem en el dominio mdp.edu.ar es fylesystem.mdp.edu.ar.

8 DNS Estructura jerárquica

9 DNS Estructura jerárquica La estructura general del Sistema de Nombres se divide en tres áreas en lo que respecta a los dominios. top level (son aquellos que no pertenecen a otro dominio. Por ejemplo: com, org, ar y es ). A su vez se los puede clasificar en: arpa: se trata de un dominio especial usado para mapeo de direcciones a nombres genéricos u organizacionales: los más conocidos son siete, cada uno de tres caracteres. países o geográficos: son de dos caracteres y debajo generalmente se arman dominios con características organizacionales.

10 DNS Cómo obtener un nombre de dominio No se puede ir directamente a ICANN (Internet Corporation for Assigned Names and Numbers), debiendo recurrirse a sus delegaciones en los distintos países. El lugar donde debe hacerse la reserva de dominio depende del tipo de dirección que se desee obtener. Si se trata de una dirección de las denominadas top level domain, el trámite deberá realizarse ante Network Solutions o alguna de las nuevas entidades a las que haremos referencia más adelante. Para cada uno de los otros dominios de países (por ejemplo,.ar para la Argentina,.br para Brasil, etc.) el trámite deberá efectuarse ante la entidad delegada, que según el país puede ser una universidad, un proveedor de acceso o una organización gubernamental. En cuanto al código de país, se determina por una norma estándar ISO 3166 que otorga a cada país una identificación única de dos letras. La mayoría de los países lo exigen.

11 Argentina. Cómo obtener un nombre de dominio En primer lugar hay que dirigirse al sitio web que mantiene el Ministerio de Relaciones Exteriores, Comercio Internacional y Culto en Allí se encuentran además de los formularios a completar, un buscador de nombres de dominio ya registrados, la normativa pertinente e instructivos. Primero se debe verificar que el dominio que pretendemos registrar todavía esté disponible en Consultas sobre nombres de dominio registrados. Hay que recordar que en la búsqueda no se debe incluir "www", sino directamente el nombre buscado terminado en.com.ar,.org.ar, o.net.ar, que son los tres dominios aceptados. Es distinto el caso de pretender un dominio ".edu.ar", pues habrá que dirigirse a su administración, encomendada a la Red de Interconexión Universitaria (RIU), o más directamente a Procedimientos Técnicos, en donde encontraremos suficiente información sobre el trámite. Si el nombre está disponible, es decir "no hay información" sobre el mismo, como reza la leyenda que se obtiene en este caso, podremos ir a "Formularios web" y de allí a "Registro de denominación".

12 Argentina. Cómo obtener un nombre de dominio "Registro de denominación. En la primera pantalla se nos pedirá una dirección de correo electrónico y el nombre de dominio que pretendemos. En la segunda página, en el caso de que efectivamente el dominio esté disponible, se nos pedirá el nombre de la entidad registrante, que puede ser tanto una persona física como jurídica. En el caso de que no se haya dado previamente de alta a la entidad, habrá que ir a "nueva" y proporcionar todos los datos. De allí pasaremos a "nombre del responsable", y nuevamente, si no estamos ya incluidos en la base de datos de Nic.ar, deberemos completar un formulario con nuestros datos. Por fin habrá que brindar las direcciones IP del servidor en donde ubicaremos nuestra página (hosting) con sus correspondientes DNS. No se puede superar esta etapa si no se incluye esta información, lo que torna imposible registrar un nombre de dominio sin tener dónde publicarlo de antemano. Le seguirán cuestiones referidas al soporte técnico del proveedor del hosting, y como siempre, si no se haya previamente en la base de nombres hay que proporcionar sus datos.

13 Argentina. Cómo obtener un nombre de dominio Como un requisito que se agregó en el año 2001, se solicita en la página siguiente que se ingrese el CUIT/CUIL y/o documento de la entidad registrante según corresponda. Por último se devuelve una página con toda la información que le hemos proporcionado. Si está todo bien, aceptamos los términos de las reglas del registro y hacemos un último clic en confirmar datos. Inmediatamente veremos una nueva página en donde se nos comunica que se nos enviará a la cuenta de que hemos proporcionado el requerimiento, al que deberemos reenviar sin cambios a la dirección [email protected]. Probablemente en un par de días como máximo recibiremos un nuevo correo comunicándonos que el registro del dominio ha recibido un número provisorio. Ya sea en caso de que todo estuviera bien, como en caso contrario, se nos enviará un último comunicándonos tal situación. El registro todavía es gratis.

14 DNS Responsabilidad Administrativa Cuando una organización registra un dominio, se hace responsable de mantener sus Servidores de Nombre y se deben registrar al menos dos en el sistema DNS. El sistema es distribuido, jerárquico, replicado y tolerante a fallas. Cada componente del dominio (y también la raíz) tiene un Servidor Primario y uno o más Servidores Secundarios. Todos estos servidores tienen la misma autoridad para responder por ese dominio, pero el primario es el único con derecho a modificarlo. Todo servidor de nombres debe ser configurado con la lista de los servidores raíz bien conocidos. Estos servidores conocen los dominios de primer nivel que existen y cuáles son sus servidores de nombres. A su vez, los servidores de esos dominios conocen los sub-dominios que existen y cuáles son sus servidores: estructura de árbol. Las etiquetas top level están a cargo del NIC (Network Information Center) y se delegan responsabilidades por zonas. Una zona es un subárbol que se administra por separado. Por ejemplo.ar lo administra el NIC,.edu queda delegado, así como también mdp.edu.ar y aún fi.mdp.edu.ar. Es habitual que los dominios de segundo nivel se vayan dividiendo en zonas más pequeñas y por tanto más fáciles de administrar.

15 DNS Responsabilidad Administrativa Una vez que se delega autoridad sobre una zona, el administrador pasa a ser el responsable del mantenimiento y coherencia de los Servidores de Nombre de la misma. Cada vez que se instale una nueva máquina en su zona, el administrador le asignará un nombre y una dirección y anexará ambos a la base de datos. Esto da una idea aproximada del tamaño que podría tener cada zona. El responsable de una zona debe configurar un Servidor Primario, que obtiene su información desde archivos en disco, y uno o varios Secundarios, que obtienen su información desde el primario a través del mecanismo conocido como transferencia de zona. El Primario y los Secundarios deben ser independientes entre sí, de tal manera que la disponibilidad del servicio no se vea afectada por un único punto de falla. Cuando se produce una modificación en la zona, el administrador agrega la información apropiada en los archivos de configuración del Servidor Primario. Un Servidor Secundario se comunica con el Primario regularmente y, si existe alguna modificación, obtiene los nuevos datos. En este sentido, la existencia de Servidores de nombres Secundarios provee redundancia para así evitar un único punto de falla y posibilidad de reducción de carga.

16 DNS Servidores Root Dado que la información de cada zona se almacena en archivos separados, la definición de Primario o Secundario se realiza a nivel de Zona. Un servidor de nombres particular puede de este modo ser servidor de nombres primario para ciertas zonas y servidor de nombres secundario para otras. Cuando el Servidor no contiene la información que se le requiere debe contactar a otro. No todos los Servidores entienden cómo contactar otros, pero todos deben conocer cómo contactar los Root Name Servers pues sus direcciones IP, no sus nombres, se encuentran cargadas en los archivos de configuración de todos los Servidores Primarios. Estos Servidores especiales sólo se usan como puntos de entrada al sistema y el caching evita contactar los Root Servers siempre que sea posible para mantener bajo el número de búsquedas. Para reducir el tráfico DNS, todos los Servidores usan un caché. La potencialidad de los Root Servers radica en que conocen el nombre y dirección IP de cada Servidor de Nombre con autoridad en todos los dominios de segundo nivel.

17 DNS Servidores Root Los administradores de los Root Servers copian una BdD cuyo contenido lo decide el IANA (Internet Assigned Numbers Authority) y el Dto. De Comercio de USA y la hacen disponible a todos los usuarios de Internet. A su vez, cooperan entre ellos para mantener el nivel de servicio apropiado. No forman un solo grupo, se trata de 13 operadores diferentes. La mayor amenaza operacional es entonces un ataque de DdoS (ataque de denegación de servicio) para cuya defensa se provee anycast. En este sentido, se configuran diversas copias de los servers existentes, con la misma dirección IP y los mismos datos y trabajan de tal manera que las consultas se realizan al más cercano ya que el ruteo estándar Internet así lo permite.

18

19 DNS Servidores Root

20 DNS Formato de losmensajes 32 bits

21 DNS Formato de los Mensajes. Cabecera Fija Cabecera fija de 12 bytes y 4 campos de longitud variable. Identificación: lo llena el Cliente y lo repite el Servidor para correlacionar pregunta con respuesta. Los 4 campos siguientes al de flags, cada uno de 16 bits, especifican el número de entradas en los 4 campos de longitud variable que vendrán a continuación. Estos 4 campos, junto con el de flags e identificación son de longitud fija, de 12 bytes. Para una query, el número de preguntas es en general 1 y los otros tres campos van en 0. En el caso de respuesta, el número de respuestas es por lo menos 1 y los dos campos siguientes pueden ser 0 según la calificación de la misma. Las siglas RRs indican Registro de Recursos (Resource Records).

22 DNS Formato de los Mensajes. Flags El campo de flags (16 bits) califica el tipo de requerimiento o respuesta y consta de los siguientes campos: QR (1 bit): 0 (query); 1 (response) Opcode (4 bit): 0 (std query); 1 (inverse query); 2 (server status required) AA (1 bit): respuesta de un servidor autorizado para el dominio en cuestión TC (1 bit) truncado. En UDP quiere decir que la respuesta es mayor a 512 bytes y sólo se están enviando los primeros 512.

23 DNS Formato de los Mensajes. Flags RD (1 bit) recursion desired. Puede setearse en el query y es retornado en la respuesta y le dice al Servidor de nombres que maneje la pregunta él mismo (recursive query). Si el bit no se setea, y el Servidor al que se le pregunta no tiene autoridad, retorna una lista de otros Servidores a ser contactados para obtener la respuesta (iterative query). RA (1 bit) recursion available. Se setea a 1 en la respuesta si el Servidor soporta recursión. Excepto algunos root servers, casi todos soportan recursión. Rcode (4 bits) de código de retorno: 0 (no error), 1 (error de formato, el servidor no pudo entender el mensaje), 2 (fallo en el servidor, mensaje no procesado por problema en el servidor), 3 (error de nombre, el servidor no lo reconoce como tal), 4 (no se implementa el tipo de consulta solicitado), 5 (se rechaza ofrecer una respuesta por razones de política de seguridad o administrativas).

24 DNS Formato de los Mensajes. Preguntas. Query name es el nombre a buscar. Se trata de una secuencia de etiquetas, cada una comienza con un número de 1 byte que especifica la cantidad de bytes que siguen, que no pueden superar 63. El nombre termina con el byte 0, que es una etiqueta de longitud 0 (etiqueta del root). Se permite que este campo no posea en su totalidad un múltiplo de 32 bits de longitud. No se usa padding. Query class va normalmente en 1, significando dirección Internet. Query Type en la pregunta y Type en cada respuesta (RR). Se los distingue de esta Query Type en la pregunta y Type en cada respuesta (RR). Se los distingue de esta manera por que query type es un superconjunto de type.

25 DNS Formato de los Mensajes. Preguntas.

26 DNS Formato de los Mensajes. Respuestas Los tres últimos campos del mensaje de Respuesta DNS (Respuestas, Autoridad e Información Adicional) comparten un formato común, el de Resource Record o RR. Nombre de Dominio, de longitud variable, es el nombre para el cual corresponden los siguientes datos de recursos y tiene el mismo formato que el Query Name Type, de 1 byte, corresponde a uno de los Type de la Tabla. Class es normalmente 1 para Internet y su longitud de 1 byte. Tiempo de Vida, TTL, de 16 bits, indica el número de segundos que el Registro de Recursos puede mantenerse almacenado en caché de Cliente. Resource Data Length de 1 byte especifica la cantidad de datos de Recurso y su formato depende de Type. Por ejemplo, si Type es A, la longitud será 4, indicando que son 4 los bytes de una dirección Internet.

27 DNS Formato de los Mensajes. Respuestas Existen unos 20 tipos distintos de Resource Records. A (Address): se usa para traducir nombres de hosts a direcciones IPv4. AAAA: se usa para traducir nombres de hosts a direcciones IPv6. PTR (pointer): funciona a la inversa del registro A, traduciendo IPs en nombres de dominio. CNAME (Canonical Name): Permite a una máquina ser conocida por más de un nombre. Se usa para crear nombres de hosts adicionales, o alias, para los hosts de un dominio. Es usado cuando se están corriendo múltiples servicios (como ftp y web server) en un servidor con una sola direccion IP. Cada servicio tiene su propia entrada de DNS (como ftp.ejemplo.com. y también es usado cuando se corren múltiples servidores http, con diferente nombres, sobre el mismo host. HINFO (Host Information): Descripción del host, permite que la gente conozca el tipo de máquina y sistema operativo al que corresponde un dominio. MX (Mail Exchange Record): Asocia un nombre de dominio a una lista de servidores de intercambio de correo para ese dominio. Lleva asociado un número de 16 bits, preferencia, cuanto menor mayor si hay múltiples MX. 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.

28 DNS Tipos de Preguntas. En una pregunta recursiva el Servidor de Nombres no puede referirse o delegar la petición a otro Servidor de Nombres diferente, debe intentar por todos los medios resolverla. En una pregunta iterativa el Servidor de Nombres envía la mejor respuesta que puede o que conoce en ese momento. La respuesta puede ser la resolución del nombre o puede referirse a otro Servidor de Nombres que sea capaz de responder al cliente la petición original. Las preguntas inversas dan la posibilidad de preguntar un nombre a partir de una dirección IP.

29 DNS Tipos de Preguntas. En la aplicación Cliente se usa un nombre de dominio DNS. El requerimiento se pasa al Cliente DNS para resolución usando información guardada en caché local. Si el nombre se puede resolver, se responde la pregunta y se completa así el proceso. El caché del resolver local puede incluir información obtenida de dos fuentes posibles: un archivo Hosts configurado localmente o RR s obtenidos como respuestas de preguntas previas DNS que se guardan en chaché por un tiempo determinado. Si la pregunta no se puede responder con la información disponible en caché, se Si la pregunta no se puede responder con la información disponible en caché, se continúa con un proceso de resolución que implica el contacto del Cliente DNS al Server DNS.

30 DNS Tipos de Preguntas. Existe un Server DNS de preferencia para el Cliente. Cuando el Server DNS recibe la pregunta, primero chequea si existe información en sus archivos de zona y él puede resolver el nombre de manera autorizada con sus RR s. Si no existe información de zona para la pregunta, el Server chequea si puede resolver con información local en caché existente de preguntas previas. Si existe, puede responder y termina la consulta. Si el Server no encuentra la información en caché, el proceso continúa por medio de recursión. Esto implica la asistencia de otros Servidores de DNS. Por default el Cliente DNS le pide a sus Server de preferencia que use recursión para resolver en nombre del Cliente. Generalmente los Servidores DNS se configuran para soportar recursión por default.

31 DNS Tipos de Preguntas. Para poder iniciar el proceso de recursión, el Servidor DNS necesita información sobre los Servidores Roots en sus archivos de configuración: listado de servidores Roots que son autoridad en la raíz del árbol del espacio de nombres DNS. Los Servidores Root son autoridad para los dominios root y top-level. Si tuviera que encontrar un nombre, por ejemplo "host-b.example.microsoft.com., el Servidor DNS determina que necesita localizar el Servidor autorizado para el dominio top-level domain "com". Entonces usa una pregunta iterativa (o sea no recursiva) para el servidor "com" y obtener entonces una referencia para el servidor "microsoft.com". Luego le pregunta a este servidor y recibe una respuesta de referencia al Server para "example.microsoft.com". Finalmente contacta al Servidor "example.microsoft.com." y como éste contiene el nombre como parte de sus archivos de configuración de zona, responde de manera autorizada al Server que inició el proceso recursivo, que re-envía la respuesta al Cliente, completando el proceso. Durante el proceso de recursión, el servidor DNS que hace la búsqueda obtiene información del espacio de nombres que guarda en caché y puede usar para acelerar respuestas en requerimientos posteriores.

32 Preguntas Recursivas

33 Preguntas Iterativas

34 DNS Respuestas. Authoritative answer: es una respuesta positiva que lleva el bit de autorizado en alto para indicar que la respuesta fue obtenida desde un Servidor con autoridad directa sobre el nombre requerido. Positive response: puede estar formada por el RR requerido o un conjunto de RR s que se adaptan al nombre de dominio requerido y tipo de registro especificado en el mensaje de query. Referral answer: contiene recursos adicionales no especificados por nombre o tipo en la pregunta. Este tipo de respuesta es retornada al Cliente si no se soporta el proceso de recursión. Los registros actúan como respuestas de referencia útil que el Cliente puede usar para continuar la iteración. Los datos adicionales son RR s no requeridos en el type de la query. Por ejemplo, si el nombre de host era del tipo "www" y no se encontró ningún A RR para el mismo en la zona, pero se halló un CNAME RR para información en la respuesta. Negative response: puede indicar que uno de dos posibles resultados fue encontrado, o un server autorizado indicó que el nombre no existe o existe pero ningún registro del tipo especificado existe.

35 DNS Respuestas.

36 DNS Caché. El costo de la búsqueda de nombres no locales puede ser muy alto si los revolvedores transmiten sus pedidos a los Servidores Root y se genera mucha carga sobre Internet. Los Servidores usan caching para optimizar estos costos. Cada Servidor mantiene un caché de nombres usados recientemente así como registros de dónde se obtuvo la información de mapeo para ese nombre. Cuando el cliente pregunta, el Servidor primero chequea para ver si tiene autoridad para ese nombre. Si no la tiene chequea su cache.la información que obtiene del cache marca la respuesta como no autorizada y da el nombre del dominio del Servidor del cual obtuvo el resultado. El único problema es que la información podría estar desactualizada, por este motivo es que existe un parámetro indicador del tiempo de vida de la misma.

37 DNS Ejemplos.

38 DNS Ejemplos.

39

40

41 DNS Preguntas Inversas. Necesidad de búsqueda inversa: El resolver envía una petición al servidor de nombres para resolver el nombre de un host asociado a una determinada dirección IP. Esto puede suceder en el contexto de seguridad de algunas aplicaciones. Como no hay correlación entre direcciones IP y nombres de hosts en el espacio de nombres DNS, solo una búsqueda en todos los dominios garantizaría una respuesta correcta. La estructura de nombres normal es del tipo árbol a partir de una raíz. Escribimos un nombre de dominio de izquierda a derecha pero la estructura jerárquica es al revés. Por ejemplo: name de dominio = => nodo más alto en el árbol =.com, siguiente más bajo =.example, siguiente más bajo = www. Una dirección IPv4, por ejemplo , define un host host = 17 en un rango de direcciones Clase C ( x). En este caso la parte más importante (nodo más alto) está a la izquierda (192). Sería imposible construir una estructura de árbol sensible que pudiera ser recorrida en un tiempo aceptable. La solución es invertir el orden de la dirección y colocar el resultado bajo un dominio especial IN-ADDR.ARPA.

42 DNS Preguntas Inversas. IN-ADDR.ARPA Esta parte del espacio de nombres está estructurada de acuerdo a direcciones, por eso garantiza la localización de datos, sin la necesidad alternativa de realizar una búsqueda exhaustiva del espacio de dominios. El dominio empieza en IN-ADDR.ARPA y posee una subestructura que sigue a estructura de direccionamiento IP. Los nombres de dominio en el dominio IN- ADDR.ARPA se definen con 4 etiquetas aparte del sufijo IN-ADDR.ARPA. Cada etiqueta es un número Así, por ejemplo, los datos para la dirección de Internet se localizan en el nombre de dominio IN-ADDR.ARPA. Esta manera de escribir al revés, aunque engorrosa de leer, permite que se deleguen zonas que sean una red en el espacio de direcciones. Por ejemplo 10.IN-ADDR.ARPA puede ser una zona que contenga datos para ARPANET, mientras que 26.IN- ADDR.ARPA puede ser una zona separada para MILNET.

43 DNS Preguntas Inversas. IN-ADDR.ARPA Los Registros son del tipo PTR RR. Por ejemplo, el dominio IN-ADDR.ARPA contendrá información del GW de ISI entre las redes 10 y 26, que tiene tiene direcciones y y un nombre MILNET- GW.ISI.EDU, un GW de MIT entre las redes 10 a 18 (también de MIT), con direcciones y y un nombre GW.LCS.MIT.EDU y los hosts A.ISI.EDU and MULTICS.MIT.EDU. La base de datos podría escribirse: 10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU. 10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU. 10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU. 18.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU. 26.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU IN-ADDR.ARPA. PTR A.ISI.EDU IN-ADDR.ARPA. PTR MULTICS.MIT.EDU.

44 DNS Preguntas Inversas. IN-ADDR.ARPA 10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU. 10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU. 18.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU. 26.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU IN-ADDR.ARPA. PTR A.ISI.EDU IN-ADDR.ARPA. PTR MULTICS.MIT.EDU. Un programa que buscara GWs en la red 10, originaría un query del tipo QTYPE=PTR, QCLASS=IN, QNAME=10.IN-ADDR.ARPA. Recibiría dos RRs en respuesta: 10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU. 10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU. Luego el programa podría generar queries del tipo QTYPE=A, QCLASS=IN preguntando por MILNET- GW.ISI.EDU. and GW.LCS.MIT.EDU. para descubrir las direcciones de Internet de estos GWs. Un resolver que busque el nombre de host de editará un query QTYPE=PTR, QCLASS=IN, QNAME= IN-ADDR.ARPA, y recibirá IN-ADDR.ARPA. PTR MULTICS.MIT.EDU.

45 DNS Preguntas Inversas. IN-ADDR.ARPA Entonces, la solución encontrada a la oposición intrínseca entre la disposición de los nombres y de las dorecciones IP es el ordenamiento de servidores por IP. De este modo no se descarta la jerarquía de nombres, sino que se crea una jerarquía nueva, numérica que coexiste con la de nombres. De este modo se facilita la búsqueda inversa. IN-ADDR.ARPA, el nuevo dominio, se localiza en el dominio top level reservado.arpa, que originalmente fue usado para la transición de viejos hosts a DNS. Dentro de esta IN-ADDR.ARPA se crea una nueva jerarquía numérica para cubrir todo el espacio de direcciones IP. En el primer nivel dentro de IN-ADDR.ARPA, existen 256 subdominios, llamados 0, 1, 2 hasta 255. Dentro de cada subdominio, existen 256 subdominios más en el segundo nivel que se numeran de igual manera., por ejemplo IN-ADDR.ARPA. Existe un tercer nivel similar, por ejemplo, IN-ADDR.ARPA. Finalmente, existen 256 subdominios en un cuarto nivel dentro de cada subdominio de tercer nivel, tal como IN-ADDR.ARPA.

46 DNS Preguntas Inversas. IN-ADDR.ARPA Entonces, dentro de IN-ADDR.ARPA se ha creado un espacio de nombres que es un paralelo del espacio de direcciones de IP. (O sea que existen varios billiones de nodos y ramas en esta parte espacio de nombres!) Observar RR convencional apuntando a su dirección IP RR reverso en IN-ADDR.ARPA apuntando al dominio

47 DNS Ejemplo Base de Datos /var/named/db.mycompany.com.hosts. mycompany.com. IN SOA mymachine.mycompany.com. root.mymachine.mycompany.com. ( ; Serial number as date and two digit number YYMMDDXX ; Refresh in seconds 28800=8H 3600 ; Retry in seconds 7200=2H ; Expire =1 week ) ; Minimum TTL 86400=24Hours mycompany.com. IN NS mymachine.mycompany.com. mycompany.com. IN MX 10 mailmachine.mycompany.com. mymachine.mycompany.com. IN A mailmachine.mycompany.com. IN A george.mycompany.com. IN A mycompany.com. indica que el Server es para ese dominio. IN es Internet Name. SOA es Start of Authority (es el server autoridad del dominio) mymachine.mycompany.com. es el servidor de nombres primario del dominio root.mymachine.mycompany.com. es la persona a contactar para más información.

48 DNS Ejemplo Base de Datos Las líneas entre () son para el servidor secundario, que corre como esclavo Número de serie, para indicar si la información es nueva o vieja. Se incrementa cuando se modifica el archivo de zona. De este modo, el Secundario sabe cuando se ha modificado la zona y entonces debería actualizarse Refresco Tiempo en segundos entre requerimientos de actualización por parte del Secundario. (Cada 3 hs el Secundario requiere transferencia) Reintentar Cuando falla la actualización. Es el número de segundos que el Secundario esperará antes de volver a intentar cuando ha fallado el último intento. (Reintentará luego de 1h) Expiración Hasta cuando puede responder el secundario aunque no haya podido actualizar. Número de segundos que un Servidor esperará antes de considerar los datos como caducados si no puede acceder al Primario. (Podrá responder durante 7 días) TTL Para el resolver, tiempo máximo en caché. Luego de pasado este tiempo se debe recurrir a servidores autorizados para actualizar a información. (Validez del caché de 1 día) A continuación empiezan los RRs. Primero el nombre del Servidor Primario, luego él o los Secundarios (NS), un registro del servidor de correo (MX), acompañado de un valor de preferencia variable de 0 a (más bajo, mayor prioridad), luego el resto de las máquinas del dominio, los nombres canónicos (CNAME), etc.