DNS

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)
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)
DNS
• Por razones históricas hay dos tipos
de nombres de dominio de alto
nivel
• En los Estados Unidos, los dominios
de alto nivel describen la estructura
política y organizacional con tres
letras, como .com y .edu. Algunos
de estos dominios, como .com, .org
y .net también se usan fuera de los
EEUU, a estos les llamamos los
dominios de alto nivel genérico o
gTLD
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
DNS
• Para otros países, 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
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, pero
en el Reino Unido y en Japón es ac,
ac.uk y ac.jp respectivamente
• El dominio de alto nivel us a veces se
utiliza para los Estados Unidos
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, por ejemplo
boulder.colorado.edu. La carencia
del punto final indica una dirección
relativa
Registro de un nombre en
México
http://www.nic.mx
Registro de un dominio
dinámico
http://www.dyndns.com
BIND, 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, 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
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, obtiene su información de un
archivo en el disco
slave (esclavo) Copia su información desde el master
stub Similar al esclavo, 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, 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, usualmente no tiene zonas locales
forwarder Hace peticiones a nombre de muchos clientes, 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

¿Cómo funciona el DNS?
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, correcta, 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
• Por mucho tiempo, no se podían poner
en el cache las respuestas negativas,
sólo las negativas, 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.in-
addr.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
• 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, los
demás sólo por 5 minutos. Las respuestas
sin autoridad podrían ser puestas en el
cache, las respuestas con autoridad
negativas deben ser puestas en el cache
• Con frecuencia, named recibe varios
registros de DNS en respuesta a una
pregunta, por ejemplo si se solicitan los
nombres de los servidores del dominio
raíz, la respuesta serán 13 servidores raíz,
¿Cuál debería ser el servidor adecuado
para preguntar?
• Cuando named deba escoger entre varios
servidores remotos, todos ellos con
autoridad sobre el dominio, primero se
determina el RTT Round Trip Time o
tiempo de viaje de red para cada servidor.
Luego se ordenan los servidores en
“cubetas” de acuerdo con su RTT y se
selecciona un servidor de la “cubeta” más
rápida. Los servidores dentro de una
• Se puede hacer una forma de
balanceo de carga primitiva, pero
efectiva, asignando un solo
hostname a varias direcciones IP
(que en realidad sean distintas
máquinas)

www
 IN A 192.168.0.1
 IN A 192.168.0.2
 IN A 192.168.0.3
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
• El problema es que el tamaño máximo
garantizado para las
implementaciones UDP es de 512
bytes, 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,
para hacer que toda la información de
los servidores raíz quepa en un
paquete UDP de 512 bytes, sólo hay
13 servidores raíz, cada uno con un
nombre limitado a una letra del
• Muchos clientes lanzan una pregunta
UDP primero y luego, si la
respuesta está truncada, vuelven a
hacer la pregunta por TCP, 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, puesto
que las conexiones TCP son más
caras
• Una pregunta/respuesta típica puede
ser tan breve como dos paquetes
UDP, el de pregunta y el de
respuesta
• Un intercambio TCP involucra al
menos siete paquetes, un
handshake de tres vías para iniciar
la conversación, una pregunta, una
respuesta, y un handshake final
para cerrar la conexión
• A finales de la década de los 90, el
EDNS0 (Extended DNS versión 0)
resolvió algunas de estas
limitaciones del protocolo DNS
• Permite el reensamble del tamaño
del buffer, opciones soportadas y
protocolos hablados
• Si el servidor de nombres receptor
contesta con un mensaje de error,
el remitente regresa al protocolo
DNS original. BIND9 implementa
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
Configuración del
resolvedor
• Cada host de la red debe tener un
archivo llamado /etc/resolv.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, el archivo /etc/resolv.conf debe
ponerse automáticamente, de otra
forma, se puede editar a mano, el
formato es
 search nombrededominio
 nameserver direcciónip
Configuración del
resolvedor
• Se pueden enlistar hasta tres servidores
de nombres, como en este ejemplo
 search cs.colorado.edu colorado.edu
ee.colorado.edu
 nameserver 128.138.243.151 ; ns
 nameserver 128.138.204.4 ; piper
 nameserver 128.138.240.1 ; anchor
• S ih a y a lg u n a o tra co sa e n e se a rch ivo ,
sim p le m e n te se ig n o ra , 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 , 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
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, si el usuario
hace un ssh foo, el resolvedor
completará el nombre con el primer
dominio de la lista de búsqueda, en
este caso, buscará
foo.cs.colorado.edu, si no lo
encuentra probará también con
foo.colorado.edu y
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 . co n f deben ser recursivos , 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,
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. C a d a se rvid o r se p ru e b a p o r
tu rn o s, h a sta cu a tro ve ce s. 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
Configuración del
resolvedor
• Muchos resolvedores permiten un
máximo de tres servidores de
nombres enlistados, si hay más,
simplemente se ignoran
silenciosamente
• Si un host es por sí mismo un
servidor de nombres, debe ser
enlistado al principio en su propio
archivo resolv.conf
•
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.conf para propagar la
carga entre los servidores, para
minimizar el tráfico de red y reducir la
vulnerabilidad de las máquinas a un
solo punto de falla, porque si el
servidor de nombres falla, todo el sitio
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
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, de tal forma que
ninguno de los dos grupos se sobrecargue
• También se muestra el uso de un servidor
esclavo fuera del sitio, que se recomienda
ampliamente si se puede conseguir que
Configuración del
resolvedor
Pruebas para el resolvedor
• En algunos sistemas, para usar un
DNS basta con agregar la línea
nameserver al archivo
/etc/resolv.conf
• En otros, 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
Pruebas para el resolvedor
• Después de configurar el
/etc/resolv.conf, y suponiendo que
todo funciona bien en la red, 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, intenta verla a
través de su dirección IP, si eso
funciona, es que la configuración
del DNS tiene algún problema
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, 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
nombres
• BIND son las siglas de Berkeley
Internet Name Domain (Nombres
de dominio de Internet, 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

nombres
• Los archivos de configuración se
encuentran en
 /etc/bind
• Los archivos de configuración
relevantes son
 /etc/bind/named.conf
 /etc/bind/named.conf.local
 /etc/bind/named.conf.options
 que, en otras distribuciones son uno
solo.
nombres
cat /etc/bind/named.conf

// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the

// structure of BIND configuration files in Debian, *BEFORE* you customize
// this configuration file.
//
// If you are just adding zones, please do that in

/etc/bind/named.conf.local

include "/etc/bind/named.conf.options";

// prime the server with knowledge of the root servers

zone "." {
 type hint;
 file "/etc/bind/db.root";
};

nombres
// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912

zone "localhost" {
 type master;
 file "/etc/bind/db.local";
};

zone "127.in-addr.arpa" {
 type master;
 file "/etc/bind/db.127";
};

 type master;
 file "/etc/bind/db.0";
};

 type master;
