Configuración Del DNS: - Max de Mendizábal - 24 de Noviembre de 2008

Configuracin del DNS
Max de Mendizbal
24 de noviembre de 2008
El servidor de nombres
(DNS)
El servidor de nombres establece una
relacin entre nombres de mquinas
y direcciones IP
Tambin desempea un importante
papel en el enrutamiento del correo
electrnico (ah se definen los
intercambiadores de correo)
Es una base de datos distribuida en
la que cada sitio almacena
informacin sobre sus propias
DNS
Es un espacio de nombres jerrquico 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 informacin 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 informacin de
los archivos de DNS en la memoria y
las utilizan para responder preguntas
tanto de los clientes externos como
internos
Todas las mquinas de la red
deberan ser clientes del DNS
DNS
Para las organizaciones pequeas, basta
utilizar un solo servidor de nombres
Una organizacin 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 porcin
distinta del espacio de nombres y es
manejada por una sola entidad
administrativa
La raz del rbol se llama punto .,
bajo l estn 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 direccin 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 histricas hay dos tipos de
nombres de dominio de alto nivel
En los Estados Unidos, los dominios de
alto nivel describen la estructura poltica
y organizacional con tres letras, como
.com y .edu. Algunos de estos dominios,
como .com, .org y .net tambin se usan
fuera de los EEUU, a estos les llamamos
los dominios de alto nivel genrico o gTLD

DNS
Domin Para qu se usa
io
Domin Para qu se usa

io
com
Compaas
comerciales
net
Proveedores de red
edu
Instituciones
educativas
org
Organizaciones sin fines de

lucro
gov
Agencias
gubernamentales
int
Organizaciones
internacionales
mil
Agencias militares
arpa
Ancla para el rbol de

direcciones IP
Los dominios de alto nivel genricos

DNS
Para otros pases, los dominios
utilizan los cdigos de pas ISO de
dos letras, y se llaman los ccTLD
(country code Top Level Domain)
Cdi
go
Pas
Cdi
go
Pas
Cdi
go
Pas
au
Australi
a
fi
Finlandia
hk
Hong Kong
ca
Canad
fr
Francia
ch
Suiza
br
Brasil
jp
Japn
mx
Mxico
de
Aleman
ia
se
Suecia
hu
Hungra

DNS
Algunos pases tienen su propia
jerarqua organizacional para los
dominios de segundo nivel por
ejemplo una institucin acadmica
en los Estados Unidos es edu, pero
en el Reino Unido y en Japn 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 maysculas y minsculas
La norma actual es que los dominios siempre
se ponen con minsculas
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 direccin relativa
En general, el punto final se oculta al usuario
Registro de un nombre en Mxico

http://www.nic.mx
Registro de un dominio dinmico

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 informacin
sobre otros dominios sobre los que se
preguntan y sirven para acelerar las consultas
al Internet
nombres
Tipo de servidor
Descripcin
authoritative
(autoridad)
Es el representante oficial de la zona
master (amo)
Es el repositorio primario de los datos de una zona, obtiene su

informacin de un archivo en el disco
slave (esclavo)
Copia su informacin desde el master
stub
Similar al esclavo, pero slo copia los datos del nombre del
servidor (sin los datos de los otros hosts)
distribution
Un servidor que slo es visible dentro de un dominio (tambin

se le conoce como stealth server, o servidor oculto)
nonauthoritative
(sin autoridad)
Responde una peticin desde un cache, no sabe si la

informacin todava es vlida
caching
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 peticin
Cmo funciona el DNS?
Eficiencia del cache

Tener un cache de DNS incrementa la eficiencia
de las bsquedas
Una respuesta en el cache es prcticamente
gratuita y, normalmente, correcta, debido a que
los mapeos cambian con poca frecuencia
Muchas bsquedas se hacen hacia los
servidores locales y pueden ser resueltos
rpidamente
Los usuarios pueden ayudar sin querer con la
eficiencia porque hacen muchas preguntas
repetidas con frecuencia

Por mucho tiempo, no se podan poner en el cache
las respuestas negativas, slo las negativas, a
partir de BIND9 ya es posible hacerlo
En una medicin en el servidor raz de RIPE se
demostr que el 60% de las preguntas que se
hacan al DNS eran sobre informacin 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 informacin reduce de
forma dramtica la carga en los servidores raz

El cache negativo guarda respuestas de los siguientes
tipos
Ningn 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 dems slo por 5 minutos.
Las respuestas sin autoridad podran 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 raz, la
respuesta sern 13 servidores raz, Cul debera 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 ms rpida. Los
servidores dentro de una cubeta se tratan como
iguales y se utilizan de modo uno a la vez (round robin)

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
mquinas)
www
IN
IN
IN
A 192.168.0.1
A 192.168.0.2
A 192.168.0.3
El protocolo DNS extendido

En la definicin 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 tamao mximo
garantizado para las implementaciones UDP es
de 512 bytes, que es muy pequeo para incluir
las caractersticas de seguridad actuales del
DNS que incluyen firmas digitales
Ese lmite tambin afecta el nmero y los
nombres de los servidores raz, para hacer que
toda la informacin de los servidores raz
quepa en un paquete UDP de 512 bytes, slo
hay 13 servidores raz, cada uno con un
nombre limitado a una letra del alfabeto

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 podra pensar que lo ms fcil es
utilizar TCP para todo, pero esto
tambin es un desperdicio, puesto
que las conexiones TCP son ms caras

Una pregunta/respuesta tpica 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 vas para iniciar la
conversacin, una pregunta, una
respuesta, y un handshake final para
cerrar la conexin

A finales de la dcada de los 90, el EDNS0
(Extended DNS versin 0) resolvi algunas
de estas limitaciones del protocolo DNS
Permite el reensamble del tamao 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 EDNS0 tanto en el cliente como
en el servidor
Tarea
Instalacin de BIND y
mantenimiento
Para
Frecuencia
Obtener un nombre de
dominio
Sitio
Una vez
Escoger los servidores de

nombres
Sitio
Una vez o ms
Obtener una distribucin

BIND
Sitio
Una vez, pero es necesario

mantenerla actualizada
Configurar el resolvedor
Cliente
Una vez y distribuir
Configurar un resolvedor
eficiente
Cliente
Para cada subred y distribuir
Configurar el cambio de
servicios
Cliente
Para cada arquitectura y

distribuir
Iniciar named durante el

inicio
Servidor
Para cada servidor de nombres
Ajustar el archivo config de

named
Servidor
Para cada tipo de servidor
Configurar el archivo de
hints
Servidor
Una sola vez y distribuir a los

servidores
Configuracin 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 harn las
preguntas
Si el cliente obtiene su direccin IP y
parmetros de red de un servidor DHCP, el
archivo /etc/resolv.conf debe ponerse
automticamente, de otra forma, se puede
editar a mano, el formato es
search nombrededominio
nameserver direccinip
Configuracin 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
Si hay alguna otra cosa en ese archivo,

simplemente se ignora, por eso se pueden
poner al final de la lnea nameserver un
comentario, en la lnea search no se
recomienda poner ningn comentario
Configuracin del
resolvedor
La lnea 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 bsqueda, en
este caso, buscar
foo.cs.colorado.edu, si no lo
encuentra probar tambin con
Configuracin del
resolvedor
Se pueden tener hasta ocho dominios en una lnea
search
Los resolvedores enlistados en el archivo resolv.conf

