El servicio DNS. Zonas y dominios.

Transcripción

1 DNS Relación entre nombre y dirección IP Nombres públicos y privados Concepto y estructura jerárquica Los Top Level Domains El Internic. Los Nic delegados El dominio in addr.arpa Zonas y dominios Servidores de nombres Tipos de servidores Búsquedas recursivas y servidores forwarder Configuración de un servidor de nombres El registro SOA Los registros de origen relativo y de inclusión. La delegación de autoridad: NS Los registros de identificación: A, PTR, CNAME La encaminación del correo: MX, MB, MR, MINFO, MG Registros de descripciones: TXT, HINFO, WKS, RP Registros experimentales: ISDN, X25, GPOS El servidor BIND de la Universidad de Berkeley Las herramientas de consulta Nslookup Cyberkit El servicio Whois. Página 1 de 19, a las 1:27 del 18/09/aa

2 Relación entre nombre y dirección. Aunque las direcciones numéricas de los ordenadores en Internet las podemos manejar fácilmente son difíciles de recordar, y pueden no ser estables si la máquina cambia de red, con los consiguientes problemas asociados: Imaginemos que una casa comercial recibe su correo electrónico en la dirección ventas@[ ]. Después de usarla durante seis meses otro proveedor de Internet le oferta un servicio mejor y decide cambiar su dirección de correo cambia a ventas@[ ] y por tanto debe comunicar esta cambio de dirección a todos sus posibles clientes con los problemas propios de estos casos. Si vuelve a repetirse el cambio volveremos a tener el problema. Sería mucho mejor tener una dirección de correo de la forma ventas@fabricante.es, por ejemplo, que se mantuviese fija aunque cambiásemos de proveedor y por ende de dirección de red. Esto es realmente el objetivo del DNS (Domain Name System), conseguir que podamos referirnos a los nodos de Internet por un nombre propio que no dependa de su situación y que sea estable. Nombres públicos y privados. Otra característica importante a tener en cuenta es en que ámbito queremos que sea conocido el nombre de nuestras máquinas: en toda la Internet o simplemente en nuestra red. En el primer caso estamos hablando de un nombre público, en el segundo de un nombre privado. Concepto y estructura jerárquica. Pero, qué es el DNS?. En esencia un servicio de directorio (una base de datos) distribuido por toda la Internet, y por tanto muy, muy grande, que relaciona los nombres y las direcciones IP de las máquinas conectadas a Internet, relación que en contra de lo que se pudiera pensar no es biunívoca: a cada dirección IP le pueden corresponder varios nombres, es decir, una máquina puede llamarse de varias maneras, y un nombre puede corresponder a un conjunto de direcciones de máquinas. Dos cosas más hay que ver sobre el DNS: como esta organizado y como está distribuido. En primer lugar el DNS tiene una estructura jerárquica en forma de árbol, donde los nodos de cada uno de los niveles recibe el nombre de dominio de una forma independiente y de subdominio con respecto al dominio de nivel superior directamente relacionado con él, existiendo una relación parental entre ellos. Una primera premisa fundamental para que el sistema funcione bien es que, si bien el nombre de un dominio debe ser único entre los hijos de un mismo padre, no necesita serlo entre los demás. En segundo lugar, cuando nos referimos a él, hay que fijar la posición del dominio en el árbol, lo que se hace añadiendo a la derecha de su nombre los sucesivos nombres que vamos encontrando recorriendo el árbol hacia arriba, separados por el carácter., hasta llegar a la raíz, dominio que recibe el nombre de.. Dentro de la jerarquía, los nodos finales del árbol corresponden a los nombres de las máquinas. Página 2 de 19, a las 1:27 del 18/09/aa

3 El DNS se basa en tres componentes fundamentales: 1. Un plan de atribución de nombres que refleja la estructura definida anteriormente. 2. Un protocolo que puede evolucionar basado en TCP y UDP. 3. Un conjunto de servidores conectados a Internet que cooperan proporcionando un servicio ininterrumpido. Estos fundamentos están descritos en las RFC 1034 y Los Top Level Domains. Los dominios de primer nivel bajo., son llamados TLD (Top Level Domain), existen ya en un número fijo sólo circunstancias excepcionales motivarían la creación de alguno nuevo, al contrario que los dominios bajo ellos que se crean según las necesidades. Existen los siguientes TLD: com. Entidades comerciales. edu. Entidades educativas. net. Proveedores de Internet. org. Cualquier tipo de organización. int. Organizaciones internacionales. gov. Agencias del gobierno de los EE.UU. Página 3 de 19, a las 1:27 del 18/09/aa

