El servicio DNS

DNS Relacin entre nombre y direccin IP Nombres pblicos y privados Concepto y estructura jerrquica Los Top Level Domains El Internic. Los Nic delegados El dominio in-addr.arpa Zonas y dominios Servidores de nombres Tipos de servidores Bsquedas recursivas y servidores forwarder Configuracin de un servidor de nombres El registro SOA Los registros de origen relativo y de inclusin. La delegacin de autoridad: NS Los registros de identificacin: A, PTR, CNAME La encaminacin 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.

Pgina 1 de 19, a las 1:27 del 18/09/aa

El servicio DNS

Relacin entre nombre y direccin. Aunque las direcciones numricas de los ordenadores en Internet las podemos manejar fcilmente son difciles de recordar, y pueden no ser estables si la mquina cambia de red, con los consiguientes problemas asociados: Imaginemos que una casa comercial recibe su correo electrnico en la direccin ventas@[130.12.3.45]. Despus de usarla durante seis meses otro proveedor de Internet le oferta un servicio mejor y decide cambiar; su direccin de correo cambia a ventas@[192.23.4.5] y por tanto debe comunicar esta cambio de direccin a todos sus posibles clientes con los problemas propios de estos casos. Si vuelve a repetirse el cambio volveremos a tener el problema. Sera mucho mejor tener una direccin de correo de la forma ventas@fabricante.es, por ejemplo, que se mantuviese fija aunque cambisemos de proveedor y por ende de direccin 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 situacin y que sea estable. Nombres pblicos y privados. Otra caracterstica importante a tener en cuenta es en que mbito queremos que sea conocido el nombre de nuestras mquinas: en toda la Internet o simplemente en nuestra red. En el primer caso estamos hablando de un nombre pblico, en el segundo de un nombre privado. Concepto y estructura jerrquica. 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 mquinas conectadas a Internet, relacin que en contra de lo que se pudiera pensar no es biunvoca: a cada direccin IP le pueden corresponder varios nombres, es decir, una mquina puede llamarse de varias maneras, y un nombre puede corresponder a un conjunto de direcciones de mquinas. Dos cosas ms hay que ver sobre el DNS: como esta organizado y como est distribuido. En primer lugar el DNS tiene una estructura jerrquica 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 relacin 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 dems. En segundo lugar, cuando nos referimos a l, hay que fijar la posicin del dominio en el rbol, lo que se hace aadiendo a la derecha de su nombre los sucesivos nombres que vamos encontrando recorriendo el rbol hacia arriba, separados por el carcter ., hasta llegar a la raz, dominio que recibe el nombre de .. Dentro de la jerarqua, los nodos finales del rbol corresponden a los nombres de las mquinas.
Pgina 2 de 19, a las 1:27 del 18/09/aa

El servicio DNS

El DNS se basa en tres componentes fundamentales: 1. Un plan de atribucin 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 estn descritos en las RFC 1034 y 1035. Los Top Level Domains. Los dominios de primer nivel bajo ., son llamados TLD (Top Level Domain), existen ya en un nmero fijo; slo circunstancias excepcionales motivaran la creacin de alguno nuevo, al contrario que los dominios bajo ellos que se crean segn las necesidades. Existen los siguientes TLD: com. edu. net. org. int. gov. Entidades comerciales. Entidades educativas. Proveedores de Internet. Cualquier tipo de organizacin. Organizaciones internacionales. Agencias del gobierno de los EE.UU.

Pgina 3 de 19, a las 1:27 del 18/09/aa

El servicio DNS

mil. XX arp.

Ejrcito de los EE.UU. Un dominio por pas. Ej: es = Espaa. Redes arpa para la gestin de zonas inversas.