deben ser recursivos, ya que un resolvedor no entiende
referencias, y cada uno de ellos debe tener un cache
Los servidores en las lneas nameserver se contactan
en orden. En tanto que el primero siga contestando las
preguntas, los dems sern ignorados
Si hay un problema, la pregunta expira y se probar
con el siguiente servidor de nombres. Cada servidor se
prueba por turnos, hasta cuatro veces. El intervalo de
reintento se incrementa con cada falla
Configuracin del
resolvedor
Muchos resolvedores permiten un
mximo de tres servidores de
nombres enlistados, si hay ms,
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
Configuracin del
resolvedor
Es una buena idea tener servidores separados
para resolver peticiones internas al dominio
Los servidores internos deberan ser de slo de
cache y recursivos
Un sitio muy grande debera 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
trfico de red y reducir la vulnerabilidad de las
mquinas a un solo punto de falla, porque si el
servidor de nombres falla, todo el sitio se detiene
Configuracin del
resolvedor
Los forwarders tambin 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 configuracin minimiza el uso de ancho
de banda externo utilizado por el servidor de
nombres y permite a las mquinas locales
compartir un gran cache
Configuracin del
resolvedor
En la figura siguiente se ilustran las recomendaciones
de diseo que se explicaron anteriormente
Se muestra una jerarqua 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
Tambin se muestra el uso de un servidor esclavo fuera
del sitio, que se recomienda ampliamente si se puede
conseguir que un ISP o una universidad local cubra este
papel
Configuracin del
resolvedor
Pruebas para el resolvedor

En algunos sistemas, para usar un
DNS basta con agregar la lnea
nameserver al archivo /etc/resolv.conf
En otros, es necesario decirle al
sistema explcitamente 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

Despus de configurar el
/etc/resolv.conf, y suponiendo que
todo funciona bien en la red, se
podrn ver las otras mquinas por
nombre en vez de por IP
Si se intenta ver otra mquina y la
instruccin se tarda, intenta verla a
travs de su direccin IP, si eso
funciona, es que la configuracin del
DNS tiene algn problema
Impacto en el resto del

sistema
La configuracin del DNS impacta en
varios puntos conforme el sistema se
inicia, por ejemplo, si se tiene un
servidor de correo, y an no se
resuelve el DNS, puede que no
funcione
Tambin si se montan unidades de
disco duro a travs de NFS, podra
ser que no encontrara la mquina
nombres
BIND son las siglas de Berkeley
Internet Name Domain (Nombres de
dominio de Internet, Berkeley) y es
un programa de cdigo 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 configuracin se
encuentran en
/etc/bind
Los archivos de configuracin

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;
};
type master;
};
include "/etc/bind/named.conf.local";
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.
Uncomment the following block, and insert the addresses replacing
the all-0's placeholder.
// forwarders {
//
0.0.0.0;
// };
auth-nxdomain no;
# conform to RFC1035
listen-on-v6 { any; };
};
Instrucci
n
Instrucciones del
named.conf
Funcin
include
Interpola un archivo
options
Pone las opciones de configuracin globales del servidor de

nombres
server
Especifica las opciones para cada servidor
key
Define la informacin de autentificacin
acl
Define las listas de control de acceso
zone
Define una zona de registro de recursos
trustedkeys
Utiliza las llaves preconfiguradas
controls
Define canales utilizados para controlar el servidor de

nombres con ndc
logging
Especifica las categoras de las bitcoras y sus destinos
view
Define una vista del espacio de nombres
Lista de coincidencia de
direcciones
Una lista de coincidencia de direcciones
es una generalizacin de una direccin IP
y puede incluir
Una direccin IP (por ejemplo 199.165.145.4)
Una red IP especificada con una mscara
CIDR (por ejemplo 199.165/16)
El nombre de una lista de acceso de control
definida con anterioridad
Una llave criptogrfica para autentificacin
El carcter ! que niega las cosas
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 direccin 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
revs las entradas, no se tendra el efecto
deseado, porque nunca se alcanzara la direccin
1.2.3.13 y nunca se encontrara la entrada negada
Instrucciones del named.conf

include
Para organizar mejor un DNS es posible
poner diferentes porciones de
configuracin 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 {
opcin;
opcin;
};

options
En el caso de Debian, las opciones
globales preconfiguradas son las
siguientes
options {
directory "/var/cache/bind";
auth-nxdomain no; # conform
to
# RFC1035
listen-on-v6 { any; };
};

options
En BIND9 hay ms de 50 opciones
que se pueden consultar en el
manual
http://www.bind9.net/manuals
http://www.bind9.net/manual/bind/9
.3.2/Bv9ARM.ch06.html#options
http://www.zytrax.com/books/dns/ch7
/statements.html

options
Los valores por omisin se enlistan en corchetes
cuadrados al final de la opcin, por ejemplo
version cadena de texto; [nmero de versin real del servidor]
Hay dos formas de ver el mundo, los que creen

que los hackers, con el nmero de versin
pueden atacar mejor, o los que consideran que
enmascarando las cosas no se resuelve nada
porque de todas formas los hackers probarn
con las ltimas vulnerabilidades

options
La instruccin directory hace que
named busque todos los archivos
incluidos en el directorio especificado
y, a partir de ah haga sus bsquedas
relativas. Debe ser una ruta absoluta,
los archivos de salida tambin irn
dentro de este directorio
directory ruta; [directorio en donde inicia el servidor]

options
Si la opcin notify se pone afirmativa, y
este es un servidor master para una ms
zonas, named notifica automticamente
a todos los esclavos cuando haya
cambios en la base de datos. Esto
provoca que los archivos de zona
converjan ms rpido cuando se hacen
cambios
notify yes | no; [yes]
also-notify servers_ipaddrs; [vaco]

options
La opcin recursion especifica si el
named preguntar a otros servidores de
nombres a nombre de sus clientes, es
muy raro que haya servidores con esta
opcin deshabilitada, sin embargo, se
puede habilitar la recursin slo 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 slo
una lista de direcciones
acl nombre_de_la_acl {
lista_de_direcciones_coincidentes;
};
Hay cuatro listas predefinidas: any,

localnets, localhost y none, que
coinciden con cualquier mquina, todas
las mquinas de la red local, la mquina
en si misma y nada, respectivamente

server
named puede hablar con varios servidores,
algunos de los cuales pueden hablar otras
versiones de BIND, la instruccin server indica
las caractersticas 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
corazn de los archivos named.conf
Indican si las zonas son de autoridad
y ponen las opciones adecuadas para
cada dominio
Una instruccin zone puede ser
utilizada para precargar los
servidores de ayuda root
Una configuracin simple de master
de zona sera 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 especificacin nombre_de_dominio
debe estar entre comillas
La informacin 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
coleccin de registros de recursos DNS

zone
zone ejemplo.com {
type master;
file forward/ejemplo.com;
allow-query { any; }
allow-transfer { mis-esclavos;}
};

zone
Configuracin de un servidor esclavo
para una zona
type slave | stub;
file ruta;
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 raz (root hints)
zone . {
type hint;
file ruta;
};
Los hints son el conjunto de los registros DNS
que enlista los servidores del dominio raz (.). Es
el lugar en donde el se comienzan las bsquedas
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 instruccin key define la llave
criptogrfica 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 instruccin 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
travs de la utilera ndc
controls {
inet ip_addr port port# allow { lista_dirs | key };
unix permission owner group; [0600 0 0]
};
Ejemplo de configuracin de BIND en

