El servicio DNS

DNSRelación entre nombre y dirección IPNombres públicos y privadosConcepto y estructura jerárquica

Los Top Level DomainsEl Internic. Los Nic delegadosEl dominio in­addr.arpa

Zonas y dominiosServidores de nombres

Tipos de servidoresBúsquedas recursivas y servidores “forwarder”

Configuración de un servidor de nombresEl registro SOALos registros de origen relativo y de inclusión.La delegación de autoridad: NSLos registros de identificación: A, PTR, CNAMELa encaminación del correo: MX, MB, MR, MINFO, MGRegistros de descripciones: TXT, HINFO, WKS, RPRegistros experimentales: ISDN, X25, GPOS

El servidor BIND de la Universidad de BerkeleyLas herramientas de consulta

NslookupCyberkit

El servicio Whois.

Página 1 de 19,  a las 1:27 del 18/09/aa

El servicio DNS

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@[130.12.3.45].  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@[192.23.4.5] 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

El servicio DNS

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 1035.

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

El servicio DNS

• 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 “in­addr.arpa”.   El ejemplo siguiente lo aclarará más:

Página 4 de 19,  a las 1:27 del 18/09/aa

El servicio DNS

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 150.214.0.0) y permite asociar nombres de máquinas a direcciones 

Página 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 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

El servicio DNS

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:   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

Página 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  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

El servicio DNS

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

El servicio DNS

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 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   dirección   de   correo   electrónico   del responsable de la zona en la cual se ha sustituido la @ 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

El servicio DNS

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. (

1999092301 ; Serial

28800 ; Refresh

7200 ; Retry

604800 ; Expire

86400     ) 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 194.33.8.12

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

El servicio DNS

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 194.33.8.12

0.33.123.194.in­addr.arpa. IN A 255.255.255.240

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:

194.33.8.12 IN PTR Malaga.andalucia.editorial.es.

0.8.33.194.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 0.8.33.194.in­addr.arpa.

Editorial.es. IN PTR

IN PTR

0.8.33.194.in­addr.arpa.

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 máquinas por distintos nombres, por ejemplo uno distinto para cada servicio:

Www.editorial.es. 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 la @ 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

El servicio DNS

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

El servicio DNS

*.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:Www.editorial.es. IN TXT “Servidor Web de la editorial”.

Los registros de tipo HINFO indican información sobre la máquina:Www.editorial.es. 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: 

Www.editorial.es. IN GPOS ­3.8 39.7 35.7

Los registros de tipo ISDN permiten asociar un número de teléfono de RDSI a una máquina:

 Www.editorial.es. IN ISDN 952203347

Los registro de tipo X25 permiten asociar una dirección X.121 a una máquina:Www.editorial.es. IN X25 252069004007

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

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 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 Directorio donde se encuentran los demás ficheros

cache nombre Nombre del fichero de cache

primary dominio fichero 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.

secondary  dominio maestro fichero

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.

forwarder direccion ….. Direcciones   de   los   forwarders.   Puede   haber   más   de   un registro.

include fichero Incluye un fichero de configuración añadido

bogusns direccion … Lista de servidores con los que no hay que contactar

limit Definición de límites

options Opciones diversas: no­recursion:   sólo   acepta   peticiones   no recursivasquery­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

El servicio DNS

Nombre TCP/IP Estafeta SMTP1 Uropigio Ciervo2 Leopardo 135.1.1.23 Okapi 135.1.1.5 Leopardo4 Pangolín 135.1.1.4 Gorila5 Ciervo 135.1.1.16 Gorila 135.1.1.37 Turaco8 Lemur 135.1.2.5 Gorila9 Impala 135.1.2.4 Elefante10 Elefante 135.1.2.111 Hiena12 Gnu 135.1.2.213 Licaón14 Gereunc 135.1.2.3 Gnu15 Gacela16 Lince 135.1.3.1 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 Bosque.Africa

@ IN SOA Gorila.Bosque.Africa.  root@Gorila.Bosque.Africa.$ORIGIN Bosque.Africa.Gorila IN A 135.1.1.3

IN MX 10 Gorila.Bosque.Africa.localhost IN A 127.0.0.1Leopardo IN A 135.1.1.2Okapi IN A 135.1.1.5

IN MX 5 Leopardo.Bosque.Africa.Pangolin IN A 135.1.1.4

IN MX 5 Gorila.Bosque.Africa.Ciervo IN A 135.1.1.1

Página 16 de 19,  a las 1:27 del 18/09/aa

El servicio DNS

Fichero directo Sabana.Africa@ IN SOA Gorila.Bosque.Africa. root@Gorila.Bosque.Africa.$ORIGIN Africa.Sabana IN NS Gorila.Bosque.Africa.$ORIGIN Sabana.Africa.Lemur IN A 135.1.2.5

IN MX 5 Gorila.Bosque.Africa.Impala IN A 135.1.2.4

IN MX 5 Elefante.Sabana.Africa.Elefante IN A 135.1.2.1Ñu IN A 135.1.2.2Gereunc IN A 135.1.2.3

IN MX 5 Ñu.Sabana.Africa.

Fichero directo Bosque.Europa@ IN SOA Gorila.Bosque.Africa. root@Gorila.Bosque.Africa.

              Bosque.Europa IN NS Gorila.Bosque.Africa.$ORIGIN Bosque.Europa.Lince IN A 135.1.3.1

IN MX 5 Gorila.Bosque.Europa.

Fichero Reverso para 135.1.1.0@ 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 135.1.2.0@ IN SOA Gorila.Bosque.Africa. root@Gorila.Bosque.Africa1 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 135.1.3.0@ IN SOA Gorila.Bosque.Africa. root@Gorila.Bosque.Africa1 IN PTR Lince.Bosque.Europa.

Las herramientas de consultaAunque 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:

NslookupSe 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

El servicio DNS

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.

CyberKitPara 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

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 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 www.nic.es, 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