4 mil. Ejército de los EE.UU. XX Un dominio por país. Ej: es = España. arp. Redes arpa para la gestión de zonas inversas. Mientras los cinco primeros son de adscripción abierta los restantes están restringido a sus correspondientes ámbitos de influencia. El Internic. Los Nic delegados. Para ver como está distribuido el servicio en Internet hagamos un poco de historia. Al igual que el tema de la asignación de direcciones, no es posible dejar la elección de nombre al libre albedrío de cada uno de los que se conecten a Internet ya que inevitablemente se producirían conflictos. Es por esto, que en principio la asociación de nombre y direcciones de máquinas se mantenía en el NIC (Network Information Center) mediante un archivo que se actualizaba manualmente y se ponía a disposición de los usuarios. También se publicaron las reglas que habían de regir los nombres de dominios en las RFC 952 y 1123 y que fundamentalmente son: Se admiten como caracteres válidos las letras no acentuadas, las cifras y el carácter, si bien el nombre no puede empezar por este último carácter. No se distingue entre letras mayúsculas y minúsculas. La longitud máxima de la cadena del nombre es de 256 caracteres. Este procedimiento que hubo que desechar por inviable debido al crecimiento de Internet y se implementó entonces el servicio de nombres y se delegó en los NIC regionales la gestión de los TLD correspondientes de la siguiente forma: El INTERNIC es el responsable de la creación de los TLD y de la delegación de dominios bajo los TLD com, org, edu y net. El DDN NIC (Defense Data Network Network Information Center) asigna los dominios bajo mil y gov, y en cada país existen NIC que gestionan los dominios correspondientes. El NIC español o ES NIC depende de Rediris (Red de Investigación Española) que a su vez depende del Consejo Superior de Investigaciones Científicas). El dominio in addr.arpa Dentro de la jerarquía definida anteriormente queda resuelto el problema de encontrar una dirección a partir de un nombre, pero nos queda el problema inverso, encontrar el nombre que corresponde a una dirección. Para resolverlos se creo el TLD in addr.arpa, llamado dominio inverso y cuya jerarquía se forma fraccionando la dirección IP en 4 bytes (o sea su representación decimal) y tomando cada una como un nivel en el árbol invirtiendo los campos al considerarla como parte del dominio inaddr.arpa. El ejemplo siguiente lo aclarará más: Página 4 de 19, a las 1:27 del 18/09/aa

5 Zonas y dominios. Por definición una zona representa un grupo inconfundible de sistemas gestionado por una autoridad central. En el caso del DNS, una zona corresponde bien a un dominio o grupo de ellos (por ejemplo editorial.es) que permite asociar direcciones IP a nombres de máquinas (zonas directas) o bien corresponden a una subred o grupo de ellas ( por ejemplo ) y permite asociar nombres de máquinas a direcciones Página 5 de 19, a las 1:27 del 18/09/aa