una mquina linux casera
En una red casera, podramos instalar una
pequea red privada, por ejemplo con la
direccin de red siguiente
192.168.77.0/24
y con el dominio
guarida.dyndns.org
Se necesitan dos archivos, el de bsqueda
directa (forward) y el de bsqueda inversa
(reverse) y modificar el /etc/bind/named.conf
para que se resuelvan las dos zonas

Modificacin 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;
};

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
; Expiracin 2 semanas
432000 ) ; Mnimo 5 das
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

El archivo 77.168.192.inaddr.arpa.zone
; 77.168.192.in-addr.arpa.zone
@ IN SOA ns.guarida.dyndns.org. root.guarida.dyndns.org. (
2009100201 ; Serie
21600 ; Refresco 6 horas
1800 ; Reintentar, 30 min
1209600 ; Expiracin 2 semanas
432000 ) ; Mnimo 5 das
IN NS ns
254 IN PTR ns.guarida.dyndns.org.
1 IN PTR m1.guarida.dyndns.org.
...
253 IN PTR m253.guarida.dyndns.org.

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 mster 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
Slo los RRs son parte de la base de
datos, los comandos de parseo slo
dan algunos atajos para poner
registros

Los registros de recursos RRs
Cada zona de la jerarqua del DNS tiene un
conjunto de recursos asociados con l
(aunque podra estar vaco)
El formato bsico de un registro de recurso
es
[nombre] [ttl] [clase] tipo datos
Los campos se separan con un espacio en

blanco (tabuladores o espacios) y puede
contener los caracteres especiales
siguientes

Los registros de recursos RRs
Caracteres especiales usados en los
RRsCaracte Significado
r
;
Introduce un comentario
El nombre actual del dominio
()
Permite que la informacin se divida en

varias lneas
Comodn (slo en el nombre del campo)
Tipo
Zo SOA
na
NS
Nombre
Funcin
Startbase
Of Authority
Define una
zona
de autoridad del
La
de datos
del
DNS
DNS
Los
tipos
DNSde
Name
Server de registro
Identifica adel
los servidores
zona, delega los subdominios
Ba A
sic AAAA
os
A6
Direccin IPv4
Traduccin nombre-a-direccin
Direccin IPv6 original
Obsoleto NO USAR
Direccin IPv6
Traduccin nombre-a-direccinipv6
PTR
Apuntador
Traduccin direccin-a-nombre
DNAM
E
Redireccin
Redireccin para bscadas

inversas ipv6
MX
Intercambiador de
correo
Controla el ruteo del correo-e
Llave pblica
Llave pblica para un nombre

DNS
Siguiente
Se usa con DNSSEC para

respuestas negativas
Firma
Zona autentificada firmada
Se KEY
gu
rid NXT
ad
SIG
Op CNAME Nombre cannico

cio
Sobrenombres o alias de un host

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 tambin es
conocido como el punto de
delegacin 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 direccin contraria
El rbol del DNS tiene una rama
hacia adelante (forward) organizada
por nombre y una rama hacia atrs
organizada por direccin IP

El registro SOA
Cada zona tiene exactamente un
registro SOA
La zona contina hasta que se
encuentre otro registro SOA
El registro SOA incluye el nombre de
la zona, un contacto tcnico y varios
valores de expiracin 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
21600
; Refresco 6 horas
1800
432000 ) ; Mnimo 5 das

El registro SOA
Aqu, el campo name contiene el smbolo
@, 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 instruccin 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
dems elementos forman el campo de datos
ns.cch.unam.mx es el nombre el servidor
mster de nombres de la zona
admin.cch.unam.mx es la direccin de correo
del contacto tcnico en formato usuario.host,
en vez del estndar usuario@host. Basta con
reemplazar el primer punto por una arroba si se
necesita enviar un correo al administrador

El registro SOA
Los parntesis permiten que el registro SOA
contine por varias lneas
El primer parmetro numrico es el nmero de
serie de los datos de configuracin de la zona
Este nmero de serie lo utilizan los servidores
esclavos para determinar cuando es necesario
obtener informacin fresca. Puede ser
cualquier entero de 32 bits y debe ser
incrementado cada vez que se actualiza el
archivo de la zona

El registro SOA
En algunos sitios se codifica la fecha en el
nmero de serie, por ejemplo 2008100201
sera la primer modificacin del 2 de octubre de
2008
Los nmeros de serie no necesariamente son
consecutivos continuos, pero si deben
incrementarse de forma montona
Si por accidente se pone un valor muy grande
en el servidor mster y ese valor es transferido
a los esclavos, corregir el nmero de serie en el
mster no funcionar

El registro SOA
Un truco para arreglar este problema
es poner el nmero de serie 0, con lo
que se causar una recarga forzada
No olvides poner nuevamente el
nmero de serie correcto despus de
la recarga
Es un error comn cambiar los
archivos de datos y luego olvidar la
actualizacin del nmero de serie

El registro SOA
Las cuatro entradas siguientes del
registro SOA son los valores de
expiracin temporal, en segundos
que controlan por cunto tiempo se
va a guardar la informacin en el
cache en varios puntos a travs 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
deberan revisar al mster para ver si ha
habido cambios en el nmero 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 (3,600 21,600 segundos)

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
parmetro notify est
especficamente apagado en el
archivo de configuracin
Los esclavos pueden entender la
notificacin y actuar inmediatamente

El registro SOA
Si un esclavo intenta revisar el
nmero de serie del mster, pero el
mster no responde, el esclavo
intenta de nuevo despus de que
haya concluido el periodo de
reintento, retry
Por experiencia, se sugiere que sea
de entre 20 y 60 minutos (1,2003,600)

El registro SOA
Si un servidor de nombres est cado por
mucho tiempo, los esclavos fallarn cada
vez que intenten refrescarse, por lo cual es
muy probable que la informacin que tienen
sea inservible
El parmetro expire determina por cunto
tiempo los esclavos seguirn intentando
continuar obtener la informacin del mster.
Se recomienda una expiracin de entre una
semana y un mes

El registro SOA
Antes de la versin 8.2 de BIND el parmetro minimum
se pona con un tiempo de omisin para los registros de
recursos
A partir de la versin 8.2 el significado de minimum del
registro SOA cambi, ahora pone el tiempo de vida
para las respuestas negativas que estn en el cache
El valor por omisin de las respuestas positivas se
especifica al inicio del archivo de zona con la directiva
$TTL
Los valores sugeridos van entre unas cuantas horas y
varios das para el $TTL y una hora o dos para
minimum

El registro SOA
Los parmetros $TTL, expire y
minumum hacen que con cierta
periodicidad se descarten todos los
valores anteriores
El diseo del DNS confa en el hecho
de que la informacin 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 estn
a continuacin del registro SOA

Los registros NS
El formato es
zona [TTL] IN NS hostname
Por ejemplo
cs.colorado.edu.
cs.colorado.edu.
cs.colorado.edu.
INNS ns.cs.colorado.edu.
INNS anchor.cs.colorado.edu.
INNS 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 lneas son equivalentes
INNS ns.cs.colorado.edu.
IN
IN
NS anchor.cs.colorado.edu.
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 parmetros en el registro NS se
supondr que el servidor es amo o esclavo,
como se indique en el archivo named.conf