Mientras los cinco primeros son de adscripcin abierta los restantes estn 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 asignacin de direcciones, no es posible dejar la eleccin de nombre al libre albedro de cada uno de los que se conecten a Internet ya que inevitablemente se produciran conflictos. Es por esto, que en principio la asociacin de nombre y direcciones de mquinas se mantena en el NIC (Network Information Center) mediante un archivo que se actualizaba manualmente y se pona a disposicin de los usuarios. Tambin se publicaron las reglas que haban de regir los nombres de dominios en las RFC 952 y 1123 y que fundamentalmente son: Se admiten como caracteres vlidos las letras no acentuadas, las cifras y el carcter -, si bien el nombre no puede empezar por este ltimo carcter. No se distingue entre letras maysculas y minsculas. La longitud mxima 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 gestin de los TLD correspondientes de la siguiente forma: El INTERNIC es el responsable de la creacin de los TLD y de la delegacin 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 pas existen NIC que gestionan los dominios correspondientes. El NIC espaol o ES-NIC depende de Rediris (Red de Investigacin Espaola) que a su vez depende del Consejo Superior de Investigaciones Cientficas). El dominio in-addr.arpa Dentro de la jerarqua definida anteriormente queda resuelto el problema de encontrar una direccin a partir de un nombre, pero nos queda el problema inverso, encontrar el nombre que corresponde a una direccin. Para resolverlos se creo el TLD in-addr.arpa, llamado dominio inverso y cuya jerarqua se forma fraccionando la direccin IP en 4 bytes (o sea su representacin 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 ms:

Pgina 4 de 19, a las 1:27 del 18/09/aa

El servicio DNS

Zonas y dominios. Por definicin 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 mquinas (zonas directas) o bien corresponden a una subred o grupo de ellas ( por ejemplo 150.214.0.0) y permite asociar nombres de mquinas a direcciones
Pgina 5 de 19, a las 1:27 del 18/09/aa

El servicio DNS

IP (zonas inversas). Si cada uno de los nodos del rbol jerrquico 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 informacin contenida en aqul. Servidores de nombres. Llevar a la prctica la organizacin anterior se hace mediante el conjunto de los servidores de nombres distribuidos por Internet. Estos servidores ofrecen la informacin sobre las zonas, que ellos mismos mantienen en unos ficheros llamados archivos de zona. Volvemos a tener una relacin no biunvoca entre zona y servidor. Para una zona pueden existir ms de un servidor y un servidor puede distribuir informacin sobre varias zonas. Esto se hace as por necesidad, ya que cualquier red conectada a Internet se vuelve prcticamente inaccesible si los servidores del DNS que gestionan las zonas a que pertenecen sus mquinas dejan de funcionar. Con respecto a una zona, a los servidores que distribuyen su informacin se les llama servidores que tienen la autoridad (authoritative servers) y las respuestas que dan a las peticiones de informacin sobre las zonas que mantienen se dice que sientan autoridad (authoritative answers). Los modelos de gestin 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 envan 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 raz de la jerarqua de la zona. Los servidores furtivos (Stealth servers), que son como los esclavos, pero no estn referenciados como servidores que mantienen la zona.

Dentro de esta organizacin 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 jerarqua se ve en:

Pgina 6 de 19, a las 1:27 del 18/09/aa

El servicio DNS

Pare evitar incoherencias en los datos estos slo 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. Bsquedas recursivas y servidores forwarders. Ya hemos visto como est organizada la jerarqua del servicio de nombres, veamos ahora como funciona. En primer lugar hay que saber que los servidores de nombre no slo saben dar informacin a sus clientes sino tambin preguntar y responder a sus iguales para obtener y dar informacin. Por otro lado todos los servidores de nombres usan en su configuracin un fichero llamado cache que contiene informacin sobre los servidores races 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: 1997082200 ; ; ; formerly NS.INTERNIC.NET ; . 3600000 IN NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4 ; ; formerly NS1.ISI.EDU

Pgina 7 de 19, a las 1:27 del 18/09/aa

El servicio DNS

; . 3600000 NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107 ; ; formerly C.PSI.NET ; . 3600000 NS C.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12 ; ; formerly TERP.UMD.EDU ; . 3600000 NS D.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90 ; ; formerly NS.NASA.GOV ; . 3600000 NS E.ROOT-SERVERS.NET. E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10 ; ; formerly NS.ISC.ORG ; . 3600000 NS F.ROOT-SERVERS.NET. F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241 ; ; formerly NS.NIC.DDN.MIL ; . 3600000 NS G.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4 ; ; formerly AOS.ARL.ARMY.MIL ; . 3600000 NS H.ROOT-SERVERS.NET. H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53 ; ; formerly NIC.NORDU.NET ; . 3600000 NS I.ROOT-SERVERS.NET. I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17 ; ; temporarily housed at NSI (InterNIC) ; . 3600000 NS J.ROOT-SERVERS.NET. J.ROOT-SERVERS.NET. 3600000 A 198.41.0.10 ; ; housed in LINX, operated by RIPE NCC ; . 3600000 NS K.ROOT-SERVERS.NET. K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129 ; ; temporarily housed at ISI (IANA) ; . 3600000 NS L.ROOT-SERVERS.NET. L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12 ; ; housed in Japan, operated by WIDE ; . 3600000 NS M.ROOT-SERVERS.NET. M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33 ; End of File

Cuando un cliente pide la traduccin de un nombre o de una direccin a su servidor incluye activado en su peticin el llamado bit de recursividad, indicndole con
Pgina 8 de 19, a las 1:27 del 18/09/aa

El servicio DNS

ello al servidor que si no sabe la respuesta la busque. Si el servidor conoce la respuesta la enva al cliente, y si no enva la peticin de informacin, sin activar el bit de recursividad a uno de los servidores del dominio raz, 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 peticin. Nuestro servidor elegir nuevamente al azar uno de estos servidores y le preguntar, a lo que el otro responder, bien con la direccin 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 traduccin a su direccin IP del nombre requerido o el mensaje de que dicha direccin no existe, informacin que a su vez es remitida al cliente. Este proceso requiere un buen nmero de peticiones y respuesta, que ocasiona que si el servidor interrogado por el cliente est tras una lnea de baja velocidad pueda cargarla con trfico 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 bsqueda es realizada por aqul. En la configuracin del servidor se puede optar por realizar o no la bsqueda recursiva si el servidor forwarder no responde de forma satisfactoria. La siguiente animacin muestra como se realiza una bsqueda recursiva:

Configuracin de un servidor de nombres. Existen distintos programas que pueden actuar como servidores de nombres pero en la configuracin de todos ellos deben existir: El fichero de cache que contienen las direcciones de los servidores de nombres del dominio raz .. Los archivos de zona, ficheros contienen la informacin de las mismas. Si el servidor es esclavo estos ficheros se copiaran de su servidor maestro. El archivo de arranque o configuracin, 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 duracin de la informacin de este registro en los cache. Esta informacin no se indica habitualmente

Pgina 9 de 19, a las 1:27 del 18/09/aa

El servicio DNS

porque en su lugar se suele usar predeterminada en el registro SOA que contiene la informacin 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 funcin del tipo de registro.

Dos reglas generales de abreviacin 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 ms 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 una @ 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 direccin de correo electrnico del responsable de la zona en la cual se ha sustituido la @ por un punto. El siguiente campo es el serial, nmero fabricado normalmente a partir de la fecha de ltima modificacin 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 despus 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 duracin de vida predeterminada para los registros de la zona.

Pgina 10 de 19, a las 1:27 del 18/09/aa

El servicio DNS

La tabla siguiente indica los valores recomendados por la RFC 1537 para estos parmetros.
TLD Refresh Retry

Otro dominio 8 horas 2 horas 7 das 1 da

24 horas 2 horas 30 das 4 das

Expire
Minimum TTL

Un ejemplo de registro SOA es el siguiente:

Editorial.es. IN SOA Servidor.editorial.es. Hostmaster.editorial.es. 1999092301 28800 7200 604800 86400 ) ( ; Serial ; Refresh ; Retry ; Expire Minimun TTL

Los registros de orden relativo y de inclusin. 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 lnea 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 delegacin 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 NS Servidor.editorial.es. IN Segundo.editorial.es.

Supongamos que tenemos una subzona llamada andaluca 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. 194.33.8.12 Malaga.andalucia.editorial.es. IN A

El registro de tipo A, que explicaremos ms adelante es necesario para evitar un bucle en el proceso de resolucin.

Los registros de identificacin: A, PTR, CNAME.

Pgina 11 de 19, a las 1:27 del 18/09/aa

El servicio DNS

El registro de tipo A permite asociar una direccin IP a un nombre de mquina, de dominio o una mascara de subred. Por ejemplo:
Malaga.andalucia.editorial.es. IN A 0.33.123.194.in-addr.arpa. IN A 194.33.8.12 255.255.255.240

El registro de tipo PTR se usa para asociar un nombre de mquina o un nombre de red a una direccin IP si se usa en los ficheros de zona inversa:
194.33.8.12 0.8.33.194.in-addr.arpa. IN PTR Malaga.andalucia.editorial.es. IN PTR Red.editorial.es.

Si se usan en los ficheros de zona directa sirven para asociar una direccin de red a un nombre de red o para asociar varias redes a un dominio:
Red.editorial.es. Editorial.es. IN PTR 0.8.33.194.in-addr.arpa. IN PTR 0.8.33.194.in-addr.arpa. IN PTR 0.33.123.194.in-addr.arpa.

El registro CNAME se usa para crear alias a otros nombres, es decir para poder referirnos a una misma mquinas por distintos nombres, por ejemplo uno distinto para cada servicio:
Www.editorial.es. ftp.editorial.es IN CNAME IN CNAME Malaga.andalucia.editorial.es. Malaga.andalucia.editoria.es

La encaminacin 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 direccin 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 descripcin 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 mquina, el nombre de un dominio, un nombre cannico de cualquier entidad o un nombre con caracteres de generalizacin (* Wildcard), o sea lo que aparece a la derecha de la @ en una direccin de correo electrnico. Pueden existir varios registros MX para una misma entidad. El campo central, adems de los identificadores de protocolo (IN) y de tipo de registro (MX) lleva un peso (valor numrico) para indicar la prioridad de ese MX con relacin 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 mquina que actuar como estafeta de correo para la entidad que aparezca en la parte izquierda del registro.
Pgina 12 de 19, a las 1:27 del 18/09/aa

El servicio DNS

Veamos ahora como interactan los registro MX con el correo. Cuando una estafeta SMTP tiene que entregar un mensaje de correo a una determinada direccin donde el campo nodo viene indicado con un nombre, utiliza el DNS para averiguar a que mquina debe ser entregado. Para ello primero pregunta al DNS por el nombre y si este es un nombre cannico 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 mquina 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 mquinas referenciadas en los registros MX correspondientes a la entidad, o bien estos no existan, se pregunta al DNS por la direccin IP de la entidad destinatario e intenta enviarle el correo directamente. Si no es posible la estafeta suspende el envo del mensaje reintentdolo ms tarde. Al cabo de un cierto nmero de intentos infructuosos enva un mensaje al remitente avisndole del retraso y al cabo de otro espacio de tiempo sin poder entregarlo lo destruye avisando tambin al remitente.

Los caracteres de generalizacin (*) se ponen en el campo izquierdo para indicar que hay que entregar los mensajes dirigidos a cualquier mquina 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 mquinas y normalmente deberamos 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 direccin del tipo usuarios@editorial.es sea entregada en nuestra estafeta local quedando la estafeta del proveedor de respaldo, los registros MX necesarios seran:
Editorial.es Editorial.es IN MX 10 IN MX 20 Correo.editorial.es Correo.proveedor.es

Si adems queremos que la mquina prueba.editorial.es reciba el correo directamente y que tenga como respaldo a la estafeta del proveedor debemos aadir los siguientes registros MX:
Prueba.editorial.es Prueba.editorial.es IN MX 5 IN MX 10 Prueba.editorial.es Correo.proveedor.es

Si ahora quisiramos que cualquier otra mquina bajo el dominio editorial.es recibiese el correo en la estafeta local podramos incluir el siguiente registro MX con wildcard pero esta es una prctica que no se recomienda:

Pgina 13 de 19, a las 1:27 del 18/09/aa

El servicio DNS

*.editorial.es

IN MX 20

Correo.editorial.es

Hay que hacer constar que si la direccin de correo viene en formato numrico 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 electrnico. Por ejemplo, si queremos que los mensajes que vengan a la direccin selte@editorial.es se entreguen al usuario varse de la mquina malaga.andalucia.editorial.es habra que poner los siguientes registros en el fichero del dominio editorial.es:
Selte IN MB Malaga.andalucia.editorial.es Varse@malaga.andalucia.editorial.es Selte@editoriales IN MR

Los registros MINFO, y MG apenas se usan y estn diseados para relacionar a varios usuarios con una sola direccin de correo, tarea que se hace de forma mas eficiente con las llamadas listas de correo que se vern en otro lugar del curso. Registros de descripciones: TXT, HINFO, WKS, RP. Los registro de tipo TXT asocian un texto a su poseedor:
Www.editorial.es. IN TXT Servidor Web de la editorial.

Los registros de tipo HINFO indican informacin sobre la mquina:

Www.editorial.es. IN HINFO AXP 8400, OVMS 7.2, OSU

Los registro de tipo WKS , indicacin de servicios prestados por la mquina y RP, persona responsable apenas se utilizan. Registros experimentales: GPOS, ISDN, X25.
Los registros de tipo GPOS sitan geogrficamente a la mquina, dando su latitud y longitud en grados y su altitud en metros:
Www.editorial.es. IN GPOS -3.8 39.7 35.7

Los registros de tipo ISDN permiten asociar un nmero de telfono de RDSI a una mquina:
Www.editorial.es. IN ISDN 952203347

Los registro de tipo X25 permiten asociar una direccin X.121 a una mquina:
Www.editorial.es. IN X25 252069004007

El servidor BIND de la Universidad de Berkeley, Bind (Berkeley Internet Name Domain Server) es el ms difundido de entre los programas servidores de nombre y es prcticamente una referencia obligada para los otros. Bind se puede utilizar para gestionar un nmero cualquiera de zonas, actuando de primario o secundario y tambin como forwarder. La distribucin para unix incluye los siguientes programas:
Pgina 14 de 19, a las 1:27 del 18/09/aa

El servicio DNS

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 gestin de named.

Bind lleva tres tipos de archivos de configuracin: 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 estn los dems archivos de configuracin.
Directorio donde se encuentran los dems ficheros Nombre del fichero de cache

El archivo de arranque permite las siguientes rdenes:

Directory nombre cache nombre

primary dominio fichero Indica que se es primario de una zona directa o inversa y el nombre del archivo de zona. Puede haber ms de un registro. secondary dominio maestro fichero
forwarder direccion ..

Secundario de una zona directa o inversa donde maestro es el primario y fichero el archivo de zona que se debe recuperar. Puede haber ms de un registro. Direcciones de los forwarders. Puede haber ms de un registro. Incluye un fichero de configuracin aadido Lista de servidores con los que no hay que contactar Definicin de lmites Opciones diversas: no-recursion: slo acepta peticiones no recursivas query-log: registro de las peticiones. forward-only: pasar a modo esclavo.

include fichero
bogusns direccion limil options

Vamos a ver un ejemplo de configuracin para la red indicada en la imagen siguiente:

Pgina 15 de 19, a las 1:27 del 18/09/aa

El servicio DNS

RedB
Nombre
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Uropigio TCP/IP

Estafeta SMTP Ciervo

Leopardo
Okapi Pangoln

135.1.1.2 135.1.1.5 135.1.1.4 135.1.1.1 135.1.1.3 135.1.2.5 135.1.2.4 135.1.2.1 135.1.2.2 135.1.2.3 135.1.3.1

Leopardo Gorila

Ciervo Gorila
Turaco Lemur

Gorila Elefante

Impala Elefante Hiena Gnu

Lican Gereunc

Gnu Gorila

Gacela Lince

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 Bosque.Africa @ IN $ORIGIN Bosque.Africa. Gorila IN IN localhost IN A Leopard IN A o Okapi IN IN Pangolin IN A IN Ciervo IN
SOA Gorila.Bosque.Africa. root@Gorila.Bosque.Africa.

A
MX 10 127.0.0.1 135.1.1.2

135.1.1.3 Gorila.Bosque.Africa.

A
MX 5 135.1.1.4 MX 5

135.1.1.5 Leopardo.Bosque.Africa. Gorila.Bosque.Africa. 135.1.1.1

Pgina 16 de 19, a las 1:27 del 18/09/aa

El servicio DNS

Fichero directo Sabana.Africa @ IN $ORIGIN Africa. Sabana IN $ORIGIN Sabana.Africa.

Lemur Impala Elefante u Gereunc IN IN IN IN IN IN IN IN

SOA NS
A MX 5 A MX 5 A A A MX 5

Gorila.Bosque.Africa. root@Gorila.Bosque.Africa. Gorila.Bosque.Africa. 135.1.2.5 Gorila.Bosque.Africa. 135.1.2.4 Elefante.Sabana.Africa. 135.1.2.1 135.1.2.2 135.1.2.3 u.Sabana.Africa.

Fichero directo Bosque.Europa @ IN SOA Bosque.Europa $ORIGIN Bosque.Europa.

Lince IN IN Fichero Reverso para 135.1.1.0 @ 1 2 3 4 5 IN IN IN IN IN IN SOA PRT PRT PRT PTR PRT A MX 5

Gorila.Bosque.Africa. root@Gorila.Bosque.Africa. IN NS Gorila.Bosque.Africa.

135.1.3.1 Gorila.Bosque.Europa.

Gorila.Bosque.Africa. root@Gorila.Bosque.Africa. Ciervo.Bosque.Africa. Leopardo.Bosque.Africa. Gorila.Bosque.Africa. Pangolin.Bosque.Africa. Okapi.Bosque.Africa.

Fichero Reverso para 135.1.2.0 @ 1 2 3 4 5 IN IN IN IN IN IN SOA PTR PTR PTR PTR PTR Gorila.Bosque.Africa. root@Gorila.Bosque.Africa Elefante.Sabana.Africa. u.Sabana.Africa. Gereunc.Sabana.Africa. Impala.Sabana.Africa. Lemur.Sabana.Africa. Gorila.Bosque.Africa. root@Gorila.Bosque.Africa Lince.Bosque.Europa.

Fichero Reverso para 135.1.3.0 @ IN SOA 1 IN PTR

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 informacin de forma explcita, 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 situacin: server nombre. Define el servidor que contestara a nuestras peticiones. set server=nombre. Igual que el anterior.

Pgina 17 de 19, a las 1:27 del 18/09/aa

El servicio DNS

root nombre. Pone la raz de bsqueda en el server especificado. set root= nombre. Igual que el anterior. rdenes de modificacin: set debug, set d2. Activa la opcin de debug. set defname=nombre. Aade el dominio nombre a cada interrogacin. set recurse. Indica hacer bsquedas recursivas para contestar a las preguntas. set domain=nombre. Define el dominio para las peticiones. set timeout=tiempo. Tiempo mximo de espera a la respuesta. set querytype=opcion. Tipo de consulta. Las opciones vlidas son a,any,cname,hinfo,mx,px,ns,ptr,soa,txt,wks,srv,natpr. set query=opcin. Igual que el anterior. set type=opcin. Igual que el anterior. rdenes de interrogacin: Un nombre o una direccin implica una orden de traduccin. finger nodo. Da informacin de los usuarios en el nodo indicado. ls opt dominio [>fichero]. Es la orden de interrogacin sobre los elementos pertenecientes al dominio. Si la opcion es a devuelve los nombres cannicos, 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.

CyberKit Para consultar el DNS desde el entorno Windows puede usarse la utilidad CyberKit que en su opcin Nslookup tiene la implementacin de esta utilidad. Para usarla en la opcin de Name Server hay que poner la direccin del servidor de nombre al que vamos a preguntar, en la opcin de Type of search el tipo de peticin a realizar y en la de Host or Address los datos para la peticin. El servicio Whois. Aunque nslookup y otras herramientas nos permiten obtener informacin sobre el DNS, no es posible obtener por estos medios ninguna informacin 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 an, etc. La informacin indicada anteriormente est registrada en bases de datos whois. Whois naci inicialmente como la base de datos que registraba la informacin sobre dominio, hosts, redes y usuarios de ARPANET, gestionada por el centro de informacin de la red de datos de Defensa de los Estados Unidos de Amrica. Con la creacin de los NIC whois se convirti en un servicio distribuido de pginas blancas, donde la informacin relativa a cada dominio se encuentra en el NIC correspondiente. El

Pgina 18 de 19, a las 1:27 del 18/09/aa

El servicio DNS

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 informacin tcnica sobre un dominio. Objetos de tipo red (inetnum) que contienen informacin tcnica sobre la delegacin de una direccin de red. Objeto de tipo ruta (route) que contienen informacin sobre redes anunciadas dentro de una ruta de tipo CIDR por un protocolo de ruta externa. Objetos de tipo persona (person) que contienen informacin sobre las personas de contacto tcnico o administrativo de otros objetos. Objetos del tipo sistema autnomo (aut-num) que contienen informacin tcnica sobre un proveedor. Servidores whois importantes son: Whois.internic.net que contiene informacin respecto de los dominios raz y genricos. 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 travs del servidor web de las distintas organizaciones, por ejemplos el whois de NIC espaol tiene la direccin www.nic.es, o bien con cliente especficos, tecleando desde una mquina unix whois h servidor-whois consulta o bien desde las utilidades Cyberkit y Netlab en las mquina Windows.

Pgina 19 de 19, a las 1:27 del 18/09/aa