nombres
cat /etc/bind/named.conf.options

options {

 directory "/var/cache/bind";

 // If there is a firewall between you and nameservers you want
 // to talk to, you might need to uncomment the query-source
 // directive below. Previous versions of BIND always asked
 // questions using port 53, but BIND 8.1 and later use an unprivileged
 // port by default.

 // query-source address * port 53;

 // If your ISP provided one or more IP addresses for stable
 // nameservers, you probably want to use them as forwarders.
Instrucciones del
named.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- 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
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.165.145.4)
– Una red IP especificada con una
máscara CIDR (por ejemplo
199.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
• Ejemplos de listas
– { ! 1.2.3.13; 1.2.3/24; };
– { 128.138/16; 198.11.16/24; 204.228.69/24;
127.0.0.1; };
• Cuando una dirección IP o una red es
comparada con la lista de coincidencias,
la lista se busca en orden hasta que exista
la coincidencia, este algoritmo de “primer
encuentro” hace que el orden de la lista
sea importante
• Por ejemplo, en la primera lista, si
estuvieran al revés las entradas, no se
tendría el efecto deseado, porque nunca
se alcanzaría la dirección 1.2.3.13 y nunca
se encontraría la entrada negada
Instrucciones del named.conf
include
• Para organizar mejor un DNS es
posible poner diferentes porciones
de configuración en distintos
archivos, tal y como se hace en
Debian
• Para incluir un archivo se escribe, por
ejemplo
 include "/etc/bind/named.conf.options";
• Nota: la trayectoria es relativa, por
eso es necesario poner las / para
especificarla precisamente
options
• La sentencia options especifica las
opciones globales, algunas de las
cuales pueden ser sobreescritas
para algunas zonas o servidores en
particular, el formato general es
 options {
 opción;
 opción;
 …
 };
options
• En el caso de Debian, las opciones
globales preconfiguradas son las
siguientes
 options {
 directory "/var/cache/bind";
 auth-nxdomainno; #
conform to #
RFC1035
 listen-on-v6 { any; };
 };
options
• En BIND9 hay más de 50 opciones
que se pueden consultar en el
manual
• http://www.bind9.net/manuals
• http://www.bind9.net/manual/bind/9.3.2/
• http://www.zytrax.com/books/dns/ch7/sta
•
options
• Los valores por omisión se enlistan en
corchetes cuadrados al final de la
opción, por ejemplo

 version “cadena de texto”; [número de versión real del servidor]

• Hay dos formas de ver el mundo, los que

creen que los hackers, con el número de
versión pueden atacar mejor, o los que
consideran que enmascarando las cosas
no se resuelve nada porque de todas
formas los hackers probarán con las
últimas vulnerabilidades
options
• La instrucción directory hace que
named busque todos los archivos
incluidos en el directorio
especificado y, a partir de ahí haga
sus búsquedas relativas. Debe ser
una ruta absoluta, los archivos de
salida también irán dentro de este
directorio
•
directory “ruta”; [directorio en donde inicia el servidor]

options
• Si la opción notify se pone
afirmativa, y este es un servidor
master para una más zonas, named
notifica automáticamente a todos
los esclavos cuando haya cambios
en la base de datos. Esto provoca
que los archivos de zona converjan
más rápido cuando se hacen
cambios
 notify yes | no; [yes]
 also-notify servers_ipaddrs; [vacío]
options
• La opción recursion especifica si el
named preguntará a otros
servidores de nombres a nombre
de sus clientes, es muy raro que
haya servidores con esta opción
deshabilitada, sin embargo, se
puede habilitar la recursión sólo
para los clientes propios y no para
los externos
 recursion yes | no; [yes]
 allow-recursion { lista }; [todos los hosts]
acl
• Una lista de control de acceso es sólo
una lista de direcciones
 acl nombre_de_la_acl {
 lista_de_direcciones_coincidentes;
 };
• H a y cu a tro lista s p re d e fin id a s: any,
localnets, localhost y none, que
co in cid e n co n cu a lq u ie r m á q u in a ,
to d a s la s m á q u in a s d e la re d lo ca l,
la m á q u in a e n sim ism a y n a d a ,
re sp e ctiva m e n te
server
• named puede hablar con varios
servidores, algunos de los cuales
pueden hablar otras versiones de
BIND, la instrucción server indica las
características de sus pares remotos
server ip_addr {
 bogus yes | no; [no]
 provide-ixfr yes | no; [yes (V9 only)]
 request-ixfr yes | no; [yes (V9 only)]
 support-ixfr yes | no; [no (V8 only)]
 transfers number; [2 (V9 only)]
 transfer-format one-answer| many-answers;
[v8:1,v9:n]
 keys { key-id; key-id; };
}
zone
• Las instrucciones de zona son el
corazón de los archivos 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
zone
zone “nombre_de_dominio” {
 type master;
 file “ruta”;
 allow-query { lista_de_dirs; } [all]
 allow-transfer { lista_de_dirs; }
[all]
 allow-update { lista_de_dirs; } [none]
 ixfr-base “ruta”; [v8 only]
};
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
zone
zone “ejemplo.com” {
 type master;
 file “forward/ejemplo.com”;
 allow-query { any; }
 allow-transfer { mis-
esclavos;}
};

zone
• Configuración de un servidor esclavo
para una zona
 type slave | stub;
 ixfr-base “ruta”; [v8 only]
 masters { ip_addr; ip_addr; … } [no
default]
 allow-query { lista_de_dirs; } [all]
 allow-transfer { lista_de_dirs; } [all]
};

zone
• Poniendo los servidores raíz (root hints)
 zone “.” {
 type hint;
 };
• Los “hints” son el conjunto de los registros
DNS que enlista los servidores del dominio
raíz (“.”). 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.cache
•
zone
• Instalando una zona de forwarding
 type forward;
 forward only | first;
 forwarders { ip_addr; … }
 };

•
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;
 secret cadena;
 };

trusted-keys
• La instrucción trusted-keys se utiliza
para la seguridad con protocolo
DNSSEC, cada entrada es una tupla-5
que identifica el nombre el dominio,
las banderas, el protocolo, 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;
 domain flags protocol algorithm key;
 …
 };
controls
• Permite el control del servidor a
través de la utilería ndc