6 IP (zonas inversas). Si cada uno de los nodos del árbol jerárquico del DNS es un dominio, una zona es una entidad administrativa que engloba a uno o varios de aquellos. Cada zona tiene asociada un archivo de zonas y un conjunto de servidores que cooperan para servir la información contenida en aquél. Servidores de nombres. Llevar a la práctica la organización anterior se hace mediante el conjunto de los servidores de nombres distribuidos por Internet. Estos servidores ofrecen la información sobre las zonas, que ellos mismos mantienen en unos ficheros llamados archivos de zona. Volvemos a tener una relación no biunívoca entre zona y servidor. Para una zona pueden existir más de un servidor y un servidor puede distribuir información sobre varias zonas. Esto se hace así por necesidad, ya que cualquier red conectada a Internet se vuelve prácticamente inaccesible si los servidores del DNS que gestionan las zonas a que pertenecen sus máquinas dejan de funcionar. Con respecto a una zona, a los servidores que distribuyen su información se les llama servidores que tienen la autoridad (authoritative servers) y las respuestas que dan a las peticiones de información sobre las zonas que mantienen se dice que sientan autoridad (authoritative answers). Los modelos de gestión de una zona y sus servidores vienen dado por las RFC 1034 y 1996 que definen cuatro tipos de servidores: Servidores maestros o propietarios (master servers), que sientan autoridad, donde se mantienes los originales de los archivos de zonas que se envían a otros servidores mediante las llamadas transferencias de zonas. Los servidores esclavos (slave servers), que sientan autoridad y recuperan los archivos de zonas de los servidores maestros. El servidor maestro primario (primary master), que sienta autoridad y es la raíz de la jerarquía de la zona. Los servidores furtivos (Stealth servers), que son como los esclavos, pero no están referenciados como servidores que mantienen la zona. Dentro de esta organización los servidores maestros, esclavos y furtivos son servidores secundarios dentro de la zona. Hay que tener en cuenta que cualquier servidor secundario puede ser esclavo en la zona y maestro de otra subzona. Un ejemplo de la jerarquía se ve en: Página 6 de 19, a las 1:27 del 18/09/aa

7 Pare evitar incoherencias en los datos estos sólo se actualizan en los servidores maestros y se sincronizan en los esclavos mediante las llamadas transferencias de zonas que se realizan usando el protocolo TCP mientras que las consultas se hacen habitualmente usando el protocolo UDP. Búsquedas recursivas y servidores forwarders. Ya hemos visto como está organizada la jerarquía del servicio de nombres, veamos ahora como funciona. En primer lugar hay que saber que los servidores de nombre no sólo saben dar información a sus clientes sino también preguntar y responder a sus iguales para obtener y dar información. Por otro lado todos los servidores de nombres usan en su configuración un fichero llamado cache que contiene información sobre los servidores raíces del servicio DNS. Un ejemplo es el siguiente: This file holds the information on root name servers needed to initialize cache of Internet domain name servers (e.g. reference this file in the "cache. <file>" configuration file of BIND domain name servers). This file is made available by InterNIC registration services under anonymous FTP as file /domain/named.root on server FTP.RS.INTERNIC.NET OR under Gopher at RS.INTERNIC.NET under menu InterNIC Registration Services (NSI) submenu InterNIC Registration Archives file named.root last update: Aug 22, 1997 related version of root zone: formerly NS.INTERNIC.NET IN NS A.ROOT SERVERS.NET. A.ROOT SERVERS.NET A formerly NS1.ISI.EDU Página 7 de 19, a las 1:27 del 18/09/aa

8 NS B.ROOT SERVERS.NET. B.ROOT SERVERS.NET A formerly C.PSI.NET NS C.ROOT SERVERS.NET. C.ROOT SERVERS.NET A formerly TERP.UMD.EDU NS D.ROOT SERVERS.NET. D.ROOT SERVERS.NET A formerly NS.NASA.GOV NS E.ROOT SERVERS.NET. E.ROOT SERVERS.NET A formerly NS.ISC.ORG NS F.ROOT SERVERS.NET. F.ROOT SERVERS.NET A formerly NS.NIC.DDN.MIL NS G.ROOT SERVERS.NET. G.ROOT SERVERS.NET A formerly AOS.ARL.ARMY.MIL NS H.ROOT SERVERS.NET. H.ROOT SERVERS.NET A formerly NIC.NORDU.NET NS I.ROOT SERVERS.NET. I.ROOT SERVERS.NET A temporarily housed at NSI (InterNIC) NS J.ROOT SERVERS.NET. J.ROOT SERVERS.NET A housed in LINX, operated by RIPE NCC NS K.ROOT SERVERS.NET. K.ROOT SERVERS.NET A temporarily housed at ISI (IANA) NS L.ROOT SERVERS.NET. L.ROOT SERVERS.NET A housed in Japan, operated by WIDE NS M.ROOT SERVERS.NET. M.ROOT SERVERS.NET A End of File Cuando un cliente pide la traducción de un nombre o de una dirección a su servidor incluye activado en su petición el llamado bit de recursividad, indicándole con Página 8 de 19, a las 1:27 del 18/09/aa