Los registros NS
named utiliza los registros NS de la zona
para identificar los servidores esclavos
cuando se les deba enviar una notificacin
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
computacin

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 utilizarn para
contestar las preguntas del exterior
Esta situacin se puede presentar por
problemas de diseo o por simple olvido
Revise los servidores delegados con
nslookup o dig para asegurarse de que
estn registrados

Los registros A
Los registros A (address, es decir
direccin) son el corazn 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 mquina 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
resolucin 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 mquina 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 en el
archivo named.conf)

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 omisin de

138.128.in-addr.arpa.

El dominio in-addr.arpa.
Los dominios completamente calificados
pueden ser vistos como una notacin en la
cual la parte ms 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 ms significativa del lado izquierdo.
En la direccin 128.138.243.100, es el host
100 en la subred 243 que es parte de la red
128.138

El dominio in-addr.arpa.
El dominio in-addr.arpa. fue creado para
permitir que un conjunto de mdulos 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 revs,
por ejemplo, la zona para nuestra subred
243 es 243.138.128.in-addr.arpa.

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.inaddr.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
Adems de definir una zona inaddr.arpa para cada red real, es
necesaria una zona que se haga

Los registros PTR
Esta tcnica funciona bien si las
subredes estn dentro de los lmites
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 ms

Los registros PTR
Los mapeos inversos provistos por
los registros PTR se utilizan por
cualquier programa que autentifique
el trfico que ingresa
Por ejemplo el sshd podra permitir
ingresos remotos sin contrasea si la
mquina de origen est enlistada,
por nombre, en el archivo ~/.shosts
del usuario

Los registros PTR
Cuando el host destino recibe una peticin de
conexin, sabe la direccin de la mquina
fuente nicamente por su direccin IP
Entonces se utiliza el DNS para convertir la
direccin 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 nombres del host a partir de la
direccin IP

Los registros MX
El sistema de correo utiliza los
registros del intercambiador de
correo para enrutar el correo de
forma ms eficiente
Un registro MX prepara el destino de
un mensaje, en muchos casos
dirigindolo hacia el repositorio de
correo del sitio del receptor en vez
de a la estacin de trabajo del
receptor

Los registros MX
El formato de un registro MX es
nombre [ttl]
IN MX preferencia host
A continuacin 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 ningn correo
piper IN
IN MX
IN MX
xterm1
IN MX
IN MX
MX
20
50
IN
20
50
10 piper
mailhub
boulder.colorado.edu.
MX 10 mailhub
anchor
boulder.colorado.edu.

Los registros MX
Los hosts con menor preferencia se intentan
primero: 0 es el ms deseable y 65,535 es el
peor
En este ejemplo el correo enviado a
bob@xterm1 se enviara primero a mailhub si
est accesible, a anchor como segunda opcin
y si mailhub y anchor estn caidos, a boulder
Observe que el nombre boulder debe estar
completamente calificado porque no es parte
del dominio por omisin, que aqu es
cs.colorado.edu.

Los registros MX
La lista de las preferencias y hosts puede estar
en la misma lnea, pero hacerlo en lneas
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 cado
Cuando el destino no es alcanzable desde Internet
Cuando el destino no habla SMTP
Cuando el administrador local sabe a dnde enviar
el correo mejor que los corresponsales

Los registros MX
En el primer caso, el correo se enrutar a
un concentrador de correo, la mquina 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 estn conectados a
Internet no pueden tener registro A, pero
pueden tener registros MX

Los registros MX
El dominio en si mismo puede tener
un registro MX para concentrar todo
el correo en una mquina especial
Por ejemplo
cs
IN MX 10 mailhub.cs.colorado.edu.
IN MX 20 anchor.cs.colorado.edu.
IN MX 50 boulder.colorado.edu.

Los registros CNAME
Los registros CNAME asignan
nombres adicionales a un host
Estos apodos se utilizan
normalmente para asociar una
funcin con un host o para acortar un
nombre largo
Al nombre real se le conoce como el
nombre cannico 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
bsqueda 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 pblico de
un servidor web a varias mquinas
distintas
www
www
www
IN CNAME web1
IN CNAME web2
IN CNAME web3

Los registros CNAME
Tambin 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
En el apache es posible configurar que,

si se recibe un nombre distinto lleve a
un sitio especfico

El truco del CNAME
Cuando hay redes que no estn divididas en los
lmites de byte, se puede utilizar CNAME para
lograr la resolucin inversa
El truco es el siguiente: para cada direccin de
host posible en una zona in-addr.arpa natural, se
agrega un CNAME que deflecte la bsqueda a la
zona controlada por el dueo 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 organizacin padre crea los registros
CNAME para cada direccin IP posible con
un componente extra falso (un trozo
separado por un punto) que representa la
subred
Por ejemplo, en el escenario /26 recin
descrito, el primer cuarto de las
direcciones tendran un componente 063, el segundo cuarto, uno 64-127 y as
sucesivamente

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
0-63 IN NS
...
ns1.cliente1.com.
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
delegacin
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 bsqueda al nombre 1.063.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, slo el ISP debe hacer el
truco con nombres de configuracin
poco elegantes
Las cosas pueden complicarse an
ms 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 enlace

El truco del CNAME
En las nuevas versiones de BIND hay una
instruccin nueva, $GENERATE que facilita la
creacin de registros de recursos en la zona
padre
Por ejemplo para producir los registros de la
primera subred, basta con las siguientes
lneas
$GENERATE 0-63 $ CNAME $.0-63
0-63 NS ns1.cliente1.com.
0-63 NS ns2.cliente1.com.

El truco del CNAME
El smbolo $ 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
21600
; Refresco 6 horas
1800
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
21600
; Refresco 6 horas
1800
3600 ) ; cache inverso 1hr
IN
NS
1
IN
PTR
m1.guarida.dyndns.org.
2
IN
PTR
gateway.guarida.dyndns.org.
$GENERATE 3-128 $ IN PTR m$.guarida.dyndns.org.
129
IN
PTR
$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-omisin
$GENERATE muchos argumentos
Todos los comandos deben comenzar

en la primera columna y estar
aislados en una sola lnea

$ORIGIN
En condiciones normales, conforme
named lee un archivo de zona, le
agrega un dominio por omisin u
origen a cualesquiera nombres que
no estn 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 instruccin
como la siguiente

$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 lgicas
de un archivo de zona o para
mantener las llaves criptogrficas en
un archivo con permisos restringidos

$INCLUDE
La sintxis de la directiva $INCLUDE
es
$INCLUDE nombre-de-archivo
El archivo especificado es ledo en la
base de datos en el punto en el que
encuentra la directiva $INCLUDE

$TTL
La directiva $TTL pone un valor por
omisin para el tiempo de vida (timeto-live) de cada uno de los registros
que le siguen

$GENERATE
$GENERATE es la forma ms 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 lneas generadas son de la forma

lhs tipo rhs
El campo de inicio y trmino especifican el

intervalo de valores para un iterador
numrico, se genera una lnea para cada
valor en el intervalo