controls {
 inet ip_addr port port# allow { lista_dirs | key
… };
 unix permission owner group; [0600 0 0]
};
Ejemplo de configuración de
BIND en
una máquina linux casera
• En una red casera, podríamos instalar
una pequeña red privada, por ejemplo
con la dirección de red siguiente
 192.168.77.0/24
 y con el dominio
 guarida.dyndns.org
• Se necesitan dos archivos, el de
búsqueda directa (forward) y el de
búsqueda inversa (reverse) y
modificar el /etc/bind/named.conf
para que se resuelvan las dos zonas
BIND en
• Modificación del /etc/bind/named.conf

zone “guarida.dyndns.org” {
 type master;
 file “guarida.dyndns.org.zone”;
};
zone “77.168.192.in-addr.arpa” {
 type master;
 file “77.168.192.in-
addr.arpa.zone”;
};
BIND en
• El archivo “guarida.dyndns.org.zone”
 ; guarida.dyndns.org.zone
@ IN SOA ns.guarida.dyndns.org. root.guarida.dyndns.org. (
 2009100201 ; Serie
 21600 ; Refresco 6 horas
 1800 ; Reintentar, 30 min
 1209600 ; Expiración 2 semanas
 432000 ) ; Mínimo 5 días
 IN NS ns
 IN MX 10 ns
ns IN A 192.168.77.254
m1 IN A 192.168.77.1
...
m253 IN A 192.168.77.253


BIND en
• El archivo “77.168.192.in-
addr.arpa.zone”
; 77.168.192.in-addr.arpa.zone
@ IN SOA ns.guarida.dyndns.org. root.guarida.dyndns.org. (
 2009100201 ; Serie
 432000 ) ; Mínimo 5 días
 IN NS ns
254 IN PTR ns.guarida.dyndns.org.
1 IN PTR m1.guarida.dyndns.org.
...

BIND en
• Reiniciar el servidor de nombres
• /etc/init.d/bind9 restart
• Probar el servidor de nombres
– nslookup
– dig
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
• Contienen dos tipos de entradas: los
comandos de parseo (cosas como
$ORIGIN y $TTL) y los “registros de
recursos”, o RRs
• Sólo los RRs son parte de la base de
datos, los comandos de parseo sólo
dan algunos atajos para poner
registros
•
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
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
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
El registro SOA
• Un registro SOA marca el inicio de
una zona, 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
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
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
El registro SOA
 ; Inicio del registro de autoridad para cch.unam.mx
@ IN SOA ns.cch.unam.mx. root.cch.unam.mx.(
 2009100201 ; Serie
 432000 ) ; Mínimo 5 días

El registro SOA
• Aquí, 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.unam.mx” en lugar de la @
• El valor de @ es el nombre del dominio
especificado en la instrucción zone
del archivo named.conf; puede ser
cambiado dentro del archivo de zona
con la directiva $ORIGIN
El registro SOA
• Este ejemplo no tiene el campo TTL. La
clase es IN, abreviatura de Internet, el
tipo es SOA y los demás elementos
forman el campo de datos
• “ns.cch.unam.mx” es el nombre el
servidor máster de nombres de la
zona
• “admin.cch.unam.mx” es la dirección
de correo del contacto técnico en
formato “usuario.host”, en vez del
estándar usuario@host. Basta con
reemplazar el primer punto por una
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
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,
corregir el número de serie en el
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
El registro SOA
• Las cuatro entradas siguientes del
registro SOA son los valores de
expiración temporal, 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
El registro SOA
• El primero es el timeout refresh, 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
El registro SOA
• En vez de esperar pasivamente a
que los esclavos esperen al
timeout, 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
El registro SOA
• Si un esclavo intenta revisar el
número de serie del máster, pero el
máster no responde, el esclavo
intenta de nuevo después de que
haya concluido el periodo de
reintento, retry
• Por experiencia, se sugiere que sea
de entre 20 y 60 minutos (1,200-
3,600)
•
El registro SOA
• Si un servidor de nombres está caído
por mucho tiempo, los esclavos
fallarán cada vez que intenten
refrescarse, 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.
• Se recomienda una expiración de entre
El registro SOA
• Antes de la versión 8.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.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
El registro SOA
• Los parámetros $TTL, 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
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
Los registros NS
• El formato es
 zona [TTL] IN NS hostname
• Por ejemplo

cs.colorado.edu. IN NS ns.cs.colorado.edu.
cs.colorado.edu. IN NS anchor.cs.colorado.edu.
cs.colorado.edu. IN NS ns.cs.utah.edu.
• Puesto que el nombre e la zona es el mismo que el

campo nombre del registro SOA que precede a esos
registros, se puede quedar en blanco, así las
siguientes líneas son equivalentes
 IN NS ns.cs.colorado.edu.
 IN NS anchor.cs.colorado.edu.
 IN NS ns.cs.utah.edu.
Los registros NS
• Cada nombre de servidor con
autoridad para cs.colorado.edu
debe estar enlistado tanto en el
archivo de zona para
cs.colorado.edu como en el archivo
de zona padre colorado.edu
• Los servidores de cache puro no
pueden tener autoridad, por ello no
se enlistan
• Si no hay parámetros en el registro
NS se supondrá que el servidor es
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
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
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

Los registros A
• El formato es
 hostname [TTL] INA ipaddr
• Por ejemplo
 anchor INA 128.138.243.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
Los registros PTR
• Los registros PTR (Pointer,
apuntador) sirven para hacer la
resolución inversa de nombres, 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
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.138.128.in-addr.arpa. que
corresponde al registro A de la
máquina anchor es
 100 IN PTR anchor.cs.colorado.edu.