9 ello al servidor que si no sabe la respuesta la busque. Si el servidor conoce la respuesta la envía al cliente, y si no envía la petición de información, sin activar el bit de recursividad a uno de los servidores del dominio raíz, elegido al azar entre aquellos que aparecen en su fichero de cache. Este le contesta con las direcciones de los servidores que gestionan el TLD que aparece en la petición. Nuestro servidor elegirá nuevamente al azar uno de estos servidores y le preguntará, a lo que el otro responderá, bien con la dirección requerida, o con las direcciones de los servidores que gestionan el subdominio siguiente en el nombre. Este proceso se reitera hasta que un servidor devuelve la traducción a su dirección IP del nombre requerido o el mensaje de que dicha dirección no existe, información que a su vez es remitida al cliente. Este proceso requiere un buen número de peticiones y respuesta, que ocasiona que si el servidor interrogado por el cliente está tras una línea de baja velocidad pueda cargarla con tráfico innecesario. En este caso podemos configurar al servidor para que transmita las peticiones recibidas que no sea capaz de resolver a otro servidor o servidores llamados forwarder, con el bit de recursividad activado, con lo que la búsqueda es realizada por aquél. En la configuración del servidor se puede optar por realizar o no la búsqueda recursiva si el servidor forwarder no responde de forma satisfactoria. La siguiente animación muestra como se realiza una búsqueda recursiva: Configuración de un servidor de nombres. Existen distintos programas que pueden actuar como servidores de nombres pero en la configuración de todos ellos deben existir: El fichero de cache que contienen las direcciones de los servidores de nombres del dominio raíz.. Los archivos de zona, ficheros contienen la información de las mismas. Si el servidor es esclavo estos ficheros se copiaran de su servidor maestro. El archivo de arranque o configuración, que dice que zonas se gestionan y donde se encuentran los archivos de zonas y de cache. Los ficheros de cache y de zonas pueden contener distintos tipos de registros, pero todos ellos llamados registros de recursos (RR, Resource records) tienen la misma estructura: La parte izquierda del registro indica su poseedor, es decir, el nodo del árbol a quien se aplica este registro. La parte central es una estructura de tres campos: El TTL (Time to live) que indica la duración de la información de este registro en los cache. Esta información no se indica habitualmente Página 9 de 19, a las 1:27 del 18/09/aa

10 porque en su lugar se suele usar predeterminada en el registro SOA que contiene la información global de la zona. La clave que identifica la familia de protocolos. IN se refiere a los protocolos de Internet. El tipo de registro. La parte derecha indica el valor del registro y puede tener varios campos en función del tipo de registro. Dos reglas generales de abreviación son que cuando el campo izquierdo está referenciado en el derecho se puede sustituir por una arroba, y cuando dos registros consecutivos tienen iguales el campo izquierdo, este se puede suprimir en el segundo. Veamos ahora los distintos tipos de registros que existen. El registro SOA. Es el registro más importante de la zona. Es único y su estructura es la siguiente: En el campo de la izquierda se incluye el nombre de domino propietario de la zona o bien para indicar que el propietario es la propia zona. En el campo central se incluye los valore IN SOA (start of authority). El campo de la derecha incluye varios subcampos: En primer lugar aparece el nombre del servidor de nombres primario de la zona. En segundo lugar aparece la dirección de correo electrónico del responsable de la zona en la cual se ha sustituido por un punto. El siguiente campo es el serial, número fabricado normalmente a partir de la fecha de última modificación y que se usa como control por los servidores secundarios para saber si se ha modificado desde la última transferencia. El siguiente campo es el refresh e indica la frecuencia en segundos con que los secundarios deben de solicitar los registros SOA al primario para saber si es necesaria una transferencia de zona El campo retry indica la frecuencia en segundos con que los secundarios deben de interrogar al primario después de un primer fallo. El campo expire indica la el tiempo en segundos que debe transcurrir para que un servidor secundario invalide una zona cuyo primario le es inaccesible El campo Minimum TTL que indica la duración de vida predeterminada para los registros de la zona. Página 10 de 19, a las 1:27 del 18/09/aa