$GENERATE
El valor del iterador se incorpora
dentro del lhs y el rhs con el caracter
$
Tambin se puede especificar un
paso, con lo cual los incrementos
entre el inicio y el final se harn del
tamao de cada paso
Tipo es el tipo de registro, por el
momento slo se acepta en CNAME,
PTR y NS

La zona localhost
La direccin 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 direccin
simplemente como localhost, como si
fuera parte del dominio root, esta
configuracin es incorrecta

La zona localhost
Si se olvida de configurar la zona
localhost, su sitio podra acabar
preguntando a los servidores root
sobre la informacin local
Los servidores root reciben
actualmente tantas preguntas de
estas que los operadores estn
considerando agregar un mapeo
genrico entre localhost y 127.0.0.1
a nivel root

La configuracin 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 mster de su propio dominio
inverso
@ IN SOA cch.unam.mx. root.cch.unam.mx. (
2008101401 ; nmero de serie
3600; refresco
900 ; reintento
3600000 ; expiracin
14400 ); mnimo
IN NS cch.unam.mx.
1 IN PTR localhost.cch.unam.mx.
El mapeo inverso para la direccin 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 jerarqua
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 estn
por encima de su jerarqua en el DNS
enlaces entre zonas
Los servidores de un dominio padre deben
conocer la direccin 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 trminos 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 tocn (stub)
enlaces entre zonas
En el primer mtodo se incluyen los registros NS y A
que sean necesarios en la zona padre (colorado.edu)
; informacin 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 forneos 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 obtendrn errores
host unknown
enlaces entre zonas
Es un error comn incluir registros de
pegamento para nombres de host
que no los necesitan, por ejemplo
ns.xor.com del ejemplo anterior,
podra ser resuelto por una peticin
normal del DNS
Un registro A podra ser a primera
vista simplemente redundante, pero
si hay cambios en xor.com, podra
ocasionar fallas
enlaces entre zonas
La regla a seguir es que se deben
incluir registros A nicamente para
los hosts que estn 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
bitcora como un error
enlaces entre zonas
El esquema recin descrito es la forma estndar 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 mquinas distintas, las actualizaciones son
con frecuencia una tediosa tarea manual que
requiere de coordinacin entre fronteras
administrativas
El corolario es que en el mundo real, este tipo de
configuracin, con frecuencia, est desactualizada
enlaces entre zonas
La segunda forma de mantener estos
enlaces es utilizando zonas tocn (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 idntica tanto en los
servidores amo y esclavo del padre, algo
que por s mismo es difcil mantener de
forma consistente
enlaces entre zonas
La mejor apuesta es mantenerse en contacto con
la del dominio padre y verificar la configuracin
al menos dos veces al ao
Se puede usar el programa dig para verificar
cules 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 nombres pblicos
Sutilezas de las zonas stub
Las zonas stub no son copias con autoridad sobre la
informacin de la zona, los servidores stub no deben
estar enlistados entre los registros de zona NS
Como no estn enlistados en los registros NS, no sern
notificados cuando cambie la informacin de la zona.
Para actualizarlos, se puede aadir una clusula alsonotify a la configuracin de los servidores mster , 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 opcin timeout debera
funcionar bien en la mayor parte de los casos, pero
podra resultar en una delegacin coja transitoria en
algunos casos
Actualizacin 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 mster deben ser actualizados
Se debe incrementar el nmero de serie en el
registro SOA y luego ejecutar ndc reload para
enviar una seal al demonio named para que
revise los cambios, tambin se puede matar y
reiniciar named con ndc restart, o
/etc/init.d/bind9 restart, pero esta operacin causa
que se pierdan los datos recopilados en el cache
Actualizacin de archivos de
zona
La informacin de actualizacin de la zona se
propaga hacia los servidores esclavo
inmediatamente puesto que la opcin notify est
prendida por omisin
Si esta opcin est apagada, los servidores
esclavos se actualizarn 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 mster 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 modificacin de un registro
inverso, pueden suceder errores difciles de
encontrar, porque algunos comandos
funcionarn y otros no
Si se cambia la informacin y no se
actualiza el nmero de serie, los cambios
funcionarn en el servidor mster despus
de hacer un reload, pero no en los esclavos
zona
Es completamente inadecuado editar
informacin 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 fcil
verlo en el servidor mster, 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 travs de un
mecanismo llamado transferencia de
zonas
Antes se tenan 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
informacin hace una peticin de
transferencia de zona a un servidor
mster y hace una copia de respaldo del
archivo de zona
Si la informacin del servidor mster no
ha cambiado (esto se determina
comparando los nmeros de serie) no hay
ninguna actualizacin y los respaldos slo
se tocan
Las transferencias de zona utilizan el
protocolo TCP en el puerto 53 y hacen una
bitcora a travs del syslog con la
etiqueta named-xfer
Tanto el servidor amo como el esclavo
estn disponibles para contestar las
peticiones durante una transferencia de
zona, slo despus de que haya
terminado la transferencia, es cuando el
servidor tendr la nueva informacin
Cuando las zonas son muy grandes,
como la .com, o se actualizan
dinmicamente, los cambios son
muy pequeos con respecto al
tamao de la zona completa
Con IXFR slo se envan los cambios
El mecanismo es como el del
programa patch y slo se aplican las
diferencias sobre una base de datos
anterior
En BIND 9 IXFR est puesto por omisin
Las opciones provide-ixfr y request-ixfr
pueden ser puestas en las sentencias
server para los pares individuales. provideixfr habilita o deshabilita el servicio IXFR
para las zonas para las cuales este
servidor es el mster. La opcin requestixfr hace las peticiones IXFR para las
zonas para las cuales este servidor es
esclavo
Las instrucciones para los archivos
de configuracin son las siguientes
provide-ixfr yes; # en la sentencia server
request-ixfr yes; # en la sentencia server
Ejemplo para un servidor esclavo
Si quisiramos ser servidores esclavos de upn.mx y de acer.com.mx
deberamos escribir las siguientes lneas 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 dinmicas
La premisa del DNS es que los mapeos
nombre-a-direccin son relativamente
estables y no cambian con frecuencia
En los sitios con DHCP esto no es as
Hay dos soluciones clsicas: agregar
entradas genricas a la base de datos del
DNS o editar continuamente los archivos
del DNS
Estas dos soluciones podran no ser
satisfactorias en algunos casos
La primera solucin es conocida para
cualquiera que haya utilizado un ISP con dialup, la configuracin del DNS es como sigue
dhcp-host1.dominio. IN A 129.168.0.1
dhcp-host2.dominio. IN A 129.168.0.2
An cuando es una solucin simple, los

nombres de las mquinas estn
permanentemente asociados a direcciones IP
an cuando cambien. Esto podra
representar un riesgo de seguridad
Las ltimas versiones de DHCP y BIND
permiten que, desde el DHCP se notifique cada
vez que se asigne una direccin y se actualice
el servidor de nombres al vuelo
Las actualizaciones dinmicas 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
proveen las herramientas para hacer
Seguridad en el DNS
Caracterst Sentencias Qu especifica
ica
allow-query
options,
zone
Quin puede preguntar una zona o un

servidor
allowtransfer
options,
zone
Quin puede solicitar una transferencia

de zona
allowupdate
zone
Quin puede hacer actualizaciones

dinmicas
blackhole
options
A qu servidores se debe ignorar por

completo
bogus
server
A qu servidores nunca se debe

preguntar
acl
various
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
Tambin se pueden utilizar firmas de
transaccin para controlar las
actualizaciones dinmicas 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 denegacin de
servicio

Cada sitio debera 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 omisin, direcciones comodn
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;
204.228.69.24;
};