• El nombre 100 no termina con un punto
y por lo tanto es relativo al dominio
243.138.128.in-addr.arpa. (indicado
Los registros PTR
• Se puede poner el dominio colocando
los registros PTR para cada subred
en su propio archivo, como en el
ejemplo anterior
• Otra forma de hacer mapeos
inversos es incluir registros tales
como
 100.243 IN PTR anchor.cs.colorado.edu.
• Con un dominio por omisión de
138.128.in-addr.arpa.
El dominio in-addr.arpa.
• Los dominios completamente
calificados pueden ser vistos como
una notación en la cual la parte “más
significativa” está del lado derecho,
por ejemplo, en el nombre
anchor.cs.colorado.edu, anchor está
en cs y cs está en colorado y colorado
está en edu
• Las direcciones IP, por otra parte,
tienen la parte “más significativa” del
lado izquierdo. En la dirección
128.138.243.100, es el host 100 en la
El dominio in-addr.arpa.
• El dominio in-addr.arpa. 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, así como de
los nombres poder llegar a las
direcciones IP
• Los dominios bajo in-addr.arpa. se
nombran como direcciones IP con sus
bytes al revés, por ejemplo, la zona
para nuestra subred 243 es
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.edu. termina
con un punto para evitar que
138.128.in-addr.arpa. sea agregado
al final del nombre
Los registros PTR
• Puesto que cs.colorado.edu y
243.138.128.in-addr.arpa son
distintas regiones del espacio de
nombres del DNS, ellos constituyen
dos zonas distintas
• Cada zona debe tener su propio SOA
y sus RRs
• Además de definir una zona in-
addr.arpa para cada red real, es
necesaria una zona que se haga
Los registros PTR
• Esta técnica funciona bien si las
subredes están dentro de los
límites a nivel byte, pero si se
necesita definir una subred tal
como 128.138.243.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
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, por nombre, en el
archivo ~/.shosts del usuario
Los registros PTR
• Cuando el host destino recibe una
petición de conexión, 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, el cual se comparará con el
archivo apropiado
• Los programas netstat, tcpd,
sendmail, sshd, X Window, syslogd,
fingerd, ftpd y rlogind hacen los
mapeos inversos para obtener los
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
Los registros MX
• El formato de un registro MX es
 nombre [ttl] IN MX preferencia host …
• A continuación se muestran dos
ejemplos, 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.colorado.edu.
xterm1 IN MX 10 mailhub
 IN MX 20 anchor
•
Los registros MX
• Los hosts con menor preferencia se
intentan primero: 0 es el más
deseable y 65,535 es el peor
• En este ejemplo el correo enviado a
bob@xterm1 se enviaría primero a
mailhub si está accesible, a anchor
como segunda opción y si mailhub y
anchor están caidos, a boulder
• Observe que el nombre boulder debe
estar completamente calificado
porque no es parte del dominio por
omisión, que aquí es cs.colorado.edu.
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
Los registros MX
• En el primer caso, 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,
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.cs.colorado.edu.
 IN MX 20 anchor.cs.colorado.edu.
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
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

Los registros CNAME
• Cuando el DNS encuentra un registro
que tiene un CNAME detiene la
búsqueda y trata de encontrar el
nombre real, uno que tenga un
registro A
• Cada nombre que tenga CNAME debe
tener un nombre real con un
registro A
•
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
Los registros CNAME
• También existe el truco inverso, un
solo servidor web para varios sitios
distintos
www IN A 132.248.29.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 , 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
El truco del CNAME
• Cuando hay redes que no están
divididas en los límites de byte, 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.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
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 primer cuarto de
las direcciones tendrían un
componente “0-63”, el segundo
El truco del CNAME
$ORIGIN 243.138.128.in-addr.arpa.
1 IN CNAME 1.0-63
2 IN CNAME 2.0-63
…
63 IN CNAME 63.0-63

64 IN CNAME 64.64-127
65 IN CNAME 65.64-127
…
El truco del CNAME
• Para delegar el bloque 0-63 de la zona
inversa al subdominio, se deben agregar
los siguientes registros NS
0-63 IN NS ns1.cliente1.com.
0-63 IN NS ns2.cliente1.com.
...
• El sitio que maneje la subred deberá tener

un archivo de zona que contenga los
mapeos inversos de la zona 0-
63.243.138.128.in-addr.arpa.
1 IN PTR host1.cliente1.com.
2 IN PTR host2.cliente1.com.
...

El truco del CNAME
• Cuando se agrega este componente
extra, se crea un “corte” que hace
la delegación
• Cuando alguien busca el mapeo
inverso para 128.138.243.1, por
ejemplo, el registro CNAME en
1.243.138.128.in-addr.arpa redirige
la búsqueda al nombre 1.0-
63.243.138.128.in-addr.arpa y ese
nombre es controlado por el cliente
El truco del CNAME
• Los archivos del cliente son bastante
limpios, 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, pero eso está bien
porque en BIND se pueden
encadenar hasta 8 niveles de
El truco del CNAME
• En las nuevas versiones de BIND hay
una instrucción nueva, $GENERATE
que facilita la creación de registros
de recursos en la zona padre
• Por ejemplo para producir los
registros de la primera subred,
basta con las siguientes líneas
$ORIGIN 243.138.128.in-addr.arpa.
$GENERATE 0-63 $ CNAME $.0-63
0-63 NS ns1.cliente1.com.
0-63 NS ns2.cliente1.com.
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
Revisita de ejemplos
 root@u804:/var/cache/bind# cat guarida.dyndns.org.zone
; guarida.dyndns.org.zone
$TTL 3600
@ IN SOA ns.guarida.dyndns.org.
root.guarida.dyndns.org. (
 2009100202 ; Serie
 300 ) ; Reverse cache expiration
5min
 IN NS ns
 IN MX 10 ns
ns IN A 192.168.226.129
m1 IN A 192.168.226.1
gateway IN A 192.168.226.2
$GENERATE 3-128 m$ IN A 192.168.226.$
$GENERATE 130-254 m$ IN A 192.168.226.$

 root@u804:/var/cache/bind# cat 226.168.192.in-addr.arpa.zone
; 226.168.192.in-addr.arpa.zone
$TTL 3600
@ IN SOA ns.guarida.dyndns.org.
root.guarida.dyndns.org. (
 2009100204 ; Serie
 3600 ) ; cache inverso 1hr
 IN NS ns.guarida.dyndns.org.
2 IN PTR gateway.guarida.dyndns.org.
$GENERATE 3-128 $ IN PTR m$.guarida.dyndns.org.
129 IN PTR ns.guarida.dyndns.org.

$GENERATE 130-254 $ IN PTR m$.guarida.dyndns.org.
root@u804:/var/cache/bind# cat /etc/bind/named.conf.local
//
// Do any local configuration here
//
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";
 zone "guarida.dyndns.org" {
 type master;
 file "guarida.dyndns.org.zone";
};
 zone "226.168.192.in-addr.arpa" {
 type master;
 file "226.168.192.in-addr.arpa.zone";
};
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
$ORIGIN
• En condiciones normales, 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.conf

$ORIGIN
• El comando $ORIGIN permite poner
el origen de forma manual
• Por ejemplo, para los registros
inversos para una subred de clase
B se puede poner con una
instrucción como la siguiente
 $ORIGIN 243.138.128.in-addr.arpa.
•
$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, para separar las partes
lógicas de un archivo de zona o
para mantener las llaves
criptográficas en un archivo con
permisos restringidos
$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
$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
•
$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
$GENERATE
• El valor del iterador se incorpora
dentro del lhs y el rhs con el
caracter $
• También se puede especificar un
paso, 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, por el
momento sólo se acepta en
CNAME, PTR y NS
La zona localhost
• La dirección 127.0.0.1 se refiere a el
host en si mismo y siempre puede
ser mapeado al nombre
localhost.localdomain por ejemplo
localhost.cch.unam.mx
• Algunos sitios mapean la dirección
simplemente como localhost, como
si fuera parte del dominio root, esta
configuración es incorrecta
La zona localhost
• Si se olvida de configurar la zona
localhost, 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.0.1 a nivel root
La configuración de la zona
•
localhost
El mapeo directo para el nombre localhost o localhost.dominio se
hace en el archivo directo de la zona para el dominio.
• Sin embargo, cada servidor normalmente es el máster de su
propio dominio inverso
•
@
 IN SOA cch.unam.mx. root.cch.unam.mx. (
 2008101401 ; número de serie
 3600 ; refresco
 900 ; reintento
 3600000 ; expiración
 14400 ) ; mínimo
 IN NS cch.unam.mx.
1
 IN PTR localhost.cch.unam.mx.

• El mapeo inverso para la dirección del localhost, 127.0.0.1 nunca

cambia por lo que los timeouts pueden ser grandes
• En este caso @ significa 0.0.127.in-addr.arpa.
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
enlaces entre zonas
• Hay dos formas de cumplir este
requisito
– Incluyendo los registros necesarios
– Utilizar zonas tocón (stub)
enlaces entre zonas
• En el primer método se incluyen los
registros NS y A que sean necesarios en la
zona padre (colorado.edu)
; información de subdominio
cs IN NS ns.cs.colorado.edu.
 IN NS piper.cs.colorado.edu.
 IN NS ns.xor.com.
ee IN NS ns.ee.colorado.edu.
 IN NS ns.cs.colorado.edu.
; registros pegamento
ns.cs IN A 128.138.243.151
piper.cs IN A 128.138.204.4

ns.ee IN A 128.138.200.1
enlaces entre zonas
• Ejemplo en la UNAM
• En el archivo named.conf del
servidor de nombres que resuelve
la zona “unam.mx” se escribe

; cch.unam.mx es el subdominio a delegar

cch IN NS ns.cch.unam.mx.
ns.cch IN A 132.248.122.1
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, se dejará
parte del espacio de nombres
inaccesible, los usuarios que intenten
llegar a ellos obtendrán errores “host
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 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,
pero si hay cambios en xor.com,
podría ocasionar fallas
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
enlaces entre zonas
• El esquema recién descrito es la forma
estándar de conectar zonas, 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, 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, este
tipo de configuración, con frecuencia, 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, 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
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, luego se
escoge uno y se ejecuta
 dig @servidor-de-nombres dominio-padre dominio-hijo ns
 para ver tu lista de servidores de
Sutilezas de las zonas stub
• Las zonas stub no son copias con autoridad
sobre la información de la zona, los
servidores stub no deben estar enlistados
entre los registros de zona NS
• Como no están enlistados en los registros
NS, no serán notificados cuando cambie la
información de la zona. Para actualizarlos,
se puede añadir una cláusula also-notify a
la configuración de los servidores máster ,
o simplemente esperar a que la zona se
actualice hacia el final del intervalo de
refresco especificado en el registro SOA
de la zona. La opción timeout debería
funcionar bien en la mayor parte de los
casos, pero podría resultar en una
delegación coja transitoria en algunos
Actualización de archivos de
zona
• Cuando se hace un cambio a un dominio,
como puede ser agregar o borrar un host,
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,
también se puede matar y reiniciar
named con ndc restart, o
/etc/init.d/bind9 restart, pero esta
operación causa que se pierdan los datos
recopilados en el cache
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, 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, se
puede utilizar ndc reload en el
esclavo, para que revise si hubo
cambios en su máster y, si los hay,
solicita una transferencia de zona
zona
• Cuando se actualice una zona, no
olvides modificar los registros directos
e inversos
• Si se olvida la modificación de un
registro inverso, 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, los
cambios funcionarán en el servidor
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, por
ejemplo, cuando olvidamos poner
un punto no es fácil verlo en el
servidor máster, pero si en el
esclavo, porque ahí aparecerá
completo
 foo.cs.colorado.edu.cs.colorado.edu
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, la forma en
que se refieren estas transferencias
es AXFR y IXFR, respectivamente
• 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”
• 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, sólo
después de que haya terminado la
transferencia, es cuando el servidor
tendrá la nueva información
• Cuando las zonas son muy grandes,
como la .com, 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
• 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. La opción request-ixfr
hace las peticiones IXFR para las
zonas para las cuales este servidor
es esclavo
• Las instrucciones para los archivos
de configuración son las siguientes
provide-ixfr yes; # en la sentencia server
request-ixfr yes; # en la sentencia server

• 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";
};
• 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
'upn.mx/IN' from 200.23.113.1#53: failed
while receiving responses: REFUSED
'upn.mx/IN' from 200.23.113.1#53: end of
transfer
• 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.
'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
'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
• 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
• Las últimas versiones de DHCP y BIND
permiten que, 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, borrar o modificar los
registros de recursos
• Puesto que es un poco espantoso que
se actualice el DNS con esa
frecuencia, se recomienda para estos
casos utilizar un subdominio
Seguridad en el DNS
• El DNS se concibió como un sistema
abierto
• En condiciones normales, cualquiera
puede explorar un dominio con
peticiones individuales con las
herramientas dig, host o
nslookup, e incluso obtener la
base de datos completa del
dominio
• Las versiones nuevas de BIND
Seguridad en el DNS
Característic Sentencias Qué especifica
a
allow-query options, Quién puede preguntar una zona o un
allow- zone
options, 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
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, por
supuesto el soporte completo de
DNSSEC
• 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
• 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/8; // por omisión, direcciones comodín
 169.254.0.0/16; // direcciones delegadas de enlace local
 192.0.2.0/24; // direcciones de muestra como
