Está en la página 1de 276

Configuración del DNS

• Max de Mendizábal
• 24 de noviembre de 2008

El servidor de nombres
(DNS)
• El servidor de nombres establece una
relación entre nombres de
máquinas y direcciones IP
• También desempeña un importante
papel en el enrutamiento del correo
electrónico (ahí se definen los
intercambiadores de correo)
• Es una base de datos distribuida en
la que cada sitio almacena
información sobre sus propias

DNS
• Es un espacio de nombres jerárquico para
hosts y direcciones IP
• Una tabla de hosts implementada como una
base de datos distribuida
• Un resolvedor y una serie de bibliotecas que
hacen preguntas a la base de datos
• Un enrutamiento mejorado para el e-mail
• Un mecanismo para encontrar servicios en
una red
• Un protocolo para intercambiar información
de nombres

DNS
• El pedazo de base de datos que uno
mantiene consiste en uno o dos
archivos de texto que contienen los
registros para cada uno de los
hosts, por ejemplo
 servidor IN A 192.168.10.1
 IN MX 10 correo.cch.unam.mx.
 y
1
 IN PTR servidor.cch.unam.mx.

DNS
• El DNS es un sistema cliente /
servidor
• Los servidores (servidores de
nombres) cargan la información de
los archivos de DNS en la memoria
y las utilizan para responder
preguntas tanto de los clientes
externos como internos
• Todas las máquinas de la red
deberían ser clientes del DNS

DNS • Para las organizaciones pequeñas. basta utilizar un solo servidor de nombres • Una organización mediana con varias subredes pueden utilizar varios DNS para reducir la latencia de las consultas y mejorar la fiabilidad • Un sitio muy grande puede dividir un dominio en varios subdominios y tener varios servidores por cada dominio .

”. El espacio de nombres del DNS • El espacio de nombres del DNS es un árbol de dominios • Cada dominio representa una porción distinta del espacio de nombres y es manejada por una sola entidad administrativa • La raíz del árbol se llama punto “. bajo él están los dominios de alto nivel (top level domains) .

El espacio de nombres del DNS • Una rama hace el mapeo entre nombres de host y direcciones IP y una segunda rama hace el mapeo entre una dirección IP y el nombre del host • La primera rama se llama mapeo hacia adelante y los archivos asociados de BIND se llaman los archivos de zona hacia adelante (forward zone files) • La segunda rama se llama mapeo en reversa y sus archivos asociados son los archivos de zona en reversa (reverse zone files) .

El espacio de nombres del DNS • Por razones históricas hay dos tipos de nombres de dominio de alto nivel • En los Estados Unidos. a estos les llamamos los dominios de alto nivel genérico o gTLD .com. . como .edu. como .net también se usan fuera de los EEUU.com y . Algunos de estos dominios.org y . los dominios de alto nivel describen la estructura política y organizacional con tres letras.

El espacio de nombres del DNS Domini Para qué se usa Domini Para qué se usa o com Compañías o net Proveedores de red edu comerciales Instituciones org Organizaciones sin fines de gov educativas Agencias int lucro Organizaciones mil gubernamentales Agencias militares arpa internacionales Ancla para el árbol de direcciones IP Los dominios de alto nivel genéricos .

los dominios utilizan los códigos de país ISO de dos letras. y se llaman los ccTLD (country code Top Level Domain) Códig País Códig País Códig País oau Australi ofi Finlandia ohk Hong Kong ca a Canadá fr Francia ch Suiza br Brasil jp Japón mx México de Alemani se Suecia hu Hungría a . El espacio de nombres del DNS • Para otros países.

El espacio de nombres del DNS • Algunos países tienen su propia jerarquía organizacional para los dominios de segundo nivel por ejemplo una institución académica en los Estados Unidos es edu.jp respectivamente • El dominio de alto nivel us a veces se utiliza para los Estados Unidos . pero en el Reino Unido y en Japón es ac.uk y ac. ac.

edu. por ejemplo boulder. El espacio de nombres del DNS • Los nombres de dominio no consideran una diferencia entre mayúsculas y minúsculas • La norma actual es que los dominios siempre se ponen con minúsculas • En el DNS los nombres totalmente calificados deben ser terminados por un punto.colorado. La carencia del punto final indica una dirección relativa .

nic.mx .Registro de un nombre en México http://www.

com .dyndns.Registro de un dominio dinámico http://www.

simplemente son un intermediario que va guardando información sobre otros dominios sobre los que se preguntan y sirven para acelerar las consultas al Internet . el servidor de nombres • Hay dos tipos principales de servidores – Los de autoridad (authoritative) – Los de cache (caching-only) • Los de autoridad representan una zona de forma oficial y resuelven las preguntas de un dominio • Los de cache. BIND.

obtiene su información de un archivo en el disco slave (esclavo) Copia su información desde el master stub Similar al esclavo. BIND. usualmente no tiene zonas locales forwarder Hace peticiones a nombre de muchos clientes. el servidor de Tipo de servidor nombres Descripción authoritative Es el representante oficial de la zona (autoridad) master (amo) Es el repositorio primario de los datos de una zona. pero sólo copia los datos del nombre del servidor (sin los datos de los otros hosts) distribution Un servidor que sólo es visible dentro de un dominio (también se le conoce como stealth server. construye un gran cache recursive Hace las peticiones a tu nombre hasta que regresa ya sea una respuesta o un error nonrecursive Te refiere a otro servidor si no puede responder tu petición . o servidor oculto) nonauthoritative Responde una petición desde un cache. no sabe si la información todavía es válida (sincaching autoridad) Almacena los datos de las peticiones anteriores.

¿Cómo funciona el DNS? .

debido a que los mapeos cambian con poca frecuencia • Muchas búsquedas se hacen hacia los servidores locales y pueden ser resueltos rápidamente • Los usuarios pueden ayudar sin querer con la eficiencia porque hacen . correcta. Eficiencia del cache • Tener un cache de DNS incrementa la eficiencia de las búsquedas • Una respuesta en el cache es prácticamente gratuita y. normalmente.

a partir de BIND9 ya es posible hacerlo • En una medición en el servidor raíz de RIPE se demostró que el 60% de las preguntas que se hacían al DNS eran sobre información inexistente (muchos de ellos eran hacia 127. sólo las negativas.arpa o para servicios de Microsoft que se preguntaban como si fueran hosts) • Poner en el cache esta información reduce de forma dramática la carga . no se podían poner en el cache las respuestas negativas.in- addr. Eficiencia del cache • Por mucho tiempo.

Eficiencia del cache • El cache negativo guarda respuestas de los siguientes tipos – Ningún host o dominio coincide con el nombre preguntado – El tipo de datos solicitado no existe para este host – El servidor solicitado no responde – El servidor no se puede alcanzar debido a problemas de red • Los primeros dos tipos de respuestas negativas se guardan de 1-3 horas. las respuestas con autoridad negativas deben ser puestas en el cache . Las respuestas sin autoridad podrían ser puestas en el cache. los demás sólo por 5 minutos.

¿Cuál debería ser el servidor adecuado para preguntar? • Cuando named deba escoger entre varios servidores remotos. Luego se ordenan los servidores en “cubetas” de acuerdo con su RTT y se selecciona un servidor de la “cubeta” más rápida. la respuesta serán 13 servidores raíz. Eficiencia del cache • Con frecuencia. primero se determina el RTT Round Trip Time o tiempo de viaje de red para cada servidor. por ejemplo si se solicitan los nombres de los servidores del dominio raíz. named recibe varios registros de DNS en respuesta a una pregunta. Los servidores dentro de una . todos ellos con autoridad sobre el dominio.

168.2  IN A 192. pero efectiva.0.168.3 .1  IN A 192. Eficiencia del cache • Se puede hacer una forma de balanceo de carga primitiva.168. asignando un solo hostname a varias direcciones IP (que en realidad sean distintas máquinas)  www  IN A 192.0.0.

El protocolo DNS extendido • En la definición original del protocolo DNS se utilizaban UDP y TCP • UDP se utilizaba para las preguntas y respuestas • TCP se utilizaba para la transferencia de zonas entre servidores amo y sus esclavos .

que es muy pequeño para incluir las características de seguridad actuales del DNS que incluyen firmas digitales • Ese límite también afecta el número y los nombres de los servidores raíz. El protocolo DNS extendido • El problema es que el tamaño máximo garantizado para las implementaciones UDP es de 512 bytes. para hacer que toda la información de los servidores raíz quepa en un paquete UDP de 512 bytes. cada uno con un nombre limitado a una letra del . sólo hay 13 servidores raíz.

puesto que las conexiones TCP son más caras . vuelven a hacer la pregunta por TCP.El protocolo DNS extendido • Muchos clientes lanzan una pregunta UDP primero y luego. lo cual es muy ineficiente • Se podría pensar que lo más fácil es utilizar TCP para todo. pero esto también es un desperdicio. si la respuesta está truncada.

El protocolo DNS extendido • Una pregunta/respuesta típica puede ser tan breve como dos paquetes UDP. una respuesta. el de pregunta y el de respuesta • Un intercambio TCP involucra al menos siete paquetes. una pregunta. un handshake de tres vías para iniciar la conversación. y un handshake final para cerrar la conexión .

el remitente regresa al protocolo DNS original. el EDNS0 (Extended DNS versión 0) resolvió algunas de estas limitaciones del protocolo DNS • Permite el reensamble del tamaño del buffer. BIND9 implementa . opciones soportadas y protocolos hablados • Si el servidor de nombres receptor contesta con un mensaje de error.El protocolo DNS extendido • A finales de la década de los 90.

Instalación de BIND y Tarea mantenimiento Para Frecuencia Obtener un nombre de Sitio Una vez dominio Escoger los servidores de Sitio Una vez o más nombresuna distribución Sitio Obtener Una vez. pero es necesario BIND Configurar el resolvedor Cliente mantenerla actualizada Una vez y distribuir Configurar un resolvedor Cliente Para cada subred y distribuir eficiente el cambio de Cliente Configurar Para cada arquitectura y servicios Iniciar named durante el Servidor distribuir Para cada servidor de nombres inicio Ajustar el archivo config de Servidor Para cada tipo de servidor named Configurar el archivo de Servidor Una sola vez y distribuir a los hints Configurar los archivos de Master servidores Una sola vez zona Actualizar los archivos de Master Conforme sea necesario zona Revisar bitácoras Bitácora Al menos una vez a la semana Educar usuarios host Todos Continuamente .

conf debe ponerse automáticamente. se puede editar a mano. el archivo /etc/resolv. de otra forma. Configuración del resolvedor • Cada host de la red debe tener un archivo llamado /etc/resolv. el formato es  search nombrededominio  nameserver direcciónip .conf que enlista los servidores DNS a los que se les harán las preguntas • Si el cliente obtiene su dirección IP y parámetros de red de un servidor DHCP.

p o r e so se p u e d e n p o n e r a lfin a ld e la lín e a n a m e se rve r u n co m e n ta rio .edu colorado.edu ee.colorado.138. piper  nameserver 128.243.240. como en este ejemplo  search cs.4 . e n la lín e a se a rch n o se re co m ie n d a p o n e r n in g ú n co m e n ta rio .151 .204.colorado.138.edu  nameserver 128. Configuración del resolvedor • Se pueden enlistar hasta tres servidores de nombres.1 . anchor • S ih a y a lg u n a o tra co sa e n e se a rch ivo .138. sim p le m e n te se ig n o ra . ns  nameserver 128.

el resolvedor completará el nombre con el primer dominio de la lista de búsqueda. buscará foo. si no lo encuentra probará también con foo.colorado.cs. en este caso.edu.colorado. Configuración del resolvedor • La línea search enlista los dominios por los que se preguntará si un hostname no está totalmente calificado. por ejemplo.edu y . si el usuario hace un ssh foo.

co n f deben ser recursivos . E lin te rva lo d e re in te n to se in cre m e n ta co n ca d a fa lla . lo s d e m á s se rá n ig n o ra d o s • S i h a y u n p ro b le m a . la p re g u n ta exp ira y se p ro b a rá co n e lsig u ie n te se rvid o r d e n o m b re s. Configuración del resolvedor • Se pueden tener hasta ocho dominios en una línea search • Lo s re so lve d o re s e n lista d o s e n e l a rch ivo re so lv . C a d a se rvid o r se p ru e b a p o r tu rn o s. ya que u n re so lve d o r n o e n tie n d e re fe re n cia s. y ca d a u n o d e e llo s d e b e te n e r u n ca ch e • Lo s se rvid o re s e n la s lín e a s n a m e se rve r se co n ta cta n e n o rd e n . E n ta n to q u e e l p rim e ro sig a co n te sta n d o la s p re g u n ta s. h a sta cu a tro ve ce s.