La direccin 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
mquinas simplemente se asignan a s mismas
una direccin en la red 169.254.0.0/16. Las
direcciones que estn en ese intervalo deberan
ser agresivamente filtradas de tal forma que nunca
escapen del cableado local. Los mdems de cable
y DSL estn comenzando a utilizar este intervalo
de direcciones
No haga que las direcciones privadas sean
fraudalentas si se estn utilizando en su red

En la seccin de options global del
archivo de configuracin, tambin se
podra incluir
allow-recursion { cunets; };
blackhole { bogusnets; };

Tambin es una buena idea restringir las trasferencias de zona
a los servidores esclavos legtimos. Un ACL que hace las cosas
bonitas y sencillas sera el mostrado a continuacin
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 opcin se limitan las transferencias a
nuestros servidores esclavos propios y a las
mquinas de dos proyectos de medidas de
Internet que caminan a travs del rbol
inverso del DNS para determinar el tamao 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 con nslookup, dig o host

Ahora suceder lo siguiente
% nslookup
Default Server: server-name
Address: server-IP-address
> ls cs.colorado.edu.
[server name]
*** Cant list domain cs.colorado.edu: Unespecified error
Confinacin de named
Para confinar el dao que alguien podra
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
Confinacin de named
Con esto, named iniciar con el UID 53 y en el
directorio root /var/named
Un directorio chroot no puede estar vaco
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 esttica no ser
necesario copiar todas las bibliotecas a
/var/named
Confinacin de named
Si los hackers comprometen a su named,
podran 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
podra ser muy destructiva
Muchos sitios no se preocupan por las banderas
-u, -g y -t pero entonces debern ser ms
rpidos que los hackers para actualizar cuando
se anuncie una vulnerabilidad
Confinacin de named
Los pasos detallados para
implementar esta tcnica se pueden
encontrar en
http://tldp.org/HOWTO/Chroot-BIND-HOWTO.
html
Comunicacin segura servidor-aservidor con TSIG y TKEY

Antes de la especificacin de DNSSEC
que se ver ms adelante, el IETF
desarroll un sencillo mecanismo llamado
TSIG (RFC2845) para permitir la
comunicacin segura entre servidores a
travs del uso de firmas de transaccin
El control de acceso basado en firmas de
transaccin es ms seguro que el control
de acceso basado en direcciones IP

Las firmas de transaccin utilizan un
esquema de criptografa simtrica
Esto es, que la llave de codificacin es
la misma que la de descodificacin
Esta llave se llama secreto
compartido o shared-secret en ingls
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
criptografa de TSIG es mucho menos
caro que el uso de criptografa de
llave pblica, pero slo es apropiado
para una red local en el cual el
nmero de pares de servidores
comunicantes sea pequeo
No es escalable al Internet global

TSIG tambin firma las peticiones y
respuestas de DNS
Slo 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 informacin del DNS
La implementacin de TSIG ms comn es
el algoritmo HMAC-MD5

La utilera 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
Con esto se crea una llave de 1024-bits y se

guarda en el archivo Kserv1-serv2+157+00000.private
El archivo contiene la cadena Key: seguida
por una codificacin base-64 de la llave

La llave generada es nicamente un
nmero aleatorio largo. Se puede generar
la llave manualmente escribiendo una
cadena ASCII de la longitud correcta y
pretendiendo que es una codificacin
base-64 o utilizando mmencode para
codificar una cadena aleatoria
La forma de crear la llave no es
importante, slo que debe existir en
ambas mquinas

Luego se copia la llave en ambos servidores
serv1 y serv2 con scp o cortando y pegando
NO USE telnet o ftp para copiarla, an las
redes internas pueden ser inseguras
La llave debe estar incluida en los archivos
named.conf de ambas mquinas
Puesto que named.conf es normalmente un
archivo que se puede leer por cualquiera,
es conveniente poner la llave en un archivo
separado incluido en el named.conf

Por ejemplo, se puede crear un archivo
serv1-serv2.key con modo 0600 y que
su dueo 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 configuracin slo define las llaves,
para que funcione para verificar y firmar las
actualizaciones, cada servidor necesita identificar al
otro con la clusula keys
En serv1
server direccion-ip-de-serv2 {
keys { serv1-serv2; };
};
En serv2
server direccion-ip-de-serv-1 {
keys {serv1-serv2; };
};

Tambin las clusulas allow-query,
allow-transfer y allow-update en la
sentencia zone deberan referirse a
la llave, por ejemplo
allow-transfer { key serv1-serv2; };
Es conveniente, cuando se
implemente esto ejecutar named en
nivel de depuracin 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
automtica
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 extensin del DNS que
autentifica el origen de la informacin de
la zona y verifica su integridad utilizando
criptografa de llave pblica
Estas extensiones le permiten al cliente
preguntar cosas como De verdad esta
informacin de DNS proviene del dueo
de la zona? y En verdad la informacin
enviada proviene del dueo?
DNSSEC
DNSSEC tiene tres servicios
Distribucin de llaves por medios de los
registros KEY almacenados en los
archivos de zona
Verificacin de origen para servidores e
informacin
Verificacin de la integridad de la
informacin de la zona
DNSSEC
DNSSEC est basado en la confianza
de la cadena en cascada, los
servidores root proveen de
informacin para validar los dominios
de alto nivel, los dominios de alto
nivel proveen informacin validada
para los dominios de segundo nivel y
as sucesivamente
DNSSEC
Los sistemas de criptografa pblica
utilizan dos llaves, uno para codificar
(o firmar) y otro para descodificar (o
verificar)
Los que publican, firman su
informacin con una llave privada
secreta
Cualquiera puede verificar la validez
de una firma con la llave pblica, que
se distribuye a todo el mundo
DNSSEC
Si una llave pblica 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
pblicas que se utilicen para verificar sean
autnticas
Los sistemas de llave pblica permiten a una
entidad firmar la llave pblica de otra, para
respaldar la legitimidad de la llave, de ah el
trmino cadena de confianza
DNSSEC
La informacin de una zona de DNS es demasiado
voluminosa como para ser codificada con
criptografa de llave pblica, puesto que la
codificacin sera muy lenta
En cambio, puesto que la informacin no es
secreta, un hash seguro, como una suma de
verificacin MD5, se ejecuta sobre la informacin 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 informacin que autentifican
Para verificar la firma, se debe decodificar
con la llave pblica del firmante, pasar la
informacin a travs 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 de la informacin
DNSSEC
En un sistema DNSSEC cada zona
tiene sus propias llaves pblica y
privada
La llave privada firma cada conjunto
RR
La llave pblica verifica las firmas y
estn incluidas en los datos de la
zona en forma de un registro de
recursos KEY
DNSSEC
Las zonas padre firman las llaves pblicas
de las zonas hijas
Named verifica la autenticidad de un
registro de zona hijo KEY revisndola 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 raz
La llave pblica para la zona raz 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
midominio.com.
Crea las llaves para una zona llamada

midominio.com
DNSSEC
Se recibe la siguiente salida
alg = 003
key identifier = 12345
flags = 16641
Y tambin crea los archivos que