example.com
 224.0.0.0/3; // espacio de direcciones multicast
 10.0.0.0/8; // espacio de direcciones privado (RFC1918)
 172.16.0.0/12; // espacio de direcciones privado
(RFC1918)
 192.168.0.0/16; // espacio de direcciones privado
(RFC1918)
};
acl cunets { // ACL para las redes de la Universidad de

Colorado
 128.138.0.0/16; // La red principal del campus
 198.11.16/24;
• 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. Estas máquinas
simplemente se asignan a sí mismas una
dirección en la red 169.254.0.0/16. Las
direcciones que estén en ese intervalo
deberían ser agresivamente filtradas de
tal forma que nunca escapen del cableado
local. 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
• En la sección de options global del
archivo de configuración, también
se podría incluir
 allow-recursion { cunets; };
 blackhole { bogusnets; };
• También es una buena idea restringir las trasferencias
de zona a los servidores esclavos legítimos. Un ACL
que hace las cosas bonitas y sencillas sería el
mostrado a continuación
acl misesclavos {
 128.138.242.1; // ancla
…
};
acl mediciones {
 128.9.160.157; // mediciones de Bill Manning

 198.32.4.0/24; // mediciones de Bill Manning
 192.5.5.0/24; // mediciones de Mark Lottors
};
allow-transfer { misesclavos; mediciones; };

• 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, es imposible que otros sitios
obtengan la base de datos completa
• Ahora sucederá lo siguiente
% nslookup
Default Server: server-name
Address: server-IP-address
> ls cs.colorado.edu.
[server name]
*** Can’t list domain cs.colorado.edu: Unespecified error

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
• 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
• 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
• 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
• 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í
• Desde el punto de vista
computacional, el sistema de
criptografía de TSIG es mucho
menos caro que el uso de
criptografía de llave pública, 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
• TSIG también firma las peticiones y
respuestas de DNS
• Sólo puede ser utilizado entre
servidores, 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
• 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.private
• E la rch ivo co n tie n e la ca d e n a “ K e y:”

• La llave generada es únicamente un
número aleatorio largo. 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, sólo que debe existir
en ambas máquinas
• Luego se copia la llave en ambos
servidores serv1 y serv2 con scp o
cortando y pegando
• NO USE telnet o ftp para copiarla, aún
las redes internas pueden ser
inseguras
• La llave debe estar incluida en los
archivos named.conf de ambas
máquinas
• Puesto que named.conf es
normalmente un archivo que se
puede leer por cualquiera, es
• Por ejemplo, se puede crear un
archivo serv1-serv2.key con modo
0600 y que su dueño sea el UID de
named
 key serv1-serv2 {
 algorithm hmac-md5;
 secret “llave-compartida-generada”;
 };
 Y en el archivo named.conf agregar
 include “serv1-serv2.key”;
• Esta parte de la configuración sólo define las
llaves, para que funcione para verificar y
firmar las actualizaciones, cada servidor
necesita identificar al otro con la cláusula keys
En serv1
 server direccion-ip-de-serv2 {
 keys { serv1-serv2; };
 };
En serv2
 server direccion-ip-de-serv-1 {
 keys {serv1-serv2; };
 };
• También las cláusulas allow-query,
allow-transfer y allow-update en la
sentencia zone deberían referirse a
la llave, por ejemplo
 allow-transfer { key serv1-serv2; };
• Es conveniente, cuando se
implemente esto ejecutar named
en nivel de depuración 1 para ver
los mensajes de error que se
generen
• 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
debian:/etc/bind# dnssec-keygen -a hmac-md5 -b 64 -n HOST s1s2
Ks1s2.+157+17079
debian:/etc/bind# cat Ks1s2.+157+17079.key
s1s2. IN KEY 512 3 157 gp/HvgCV8iY=
debian:/etc/bind# cat Ks1s2.+157+17079.private
Private-key-format: v1.2
Algorithm: 157 (HMAC_MD5)
Key: gp/HvgCV8iY=
•
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
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, los dominios
de alto nivel proveen información
validada para los dominios de
segundo nivel y así sucesivamente
DNSSEC
• Los sistemas de criptografía pública
utilizan dos llaves, uno para
codificar (o firmar) y otro para
descodificar (o verificar)
• Los que publican, firman su
información con una llave privada
secreta
• Cualquiera puede verificar la validez
de una firma con la llave pública,
que se distribuye a todo el mundo
DNSSEC
• Si una llave pública decodifica
correctamente un archivo de zona,
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, para respaldar la legitimidad
de la llave, de ahí el término “cadena
DNSSEC
• La información de una zona de DNS es
demasiado voluminosa como para ser
codificada con criptografía de llave
pública, puesto que la codificación sería
muy lenta
• En cambio, puesto que la información no es
secreta, un hash seguro, como una suma
de verificación MD5, se ejecuta sobre la
información y los resultados de ese hash
son firmados (codificados) por la llave
privada de la zona. Los resultados de ese
has son como la huella digital de los datos
y la huella digital firmada se llama “firma
digital”
DNSSEC
• Las firmas digitales normalmente se
agregan a la información que
autentifican
• Para verificar la firma, se debe
decodificar con la llave pública del
firmante, 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, se ha autentificado al
firmante y verificado la integridad
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
DNSSEC
• En la zona padre, se utiliza el
programa dnssec-signkey para
firmar el paquete de llaves
# dnssec-signkey midominio.com.keyset Kcom.+003+56789

• Este comando produce un archivo

llamado midominio.com.signedkey
que el padre mandará nuevamente
al hijo para que sea incluido en los
archivos de zona para
midominio.com

DNSSEC
• Una vez obtenida la firma de 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
• 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)
DNSSEC
• Para utilizar la zona firmada, cambia
el parámetro file en la sentencia
zone del archivo named.conf para
midominio.com para que apunte a
db.midominio.signed en vez de a
db.midominio
DNSSEC
• La firmas digitales están bien para las
respuestas positivas como “Aquí está
la dirección IP para el host
anchor.cs.colorado.edu, junto con una
firma que demuestra que de verdad
vino de cs.colorado.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
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, pero con los
nombres que están más arriba del
árbol en primer lugar, por ejemplo en
la zona cs.colorado.edu,
cs.colorado.edu viene antes de
cualquier host.cs.colorado.edu, es
decir se conserva el orden alfabético
DNSSEC
• Si el siguiente registro después de
anchor en cs.colorado.edu fue
awesome.cs.colorado.edu y si llega
una petición para
anthill.cs.colorado.edu, la respuesta
sería firmada por el registro NXT de la
siguiente forma
 anchor.cs.colorado.edu. IN NXT awesome.cs.colorado.edu A MX NXT