11 La tabla siguiente indica los valores recomendados por la RFC 1537 para estos parámetros. TLD Otro dominio Refresh 24 horas 8 horas Retry 2 horas 2 horas Expire 30 días 7 días Minimum TTL 4 días 1 día Un ejemplo de registro SOA es el siguiente: Editorial.es. IN SOA Servidor.editorial.es. Hostmaster.editorial.es. ( Serial Refresh 7200 Retry Expire ) Minimun TTL Los registros de orden relativo y de inclusión. El registro $Origin pone el actual origen para los nombres relativos (no calificados completamente, es decir, no terminados en. ), al indicado en el segundo campo del registro. El registro $Include inserta un fichero en la línea actual del fichero en el que esta colocado y opcionalmente se puede especificar un dominio de partida para los nombres relativos que vengan en el nuevo fichero. La delegación de autoridad: NS. Este registro identifica a servidores DNS. Se usa para dar la lista de servidores de la zona y para delegar subzonas a otros servidores. Los registros siguientes dan la lista de servidores para la zona editorial.es. Editorial.es. IN NS Servidor.editorial.es. IN NS Segundo.editorial.es. Supongamos que tenemos una subzona llamada andalucía y que queremos delegar en un servidor llamado malaga.andalucia.editorial.es. Tenemos que incluir los siguientes registros: Andalucia.editorial.es. IN NS Malaga.andalucia.editorial.es. Malaga.andalucia.editorial.es. IN A El registro de tipo A, que explicaremos más adelante es necesario para evitar un bucle en el proceso de resolución. Los registros de identificación: A, PTR, CNAME. Página 11 de 19, a las 1:27 del 18/09/aa

12 El registro de tipo A permite asociar una dirección IP a un nombre de máquina, de dominio o una mascara de subred. Por ejemplo: Malaga.andalucia.editorial.es. IN A in addr.arpa. IN A El registro de tipo PTR se usa para asociar un nombre de máquina o un nombre de red a una dirección IP si se usa en los ficheros de zona inversa: IN PTR Malaga.andalucia.editorial.es in addr.arpa. IN PTR Red.editorial.es. Si se usan en los ficheros de zona directa sirven para asociar una dirección de red a un nombre de red o para asociar varias redes a un dominio: Red.editorial.es. IN PTR in addr.arpa. Editorial.es. IN PTR IN PTR in addr.arpa in addr.arpa. El registro CNAME se usa para crear alias a otros nombres, es decir para poder referirnos a una misma máquinas por distintos nombres, por ejemplo uno distinto para cada servicio: IN CNAME Malaga.andalucia.editorial.es. ftp.editorial.es IN CNAME Malaga.andalucia.editoria.es La encaminación del correo: MX, MB, MR, MINFO, MG. Los registros MX se usan bien para encaminar el correo entre estafetas SMTP, o bien decir a quien hay que entregar el correo dirigido a la dirección de una determinada entidad, de la forma usuario@dominio, conocidas por direcciones corporativas. Por ejemplo: editorial.es. IN MX 10 Malaga.andalucia.editorial.es. La descripción de los campos de este tipo de registros es la siguiente: El campo de la izquierda lleva la entidad a la que se aplica el registro MX, que puede ser el nombre de una máquina, el nombre de un dominio, un nombre canónico de cualquier entidad o un nombre con caracteres de generalización (* Wildcard), o sea lo que aparece a la derecha de en una dirección de correo electrónico. Pueden existir varios registros MX para una misma entidad. El campo central, además de los identificadores de protocolo (IN) y de tipo de registro (MX) lleva un peso (valor numérico) para indicar la prioridad de ese MX con relación a los otros registros MX correspondientes a la misma entidad. Cuanto menor es el valor del peso mayor es la prioridad. El campo de la derecha contiene el nombre de la máquina que actuará como estafeta de correo para la entidad que aparezca en la parte izquierda del registro. Página 12 de 19, a las 1:27 del 18/09/aa