contienen las llaves pblicas y
privadas
Kmidominio.com.+003+12345.key
# pblica
Kmidominio.com.+003+12345.private # privada
DNSSEC
La llave pblica tpicamente se
incluye en el archivo de zona con
$INCLUDE
Puede ir en cualquier lugar del
registro SOA, pero usualmente se
pone a continuacin del SOA
DNSSEC
DNSSEC requiere de una cadena de
confianza, de tal forma que la llave pblica
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
enva el paquete al padre para su firma
# dnssec-makekeyset t 3600 s +0 e +864000 Kmydomain.com.+003+12345
DNSSEC
Esta instruccin empaca la llave pblica de la zona
recin generada con un TTL de 3,600 segundos y
le hace la peticin a la firma del padre para que
sea vlida por 10 das a partir de hoy
dnssec-makekeyset crea un archivo de salida
nico mydomain.com.keyset
Luego se enva este archivo a la zona padre para
su firma
Contiene la llave pblica y las firmas generadas
por las llaves de la zona en s mismas para que el
padre pueda verificar la llave pblica del hijo
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 informacin de la zona
actual
La operacin de firma toma un archivo de
zona normal como entrada y le agrega los
registros SIG y NXT inmediatamente despus
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 informacin 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 (tambin
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 parmetro 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 estn bien para las
respuestas positivas como Aqu est la
direccin 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 informacin es
vlida
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
cannica ordenada
El orden es alfabtico, pero con los nombres
que estn ms 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 alfabtico en cada nivel jerrquico
DNSSEC
Si el siguiente registro despus de anchor en
cs.colorado.edu fue
awesome.cs.colorado.edu y si llega una
peticin para anthill.cs.colorado.edu, la
respuesta sera 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 continuacin de anchor en la
zona cs.colorado.edu es awesome y que anchor
tiene al menos un registro A, un MX y un NXT
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 apuntara de
regreso al primer registro del dominio
zamboni.cs.colorado.edu.
IN NXT cs.colorado.edu A MX NXT
Los registros NXT tambin son regresados si el host

existe pero el tipo de registro solicitado no existe
Por ejemplo si se pide un registro LOC para anchor,
se regresar el mismo registro NXT de anchor
mostrando nicamente los registros A, MX y NXT
DNSSEC
Este sistema todava no est
implementado en el mundo real
debido a que la infraestructura de
llave pblica necesaria an 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 dinmicas de los
registros no es estndar
MS utiliza una variacin de las firmas
de transaccin llamada GSS-TSIG que
tambin est basada en secretos
DNS y Microsoft
El secreto compartido se obtiene a
travs de Kerberos desde el Kerberos
KDC (Key Distribution Center)
El problema es que la implementacin
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 raz del DNS mostraron un
incremento significativo de
peticiones
El problema es que los Win2k venan
mal configurado e intentaban
actualizar dinmicamente a los
servidores raz
Esto caus un serio problema con los
servidores raz que MS negaba
DNS pruebas y depuracin

Hay varias formas de depurar los
archivos de configuracin de named
Uno de ellos es especificar el nivel de
depuracin con rndc
Se le puede indicar a named que
enve sus estadsticas de operacin a
una bitcora y verificar las
bsquedas con dig y nslookup

Trmino
Significado
channel
Es el lugar a donde irn los mensajes: syslog, un

archivo o /dev/null
category
Una clase de mensajes que named puede generar, por

ejemplo, los mensajes sobre las actualizaciones
dinmicas o los mensajes sobre las peticiones
respondidas
module
El nombre del mdulo fuente que genera un mensaje
facility
El nombre de una caracterstica de syslog. DNS no

tiene su propia caracterstica, pero se pueden escoger
las estndares
severity
La maldad de un mensaje de error, a lo que syslog

se refiere como prioridad

La forma de configurar las bitcoras
es en el archivo named.conf
Primero se definen los canales, es
decir los destinos posibles para los
mensajes
Luego se definen las categoras de
los mensajes que van a cada uno de
los canales en particular

Cuando se genera un mensaje, se le
asigna una categora, un mdulo 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
tambin 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 definicin 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 tamaoesperado];
syslog facility;
severity severity;
print-category yes | no;
print-severity yes | no;
print-time yes | no;
};

Para un archivo numvers indica cuntas
versiones de respaldo se deben mantener
tamaoesperado especifica qu tanto se va a
permitir que crezca la bitcora, 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 estndar
En la prctica slo 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
numrico opcional, como severity debug 3
El valor dynamic tambin es reconocido y
coincide con el nivel de depuracin
especificado

Los cuatro canales en la tabla
siguiente estn predefinidos
Para la mayor parte de las
instalaciones, estos canales estn
Nombre
Qu hace
bien del
canal
default_syslog
Enva desde la severidad info y superiores al

syslog con la
default_debug
Registra hacia el archivo named.run, se pone

la severidad a dynamic
default_stderr
Enva los mensajes a la consola de error

estndar de named, con severidad info
null
Descarta todos 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 bitcoras
y quiz incrementar el nivel de
depuracin
Luego, reconfigurarlo para conservar
nicamente los mensajes ms serios,
una vez que named est estable

A continuacin 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
ms
Bad referral. Este mensaje indica una
incomunicacin entre los servidores de
nombres de la zona

Not authoritative for. Un servidor esclavo no puede
tener informacin con autoridad para una zona.
Probablemente se est apuntando al mster
incorrecto, o quiz el mster tiene problemas
cargando la zona en cuestin
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 despus del registro SOA. Podra 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 pegan a la zona del registro
SOA y por ello son malinterpretados

No default TTL set. La forma
preferida para poner un TTL por
omisin es con una clusula $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 rehsa 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 raz. 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 tendrs 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-messag
es.html

Los niveles de depuracin de named van
desde el 0 hasta el 11
Entre ms grande sea el nmero, se
obtendr mayor informacin
El nivel 0 apaga los mensajes de depuracin
Los niveles 1 y 2 estn bien para depurar la
configuracin o la base de datos
Despus del nivel 4 son para los
programadores

Se puede invocar named desde la lnea de
comandos con la bandera d, por ejemplo
# named d2
Con esta opcin se invoca named en nivel
de depuracin 2
Por omisin la informacin de esta
depuracin se coloca en el archivo
named.run
Sin embargo, esto cambia dependiendo del
sistema operativo que se utilice

Se puede modificar el nivel de depuracin
sin necesidad de reiniciar named
Una forma de incrementar el nivel de
depuracin es con el comando rndc trace, lo
cual eleva dicho nivel en uno
rndc notrace apaga la depuracin por
completo
Tambin se puede modificar el nivel de
depuracin habilitando un canal, por ejemplo
severity debug 3

Depuracin 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 depuracin con el rndc
Comando
Funcin
help
Enlista todos los comandos disponibles en rndc
status
Muestra el estado actual de la ejecucin del named
trace
Incrementa el nivel de depuracin en uno
notrace
Apaga la depuracin
dumpdb
Vuelca la base de datos del DNS a named_dump.db
stats
Vuelca las estadsticas 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 anlogo a enviarle a named
una seal HUP; hace que named relea su
archivo de configuracin y el de sus zonas
rndc reload zona es muy til en especial en
los servidores de nombres con mucho trabajo
porque slo 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 slo
informacin local, sino tambin la encontrada
en el cache
Depuracin con nslookup, dig y host