• Este registro dice que el nombre

inmediatamente a continuación de
anchor en la zona cs.colorado.edu es
awesome y que anchor tiene al menos
DNSSEC
• El último registro NXT en una zona se
dobla hasta el primer host de la
misma
• Por ejemplo, el registro NXT para
zamboni.cs.colorado.edu apuntaría de
regreso al primer registro del dominio
 zamboni.cs.colorado.edu. IN NXT cs.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, 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
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
DNS y Microsoft
• En Windows 2000 se utiliza el
registro SRV para descubrir todo:
servidores de nombres, 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
• 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
Término Significado
channel Es el lugar a donde irán los mensajes: syslog, un
category archivo
Una claseo /dev/null
de mensajes que named puede generar,
module pornombre
El ejemplo, 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. DNS no
severity respondidas
tiene su propia
La “maldad” decaracterística,
un mensaje depero se apueden
error, lo queescoger
syslog
las estándares
se refiere como prioridad
• La forma de configurar las bitácoras
es en el archivo named.conf
• Primero se definen los canales, 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
• Cuando se genera un mensaje, 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
• Un esquema de la sentencia logging
logging {
 channel_def;
 channel_def;
 …
 category category_name {
 channel_name;
 channel_name;
 …
 };
};
• 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
channel channel_name {
 file ruta [versions numvers | unlimited] [size
tamañoesperado];
 syslog facility;

 severity severity;
 print-category yes | no;
 print-severity yes | no;
 print-time yes | no;
};