si hay más.conf • . simplemente se ignoran silenciosamente • Si un host es por sí mismo un servidor de nombres. Configuración del resolvedor • Muchos resolvedores permiten un máximo de tres servidores de nombres enlistados. debe ser enlistado al principio en su propio archivo resolv.

todo el sitio . porque si el servidor de nombres falla. Configuración del resolvedor • Es una buena idea tener servidores separados para resolver peticiones internas al dominio • Los servidores internos deberían ser de sólo de cache y recursivos • Un sitio muy grande debería tener varios servidores de nombres a lo largo de todo el sitio y utilizar el archivo resolv. para minimizar el tráfico de red y reducir la vulnerabilidad de las máquinas a un solo punto de falla.conf para propagar la carga entre los servidores.

Configuración del resolvedor • Los forwarders también son una buena forma de optimizar el servicio de nombres local • Los servidores de nombres locales apuntan a un forwarder que hace todas las peticiones externas para tu sitio y construye un cache muy rico • Esta configuración minimiza el uso de ancho de banda externo utilizado por el servidor de nombres y permite a las máquinas locales compartir un .

de tal forma que ninguno de los dos grupos se sobrecargue • También se muestra el uso de un servidor esclavo fuera del sitio. Configuración del resolvedor • En la figura siguiente se ilustran las recomendaciones de diseño que se explicaron anteriormente • Se muestra una jerarquía de dos niveles con forwarding • Es necesario ajustar el balance entre los servidores y manejar las preguntas de salida y los servidores que manejan las peticiones hacia adentro. que se recomienda ampliamente si se puede conseguir que .

Configuración del resolvedor .

para usar un DNS basta con agregar la línea nameserver al archivo /etc/resolv. Pruebas para el resolvedor • En algunos sistemas. es necesario decirle al sistema explícitamente que utiliice el DNS en vez del archivo /etc/hosts o el NIS en el archivo del sistema. que se llama /etc/nsswitch.conf • En otros.conf .

Pruebas para el resolvedor • Después de configurar el /etc/resolv. intenta verla a través de su dirección IP. si eso funciona. es que la configuración del DNS tiene algún problema .conf. se podrán ver las otras máquinas por nombre en vez de por IP • Si se intenta ver otra máquina y la instrucción se tarda. y suponiendo que todo funciona bien en la red.

puede que no funcione • También si se montan unidades de disco duro a través de NFS. podría ser que no encontrara la máquina . Impacto en el resto del sistema • La configuración del DNS impacta en varios puntos conforme el sistema se inicia. por ejemplo. si se tiene un servidor de correo. y aún no se resuelve el DNS.

el servidor de nombres • BIND son las siglas de Berkeley Internet Name Domain (Nombres de dominio de Internet. BIND. Berkeley) y es un programa de código abierto que implementa el protocolo DNS • Para instalarlo en Debian basta con escribir lo siguiente   aptitude install bind9 bind9-doc bind9-host .

en otras distribuciones son uno solo.conf.local  /etc/bind/named. BIND.conf  /etc/bind/named. .options  que. el servidor de nombres • Los archivos de configuración se encuentran en  /etc/bind • Los archivos de configuración relevantes son  /etc/bind/named.conf.

Debian.   // prime the server with knowledge of the root servers zone "." {  type hint. // // Please read /usr/share/doc/bind9/README.root".  file "/etc/bind/db. }.conf. // // If you are just adding zones. el servidor de nombres cat /etc/bind/named. *BEFORE* you customize // this configuration file.gz for information on the // structure of BIND configuration files in Debian.conf.conf   // This is the primary configuration file for the BIND DNS server named. BIND.options".local  include "/etc/bind/named.  . please do that in /etc/bind/named.