13 Veamos ahora como interactúan los registro MX con el correo. Cuando una estafeta SMTP tiene que entregar un mensaje de correo a una determinada dirección donde el campo nodo viene indicado con un nombre, utiliza el DNS para averiguar a que máquina debe ser entregado. Para ello primero pregunta al DNS por el nombre y si este es un nombre canónico se traduce al nombre real. Para el nombre real se pregunta al DNS si tiene registros MX asociados. En caso afirmativo se intenta enviar el mensaje a la máquina indicada en el registro MX de menor peso si no es posible a la siguiente y así sucesivamente. Si no es posible entregarlo a ninguna de las máquinas referenciadas en los registros MX correspondientes a la entidad, o bien estos no existían, se pregunta al DNS por la dirección IP de la entidad destinatario e intenta enviarle el correo directamente. Si no es posible la estafeta suspende el envío del mensaje reintentádolo más tarde. Al cabo de un cierto número de intentos infructuosos envía un mensaje al remitente avisándole del retraso y al cabo de otro espacio de tiempo sin poder entregarlo lo destruye avisando también al remitente. Los caracteres de generalización (*) se ponen en el campo izquierdo para indicar que hay que entregar los mensajes dirigidos a cualquier máquina del dominio que no tenga registros MX propios a la estafeta referenciada en el campo de la derecha. Qué reglas hemos de seguir para configurar los registros MX de nuestro servidor de nombres? Debemos poner los registros MX necesarios para indicar quien es la estafeta de correo para nuestras máquinas y normalmente deberíamos indicar con registros MX de mayor peso una segunda estafeta de respaldo, habitualmente situada en el proveedor de servicios, para que retenga los mensajes que vengan a nuestra estafeta local cuando esta esté fuera de servicio. Consideremos el ejemplo siguiente: en nuestro dominio editorial.es existe una estafeta llamada correo.editorial.es y en nuestro proveedor otra llamada correo.proveedor.es, y queremos que todo el correo dirigido a una dirección del tipo usuarios@editorial.es sea entregada en nuestra estafeta local quedando la estafeta del proveedor de respaldo, los registros MX necesarios serían: Editorial.es IN MX 10 Correo.editorial.es Editorial.es IN MX 20 Correo.proveedor.es Si además queremos que la máquina prueba.editorial.es reciba el correo directamente y que tenga como respaldo a la estafeta del proveedor debemos añadir los siguientes registros MX: Prueba.editorial.es IN MX 5 Prueba.editorial.es Prueba.editorial.es IN MX 10 Correo.proveedor.es Si ahora quisiéramos que cualquier otra máquina bajo el dominio editorial.es recibiese el correo en la estafeta local podríamos incluir el siguiente registro MX con wildcard pero esta es una práctica que no se recomienda: Página 13 de 19, a las 1:27 del 18/09/aa

14 *.editorial.es IN MX 20 Correo.editorial.es Hay que hacer constar que si la dirección de correo viene en formato numérico se entrega el mensaje directamente sin tener en cuenta nada de lo anterior. Los registros de tipo MB y MR se usan en pareja para establecer alias de direcciones de correo electrónico. Por ejemplo, si queremos que los mensajes que vengan a la dirección selte@editorial.es se entreguen al usuario varse de la máquina malaga.andalucia.editorial.es habría que poner los siguientes registros en el fichero del dominio editorial.es: Selte IN MB Malaga.andalucia.editorial.es Selte@editoriales IN MR Varse@malaga.andalucia.editorial.es Los registros MINFO, y MG apenas se usan y están diseñados para relacionar a varios usuarios con una sola dirección de correo, tarea que se hace de forma mas eficiente con las llamadas listas de correo que se verán en otro lugar del curso. Registros de descripciones: TXT, HINFO, WKS, RP. Los registro de tipo TXT asocian un texto a su poseedor: IN TXT Servidor Web de la editorial. Los registros de tipo HINFO indican información sobre la máquina: IN HINFO AXP 8400, OVMS 7.2, OSU Los registro de tipo WKS, indicación de servicios prestados por la máquina y RP, persona responsable apenas se utilizan. Registros experimentales: GPOS, ISDN, X25. Los registros de tipo GPOS sitúan geográficamente a la máquina, dando su latitud y longitud en grados y su altitud en metros: IN GPOS Los registros de tipo ISDN permiten asociar un número de teléfono de RDSI a una máquina: IN ISDN Los registro de tipo X25 permiten asociar una dirección X.121 a una máquina: IN X El servidor BIND de la Universidad de Berkeley, Bind (Berkeley Internet Name Domain Server) es el más difundido de entre los programas servidores de nombre y es prácticamente una referencia obligada para los otros. Bind se puede utilizar para gestionar un número cualquiera de zonas, actuando de primario o secundario y también como forwarder. La distribución para unix incluye los siguientes programas: Página 14 de 19, a las 1:27 del 18/09/aa