• 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, por ejemplo 2,048, 100k,
20m, 15g, unlimited, default
• En el caso de syslog, 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
• El resto de las sentencias en un
channel_def son opcionales
• severity puede tener los valores, en
orden descendiente, critical, error,
warning, notice, info o debug, con un
nivel numérico opcional, como
severity debug 3
• El valor dynamic también es reconocido
y coincide con el nivel de
depuración especificado
• 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.run, se pone
default_stderr la severidad
Envía a dynamic
los mensajes a laconsola de error
null estándar de named,
Descarta todos con severidad info
los mensajes
• Para BIND9 simplemente se puede
escribir
•
•
logging {
 category default { default_syslog; default_debug; };
};
• 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
•
• A continuación se enlistan algunos
mensajes comunes
– Lame server. 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. Este mensaje indica una
incomunicación entre los servidores
de nombres de la zona
– Not authoritative for. Un servidor esclavo
no puede tener información con
autoridad para una zona.
Probablemente se está apuntando al
máster incorrecto, o quizá el máster
tiene problemas cargando la zona en
cuestión
– Rejected zone. named rechazó un
archivo de zona debido a que contiene
errores
– No NS RRs found. Un archivo de zona no
tiene registros NS después del registro
SOA. Podría ser que no estuviesen esos
registros, o que no comienzan con un
tabulador o un espacio en blanco. En el
segundo caso, los registros no se
• 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. Este
mensaje de error indica que el $TTL
está perdido. En Bind9 es requisito
indispensable el $TTL por lo que
named se rehúsa a cargar archivos
de zona que no lo especifiquen
• No root name server for class. Su
servidor tiene problemas para
encontrar los servidores de nombre
raíz. Revise su archivo de hints y la
conectividad a Internet del servidor
• Address already in use. El puerto en el
cual named quiere ejecutarse ya está
siendo utilizado por otro proceso,
probablemente otra copia de named.
Si no hay otro named por ahí,
probablemente se haya estrellado y
haya dejado un socket de control del
rndc abierto que tendrás que buscar y
borrar
• Una buena tabla de errores se puede
encontrar en
 http://www.acmebw.com/askmrdns/bind-messages.htm
http://www.jalix.org/ressources/reseaux/misc/bind/~vrac/bind-messages.ht


• Los niveles de depuración de named
van desde el 0 hasta el 11
• Entre más grande sea el número, 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
• Se puede invocar named desde la
línea de comandos con la bandera –
d, 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.run
• Sin embargo, esto cambia
dependiendo del sistema operativo
• 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, 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
• 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.conf
• Ejemplo /var/cache/bind
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.db
stats Vuelca las estadísticas en named.stats
reload Recarga named.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
• rndc reload es análogo a enviarle a
named una señal HUP; 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.db
• Este archivo es grande e incluye no sólo
información local, sino también la
Depuración con nslookup, 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,
buscador de información de
dominio)
– host permite revisar la sintáxis de los
archivos de zona
–
host
• En general suele ser mejor dig que
nslookup, 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, utiliza el servidor
lserver host actualel 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
host
• Para instalar nslookup y dig en
debian se hace lo siguiente
•
 aptitude install dnsutils
host
• dig básicamente provee la misma
funcionalidad que nslookup, pero
tiene valores por omisión mejor
pensados, 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.cs.colorado.edu. mx
host
• La instrucción
 dig @ns1.berkeley.edu vangogh.berkeley.edu any
• Obtiene los registros completos de

vangogh del servidor berkeley.edu
• Para hacer búsquedas inversas, se
hace así
 dig -x 128.32.33.5
• Con lo que se hace la búsqueda
inversa de esa dirección IP
host
debian:~# nslookup
> set type=any
> amazon.com.
Server: 192.168.226.131
Address: 192.168.226.131#53

Non-authoritative answer:
amazon.com nameserver = udns1.ultradns.net.

Authoritative answers can be found from:

> exit

host
 debian:~# dig amazon.com. any

; <<>> DiG 9.3.4-P1.1 <<>> amazon.com. any

;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14881
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 0
 ;; QUESTION SECTION:
 ;amazon.com. IN ANY

;; ANSWER SECTION:

amazon.com. 172725 IN NS udns1.ultradns.net.

;; AUTHORITY SECTION:


;; Query time: 6 msec

;; SERVER: 192.168.226.131#53(192.168.226.131)
;; WHEN: Tue Nov 11 18:11:08 2008
;; MSG SIZE rcvd: 108
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
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 mail is handled by 10 smtp-fw-2101.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'
Delegaciones cojas
• Con dig, se puede ver el problema
dig www.games.net.
;; …
;; QUESTIONS:
;; www.games.net, type = A, class = IN

;; ANSWERS:
www.games.net. 3600 A 209.1.23.92

;; AUTHORITY RECORDS:
games.net. 3600 NS ns.exodus.net.

games.net. 3600 NS ns2.exodus.net.
games.net. 3600 NS ns.pcworld.com.
;; ADDITIONAL RECORDS: …
Delegaciones cojas
• La primera petición al servidor local
regresa el registro de direcciones
para www.games.net y una lista de
servidores con autridad
• El servidor que está en ns.exodus.net
funciona bien cuando se le
pregunta, pero ns2.exodus.net. es
otra historia
Delegaciones cojas
dig @ns2.exodus.net www.games.net.
;; QUESTIONS:
;; www.games.net, type = A, class = IN

;; AUTHORITY RECORDS:
net. 244362 NS F.GTLD-SERVERS.net.

net. 244362 NS J.GTLD-SERVERS.net.
net. 244362 NS K.GTLD-SERVERS.net.
net. 244362 NS A.GTLD-SERVERS.net.
;; ...
• ns2 está enlistado como servidor de