Estas herramientas se pueden
utilizar para hacer preguntas a la
base de datos del DNS
nslookup es la ms antigua
dig (domain information groper,
buscador de informacin de dominio)
host permite revisar la sintxis de los
archivos de zona

En general suele ser mejor dig que
nslookup, pero host hace algunas
cosas nicas
rdenes para el nslookup
Instruccin
Funcin
nombre
Muestra informacin sobre el host o el nombre

del dominio
help o ?
Muestra la lista completa de comandos
exit
Sale del programa
server host
Pone el servidor por omisin, utiliza el servidor

actual
lserver host
Pone el servidor por omisin, usando el servidor

inicial
set type=xxx
Pone los tipos de registros a preguntar

(any=todos)
Depuracin con nslookup, dig y

host
Para instalar nslookup y dig en
debian se hace lo siguiente
aptitude install dnsutils

dig bsicamente provee la misma
funcionalidad que nslookup, pero
tiene valores por omisin mejor
pensados, otorga ms informacin 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

La instruccin
dig @ns1.berkeley.edu vangogh.berkeley.edu any
Obtiene los registros completos de

vangogh del servidor berkeley.edu
Para hacer bsquedas inversas, se
hace as
dig -x 128.32.33.5
Con lo que se hace la bsqueda
inversa de esa direccin IP

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.
amazon.com
Authoritative answers can be found from:
amazon.com
amazon.com
> exit

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.
amazon.com.
172725
172725
IN
IN
NS
NS
udns1.ultradns.net.
udns2.ultradns.net.
;; AUTHORITY SECTION:
amazon.com.
amazon.com.
172725
172725
IN
IN
NS
NS
udns2.ultradns.net.
udns1.ultradns.net.
;;
;;
;;
;;
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

Dig da mucha informacin, su salida
incluye no slo la informacin del dominio
sino tambin el nmero de peticiones
enviadas y el tiempo que tom tener la
respuesta
Adems 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 raz
para generar el archivo de hints

host muestra la informacin de una
forma simple y concreta, aunque con
la opcin -v puede mostrar ms
informacin
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 mquina 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
"delegacin coja"
Delegaciones cojas
Los efectos que puede ocasionar una
delegacin coja pueden ser muy malos
Si un usuario intenta contactar a un host en su
dominio cojo, el servidor de nombres rehusar
la peticin
El DNS reintentar varios cientos de veces la
peticin, golpeando tanto a tu servidor de
nombres como a los servidores raz
En una bitcora de 3.5 Mb (a nivel info) despus
de una semana, una tercera parte eran
delegaciones cojas
Delegaciones cojas
De ellas, el 16% de las peticiones,
involucraban a los servidores raz,
posiblemente por dominios no existentes
Un usuario persistente inquiri a los
servidores raz 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 peticin 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 informacin sobre los
servidores del dominio root
Cuando se colocan los servidores root en el
inicio del cache se mejora el proceso de
bsqueda para todos los nombres
Si no se pone el archivo hints, BIND9 utiliza
una lista de servidores root que estn
programados dentro de su cdigo 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 ms simple rastrearlos ahora
de lo que era antes porque todos
estn asignados al dominio rootservers.net
El archivo de hints
Para contactar al servidor de nombres root y
generar un archivo de hints, se puede utilizar
dig. El servidor mster 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 peticin sin indicar un servidor en
particular
dig . ns > root.cache
El archivo de hints
An 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 ao 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:
;.
;; ANSWER SECTION:
.
.
.
.
.
.
.
.
.
.
.
.
.
518400
518400
518400
518400
518400
518400
518400
518400
518400
518400
518400
518400
518400
IN
NS
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
NS
NS
NS
NS
NS
NS
NS
NS
NS
NS
NS
NS
NS
A.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET.
El archivo de hints
;; ADDITIONAL SECTION:
A.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET.
;;
;;
;;
;;
3600000
3600000
3600000
3600000
3600000
3600000
3600000
3600000
3600000
3600000
3600000
3600000
3600000
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
A
A
A
A
A
A
A
A
A
A
A
A
A
Query time: 81 msec

SERVER: 198.41.0.4#53(a.root-servers.net.)
WHEN: Sun Feb 1 11:27:14 2004
MSG SIZE rcvd: 436
198.41.0.4
192.228.79.201
192.33.4.12
128.8.10.90
192.203.230.10
192.5.5.241
192.112.36.4
128.63.2.53
192.36.148.17
192.58.128.30
193.0.14.129
199.7.83.42
202.12.27.33
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 configuracin 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
La configuracin de
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
La configuracin de
localhost
El mapeo inverso para la direccin
del localhost, 127.0.0.1 nunca
cambia, por lo tanto, los tiempos de
expiracin pueden ser muy grandes
La configuracin de
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.
La configuracin de
localhost
Observe que slo 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 raz reciben
muchas peticiones para "localhost"

Configuración Del DNS: - Max de Mendizábal - 24 de Noviembre de 2008

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Configuración Del DNS: - Max de Mendizábal - 24 de Noviembre de 2008

Cargado por

Copyright:

Formatos disponibles

Configuracin del DNS

El espacio de nombres del

El espacio de nombres del

El espacio de nombres del

El espacio de nombres del

Domin Para qu se usa

Organizaciones sin fines de

Ancla para el rbol de

Los dominios de alto nivel genricos

El espacio de nombres del

El espacio de nombres del

El espacio de nombres del

Registro de un nombre en Mxico

Registro de un dominio dinmico

Los de autoridad representan una zona de

Es el representante oficial de la zona

Es el repositorio primario de los datos de una zona, obtiene su

Copia su informacin desde el master

Un servidor que slo es visible dentro de un dominio (tambin

Responde una peticin desde un cache, no sabe si la

Almacena los datos de las peticiones anteriores, usualmente no

Hace peticiones a nombre de muchos clientes, construye un

Hace las peticiones a tu nombre hasta que regresa ya sea una

Te refiere a otro servidor si no puede responder tu peticin

Cmo funciona el DNS?

Eficiencia del cache

Eficiencia del cache

Eficiencia del cache

Los primeros dos tipos de respuestas negativas se

Eficiencia del cache

Eficiencia del cache

El protocolo DNS extendido

El protocolo DNS extendido

El protocolo DNS extendido

El protocolo DNS extendido

El protocolo DNS extendido

Escoger los servidores de

Obtener una distribucin

Una vez, pero es necesario

Una vez y distribuir

Para cada subred y distribuir

Para cada arquitectura y

Iniciar named durante el

Para cada servidor de nombres

Ajustar el archivo config de

Para cada tipo de servidor

Una sola vez y distribuir a los

Si hay alguna otra cosa en ese archivo,

Los resolvedores enlistados en el archivo resolv.conf

Pruebas para el resolvedor

Pruebas para el resolvedor

Impacto en el resto del

Los archivos de configuracin

que, en otras distribuciones son uno solo.

If there is a firewall between you and nameservers you want

// query-source address * port 53;

If your ISP provided one or more IP addresses for stable

Pone las opciones de configuracin globales del servidor de

Especifica las opciones para cada servidor

Define la informacin de autentificacin

Define las listas de control de acceso

Define una zona de registro de recursos

Utiliza las llaves preconfiguradas