0".in-addr.arpa" {  type master.127".in-addr. BIND. }. }.  file "/etc/bind/db.  zone "127.arpa" {  type master.  file "/etc/bind/db.local". el servidor de nombres // be authoritative for the localhost forward and reverse zones.arpa" {  type master.in-addr.  file "/etc/bind/db.  zone "0.  zone "255. and for // broadcast zones as per RFC 1912  zone "localhost" {  type master. }. .

but BIND 8. you might need to uncomment the query-source  // directive below. el servidor de nombres cat /etc/bind/named.   // If your ISP provided one or more IP addresses for stable  // nameservers.options  options {   directory "/var/cache/bind". . BIND.   // If there is a firewall between you and nameservers you want  // to talk to. Previous versions of BIND always asked  // questions using port 53.conf.1 and later use an unprivileged  // port by default. you probably want to use them as forwarders.   // query-source address * port 53.

Utiliza las llaves preconfiguradas keys controls Define canales utilizados para controlar el servidor de logging nombres Especificacon lasndc categorías de las bitácoras y sus destinos view Define una vista del espacio de nombres .conf Instrucció Función ninclude Interpola un archivo options Pone las opciones de configuración globales del servidor server de nombreslas opciones para cada servidor Especifica key Define la información de autentificación acl Define las listas de control de acceso zone Define una zona de registro de recursos trusted. Instrucciones del named.

165/16) – El nombre de una lista de acceso de control definida con anterioridad – Una llave criptográfica para autentificación . Lista de coincidencia de direcciones • Una lista de coincidencia de direcciones es una generalización de una dirección IP y puede incluir – Una dirección IP (por ejemplo 199.4) – Una red IP especificada con una máscara CIDR (por ejemplo 199.165.145.

Lista de coincidencia de direcciones • Ejemplos de listas – { ! 1. }. 198. 204.1. }. la lista se busca en orden hasta que exista la coincidencia.2.13 y nunca se encontraría la entrada negada . 1.3.3/24.228.69/24.13.0.0. si estuvieran al revés las entradas. • Cuando una dirección IP o una red es comparada con la lista de coincidencias. no se tendría el efecto deseado.11. este algoritmo de “primer encuentro” hace que el orden de la lista sea importante • Por ejemplo. – { 128. en la primera lista.2.2.16/24. 127.138/16.3. porque nunca se alcanzaría la dirección 1.

conf. • Nota: la trayectoria es relativa. Instrucciones del named. tal y como se hace en Debian • Para incluir un archivo se escribe.options". por ejemplo  include "/etc/bind/named.conf include • Para organizar mejor un DNS es posible poner diferentes porciones de configuración en distintos archivos. por eso es necesario poner las / para especificarla precisamente .

el formato general es  options {  opción.Instrucciones del named. . algunas de las cuales pueden ser sobreescritas para algunas zonas o servidores en particular.conf options • La sentencia options especifica las opciones globales.  opción.  …  }.

.  }. # conform to # RFC1035  listen-on-v6 { any.conf options • En el caso de Debian.  auth-nxdomainno. las opciones globales preconfiguradas son las siguientes  options {  directory "/var/cache/bind". }.Instrucciones del named.

com/books/dns/ch7/sta • . Instrucciones del named.2/ • http://www.net/manuals • http://www.bind9.conf options • En BIND9 hay más de 50 opciones que se pueden consultar en el manual • http://www.zytrax.bind9.3.net/manual/bind/9.

los que creen que los hackers. [número de versión real del servidor]  • Hay dos formas de ver el mundo. Instrucciones del named. con el número de versión pueden atacar mejor.conf options • Los valores por omisión se enlistan en corchetes cuadrados al final de la opción. por ejemplo   version “cadena de texto”. o los que consideran que enmascarando las cosas no se resuelve nada porque de todas formas los hackers probarán con las últimas vulnerabilidades .

[directorio en donde inicia el servidor]  .conf options • La instrucción directory hace que named busque todos los archivos incluidos en el directorio especificado y. Instrucciones del named. Debe ser una ruta absoluta. los archivos de salida también irán dentro de este directorio • directory “ruta”. a partir de ahí haga sus búsquedas relativas.

y este es un servidor master para una más zonas.conf options • Si la opción notify se pone afirmativa. [yes]  also-notify servers_ipaddrs. [vacío] . Esto provoca que los archivos de zona converjan más rápido cuando se hacen cambios  notify yes | no. Instrucciones del named. named notifica automáticamente a todos los esclavos cuando haya cambios en la base de datos.

es muy raro que haya servidores con esta opción deshabilitada. [todos los hosts] . se puede habilitar la recursión sólo para los clientes propios y no para los externos  recursion yes | no. [yes]  allow-recursion { lista }. sin embargo.conf options • La opción recursion especifica si el named preguntará a otros servidores de nombres a nombre de sus clientes. Instrucciones del named.

conf acl • Una lista de control de acceso es sólo una lista de direcciones  acl nombre_de_la_acl {  lista_de_direcciones_coincidentes. que co in cid e n co n cu a lq u ie r m á q u in a . localhost y none. to d a s la s m á q u in a s d e la re d lo ca l. • H a y cu a tro lista s p re d e fin id a s: any. re sp e ctiva m e n te . localnets. Instrucciones del named.  }. la m á q u in a e n sim ism a y n a d a .

key-id. }. Instrucciones del named. [no]  provide-ixfr yes | no. algunos de los cuales pueden hablar otras versiones de BIND.conf server • named puede hablar con varios servidores. [yes (V9 only)]  support-ixfr yes | no. la instrucción server indica las características de sus pares remotos server ip_addr {  bogus yes | no. [2 (V9 only)]  transfer-format one-answer| many-answers. [no (V8 only)]  transfers number. } . [yes (V9 only)]  request-ixfr yes | no. [v8:1.v9:n]  keys { key-id.

Instrucciones del named.conf • Indican si las zonas son de autoridad y ponen las opciones adecuadas para cada dominio • Una instrucción zone puede ser utilizada para precargar los servidores de ayuda root • Una configuración simple de master de zona sería como sigue .conf zone • Las instrucciones de zona son el corazón de los archivos named.

. } [none]  ixfr-base “ruta”.  file “ruta”.  allow-query { lista_de_dirs. [v8 only] }.conf zone zone “nombre_de_dominio” {  type master. } [all]  allow-transfer { lista_de_dirs. Instrucciones del named. } [all]  allow-update { lista_de_dirs.

Instrucciones del named.conf zone • La especificación nombre_de_dominio debe estar entre comillas • La información de la zona se queda en el disco en un formato legible por humanos (y editable por ellos) • Es indispensable indicar en qué archivo está el contenido de la zona • Un archivo de zona es únicamente una colección de registros de recursos DNS .

com” {  type master.} }.  allow-query { any. }  allow-transfer { mis- esclavos.  file “forward/ejemplo.conf zone zone “ejemplo. Instrucciones del named.  .com”.

 file “ruta”. ip_addr.  . … } [no default]  allow-query { lista_de_dirs.conf zone • Configuración de un servidor esclavo para una zona zone “nombre_de_dominio” {  type slave | stub. Instrucciones del named.  ixfr-base “ruta”. } [all]  allow-transfer { lista_de_dirs. [v8 only]  masters { ip_addr. } [all] }.

• Los “hints” son el conjunto de los registros DNS que enlista los servidores del dominio raíz (“.” {  type hint. Es el lugar en donde el se comienzan las búsquedas de otros dominios • Al archivo de hints se le conoce con frecuencia como el archivo root.”).  file “ruta”.cache • .  }. Instrucciones del named.conf zone • Poniendo los servidores raíz (root hints)  zone “.

 forward only | first. Instrucciones del named.  forwarders { ip_addr. … }  }.conf zone • Instalando una zona de forwarding zone “nombre_de_dominio” {  type forward.  • .

 secret cadena.conf key • La instrucción key define la llave criptográfica que será utilizada para autentificarse con un servidor en particular • La llave se representa como una cadena codificada en base 64 y es un “secreto compartido”  key key-id {  algorithm cadena.  }.  . Instrucciones del named.

el algoritmo y la llave que son necesarias para hablar con el servidor de nombres de ese dominio. . el formato es  trusted-keys {  domain flags protocol algorithm key.  …  }. Instrucciones del named. el protocolo.  domain flags protocol algorithm key. cada entrada es una tupla-5 que identifica el nombre el dominio.conf trusted-keys • La instrucción trusted-keys se utiliza para la seguridad con protocolo DNSSEC. las banderas.

. Instrucciones del named. [0600 0 0] }.  unix permission owner group.conf controls • Permite el control del servidor a través de la utilería ndc  controls {  inet ip_addr port port# allow { lista_dirs | key … }.

por ejemplo con la dirección de red siguiente  192.168.conf para que se resuelvan las dos zonas . podríamos instalar una pequeña red privada. Ejemplo de configuración de BIND en una máquina linux casera • En una red casera.org • Se necesitan dos archivos.77. el de búsqueda directa (forward) y el de búsqueda inversa (reverse) y modificar el /etc/bind/named.0/24  y con el dominio  guarida.dyndns.

dyndns.zone”. }.in- addr.conf  zone “guarida. zone “77.  file “guarida.org” {  type master.192.arpa.in-addr.zone”. Ejemplo de configuración de BIND en una máquina linux casera • Modificación del /etc/bind/named.168.org.arpa” {  type master.  file “77.192. .168. }.dyndns.

77.org.zone @ IN SOA ns.dyndns.zone”  .. 30 min  1209600 .guarida. guarida.1 . Mínimo 5 días  IN NS ns  IN MX 10 ns ns IN A 192.168.dyndns. Serie  21600 . root.dyndns.168.253   . Reintentar. m253 IN A 192.org. Refresco 6 horas  1800 .168. (  2009100201 ..dyndns.77.guarida.77.org. Expiración 2 semanas  432000 ) . Ejemplo de configuración de BIND en una máquina linux casera • El archivo “guarida.254 m1 IN A 192.org.

guarida.dyndns. Mínimo 5 días  IN NS ns 254 IN PTR ns.dyndns.192.org.arpa.guarida. Refresco 6 horas  1800 . 1 IN PTR m1.. Reintentar.192.guarida.guarida. Ejemplo de configuración de BIND en una máquina linux casera • El archivo “77. (  2009100201 .in-addr.dyndns.168. 77.org.. .org.zone @ IN SOA ns.dyndns. Expiración 2 semanas  432000 ) .arpa. Serie  21600 .168. 30 min  1209600 . 253 IN PTR m253.guarida. .org.in- addr.dyndns.zone” . root.org.

d/bind9 restart • Probar el servidor de nombres – nslookup – dig . Ejemplo de configuración de BIND en una máquina linux casera • Reiniciar el servidor de nombres • /etc/init.

La base de datos del DNS • Una base de datos de DNS es un conjunto de archivos de texto que son mantenidos por el administrador del sistema en el servidor de nombres máster del dominio • A estos archivos de texto se les conoce como los archivos de zona .

o RRs • Sólo los RRs son parte de la base de datos. La base de datos del DNS • Contienen dos tipos de entradas: los comandos de parseo (cosas como $ORIGIN y $TTL) y los “registros de recursos”. los comandos de parseo sólo dan algunos atajos para poner registros • .

La base de datos del DNS Los registros de recursos RRs • Cada zona de la jerarquía del DNS tiene un conjunto de recursos asociados con él (aunque podría estar vacío) • El formato básico de un registro de recurso es  [nombre] [ttl] [clase] tipo datos • Los campos se separan con un espacio en blanco (tabuladores o .

La base de datos del DNS Los registros de recursos RRs • Caracteres especiales usados en los RRs Caracter Significado . Introduce un comentario @ El nombre actual del dominio () Permite que la información se divida en * varias líneas Comodín (sólo en el nombre del campo) .

Tipo Nombre Función La base de datos del DNS Zon SOA Start Of Authority Define una zona de autoridad del a NS Name Server DNS Identifica a los servidores de Los tipos de registro del DNS Bas A Dirección IPv4 zona. deleganombre-a-dirección Traducción los subdominios icos AAAA Dirección IPv6 Obsoleto NO USAR A6 original Dirección IPv6 Traducción nombre-a-dirección- PTR Apuntador ipv6 Traducción dirección-a-nombre DNAM Redirección Redirección para búscadas E MX Intercambiador de inversas Controla ipv6 el ruteo del correo-e Seg KEY correo Llave pública Llave pública para un nombre urid NXT Siguiente DNS Se usa con DNSSEC para ad SIG Firma respuestas Zona negativasfirmada autentificada OpcCNAM Nombre canónico Sobrenombres o alias de un host ion ELOC Localización Localización geográfica (Sólo ales RP Persona responsable NT) Especifica el nombre del SRV Servicios contacto Indica los lugares de los TXT Texto servicios Comentarios .

un grupo de registros de recursos localizados en el mismo lugar dentro del espacio de nombres del DNS • Este nodo del árbol DNS también es conocido como el punto de delegación o el corte de zona . La base de datos del DNS El registro SOA • Un registro SOA marca el inicio de una zona.

La base de datos del DNS El registro SOA • En general debe haber por lo menos dos zonas por dominio. una para traducir nombres de hosts a direcciones IP y la otra que hace el mapeo en la dirección contraria • El árbol del DNS tiene una rama hacia adelante (forward) organizada por nombre y una rama hacia atrás organizada por dirección IP .

La base de datos del DNS El registro SOA • Cada zona tiene exactamente un registro SOA • La zona continúa hasta que se encuentre otro registro SOA • El registro SOA incluye el nombre de la zona. un contacto técnico y varios valores de expiración temporal .

unam. La base de datos del DNS El registro SOA  .unam.mx @ IN SOA ns.(  2009100201 . Inicio del registro de autoridad para cch. Refresco 6 horas  1800 . 30 min  1209600 .unam. root. Mínimo 5 días  .cch.mx.cch. Reintentar. Serie  21600 . Expiración 2 semanas  432000 ) .mx.

puede ser cambiado dentro del archivo de zona con la directiva $ORIGIN . el campo name contiene el símbolo @. que es una abreviatura para el nombre de la zona actual • En este ejemplo. se pudo haber usado “cch.conf.mx” en lugar de la @ • El valor de @ es el nombre del dominio especificado en la instrucción zone del archivo named. La base de datos del DNS El registro SOA • Aquí.unam.

unam. Basta con reemplazar el primer punto por una . el tipo es SOA y los demás elementos forman el campo de datos • “ns. en vez del estándar usuario@host. La base de datos del DNS El registro SOA • Este ejemplo no tiene el campo TTL.cch. abreviatura de Internet.host”.unam. La clase es IN.cch.mx” es la dirección de correo del contacto técnico en formato “usuario.mx” es el nombre el servidor máster de nombres de la zona • “admin.

La base de datos del DNS El registro SOA • Los paréntesis permiten que el registro SOA continúe por varias líneas • El primer parámetro numérico es el número de serie de los datos de configuración de la zona • Este número de serie lo utilizan los servidores esclavos para determinar cuando es necesario obtener información fresca. Puede ser cualquier entero de 32 bits y debe ser incrementado cada vez que se .

corregir el número de serie en el . La base de datos del DNS El registro SOA • En algunos sitios se codifica la fecha en el número de serie. por ejemplo 2008100201 sería la primer modificación del 2 de octubre de 2008 • Los números de serie no necesariamente son consecutivos continuos. pero si deben incrementarse de forma monótona • Si por accidente se pone un valor muy grande en el servidor máster y ese valor es transferido a los esclavos.

La base de datos del DNS El registro SOA • Un truco para arreglar este problema es poner el número de serie 0. con lo que se causará una recarga forzada • No olvides poner nuevamente el número de serie correcto después de la recarga • Es un error común cambiar los archivos de datos y luego olvidar la actualización del número de serie .

en segundos que controlan por cuánto tiempo se va a guardar la información en el cache en varios puntos a través de la base de datos del DNS • Estos valores representan el balance entre la eficiencia y la exactitud . La base de datos del DNS El registro SOA • Las cuatro entradas siguientes del registro SOA son los valores de expiración temporal.

es decir el tiempo de refrescado y especifica la frecuencia con la cual los servidores esclavos deberían revisar al máster para ver si ha habido cambios en el número de serie de la zona • Si hay cambios. los esclavos actualizan su copia de los datos de la zona • Los valores comunes para este intervalo son de una a seis horas . La base de datos del DNS El registro SOA • El primero es el timeout refresh.

los servidores BIND ahora pueden notificar a los esclavos cada vez que la zona cambia. a menos que el parámetro notify esté específicamente apagado en el archivo de configuración • Los esclavos pueden entender la notificación y actuar . La base de datos del DNS El registro SOA • En vez de esperar pasivamente a que los esclavos esperen al timeout.

se sugiere que sea de entre 20 y 60 minutos (1.200- 3.600) • . retry • Por experiencia. pero el máster no responde. el esclavo intenta de nuevo después de que haya concluido el periodo de reintento. La base de datos del DNS El registro SOA • Si un esclavo intenta revisar el número de serie del máster.

los esclavos fallarán cada vez que intenten refrescarse. • Se recomienda una expiración de entre . La base de datos del DNS El registro SOA • Si un servidor de nombres está caído por mucho tiempo. por lo cual es muy probable que la información que tienen sea inservible • El parámetro expire determina por cuánto tiempo los esclavos seguirán intentando continuar obtener la información del máster.

2 el significado de minimum del registro SOA cambió. ahora pone el tiempo de vida para las respuestas negativas que están en el cache • El valor por omisión de las respuestas positivas se especifica al inicio del archivo de zona con la directiva $TTL • Los valores sugeridos van entre unas .2 de BIND el parámetro minimum se ponía con un tiempo de omisión para los registros de recursos • A partir de la versión 8. La base de datos del DNS El registro SOA • Antes de la versión 8.

expire y minumum hacen que con cierta periodicidad se descarten todos los valores anteriores • El diseño del DNS confía en el hecho de que la información de los host es relativamente estable y no cambia con frecuencia . La base de datos del DNS El registro SOA • Los parámetros $TTL.

La base de datos del DNS Los registros NS • Los registros NS identifican a los servidores que tienen la autoridad para una zona y delegan los subdominios a otras organizaciones • Los registros NS normalmente están a continuación del registro SOA .

edu.colorado.utah.utah.edu.colorado.edu.cs.cs.edu.cs.cs. así las siguientes líneas son equivalentes  IN NS ns.  • Puesto que el nombre e la zona es el mismo que el campo nombre del registro SOA que precede a esos registros.  IN NS anchor.  IN NS ns. IN NS ns. IN NS anchor. cs.edu.edu.colorado. La base de datos del DNS Los registros NS • El formato es  zona [TTL] IN NS hostname • Por ejemplo  cs.cs.colorado.colorado.colorado.edu.edu. se puede quedar en blanco. cs. .edu.colorado. IN NS ns.cs.

edu • Los servidores de cache puro no pueden tener autoridad.edu debe estar enlistado tanto en el archivo de zona para cs. por ello no se enlistan • Si no hay parámetros en el registro NS se supondrá que el servidor es . La base de datos del DNS Los registros NS • Cada nombre de servidor con autoridad para cs.colorado.colorado.edu como en el archivo de zona padre colorado.

La base de datos del DNS Los registros NS • named utiliza los registros NS de la zona para identificar los servidores esclavos cuando se les deba enviar una notificación de cambios en la zona • Esos mismos registros NS dentro de la zona padre (colorado.edu) definen el subdominio cs y le delegan la autoridad a los servidores de nombres del departamento de ciencias de la computación .

La base de datos del DNS Los registros NS • Si la lista de los servidores de nombres de la zona padre no se actualiza con los de la zona en sí misma. cualquier servidor nuevo que se agregue será invisible y no se utilizarán para contestar las preguntas del exterior • Esta situación se puede presentar por problemas de diseño o por simple olvido • Revise los servidores delegados con .

La base de datos del DNS Los registros A • Los registros A (address. es decir dirección) son el corazón de la base de datos del DNS • Son los que proveen la equivalencia entre nombres de hosts y direcciones IP • Un host debe tener un registro A para cada una de sus interfaces de red  .

La base de datos del DNS Los registros A • El formato es  hostname [TTL] INA ipaddr • Por ejemplo  anchor INA 128.100 • Una máquina con varias interfaces de red puede utilizar un solo nombre de host asociado con todas las interfaces o tener distintos nombres de host para cada interfaz .243.138.

de direcciones IP a nombres de host • Como en el caso de los registros A. un host debe tener uno para cada interfaz de red . La base de datos del DNS Los registros PTR • Los registros PTR (Pointer. apuntador) sirven para hacer la resolución inversa de nombres.

138.128.128.colorado.cs. • El nombre 100 no termina con un punto y por lo tanto es relativo al dominio 243. que corresponde al registro A de la máquina anchor es  100 IN PTR anchor.138. (indicado .edu.arpa. La base de datos del DNS Los registros PTR • El formato general para un registro PTR es  addr [TTL] IN PTR hostname • Por ejemplo el registro PTR en la zona 243.in-addr.arpa.in-addr.

128.arpa.cs.colorado. La base de datos del DNS Los registros PTR • Se puede poner el dominio colocando los registros PTR para cada subred en su propio archivo. . • Con un dominio por omisión de 138.243 IN PTR anchor.edu. como en el ejemplo anterior • Otra forma de hacer mapeos inversos es incluir registros tales como  100.in-addr.

243.edu.cs. La base de datos del DNS El dominio in-addr. por otra parte.138. anchor está en cs y cs está en colorado y colorado está en edu • Las direcciones IP.colorado.arpa. por ejemplo. es el host 100 en la . En la dirección 128. en el nombre anchor. tienen la parte “más significativa” del lado izquierdo.100. • Los dominios completamente calificados pueden ser vistos como una notación en la cual la parte “más significativa” está del lado derecho.

• El dominio in-addr.arpa. la zona para nuestra subred 243 es . así como de los nombres poder llegar a las direcciones IP • Los dominios bajo in-addr. se nombran como direcciones IP con sus bytes al revés. fue creado para permitir que un conjunto de módulos de software y un árbol de nombres hagan el mapeo entre las direcciones IP y los nombres de host. La base de datos del DNS El dominio in-addr. por ejemplo.arpa.arpa.

128.edu.arpa. sea agregado al final del nombre . La base de datos del DNS Los registros PTR • Algunos sitios ponen todos los registros inversos en el mismo archivo y utilizan varias directivas $ORIGIN para especificar la subred • Observe que el nombre del host anchor.cs.colorado.in-addr. termina con un punto para evitar que 138.

La base de datos del DNS Los registros PTR • Puesto que cs.arpa son distintas regiones del espacio de nombres del DNS.colorado.edu y 243. ellos constituyen dos zonas distintas • Cada zona debe tener su propio SOA y sus RRs • Además de definir una zona in- addr.138.arpa para cada red real. es necesaria una zona que se haga .in-addr.128.

0/26 es necesario utilizar un elegante truco que se define en el RFC2317 que utiliiza los registros de recursos CNAME para lograrlo • Este tema lo veremos un poco más .243. pero si se necesita definir una subred tal como 128.138. La base de datos del DNS Los registros PTR • Esta técnica funciona bien si las subredes están dentro de los límites a nivel byte.

por nombre. La base de datos del DNS Los registros PTR • Los mapeos inversos provistos por los registros PTR se utilizan por cualquier programa que autentifique el tráfico que ingresa • Por ejemplo el sshd podría permitir ingresos remotos sin contraseña si la máquina de origen está enlistada. en el archivo ~/.shosts del usuario .

syslogd. el cual se comparará con el archivo apropiado • Los programas netstat. sshd. sendmail. La base de datos del DNS Los registros PTR • Cuando el host destino recibe una petición de conexión. tcpd. X Window. sabe la dirección de la máquina fuente únicamente por su dirección IP • Entonces se utiliza el DNS para convertir la dirección IP a un nombre de host. ftpd y rlogind hacen los mapeos inversos para obtener los . fingerd.

La base de datos del DNS Los registros MX • El sistema de correo utiliza los registros del intercambiador de correo para enrutar el correo de forma más eficiente • Un registro MX prepara el destino de un mensaje. en muchos casos dirigiéndolo hacia el repositorio de correo del sitio del receptor en vez de a la estación de trabajo del receptor .

edu.colorado. uno para un host que recibe su propio correo a menos que esté apagado y otro para un host que no recibe ningún correo piper  IN MX 10 piper  IN MX 20 mailhub  IN MX 50 boulder. xterm1 IN MX 10 mailhub  IN MX 20 anchor  IN MX 50 boulder. La base de datos del DNS Los registros MX • El formato de un registro MX es  nombre [ttl] IN MX preferencia host … • A continuación se muestran dos ejemplos.edu.colorado. • .

535 es el peor • En este ejemplo el correo enviado a bob@xterm1 se enviaría primero a mailhub si está accesible.edu. a anchor como segunda opción y si mailhub y anchor están caidos. .colorado. a boulder • Observe que el nombre boulder debe estar completamente calificado porque no es parte del dominio por omisión. La base de datos del DNS Los registros MX • Los hosts con menor preferencia se intentan primero: 0 es el más deseable y 65. que aquí es cs.

La base de datos del DNS Los registros MX • La lista de las preferencias y hosts puede estar en la misma línea. pero hacerlo en líneas separadas simplifica la lectura • Los registros MX son útiles en muchas situaciones – Cuando se tiene un concentrador de correo central – Cuando el host de destino está caído – Cuando el destino no es alcanzable desde Internet – Cuando el destino no habla SMTP .

. el correo se enrutará a un concentrador de correo. la máquina en donde la mayor parte de los usuarios leen su correo • En el segundo caso el correo se enrutará a un host cercano y reenviado cuando el destino regrese a la vida • Los hosts que no están conectados a Internet no pueden tener registro A. La base de datos del DNS Los registros MX • En el primer caso.

 IN MX 20 anchor.  IN MX 50 boulder.edu. .cs.edu.colorado.colorado.colorado.cs.edu. La base de datos del DNS Los registros MX • El dominio en si mismo puede tener un registro MX para concentrar todo el correo en una máquina especial • Por ejemplo cs  IN MX 10 mailhub.

La base de datos del DNS Los registros CNAME • Los registros CNAME asignan nombres adicionales a un host • Estos apodos se utilizan normalmente para asociar una función con un host o para acortar un nombre largo • Al nombre real se le conoce como el nombre canónico y por ello el registro es CNAME .

La base de datos del DNS Los registros CNAME • Ejemplos  ftp INCNAME anchor  kb INCNAME kibblesnbits  www INCNAME lucrecia • El formato de un registro CNAME es apodo [ttl]  IN CNAME hostname  .

uno que tenga un registro A • Cada nombre que tenga CNAME debe tener un nombre real con un registro A • . La base de datos del DNS Los registros CNAME • Cuando el DNS encuentra un registro que tiene un CNAME detiene la búsqueda y trata de encontrar el nombre real.

La base de datos del DNS Los registros CNAME • Algunos sitios utilizan los registros CNAME como una pobre forma de balanceo de carga. puesto que pueden mapear el nombre público de un servidor web a varias máquinas distintas  www IN CNAME web1  www IN CNAME web2  www IN CNAME web3 .

29. La base de datos del DNS Los registros CNAME • También existe el truco inverso.248. sise re cib e u n n o m b re d istin to lle ve a u n sitio e sp e cífico .10 wiki IN CNAME www pedagogia IN CNAME www matematicas IN CNAME www fisica IN CNAME www • E n e la p a ch e e s p o sib le co n fig u ra r q u e . un solo servidor web para varios sitios distintos www IN A 132.

La base de datos del DNS El truco del CNAME • Cuando hay redes que no están divididas en los límites de byte.arpa natural. se agrega un CNAME que deflecte la búsqueda a la zona controlada por el dueño de la subred apropiada • Este esquema hace que los archivos de zona en el padre sean complicados. pero permite delegar la autoridad a los usuarios de cada subred . se puede utilizar CNAME para lograr la resolución inversa • El truco es el siguiente: para cada dirección de host posible en una zona in-addr.

La base de datos del DNS El truco del CNAME • La organización padre crea los registros CNAME para cada dirección IP posible con un componente extra falso (un trozo separado por un punto) que representa la subred • Por ejemplo. en el escenario /26 recién descrito. el segundo . el primer cuarto de las direcciones tendrían un componente “0-63”.

138. 1 IN CNAME 1.in-addr.arpa.0-63 … 63 IN CNAME 63.0-63 64 IN CNAME 64.0-63 2 IN CNAME 2.64-127 65 IN CNAME 65. La base de datos del DNS El truco del CNAME $ORIGIN 243.64-127 … .128.

com.. se deben agregar los siguientes registros NS 0-63 IN NS ns1.com... • El sitio que maneje la subred deberá tener un archivo de zona que contenga los mapeos inversos de la zona 0- 63.cliente1.243. .128. 1 IN PTR host1. .arpa.in-addr.cliente1. La base de datos del DNS El truco del CNAME • Para delegar el bloque 0-63 de la zona inversa al subdominio.  .cliente1.com. 0-63 IN NS ns2. 2 IN PTR host2.138.com.cliente1..

128.243.arpa redirige la búsqueda al nombre 1.0- 63.1. La base de datos del DNS El truco del CNAME • Cuando se agrega este componente extra.138. por ejemplo.in-addr.138.243.138.in-addr.243. el registro CNAME en 1.arpa y ese nombre es controlado por el cliente .128. se crea un “corte” que hace la delegación • Cuando alguien busca el mapeo inverso para 128.

sólo el ISP debe hacer el truco con nombres de configuración poco elegantes • Las cosas pueden complicarse aún más si el cliente fuera un ISP que quisiera dividir a su vez sus direcciones. La base de datos del DNS El truco del CNAME • Los archivos del cliente son bastante limpios. pero eso está bien porque en BIND se pueden encadenar hasta 8 niveles de .

138. $GENERATE 0-63 $ CNAME $. . 0-63 NS ns2.cliente1.com. basta con las siguientes líneas $ORIGIN 243.com.cliente1. La base de datos del DNS El truco del CNAME • En las nuevas versiones de BIND hay una instrucción nueva.128. $GENERATE que facilita la creación de registros de recursos en la zona padre • Por ejemplo para producir los registros de la primera subred.in-addr.0-63 0-63 NS ns1.arpa.

La base de datos del DNS El truco del CNAME • El símbolo $ en el comando $GENERATE itera desde 0 hasta 63 y crea 64 diferentes registros CNAME • Las otras tres subredes /26 se pueden manejar de forma similar .

Refresco 6 horas  1800 . Serie  21600 .guarida. (  2009100202 .zone $TTL 3600 @ IN SOA ns.dyndns. Reverse cache expiration 5min  IN NS ns  IN MX 10 ns ns IN A 192.168.129 m1 IN A 192.dyndns.168.226.226.168.zone . guarida. root.org.226.226.168.$ $GENERATE 130-254 m$ IN A 192.dyndns.$  .guarida.org. 30 min  1209600 .org. La base de datos del DNS Revisita de ejemplos  root@u804:/var/cache/bind# cat guarida. Expiración 2 semanas  300 ) .1 gateway IN A 192.226.dyndns.2 $GENERATE 3-128 m$ IN A 192.168.org. Reintentar.

zone $TTL 3600 @ IN SOA ns.192. 226.dyndns.in-addr.dyndns. 129 IN PTR ns.guarida.dyndns. $GENERATE 3-128 $ IN PTR m$.zone .guarida.org. 30 min  1209600 . .192.arpa.org. Serie  21600 . Expiración 2 semanas  3600 ) .dyndns.org. $GENERATE 130-254 $ IN PTR m$. La base de datos del DNS Revisita de ejemplos  root@u804:/var/cache/bind# cat 226.dyndns. 1 IN PTR m1.dyndns.guarida. (  2009100204 .guarida.guarida.168.guarida.guarida. cache inverso 1hr  IN NS ns. Reintentar.org.dyndns.org. root.in-addr. Refresco 6 horas  1800 .168. 2 IN PTR gateway.dyndns.guarida.arpa.org.org.org.

in-addr.192.arpa.   zone "226.   zone "guarida. .rfc1918".org.  file "guarida.arpa" {  type master.168.dyndns.org" {  type master.local // // Do any local configuration here //  // Consider adding the 1918 zones here.zone".192.conf. }.  file "226. La base de datos del DNS Revisita de ejemplos root@u804:/var/cache/bind# cat /etc/bind/named.168. }.zone".dyndns.in-addr. if they are not used in your // organization //include "/etc/bind/zones.

La base de datos del DNS Comandos en los archivos de zona • Hay cuatro comandos – $ORIGIN nombre-del-dominio – $INCLUDE nombre-de-archivo – $TTL ttl-por-omisión – $GENERATE muchos argumentos • Todos los comandos deben comenzar en la primera columna y estar aislados en una sola línea .

conforme named lee un archivo de zona. le agrega un dominio por omisión u origen a cualesquiera nombres que no estén calificados • El origen se pone inicialmente de acuerdo con lo que está especificado en el comando zone del archivo named. La base de datos del DNS $ORIGIN • En condiciones normales.conf  .

arpa. para los registros inversos para una subred de clase B se puede poner con una instrucción como la siguiente  $ORIGIN 243.128. • .in-addr. La base de datos del DNS $ORIGIN • El comando $ORIGIN permite poner el origen de forma manual • Por ejemplo.138.

para separar las partes lógicas de un archivo de zona o para mantener las llaves criptográficas en un archivo con permisos restringidos . La base de datos del DNS $INCLUDE • Muchos sitios utilizan la directiva $INCLUDE en sus archivos de base de datos de la zona para separar registros de encabezado con los de datos.

La base de datos del DNS $INCLUDE • La sintáxis de la directiva $INCLUDE es  $INCLUDE nombre-de-archivo • El archivo especificado es leído en la base de datos en el punto en el que encuentra la directiva $INCLUDE .

La base de datos del DNS $TTL • La directiva $TTL pone un valor por omisión para el tiempo de vida (time-to-live) de cada uno de los registros que le siguen • .

La base de datos del DNS $GENERATE • $GENERATE es la forma más simple de generar series de registros similares • El formato de la directiva $GENERATE es  $GENERATE inicio-fin/[paso] lhs tipo rhs [comentario] • Y el tipo de líneas generadas son de la forma  lhs tipo rhs • El campo de inicio y término especifican el intervalo de valores para un iterador numérico. se genera una .

La base de datos del DNS $GENERATE • El valor del iterador se incorpora dentro del lhs y el rhs con el caracter $ • También se puede especificar un paso. por el momento sólo se acepta en CNAME. con lo cual los incrementos entre el inicio y el final se harán del tamaño de cada paso • Tipo es el tipo de registro. PTR y NS .

unam.mx • Algunos sitios mapean la dirección simplemente como localhost.localdomain por ejemplo localhost.cch.1 se refiere a el host en si mismo y siempre puede ser mapeado al nombre localhost.0. como si fuera parte del dominio root. La base de datos del DNS La zona localhost • La dirección 127.0. esta configuración es incorrecta .

0. su sitio podría acabar preguntando a los servidores root sobre la información local • Los servidores root reciben actualmente tantas preguntas de estas que los operadores están considerando agregar un mapeo genérico entre localhost y 127.0. La base de datos del DNS La zona localhost • Si se olvida de configurar la zona localhost.1 a nivel root .

1 nunca cambia por lo que los timeouts pueden ser grandes • En este caso @ significa 0.0. expiración  14400 ) .mx.cch. mínimo  IN NS cch. .in-addr.unam.mx.127. La base de datos del DNS La configuración de la zona • localhost El mapeo directo para el nombre localhost o localhost. root. reintento  3600000 . • Sin embargo. 1  IN PTR localhost. 127.  • El mapeo inverso para la dirección del localhost.arpa.unam.dominio se hace en el archivo directo de la zona para el dominio. (  2008101401 . refresco  900 .unam. cada servidor normalmente es el máster de su propio dominio inverso • @  IN SOA cch.mx.0.mx. número de serie  3600 .0.cch.unam.

Registros de pegamento. enlaces entre zonas • Para que haya una jerarquía coherente es necesario establecer en el DNS una forma de enlazar dominios con subdominios • Las referencias del DNS ocurren únicamente desde los dominios padre hacia los hijos y no es necesario que el servidor de nombres sepa nada sobre las zonas que están por encima de su .

enlaces entre zonas • Los servidores de un dominio padre deben conocer la dirección IP de los servidores de nombres de todos sus subdominios • La zona padre necesita contener los registros NS para cada zona delegada • Los registros NS se escriben en términos de nombres de host. ya sea haciendo una consulta de DNS normal (cuidando evitar un ciclo de dependencias) o copiando los registros A que sean apropiados . Registros de pegamento.

Registros de pegamento. enlaces entre zonas • Hay dos formas de cumplir este requisito – Incluyendo los registros necesarios – Utilizar zonas tocón (stub) .

com. ee IN NS ns.1 .cs IN A 128.cs IN A 128.edu) . información de subdominio cs IN NS ns. registros pegamento ns.colorado.ee.colorado.200.colorado.ee IN A 128.138. .edu.cs.151 piper. Registros de pegamento.243.4  ns.  IN NS ns.edu.138.cs.cs.edu.edu.colorado.  IN NS piper. enlaces entre zonas • En el primer método se incluyen los registros NS y A que sean necesarios en la zona padre (colorado.xor.204.138.  IN NS ns.

enlaces entre zonas • Ejemplo en la UNAM • En el archivo named.unam.mx es el subdominio a delegar cch IN NS ns.unam.248. cch.122.1 . ns.cch IN A 132.mx” se escribe  .cch.mx. Registros de pegamento.conf del servidor de nombres que resuelve la zona “unam.

enlaces entre zonas • Los registros foráneos A se llaman registros de pegamento porque en realidad no pertenecen a esta zona • Se reproducen aquí solamente para conectar el nuevo dominio al árbol de nombres de Internet • Si se omiten o se colocan registros de pegamento incorrectos. los usuarios que intenten llegar a ellos obtendrán errores “host . se dejará parte del espacio de nombres inaccesible. Registros de pegamento.

pero si hay cambios en xor. enlaces entre zonas • Es un error común incluir registros de pegamento para nombres de host que no los necesitan. por ejemplo ns.xor.com. podría ocasionar fallas . Registros de pegamento.com del ejemplo anterior. podría ser resuelto por una petición normal del DNS • Un registro A podría ser a primera vista simplemente redundante.

enlaces entre zonas • La regla a seguir es que se deben incluir registros A únicamente para los hosts que están dentro del dominio actual o cualesquiera de sus subdominios • Las versiones modernas de BIND ignoran los registros de pegamento innecesarios y los muestran en la bitácora como un error . Registros de pegamento.

las actualizaciones son con frecuencia una tediosa tarea manual que requiere de coordinación entre fronteras administrativas • El corolario es que en el mundo real. Registros de pegamento. este tipo de configuración. con frecuencia. pero requiere de que el hijo se mantenga en contacto con el padre y le indique sobre cualesquiera cambios o adiciones a su flotilla de servidores de nombres • Puesto que las zonas padre e hijas con frecuencia utilizan máquinas distintas. enlaces entre zonas • El esquema recién descrito es la forma estándar de conectar zonas. está .

enlaces entre zonas • La segunda forma de mantener estos enlaces es utilizando zonas tocón (stub) • Un zona stub es esencialmente lo mismo que una zona esclava. Registros de pegamento. pero que incluye únicamente a los registros NS de la zona • En BIND 9 las zonas stub deben ser configuradas de forma idéntica tanto en los servidores amo y esclavo del padre. algo que por sí mismo es difícil .

luego se escoge uno y se ejecuta  dig @servidor-de-nombres dominio-padre dominio-hijo ns  para ver tu lista de servidores de . enlaces entre zonas • La mejor apuesta es mantenerse en contacto con la del dominio padre y verificar la configuración al menos dos veces al año • Se puede usar el programa dig para verificar cuáles de tus servidores está siendo anunciado por el dominio padre. Primero se ejecuta  dig dominio-padre ns  para determinar los servidores de nombres del dominio padre. Registros de pegamento.

o simplemente esperar a que la zona se actualice hacia el final del intervalo de refresco especificado en el registro SOA de la zona. Para actualizarlos. los servidores stub no deben estar enlistados entre los registros de zona NS • Como no están enlistados en los registros NS. Sutilezas de las zonas stub • Las zonas stub no son copias con autoridad sobre la información de la zona. pero podría resultar en una delegación coja transitoria en algunos . Registros de pegamento. se puede añadir una cláusula also-notify a la configuración de los servidores máster . no serán notificados cuando cambie la información de la zona. La opción timeout debería funcionar bien en la mayor parte de los casos.

Actualización de archivos de zona • Cuando se hace un cambio a un dominio.d/bind9 restart. también se puede matar y reiniciar named con ndc restart. pero esta operación causa que se pierdan los datos recopilados en el cache . como puede ser agregar o borrar un host. o /etc/init. los archivos de datos en el servidor máster deben ser actualizados • Se debe incrementar el número de serie en el registro SOA y luego ejecutar ndc reload para enviar una señal al demonio named para que revise los cambios.

se puede utilizar ndc reload en el esclavo. los servidores esclavos se actualizarán en cuanto se llegue al tiempo de refresco que se puso en el registro SOA • Si se quiere actualizar manualmente. si los hay. solicita una transferencia de zona . para que revise si hubo cambios en su máster y.Actualización de archivos de zona • La información de actualización de la zona se propaga hacia los servidores esclavo inmediatamente puesto que la opción notify está prendida por omisión • Si esta opción está apagada.

pueden suceder errores difíciles de encontrar. porque algunos comandos funcionarán y otros no • Si se cambia la información y no se actualiza el número de serie.Actualización de archivos de zona • Cuando se actualice una zona. los cambios funcionarán en el servidor . no olvides modificar los registros directos e inversos • Si se olvida la modificación de un registro inverso.

cs. cuando olvidamos poner un punto no es fácil verlo en el servidor máster.edu. por ejemplo.colorado. pero si en el esclavo.Actualización de archivos de zona • Es completamente inadecuado editar información en los servidores esclavos • Es conveniente verlos de vez en cuando porque se pueden descubrir errores en los archivos de zona. porque ahí aparecerá completo  foo.cs.edu .colorado.

respectivamente . la forma en que se refieren estas transferencias es AXFR y IXFR. Transferencias de zona • Los servidores de nombres se sincronizan a través de un mecanismo llamado transferencia de zonas • Antes se tenían que transferir todas las zonas a la vez. ahora se hacen de forma incremental.

Transferencias de zona • Un esclavo que quiere refrescar su información hace una petición de transferencia de zona a un servidor máster y hace una copia de respaldo del archivo de zona • Si la información del servidor máster no ha cambiado (esto se determina comparando los números de serie) no hay ninguna actualización y los respaldos sólo se “tocan” .

es cuando el servidor tendrá la nueva información . sólo después de que haya terminado la transferencia. Transferencias de zona • Las transferencias de zona utilizan el protocolo TCP en el puerto 53 y hacen una bitácora a través del syslog con la etiqueta “named-xfer” • Tanto el servidor amo como el esclavo están disponibles para contestar las peticiones durante una transferencia de zona.

Transferencias de zona • Cuando las zonas son muy grandes. o se actualizan dinámicamente. los cambios son muy pequeños con respecto al tamaño de la zona completa • Con IXFR sólo se envían los cambios • El mecanismo es como el del programa patch y sólo se aplican las diferencias sobre una base de datos anterior . como la .com.

La opción request-ixfr hace las peticiones IXFR para las zonas para las cuales este servidor es esclavo . Transferencias de zona • En BIND 9 IXFR está puesto por omisión • Las opciones provide-ixfr y request-ixfr pueden ser puestas en las sentencias server para los pares individuales. provide-ixfr habilita o deshabilita el servicio IXFR para las zonas para las cuales este servidor es el máster.

# en la sentencia server  . Transferencias de zona • Las instrucciones para los archivos de configuración son las siguientes provide-ixfr yes. # en la sentencia server request-ixfr yes.

Transferencias de zona
• Ejemplo para un servidor esclavo
• Si quisiéramos ser servidores esclavos de upn.mx y de
acer.com.mx deberíamos escribir las siguientes líneas en
named.conf
zone "upn.mx" {

 type slave;
 masters { 200.23.113.1; };
 file "upn.mx.zone";
};

 zone "acer.com.mx" {
 type slave;
 masters { 200.23.80.27; };
 file "/var/cache/bind/acer.com.mx.zone";
};

Transferencias de zona
• En este caso upn.mx no permite la
transferencia de la zona, por lo que en
/var/log/syslog aparecen los siguientes
mensajes
Sep 5 05:16:43 u804 named[13587]: zone
upn.mx/IN: Transfer started.
Sep 5 05:16:43 u804 named[13587]: transfer of
'upn.mx/IN' from 200.23.113.1#53: connected
using 192.168.226.129#32821
Sep 5 05:16:44 u804 named[13587]: transfer of
'upn.mx/IN' from 200.23.113.1#53: failed
while receiving responses: REFUSED
Sep 5 05:16:44 u804 named[13587]: transfer of
'upn.mx/IN' from 200.23.113.1#53: end of
transfer

Transferencias de zona
• En el caso de la zona acer.com.mx los mensajes son
los siguientes
Sep 5 04:26:13 u804 named[13587]: zone
acer.com.mx/IN: Transfer started.
Sep 5 04:26:13 u804 named[13587]: transfer of
'acer.com.mx/IN' from 200.23.80.27#53:
connected using 192.168.226.129#39431
Sep 5 04:26:15 u804 named[13587]: zone
acer.com.mx/IN: transferred serial 2000221205
Sep 5 04:26:15 u804 named[13587]: transfer of
'acer.com.mx/IN' from 200.23.80.27#53: end of
transfer
Sep 5 04:26:15 u804 named[13587]: zone
acer.com.mx/IN: sending notifies (serial
2000221205)

Actualizaciones dinámicas
• La premisa del DNS es que los
mapeos nombre-a-dirección son
relativamente estables y no
cambian con frecuencia
• En los sitios con DHCP esto no es así
• Hay dos soluciones clásicas: agregar
entradas genéricas a la base de
datos del DNS o editar
continuamente los archivos del
DNS
• Estas dos soluciones podrían no ser

Actualizaciones dinámicas
• La primera solución es conocida para
cualquiera que haya utilizado un ISP
con dial-up, la configuración del DNS
es como sigue
 dhcp-host1.dominio.IN A 129.168.0.1
 dhcp-host2.dominio.IN A 129.168.0.2
• Aún cuando es una solución simple, los
nombres de las máquinas están
permanentemente asociados a
direcciones IP aún cuando cambien.
Esto podría representar un riesgo de

desde el DHCP se notifique cada vez que se asigne una dirección y se actualice el servidor de nombres al vuelo • Las actualizaciones dinámicas pueden agregar. se recomienda para estos casos utilizar un subdominio . borrar o modificar los registros de recursos • Puesto que es un poco espantoso que se actualice el DNS con esa frecuencia. Actualizaciones dinámicas • Las últimas versiones de DHCP y BIND permiten que.

e incluso obtener la base de datos completa del dominio • Las versiones nuevas de BIND . cualquiera puede explorar un dominio con peticiones individuales con las herramientas dig. host o nslookup. Seguridad en el DNS • El DNS se concibió como un sistema abierto • En condiciones normales.

servidor Quién puede solicitar una transferencia transfer allow-update zone de zonapuede hacer actualizaciones Quién blackhole options dinámicas A qué servidores se debe ignorar por bogus server completo A qué servidores nunca se debe acl various preguntar Listas de control de acceso . Quién puede preguntar una zona o un allow. Seguridad en el DNS Característic Sentencias Qué especifica a allow-query options. zone options.

por supuesto el soporte completo de DNSSEC . Seguridad en el DNS • Otra forma de mejorar la seguridad del DNS es ejecutarlo en un ambiente chroot. en donde se utilice un UID sin privilegios de tal forma que se elimine la posibilidad de explorar los directorios • También se pueden utilizar firmas de transacción para controlar las actualizaciones dinámicas y.

Listas de control de acceso • Las ACL son listas de direcciones que aparecen como argumentos a las sentencias tales como allow-query. allow-transfer y blackhole • Las ACL pueden servir para mitigar dos de los mayores problemas de seguridad de los DNS: el spoofing y los ataques de denegación de servicio .

0/16.0/16.0.0.0.16/24.0. // La red principal del campus  198.11.2. // por omisión.com  224.0.0. acl cunets { // ACL para las redes de la Universidad de Colorado  128.0.0. // espacio de direcciones privado (RFC1918)  192. .0/16.0/12.0/3. Listas de control de acceso • Cada sitio debería tener un ACL para las direcciones fraudalentas y un ACL para las direcciones locales acl bogusnets { // ACL para redes fraudalentas  0.0.0.0/24.0. // espacio de direcciones privado (RFC1918) }.0/8.254.138. // espacio de direcciones multicast  10. // direcciones de muestra como example. // espacio de direcciones privado (RFC1918)  172. // direcciones delegadas de enlace local  192.0/8.168.16. direcciones comodín  169.

0/16.0. Los módems de cable y DSL están comenzando a utilizar este intervalo de direcciones • No haga que las direcciones privadas sean fraudalentas si se están utilizando en su . Estas máquinas simplemente se asignan a sí mismas una dirección en la red 169.254. Las direcciones que estén en ese intervalo deberían ser agresivamente filtradas de tal forma que nunca escapen del cableado local. Listas de control de acceso • La dirección de enlace local se utiliza por las Macs y las PCs a las que se ha indicado que utilicen una IP pero no encuentran al servidor DHCP.

 blackhole { bogusnets. Listas de control de acceso • En la sección de options global del archivo de configuración. . }. también se podría incluir  allow-recursion { cunets. }.

5.0/24.0/24. }.157.32.160. // mediciones de Mark Lottors }.9. acl mediciones {  128. Un ACL que hace las cosas bonitas y sencillas sería el mostrado a continuación acl misesclavos {  128. allow-transfer { misesclavos. mediciones. // mediciones de Bill Manning  192. Listas de control de acceso • También es una buena idea restringir las trasferencias de zona a los servidores esclavos legítimos. // ancla … }. .242.4.5. // mediciones de Bill Manning  198.1.138.

es imposible que otros sitios obtengan la base de datos completa . Listas de control de acceso • Con esta opción se limitan las transferencias a nuestros servidores esclavos propios y a las máquinas de dos proyectos de medidas de Internet que caminan a través del árbol inverso del DNS para determinar el tamaño de Internet y el porcentaje de servidores mal configurados • Si se limitan las transferencias de esta forma.

colorado. [server name] *** Can’t list domain cs.edu. Listas de control de acceso • Ahora sucederá lo siguiente % nslookup Default Server: server-name Address: server-IP-address  > ls cs.edu: Unespecified error .colorado.

Confinación de named • Para confinar el daño que alguien podría causar si el servidor queda comprometido. se puede ejecutar named dentro de un ambiente confinado con chroot y/o ejecutarlo como un usuario no privilegiado • La bandera –t especifica el directorio a donde estará el chroot y las banderas –u y –g especifican el UID y el GID bajo el cual se ejecutará  # named –u 53 –t /var/named .

Confinación de named
• Con esto, named iniciará con el UID 53
y en el directorio root /var/named
• Un directorio chroot no puede estar
vacío puesto que debe contener todos
los archivos que normalmente
requiere el named para ejecutarse:
/dev/null, las bibliotecas compartidas,
los archivos de zona, named.conf, etc.
• Si se compila named de forma estática
no será necesario copiar todas las
bibliotecas a /var/named

Confinación de named
• Si los hackers comprometen a su
named, podrían tener acceso a todo
el sistema y todos los derechos del
usuario en el que se ejecuta named
• Si el usuario es root y no se hace dentro
de un ambiente chroot, esta brecha
de seguridad podría ser muy
destructiva
• Muchos sitios no se preocupan por las
banderas
-u, -g y -t pero entonces deberán ser
más rápidos que los hackers para

Confinación de named
• Los pasos detallados para
implementar esta técnica se
pueden encontrar en

http://tldp.org/HOWTO/Chroot-BIND-HOWTO.htm

Comunicación segura servidor-
a-servidor con TSIG y TKEY
• Antes de la especificación de
DNSSEC que se verá más adelante,
el IETF desarrolló un sencillo
mecanismo llamado TSIG
(RFC2845) para permitir la
comunicación segura entre
servidores a través del uso de
firmas de transacción
• El control de acceso basado en
firmas de transacción es más
seguro que el control de acceso
basado en direcciones IP

Comunicación segura servidor-
a-servidor con TSIG y TKEY
• Las firmas de transacción utilizan un
esquema de criptografía simétrica
• Esto es, que la llave de codificación
es la misma que la de
descodificación
• Esta llave se llama “secreto
compartido” o shared-secret en
inglés
• Se deben utilizar llaves diferentes
para cada par de servidores que se
quieren comunicar entre sí

Comunicación segura servidor- a-servidor con TSIG y TKEY • Desde el punto de vista computacional. pero sólo es apropiado para una red local en el cual el número de pares de servidores comunicantes sea pequeño • No es escalable al Internet global . el sistema de criptografía de TSIG es mucho menos caro que el uso de criptografía de llave pública.

pero no entre servidores y resolvedores • Las firmas TSIG se revisan en el momento que se recibe un paquete y luego son descartadas. no se guardan ni forman parte de la información del DNS • La implementación de TSIG más común es el algoritmo HMAC-MD5 .Comunicación segura servidor- a-servidor con TSIG y TKEY • TSIG también firma las peticiones y respuestas de DNS • Sólo puede ser utilizado entre servidores.

private • E la rch ivo co n tie n e la ca d e n a “ K e y:” . Comunicación segura servidor- a-servidor con TSIG y TKEY • La utilería dnssec-keygen genera una llave para un par de servidores. por ejemplo para generar la llave de secreto compartido entre dos servidores. serv1 y serv2 se hace así  # dnssec-keygen -a HMAC-MD5 -b 128 -n HOST serv1-serv2 • C o n e sto se cre a u n a lla ve d e 1 0 2 4 - b its y se g u a rd a e n e la rch ivo Kserv1- serv2+157+00000.

Comunicación segura servidor- a-servidor con TSIG y TKEY • La llave generada es únicamente un número aleatorio largo. sólo que debe existir en ambas máquinas . Se puede generar la llave manualmente escribiendo una cadena ASCII de la longitud correcta y pretendiendo que es una codificación base-64 o utilizando mmencode para codificar una cadena aleatoria • La forma de crear la llave no es importante.

es .conf de ambas máquinas • Puesto que named. aún las redes internas pueden ser inseguras • La llave debe estar incluida en los archivos named.conf es normalmente un archivo que se puede leer por cualquiera.Comunicación segura servidor- a-servidor con TSIG y TKEY • Luego se copia la llave en ambos servidores serv1 y serv2 con scp o cortando y pegando • NO USE telnet o ftp para copiarla.

. Comunicación segura servidor- a-servidor con TSIG y TKEY • Por ejemplo.  secret “llave-compartida-generada”.key con modo 0600 y que su dueño sea el UID de named  key serv1-serv2 {  algorithm hmac-md5.key”.  Y en el archivo named.  }.conf agregar  include “serv1-serv2. se puede crear un archivo serv1-serv2.

En serv2  server direccion-ip-de-serv-1 {  keys {serv1-serv2. cada servidor necesita identificar al otro con la cláusula keys En serv1  server direccion-ip-de-serv2 {  keys { serv1-serv2. para que funcione para verificar y firmar las actualizaciones.  }. }. }.Comunicación segura servidor- a-servidor con TSIG y TKEY • Esta parte de la configuración sólo define las llaves.  }. .

allow-transfer y allow-update en la sentencia zone deberían referirse a la llave. por ejemplo  allow-transfer { key serv1-serv2. • Es conveniente. }.Comunicación segura servidor- a-servidor con TSIG y TKEY • También las cláusulas allow-query. cuando se implemente esto ejecutar named en nivel de depuración 1 para ver los mensajes de error que se generen .

Comunicación segura servidor- a-servidor con TSIG y TKEY • TKEY es el mismo mecanismo pero en donde los dos servidores generan un secreto compartido de forma automática • Utiliza el intercambio de llaves de Diffie-Hellman .

private Private-key-format: v1.+157+17079 debian:/etc/bind# cat Ks1s2. IN KEY 512 3 157 gp/HvgCV8iY= debian:/etc/bind# cat Ks1s2. Comunicación segura servidor- a-servidor con TSIG y TKEY debian:/etc/bind# dnssec-keygen -a hmac-md5 -b 64 -n HOST s1s2 Ks1s2.2 Algorithm: 157 (HMAC_MD5) Key: gp/HvgCV8iY= • .key s1s2.+157+17079.+157+17079.

.

DNSSEC • DNSSEC es una extensión del DNS que autentifica el origen de la información de la zona y verifica su integridad utilizando criptografía de llave pública • Estas extensiones le permiten al cliente preguntar cosas como “¿De verdad esta información de DNS proviene del dueño de la zona?” y “¿En verdad la información enviada proviene del dueño?” .

DNSSEC • DNSSEC tiene tres servicios – Distribución de llaves por medios de los registros KEY almacenados en los archivos de zona – Verificación de origen para servidores e información – Verificación de la integridad de la información de la zona .

los dominios de alto nivel proveen información validada para los dominios de segundo nivel y así sucesivamente . DNSSEC • DNSSEC está basado en la confianza de la cadena en cascada. los servidores root proveen de información para validar los dominios de alto nivel.

que se distribuye a todo el mundo . firman su información con una llave privada secreta • Cualquiera puede verificar la validez de una firma con la llave pública. uno para codificar (o firmar) y otro para descodificar (o verificar) • Los que publican. DNSSEC • Los sistemas de criptografía pública utilizan dos llaves.

entonces la zona debe haber sido codificada con la llave privada correspondiente • El truco es asegurarse de que las llaves públicas que se utilicen para verificar sean auténticas • Los sistemas de llave pública permiten a una entidad firmar la llave pública de otra. de ahí el término “cadena . para respaldar la legitimidad de la llave. DNSSEC • Si una llave pública decodifica correctamente un archivo de zona.

un hash seguro. DNSSEC • La información de una zona de DNS es demasiado voluminosa como para ser codificada con criptografía de llave pública. Los resultados de ese has son como la huella digital de los datos y la huella digital firmada se llama “firma digital” . como una suma de verificación MD5. puesto que la codificación sería muy lenta • En cambio. se ejecuta sobre la información y los resultados de ese hash son firmados (codificados) por la llave privada de la zona. puesto que la información no es secreta.

pasar la información a través del mismo algoritmo de hash y comparar el hash calculado con el valor del hash decodificado • Si coinciden. DNSSEC • Las firmas digitales normalmente se agregan a la información que autentifican • Para verificar la firma. se ha autentificado al firmante y verificado la integridad . se debe decodificar con la llave pública del firmante.

DNSSEC • En un sistema DNSSEC cada zona tiene sus propias llaves pública y privada • La llave privada firma cada conjunto RR • La llave pública verifica las firmas y están incluidas en los datos de la zona en forma de un registro de recursos KEY • .

DNSSEC • Las zonas padre firman las llaves públicas de las zonas hijas • Named verifica la autenticidad de un registro de zona hijo KEY revisándola contra la firma de la zona padre • Para verificar la autenticidad de la llave de la zona padre. named puede revisar al padre del padre y así sucesivamente hasta la raíz • La llave pública para la zona raíz se incluye en el archivo de hints del root .

DNSSEC
• Primero se genera un par de llaves
para la zona
 # dnssec-keygen –a DSA –b 768 –n ZONE midominio.com.

Argumento Significado
-a DSA Utiliza el algoritmo DSA
-b 768 Crea un par de llaves de 768-bits
-n ZONE Crea las llaves para una zona llamada
midominio.com. midominio.com

DNSSEC
• Se recibe la siguiente salida
alg = 003
key identifier = 12345

flags = 16641

• Y también crea los archivos que
contienen las llaves públicas y
privadas
Kmidominio.com.+003+12345.key # pública
Kmidominio.com.+003+12345.private # privada

DNSSEC
• La llave pública típicamente se
incluye en el archivo de zona con
$INCLUDE
• Puede ir en cualquier lugar del
registro SOA, pero usualmente se
pone a continuación del SOA

DNSSEC
• DNSSEC requiere de una cadena de
confianza, de tal forma que la llave
pública de una zona debe ser
firmada por su padre para verificar
su validez
• El programa dnssec-makekeyset
empaqueta las llaves que se
quieren firmar, un TTL para el
conjunto de llaves resultante y un
periodo de validez de la firma,
luego envía el paquete al padre
para su firma

DNSSEC
• Esta instrucción empaca la llave pública
de la zona recién generada con un
TTL de 3,600 segundos y le hace la
petición a la firma del padre para que
sea válida por 10 días a partir de hoy
• dnssec-makekeyset crea un archivo
de salida único
mydomain.com.keyset
• Luego se envía este archivo a la zona
padre para su firma
• Contiene la llave pública y las firmas
generadas por las llaves de la zona en
sí mismas para que el padre pueda

com.signedkey que el padre mandará nuevamente al hijo para que sea incluido en los archivos de zona para midominio. se utiliza el programa dnssec-signkey para firmar el paquete de llaves # dnssec-signkey midominio.com.keyset Kcom.com  .+003+56789  • Este comando produce un archivo llamado midominio. DNSSEC • En la zona padre.

se puede firmar ya la información de la zona actual • La operación de firma toma un archivo de zona normal como entrada y le agrega los registros SIG y NXT inmediatamente después de el conjunto de registros de recursos • Los registros SIG son las firmas y los registros NXT dan soporte de firma a las respuestas negativas . DNSSEC • Una vez obtenida la firma de la zona padre.

DNSSEC • El registro SIG contiene información muy rica – El tipo de conjunto de registros firmado – El algoritmo utililzado para firmar (DSA en este caso) – El TTL del registro que fue firmado – La hora a la que la firma expira (como yyyymmddhhssss) – La hora a la que el registro fue firmado (también yyyymmddhhssss) – El identificador de la llave (en este caso 12345) – El nombre del firmante (midominio.com) – La firma digital (hasta al final) .

signed en vez de a db.midominio. cambia el parámetro file en la sentencia zone del archivo named.com para que apunte a db. DNSSEC • Para utilizar la zona firmada.conf para midominio.midominio .

colorado. DNSSEC • La firmas digitales están bien para las respuestas positivas como “Aquí está la dirección IP para el host anchor.edu. junto con una firma que demuestra que de verdad vino de cs.edu y que la información es válida” • Pero en las respuestas negativas tales como “No existe el host” no se regresan registros firmados .cs.colorado.

colorado. pero con los nombres que están más arriba del árbol en primer lugar. por ejemplo en la zona cs.edu. cs. DNSSEC • En DNSSEC este problema se resuelve utilizando los registros NXT que enlistan al siguiente registro en la zona en una forma canónica ordenada • El orden es alfabético.colorado.edu. es decir se conserva el orden alfabético .edu viene antes de cualquier host.colorado.cs.

edu y si llega una petición para anthill.edu A MX NXT • Este registro dice que el nombre inmediatamente a continuación de anchor en la zona cs.cs.edu fue awesome.colorado.cs.cs.colorado. IN NXT awesome.colorado.colorado.colorado.cs. DNSSEC • Si el siguiente registro después de anchor en cs.colorado.edu. la respuesta sería firmada por el registro NXT de la siguiente forma  anchor.edu.edu es awesome y que anchor tiene al menos .

cs. DNSSEC • El último registro NXT en una zona se dobla hasta el primer host de la misma • Por ejemplo.colorado.colorado.edu A MX NXT • Lo s re g istro s N X T ta m b ié n so n re g re sa d o s si e lh o st existe p e ro e ltip o d e re g istro so licita d o n o e xiste • Po r e je m p lo sise p id e u n re g istro LO C p a ra a n ch o r.cs.edu apuntaría de regreso al primer registro del dominio  zamboni. se re g re sa rá e lm ism o re g istro N X T d e a n ch o r m o stra n d o ú n ica m e n te lo s .colorado.edu. IN NXT cs. el registro NXT para zamboni.

DNSSEC • Este sistema todavía no está implementado en el mundo real debido a que la infraestructura de llave pública necesaria aún no está lista .

impresoras. sistemas de archivos y otros • La forma de insertar las actualizaciones dinámicas de los registros no es estándar • MS utiliza una variación de las firmas de transacción llamada GSS-TSIG que también está basada en . DNS y Microsoft • En Windows 2000 se utiliza el registro SRV para descubrir todo: servidores de nombres.

DNS y Microsoft • El secreto compartido se obtiene a través de Kerberos desde el Kerberos KDC (Key Distribution Center) • El problema es que la implementación de Kerberos de MS no es compatible con Kerberos 5 • Esto obliga a tener un servidor Kerberos en Window para poder implementar estas opciones .

DNS y Microsoft • Cuando se liberó Win2k los servidores raíz del DNS mostraron un incremento significativo de peticiones • El problema es que los Win2k venían mal configurado e intentaban actualizar dinámicamente a los servidores raíz • Esto causó un serio problema con los servidores raíz que MS negaba .

DNS pruebas y depuración • Hay varias formas de depurar los archivos de configuración de named • Uno de ellos es especificar el nivel de depuración con rndc • Se le puede indicar a named que envíe sus estadísticas de operación a una bitácora y verificar las búsquedas con dig y nslookup .

DNS no severity respondidas tiene su propia La “maldad” decaracterística. un mensaje depero se apueden error. module pornombre El ejemplo. lo queescoger syslog las estándares se refiere como prioridad . un category archivo Una claseo /dev/null de mensajes que named puede generar. DNS pruebas y depuración Término Significado channel Es el lugar a donde irán los mensajes: syslog. dellos mensajes módulo sobre fuente quelas actualizaciones genera un mensaje facility dinámicas El nombre odelos unamensajes sobre las característica peticiones de syslog.

es decir los destinos posibles para los mensajes • Luego se definen las categorías de los mensajes que van a cada uno de los canales en particular . DNS pruebas y depuración • La forma de configurar las bitácoras es en el archivo named.conf • Primero se definen los canales.

se le asigna una categoría. un módulo y una severidad en su punto de origen • Cada canal tiene un filtro de severidad que indica qué tan severo tiene que ser un mensaje para ser registrado • Los canales que llevan a syslog también son filtrados de acuerdo con las reglas de syslog.conf . DNS pruebas y depuración • Cuando se genera un mensaje.

 …  category category_name {  channel_name.  …  }. }. DNS pruebas y depuración • Un esquema de la sentencia logging logging {  channel_def. .  channel_def.  channel_name.

DNS pruebas y depuración • Una definición de canal es ligeramente distinta dependiendo si el canal va a un archivo o al syslog • Se debe escoger entre file y syslog para cada canal • Un canal no puede estar con las dos opciones al mismo tiempo .

  severity severity.  .  print-severity yes | no. }.  print-time yes | no. DNS pruebas y depuración channel channel_name {  file ruta [versions numvers | unlimited] [size tamañoesperado].  print-category yes | no.  syslog facility.

048. DNS pruebas y depuración • Para un archivo numvers indica cuántas versiones de respaldo se deben mantener • tamañoesperado especifica qué tanto se va a permitir que crezca la bitácora. 20m. por ejemplo 2. default • En el caso de syslog. unlimited. 15g. 100k. facility especifica el nombre del recurso que se utilizará para registrar el mensaje • Puede ser cualquier recurso estándar • En la práctica sólo daemon y local0 a local7 son las opciones razonables .

con un nivel numérico opcional. DNS pruebas y depuración • El resto de las sentencias en un channel_def son opcionales • severity puede tener los valores. info o debug. error. critical. notice. como severity debug 3 • El valor dynamic también es reconocido y coincide con el nivel de depuración especificado . en orden descendiente. warning.

se pone default_stderr la severidad Envía a dynamic los mensajes a laconsola de error null estándar de named.run. DNS pruebas y depuración • Los cuatro canales en la tabla siguiente están predefinidos • Para la mayor parte de las instalaciones. estos canales están bien Nombre del canal Qué hace default_syslog Envía desde la severidad info y superiores al • default_debug syslog con la Registra hacia el archivo named. Descarta todos con severidad info los mensajes .

. }. DNS pruebas y depuración • Para BIND9 simplemente se puede escribir • • logging {  category default { default_syslog. }. default_debug.

DNS pruebas y depuración • Cada vez que haga cambios a BIND es conveniente revisar las bitácoras y quizá incrementar el nivel de depuración • Luego. reconfigurarlo para conservar únicamente los mensajes más serios. una vez que named está estable • .

Si se ve este mensaje sobre alguna de tus propias zonas. quiere decir que algo está mal configurado. El mensaje es relativamente inocuo si es sobre otra zona de Internet. porque es el problema de alguien más – Bad referral. DNS pruebas y depuración • A continuación se enlistan algunos mensajes comunes – Lame server. Este mensaje indica una incomunicación entre los servidores de nombres de la zona .

En el segundo caso. Un archivo de zona no tiene registros NS después del registro SOA. los registros no se . o que no comienzan con un tabulador o un espacio en blanco.DNS pruebas y depuración – Not authoritative for. o quizá el máster tiene problemas cargando la zona en cuestión – Rejected zone. Podría ser que no estuviesen esos registros. named rechazó un archivo de zona debido a que contiene errores – No NS RRs found. Probablemente se está apuntando al máster incorrecto. Un servidor esclavo no puede tener información con autoridad para una zona.

En Bind9 es requisito indispensable el $TTL por lo que named se rehúsa a cargar archivos de zona que no lo especifiquen . Este mensaje de error indica que el $TTL está perdido. DNS pruebas y depuración • No default TTL set. La forma preferida para poner un TTL por omisión es con una cláusula $TTL al principio del archivo de zona.

DNS pruebas y depuración • No root name server for class. Si no hay otro named por ahí. probablemente otra copia de named. El puerto en el cual named quiere ejecutarse ya está siendo utilizado por otro proceso. Revise su archivo de hints y la conectividad a Internet del servidor • Address already in use. probablemente se haya estrellado y haya dejado un socket de control del rndc abierto que tendrás que buscar y borrar . Su servidor tiene problemas para encontrar los servidores de nombre raíz.

htm http://www.com/askmrdns/bind-messages.jalix.acmebw.org/ressources/reseaux/misc/bind/~vrac/bind-messages. DNS pruebas y depuración • Una buena tabla de errores se puede encontrar en  http://www.ht    .

se obtendrá mayor información • El nivel 0 apaga los mensajes de depuración • Los niveles 1 y 2 están bien para depurar la configuración o la base de datos • Después del nivel 4 son para los programadores . DNS pruebas y depuración • Los niveles de depuración de named van desde el 0 hasta el 11 • Entre más grande sea el número.

esto cambia dependiendo del sistema operativo .run • Sin embargo. por ejemplo # named –d2 • Con esta opción se invoca named en nivel de depuración 2 • Por omisión la información de esta depuración se coloca en el archivo named. DNS pruebas y depuración • Se puede invocar named desde la línea de comandos con la bandera – d.

lo cual eleva dicho nivel en uno • rndc notrace apaga la depuración por completo • También se puede modificar el nivel de depuración habilitando un canal. por ejemplo  severity debug 3 . DNS pruebas y depuración • Se puede modificar el nivel de depuración sin necesidad de reiniciar named • Una forma de incrementar el nivel de depuración es con el comando rndc trace.

conf • Ejemplo /var/cache/bind . DNS pruebas y depuración • Depuración con rndc • El comando rndc es una herramienta muy útil para manipular named • Los comandos que producen archivos los depositan en el directorio especificado en named.

DNS pruebas y depuración Comandos de depuración con el rndc Comando Función help Enlista todos los comandos disponibles en rndc status Muestra el estado actual de la ejecución del named trace Incrementa el nivel de depuración en uno notrace Apaga la depuración dumpdb Vuelca la base de datos del DNS a named_dump.conf y los archivos de zona reload zone Recarga únicamente la zona especificada restart Reinicia named. eliminando el cache querylog Enciende y apaga el rastreo de las peticiones de entrada .stats reload Recarga named.db stats Vuelca las estadísticas en named.

DNS pruebas y depuración • rndc reload es análogo a enviarle a named una señal HUP.db • Este archivo es grande e incluye no sólo información local. sino también la . hace que named relea su archivo de configuración y el de sus zonas • rndc reload zona es muy útil en especial en los servidores de nombres con mucho trabajo porque sólo recarga la zona modificada • rndc dumpdb hace que named vuelque su base de datos a named_dump.

dig y host • Estas herramientas se pueden utilizar para hacer preguntas a la base de datos del DNS – nslookup es la más antigua – dig (domain information groper.Depuración con nslookup. buscador de información de dominio) – host permite revisar la sintáxis de los archivos de zona – .

pero host hace algunas cosas Órdenes para el únicas nslookup Instrucción  Función nombre Muestra información sobre el host o el nombre help o ? del dominio Muestra la lista completa de comandos exit Sale del programa server host Pone el servidor por omisión. usando el servidor Pone set type=xxx inicial Pone los tipos de registros a preguntar set debug (any=todos) Prende el modo de depuración set d2 Pone gran cantidad de información de ls dominio depuración Enlista todos los mapeos host/dirección . dig y host • En general suele ser mejor dig que nslookup. utiliza el servidor lserver host actualel servidor por omisión.Depuración con nslookup.

Depuración con nslookup. dig y host • Para instalar nslookup y dig en debian se hace lo siguiente •  aptitude install dnsutils .

cs.Depuración con nslookup. mx . otorga más información y su interfaz de usuario es mejor • Por ejemplo para preguntar por los registros MX de anchor se usa así  $ dig anchor. pero tiene valores por omisión mejor pensados.colorado. dig y host • dig básicamente provee la misma funcionalidad que nslookup.edu.

Depuración con nslookup.edu any • Obtiene los registros completos de vangogh del servidor berkeley. se hace así  dig -x 128.32.edu vangogh.33. dig y host • La instrucción  dig @ns1.berkeley.5 • Con lo que se hace la búsqueda inversa de esa dirección IP .edu • Para hacer búsquedas inversas.berkeley.

168.com nameserver = udns1.net.  Authoritative answers can be found from: amazon.net. Server: 192.com.226.131#53  Non-authoritative answer: amazon. dig y host debian:~# nslookup > set type=any > amazon.ultradns.ultradns.131 Address: 192. amazon.com nameserver = udns2.ultradns. amazon.226.net.net.com nameserver = udns1.Depuración con nslookup.com nameserver = udns2. > exit  .168.ultradns.

com.ultradns.131) .. ANSWER: 2. any .3.com. status: NOERROR.  . Depuración con nslookup. ANSWER SECTION: amazon. id: 14881 .net. 172725 IN NS udns2.. AUTHORITY: 2.com.. 172725 IN NS udns1.1 <<>> amazon. amazon.168.. ->>HEADER<<.. Query time: 6 msec . any  .. AUTHORITY SECTION: amazon.net.4-P1.ultradns..  .opcode: QUERY. SERVER: 192. dig y host  debian:~# dig amazon.com. Got answer: . global options: printcmd . IN ANY  .131#53(192.com.ultradns. QUESTION SECTION:  ..com. 172725 IN NS udns1.amazon. flags: qr rd ra. QUERY: 1. ADDITIONAL: 0   .. WHEN: Tue Nov 11 18:11:08 2008 .168..226.com.net.226. 172725 IN NS udns2.net.. MSG SIZE rcvd: 108 . amazon. <<>> DiG 9.ultradns.

Depuración con nslookup, dig y
host
• Dig da mucha información, su salida
incluye no sólo la información del
dominio sino también el número de
peticiones enviadas y el tiempo que
tomó tener la respuesta
• Además está formateado de tal
forma que puede ser utilizado para
crear un archivo de zona, esto es
particularmente útil si se está
preguntado por los servidores raíz
para generar el archivo de hints

Depuración con nslookup, dig y
host
• host muestra la información de
una forma simple y concreta,
aunque con la opción -v puede
mostrar más información

debian:~# host amazon.com.
amazon.com has address 72.21.203.1

amazon.com has address 72.21.206.5

amazon.com has address 72.21.210.11

amazon.com mail is handled by 10 smtp-fw-2101.amazon.com.

amazon.com mail is handled by 10 smtp-fw-4101.amazon.com.

amazon.com mail is handled by 10 smtp-fw-9101.amazon.com.

Delegaciones cojas
• Cuando se solicita un dominio, una
de las preguntas fundamentales es
qué máquina fungirá como servidor
de nombres
• Si nunca se utiliza el dominio o se
cambian los servidores de nombres
sin actualizar los registros de
pegamento del dominio, ocurre una
"delegación coja"

Delegaciones cojas
• Los efectos que puede ocasionar una
delegación coja pueden ser muy
malos
• Si un usuario intenta contactar a un
host en su dominio cojo, el servidor
de nombres rehusará la petición
• El DNS reintentará varios cientos de
veces la petición, golpeando tanto a
tu servidor de nombres como a los
servidores raíz
• En una bitácora de 3.5 Mb (a nivel info)
después de una semana, una tercera
parte eran delegaciones cojas

Delegaciones cojas
• De ellas, el 16% de las peticiones,
involucraban a los servidores raíz,
posiblemente por dominios no
existentes
• Un usuario persistente inquirió a los
servidores raíz por el dominio
tokyotopless.net cientos de veces,
por ejemplo
Jan 29 05:32:52 ipn.caida.org named[223]: Lame

server on 'www.games.net' (in 'GAMES.net'?):
[207.82.198.150].53 'NS2.EXODUS.net'

92 . www. 3600 A 209.pcworld. class = IN . ANSWERS: www.com.net. … .games. 3600 NS ns. 3600 NS ns2..exodus. games. type = A.net. Delegaciones cojas • Con dig... games. 3600 NS ns.net.net.exodus.net..games.net.net..23. QUESTIONS: . . AUTHORITY RECORDS: games.net. se puede ver el problema dig www.1.games.. . ADDITIONAL RECORDS: … .

pero ns2.net.exodus.games.net funciona bien cuando se le pregunta.net y una lista de servidores con autridad • El servidor que está en ns. Delegaciones cojas • La primera petición al servidor local regresa el registro de direcciones para www.exodus. es otra historia .

Delegaciones cojas dig @ns2. .GTLD-SERVERS. 244362 NS A.net.net.exodus.GTLD-SERVERS..net.net.games. • ns2 está enlistado como servidor de autoridad para el dominio. . class = IN . pero no regresa registro y nos refiere a los servidores net de alto nivel • Por lo tanto concluimos que ns2. 244362 NS K. net. www..GTLD-SERVERS.. net.. QUESTIONS: . net.net está configurado incorrectamente • .net. . AUTHORITY RECORDS: net.GTLD-SERVERS.net.games.net www. type = A.. 244362 NS J.. 244362 NS F.exodus.

BIND9 utiliza una lista de servidores root que están programados dentro de su código y de todas formas podrá cargarse la zona root . El archivo de hints • El archivo de hints alimenta al cache de named con información sobre los servidores del dominio root • Cuando se colocan los servidores root en el inicio del cache se mejora el proceso de búsqueda para todos los nombres • Si no se pone el archivo hints.

El archivo de hints • Los servidores de nombres root cambian de vez en cuando. pero es mucho más simple rastrearlos ahora de lo que era antes porque todos están asignados al dominio root-servers.net .

ns > root. El servidor máster es a. se puede utilizar dig. pero puede usarse cualquier otro  dig @a.net .cache .root-servers.cache • El punto es importante • Si a.net no responde se puede hacer la petición sin indicar un servidor en particular  dig .root-servers. ns > root.net. El archivo de hints • Para contactar al servidor de nombres root y generar un archivo de hints.root-servers.

El archivo de hints • Aún cuando el archivo sea similar. se está obteniendo a partir del cache del servidor de nombres local y no de una fuente con autoridad • Es buena idea refrescar un par de veces al año al archivo hints • El archivo hints funciona. al menos uno de los servidores root esté operando . siempre y cuando.

QUESTION SECTION:  .. .  IN NS . <<>> DiG 9..2. flags: qr aa rd.. @a. status: NOERROR.  .3 <<>> ns . .  518400 IN NS D. ANSWER SECTION:  ...net. ->>HEADER<<.  518400 IN NS C.  518400 IN NS A.NET.NET.opcode: QUERY.ROOT-SERVERS.root-servers.  .ROOT-SERVERS.. QUERY: 1. .NET.root   .. El archivo de hints debian:~# cat /etc/bind/db.ROOT-SERVERS.NET. ADDITIONAL: 13   . ANSWER: 13. Got answer:  .ROOT-SERVERS. global options:  printcmd . id: 18944  .  518400 IN NS B. AUTHORITY: 0.

0.148.4 B.  3600000 IN A 128.NET.41.  3600000 IN A 192.63.ROOT-SERVERS.NET.5.ROOT-SERVERS.203.NET.228.4.36.17 J.ROOT-SERVERS.NET.  3600000 IN A 128.  3600000 IN A 192.58.  3600000 IN A 192.90 E.NET.  3600000 IN A 198.NET.8.2.128.79.12 D.NET.ROOT-SERVERS.5.129 .  3600000 IN A 193.0.201 C. El archivo de hints  .230.30 K.10.4 H.  3600000 IN A 192.ROOT-SERVERS.ROOT-SERVERS.10 F.14.NET.241 G.NET.ROOT-SERVERS.36. ADDITIONAL SECTION:  A.33.ROOT-SERVERS.NET.  3600000 IN A 192.  3600000 IN A 192.112.ROOT-SERVERS.53 I.  3600000 IN A 192..ROOT-SERVERS.ROOT-SERVERS.NET.

nic.mil/domain/named. para el cual aplican los registros NS • Un archivo de hints actualizado puede obtenerse de  ftp://ftp. puesto que definen al dominio root.root . El archivo de hints • Observe que un punto inicia al primer conjunto de registros.

La configuración de localhost • El mapeo directo para el nombre localhost o localhost. cada servidor es amo de su propio dominio inverso de localhost .dominio se hace en el archivo directo de zona para el dominio • Normalmente.

Refresh  86400 . Retry  2419200 .localhost. $TTL 604800 @ IN SOA localhost. @ IN NS localhost. root. Serial  604800 . BIND data file for local loopback interface .1  . . Negative Cache TTL . (  1 .0. el archivo de zona es el siguiente debian:/etc/bind# cat /etc/bind/db. @ IN A 127.0. La configuración de localhost • En debian.local . Expire  604800 ) .

La configuración de localhost • El mapeo inverso para la dirección del localhost. por lo tanto. los tiempos de expiración pueden ser muy grandes  . 127.0.0.1 nunca cambia.

Retry  2419200 . BIND reverse data file for local loopback interface . root.localhost.0. 1.0 IN PTR localhost.127 . . @ IN NS localhost. $TTL 604800 @ IN SOA localhost. Serial  604800 . Negative Cache TTL . Expire  604800 ) . Refresh  86400 . La configuración de localhost • En debian el archivo es el siguiente debian:/etc/bind# cat /etc/bind/db. . (  1 .

" • Es necesario asegurarse que el mapa inverso de 127.0.0. La configuración de localhost • Observe que sólo está enlistado el servidor local • El significado de @ en este contexto es "0.127.in-addr.0.domain" y no solamente a "localhost" • Esto es porque los servidores raíz reciben muchas peticiones para "localhost" .arpa.1 lo haga hacia "localhost.