15 named. Es el programa servidor. named xfer. Usado por named para hacer las transferencias de datos. named reload. Fuerza al servidor a releer los archivos de zona y recargar los archivos de las zonas de las que sea secundario. named restart. Rearranca el servidor. ndc. Utilidad para gestión de named. Bind lleva tres tipos de archivos de configuración: Los archivo de zona con los datos de las mismas. Los archivos de cache que carga named al arrancar. El archivo /etc/named.boot, de arranque, que permite definir opciones y localizar el directorio donde están los demás archivos de configuración. El archivo de arranque permite las siguientes órdenes: Directory nombre cache nombre primary dominio fichero secondary dominio maestro fichero forwarder direccion.. include fichero bogusns direccion limit options Directorio donde se encuentran los demás ficheros Nombre del fichero de cache Indica que se es primario de una zona directa o inversa y el nombre del archivo de zona. Puede haber más de un registro. Secundario de una zona directa o inversa donde maestro es el primario y fichero el archivo de zona que se debe recuperar. Puede haber más de un registro. Direcciones de los forwarders. Puede haber más de un registro. Incluye un fichero de configuración añadido Lista de servidores con los que no hay que contactar Definición de límites Opciones diversas: no recursion: sólo acepta peticiones no recursivas query log: registro de las peticiones. forward only: pasar a modo esclavo. Vamos a ver un ejemplo de configuración para la red indicada en la imagen siguiente: Página 15 de 19, a las 1:27 del 18/09/aa

16 Nombre TCP/IP Estafeta SMTP 1 Uropigio Ciervo 2 Leopardo Okapi Leopardo 4 Pangolín Gorila 5 Ciervo Gorila Turaco 8 Lemur Gorila 9 Impala Elefante 10 Elefante Hiena 12 Gnu Licaón 14 Gereunc Gnu 15 Gacela 16 Lince Gorila Dominio de la red A: Bosque.Africa. Dominio de la red B: Sabana.Africa. Dominio del nodo Lince: Bosque.Europa. Servidor de nombres de los tres dominios el nodo nº 6. Fichero directo IN SOA Gorila.Bosque.Africa. root@gorila.bosque.africa. $ORIGIN Bosque.Africa. Gorila IN A IN MX 10 Gorila.Bosque.Africa. localhost IN A Leopardo IN A Okapi IN A IN MX 5 Leopardo.Bosque.Africa. Pangolin IN A IN MX 5 Gorila.Bosque.Africa. Ciervo IN A Página 16 de 19, a las 1:27 del 18/09/aa

17 Fichero directo IN SOA Gorila.Bosque.Africa. root@gorila.bosque.africa. $ORIGIN Africa. Sabana IN NS Gorila.Bosque.Africa. $ORIGIN Sabana.Africa. Lemur IN A IN MX 5 Gorila.Bosque.Africa. Impala IN A IN MX 5 Elefante.Sabana.Africa. Elefante IN A Ñu IN A Gereunc IN A IN MX 5 Ñu.Sabana.Africa. Fichero directo IN SOA Gorila.Bosque.Africa. root@gorila.bosque.africa. Bosque.Europa IN NS Gorila.Bosque.Africa. $ORIGIN Bosque.Europa. Lince IN A IN MX 5 Gorila.Bosque.Europa. Fichero Reverso para IN SOA Gorila.Bosque.Africa. root@gorila.bosque.africa. 1 IN PRT Ciervo.Bosque.Africa. 2 IN PRT Leopardo.Bosque.Africa. 3 IN PRT Gorila.Bosque.Africa. 4 IN PTR Pangolin.Bosque.Africa. 5 IN PRT Okapi.Bosque.Africa. Fichero Reverso para IN SOA Gorila.Bosque.Africa. root@gorila.bosque.africa 1 IN PTR Elefante.Sabana.Africa. 2 IN PTR Ñu.Sabana.Africa. 3 IN PTR Gereunc.Sabana.Africa. 4 IN PTR Impala.Sabana.Africa. 5 IN PTR Lemur.Sabana.Africa. Fichero Reverso para IN SOA Gorila.Bosque.Africa. root@gorila.bosque.africa 1 IN PTR Lince.Bosque.Europa. Las herramientas de consulta Aunque los programas que se utilizan para acceder a los servicios Internet ya utilizan el servicio DNS de forma interna, podemos necesitar alguna información de forma explícita, y para ello tenemos que recurrir a alguna herramienta. Veamos alguna de ellas: Nslookup Se puede considerar la herramienta universal de consulta al DNS y se encuentra tanto en sistemas unix, de los que es originaria como en otros sistemas. Las órdenes que admite se pueden dividir en tres grupos: Órdenes de situación: server nombre. Define el servidor que contestara a nuestras peticiones. set server=nombre. Igual que el anterior. Página 17 de 19, a las 1:27 del 18/09/aa