autoridad para el dominio, pero no
regresa registro y nos refiere a los
servidores net de alto nivel
• Por lo tanto concluimos que ns2.exodus.net
está configurado incorrectamente
•
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, 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
• 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
El archivo de hints
• Para contactar al servidor de nombres
root y generar un archivo de hints, se
puede utilizar dig. El servidor máster
es a.root-servers.net, pero puede
usarse cualquier otro
 dig @a.root-servers.net . ns > root.cache
• El punto es importante
• Si a.root-servers.net no responde se
puede hacer la petición sin indicar un
servidor en particular
 dig . ns > root.cache
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, siempre y
cuando, al menos uno de los
servidores root esté operando
El archivo de hints
debian:~# cat /etc/bind/db.root


; <<>> DiG 9.2.3 <<>> ns . @a.root-servers.net.

;; global options:
 printcmd
;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18944


;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13



;; QUESTION SECTION:

;.
 IN NS
;; ANSWER SECTION:

.
 518400 IN NS A.ROOT-SERVERS.NET.
.
 518400 IN NS B.ROOT-SERVERS.NET.
.
 518400 IN NS C.ROOT-SERVERS.NET.
.
 518400 IN NS D.ROOT-SERVERS.NET.

El archivo de hints

;; ADDITIONAL SECTION:

A.ROOT-SERVERS.NET.
 3600000 IN A 198.41.0.4
B.ROOT-SERVERS.NET.
 3600000 IN A 192.228.79.201
C.ROOT-SERVERS.NET.
 3600000 IN A 192.33.4.12
D.ROOT-SERVERS.NET.
 3600000 IN A 128.8.10.90
E.ROOT-SERVERS.NET.
 3600000 IN A 192.203.230.10
F.ROOT-SERVERS.NET.
 3600000 IN A 192.5.5.241
G.ROOT-SERVERS.NET.
 3600000 IN A 192.112.36.4
H.ROOT-SERVERS.NET.
 3600000 IN A 128.63.2.53
I.ROOT-SERVERS.NET.
 3600000 IN A 192.36.148.17
J.ROOT-SERVERS.NET.
 3600000 IN A 192.58.128.30
K.ROOT-SERVERS.NET.
 3600000 IN A 193.0.14.129
El archivo de hints
• Observe que un punto inicia al
primer conjunto de registros,
puesto que definen al dominio root,
para el cual aplican los registros NS
• Un archivo de hints actualizado
puede obtenerse de
 ftp://ftp.nic.mil/domain/named.root
La configuración de
localhost
• El mapeo directo para el nombre
localhost o localhost.dominio se
hace en el archivo directo de zona
para el dominio
• Normalmente, cada servidor es amo
de su propio dominio inverso de
localhost
localhost
• En debian, el archivo de zona es el siguiente
debian:/etc/bind# cat /etc/bind/db.local
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA localhost. root.localhost. (
 1 ; Serial
 604800 ; Refresh
 86400 ; Retry
 2419200 ; Expire
 604800 ) ; Negative Cache
TTL
;
@ IN NS localhost.
@ IN A 127.0.0.1

localhost
• El mapeo inverso para la dirección
del localhost, 127.0.0.1 nunca
cambia, por lo tanto, los tiempos de
expiración pueden ser muy grandes

localhost
• En debian el archivo es el siguiente
debian:/etc/bind# cat /etc/bind/db.127
;
; BIND reverse data file for local loopback interface
;
$TTL 604800
@ IN SOA localhost. root.localhost. (
 1 ; Serial
 604800 ; Refresh
 86400 ; Retry
 2419200 ; Expire
 604800 ) ; Negative Cache TTL
;
@ IN NS localhost.
1.0.0 IN PTR localhost.
localhost
• Observe que sólo está enlistado el
servidor local
• El significado de @ en este contexto
es "0.0.127.in-addr.arpa."
• Es necesario asegurarse que el mapa
inverso de 127.0.0.1 lo haga hacia
"localhost.domain" y no solamente
a "localhost"
• Esto es porque los servidores raíz
reciben muchas peticiones para
"localhost"

DNS

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

DNS

Загружено:

Авторское право:

Доступные форматы

Configuración del DNS

Domini Para qué se usa Domini Para qué se usa

authoritative Es el representante oficial de la zona

forwarder Hace peticiones a nombre de muchos clientes, construye un gran cache

nonrecursive Te refiere a otro servidor si no puede responder tu petición

 aptitude install bind9 bind9-doc bind9-host

// Please read /usr/share/doc/bind9/README.Debian.gz for information on the

// If you are just adding zones, please do that in

// prime the server with knowledge of the root servers

• Hay dos formas de ver el mundo, los que

253 IN PTR m253.guarida.dyndns.org.

• Puesto que el nombre e la zona es el mismo que el

63 IN CNAME 63.0-63

• El sitio que maneje la subred deberá tener

129 IN PTR ns.guarida.dyndns.org.

// Do any local configuration here

• Y el tipo de líneas generadas son de la

• El mapeo inverso para la dirección del localhost, 127.0.0.1 nunca

; cch.unam.mx es el subdominio a delegar

acl cunets { // ACL para las redes de la Universidad de

 128.9.160.157; // mediciones de Bill Manning

allow-transfer { misesclavos; mediciones; };

*** Can’t list domain cs.colorado.edu: Unespecified error

• C o n e sto se cre a u n a lla ve d e 1 0 2 4 -

• E la rch ivo co n tie n e la ca d e n a “ K e y:”

debian:/etc/bind# cat Ks1s2.+157+17079.key

s1s2. IN KEY 512 3 157 gp/HvgCV8iY=

debian:/etc/bind# cat Ks1s2.+157+17079.private

Algorithm: 157 (HMAC_MD5)

• Y también crea los archivos que

• Este comando produce un archivo

• Este registro dice que el nombre

• Con esta opción se invoca named en

• Obtiene los registros completos de

Authoritative answers can be found from:

; <<>> DiG 9.3.4-P1.1 <<>> amazon.com. any

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14881

;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 0

;; ANSWER SECTION:

;; AUTHORITY SECTION:

;; Query time: 6 msec

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

server on 'www.games.net' (in 'GAMES.net'?):

;; www.games.net, type = A, class = IN

www.games.net. 3600 A 209.1.23.92

games.net. 3600 NS ns.exodus.net.

;; www.games.net, type = A, class = IN

net. 244362 NS F.GTLD-SERVERS.net.

• ns2 está enlistado como servidor de

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18944

;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13

; BIND data file for local loopback interface

; BIND reverse data file for local loopback interface

Вам также может понравиться