18 CyberKit root nombre. Pone la raíz de búsqueda en el server especificado. set root= nombre. Igual que el anterior. Órdenes de modificación: set debug, set d2. Activa la opción de debug. set defname=nombre. Añade el dominio nombre a cada interrogación. set recurse. Indica hacer búsquedas recursivas para contestar a las preguntas. set domain=nombre. Define el dominio para las peticiones. set timeout=tiempo. Tiempo máximo de espera a la respuesta. set querytype=opcion. Tipo de consulta. Las opciones válidas son a,any,cname,hinfo,mx,px,ns,ptr,soa,txt,wks,srv,natpr. set query=opción. Igual que el anterior. set type=opción. Igual que el anterior. Órdenes de interrogación: Un nombre o una dirección implica una orden de traducción. finger nodo. Da información de los usuarios en el nodo indicado. ls opt dominio [>fichero]. Es la orden de interrogación sobre los elementos pertenecientes al dominio. Si la opcion es a devuelve los nombres canónicos, si es h los registro de tipo HINFO, si es s los de tipo well known, si es d todos y si es t tipo el tipo de registro indicado. El campo fichero es opcional e indica que la respuesta se guarde en un fichero. Para consultar el DNS desde el entorno Windows puede usarse la utilidad CyberKit que en su opción Nslookup tiene la implementación de esta utilidad. Para usarla en la opción de Name Server hay que poner la dirección del servidor de nombre al que vamos a preguntar, en la opción de Type of search el tipo de petición a realizar y en la de Host or Address los datos para la petición. El servicio Whois. Aunque nslookup y otras herramientas nos permiten obtener información sobre el DNS, no es posible obtener por estos medios ninguna información de tipo administrativo sobre dominios, direcciones de redes, rutas, personas de contactos, etc. Tampoco nos permite verificar que dominios existen y si el que queremos usar no está registrado aún, etc. La información indicada anteriormente está registrada en bases de datos whois. Whois nació inicialmente como la base de datos que registraba la información sobre dominio, hosts, redes y usuarios de ARPANET, gestionada por el centro de información de la red de datos de Defensa de los Estados Unidos de América. Con la creación de los NIC whois se convirtió en un servicio distribuido de páginas blancas, donde la información relativa a cada dominio se encuentra en el NIC correspondiente. El Página 18 de 19, a las 1:27 del 18/09/aa

19 funcionamiento de whois esta regulado por la RFC 1400 y las bases de datos contienen los siguientes tipos de objetos: Objetos de tipo dominio (domain) que contienen la información técnica sobre un dominio. Objetos de tipo red (inetnum) que contienen información técnica sobre la delegación de una dirección de red. Objeto de tipo ruta (route) que contienen información sobre redes anunciadas dentro de una ruta de tipo CIDR por un protocolo de ruta externa. Objetos de tipo persona (person) que contienen información sobre las personas de contacto técnico o administrativo de otros objetos. Objetos del tipo sistema autónomo (aut num) que contienen información técnica sobre un proveedor. Servidores whois importantes son: Whois.internic.net que contiene información respecto de los dominios raíz y genéricos. Whois.ra.net que reune a todos los objetos de tipo ruta de Internet. Whois.ripe.net que contiene objetos de todo tipo relativos a Europa. El acceso a estos servidores se puede hacer a través del servidor web de las distintas organizaciones, por ejemplos el whois de NIC español tiene la dirección o bien con cliente específicos, tecleando desde una máquina unix whois h servidor whois consulta o bien desde las utilidades Cyberkit y Netlab en las máquina Windows. Página 19 de 19, a las 1:27 del 18/09/aa