Cómo configurar tu propio dominio.
Antes de nada: ¿Has leído todo lo anterior? Tienes que hacerlo.
Antes de comenzar realmente con esta sección,
voy a dar un poco de teoría sobre cómo funciona DNS.
Y lo deberías de leer porque es mejor para ti. Si no
quieres, al menos deberías echar un vistazo rápido.
Deja el repaso cuando sepas lo que debes incluir en tu fichero
named.conf.
El DNS es un sistema jerárquico, un sistema con
estructura de árbol. La raíz se escribe como
`.' y se denomina `root' como es habitual para
estructuras en árbol. Debajo hay cierto número de
Dominios de Nivel Superior (Top Level Domains, TLDs),
los más conocidos son ORG, COM, EDU y
NET, pero hay muchos más. Como en un
árbol, tiene raíz y ramas. Si tienes una base de
informática puedes reconocer DNS como un árbol de
búsqueda, y podrás buscar nodos. Los puntos son
nodos, en los extremos están los nombres.
Cuando se busca una máquina, la pregunta procede
recursivamente en la jerarquía comenzando desde la
raíz. Si quieres localizar la dirección de
prep.ai.mit.edu, tu servidor de nombres tiene que
empezar preguntando en algún sitio. Comienza mirando e el
cache. Si sabe la respuesta, por tenerla en el cache de antes,
responderá de la misma forma que vimos en la última
sección. Si lo desconoce mirará la respuesta
más cercana que verifique el nombre pedido y
utilizará el cache. En el peor de los casos que no se
encuentre nada salvo la '.' (raíz) del nombre, se
consultarán los servidores raíz. Eliminará
partes del nombre comenzando por la izquierda, comprobando si sabe
algo de ai.mit.edu., después
mit.edu., después edu. y si no, lo
que conoce de . es lo que tiene el fichero "hints".
Entonces preguntará al servidor . sobre
prep.ai.mit.edu. Este servidor .
desconoce la respuesta, pero ayudará a tu servidor a
encontrar el camino dando la referencia sobre donde buscar. Estas
referencias, le dirigen al servidor de nombres que conoce la
respuesta. Ilustramos eso ahora. +norec significa que
dig está preguntando consultas no recursivas para que la
obtengamos nosotros mismos. La otras opciones son para reducir lo
que dig genera para no obtener muchas páginas:
$ dig +norec +noH +noques +nostats +nocmd prep.ai.mit.edu. ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 980 ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0 ;; AUTHORITY SECTION: . 518400 IN NS J.ROOT-SERVERS.NET. . 518400 IN NS K.ROOT-SERVERS.NET. . 518400 IN NS L.ROOT-SERVERS.NET. . 518400 IN NS M.ROOT-SERVERS.NET. . 518400 IN NS A.ROOT-SERVERS.NET. . 518400 IN NS B.ROOT-SERVERS.NET. . 518400 IN NS C.ROOT-SERVERS.NET. . 518400 IN NS D.ROOT-SERVERS.NET. . 518400 IN NS E.ROOT-SERVERS.NET. . 518400 IN NS F.ROOT-SERVERS.NET. . 518400 IN NS G.ROOT-SERVERS.NET. . 518400 IN NS H.ROOT-SERVERS.NET. . 518400 IN NS I.ROOT-SERVERS.NET.
Esto es una referencia. Nos devuelve una "Authority section" sólo, no "Answer section". Nuestro propio servidor de nombres nos envía a un servidor de nombres. Toma uno al azar.
$ dig +norec +noques +nostats +nocmd prep.ai.mit.edu. @D.ROOT-SERVERS.NET. ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58260 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3 ;; AUTHORITY SECTION: mit.edu. 172800 IN NS BITSY.mit.edu. mit.edu. 172800 IN NS STRAWB.mit.edu. mit.edu. 172800 IN NS W20NS.mit.edu. ;; ADDITIONAL SECTION: BITSY.mit.edu. 172800 IN A 18.72.0.3 STRAWB.mit.edu. 172800 IN A 18.71.0.151 W20NS.mit.edu. 172800 IN A 18.70.0.160
Esto nos envía a los servidores de MIT.EDU de una vez. De nuevo toma uno al azar.
$ dig +norec +noques +nostats +nocmd prep.ai.mit.edu. @BITSY.mit.edu. ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29227 ;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4 ;; ANSWER SECTION: prep.ai.mit.edu. 10562 IN A 198.186.203.77 ;; AUTHORITY SECTION: ai.mit.edu. 21600 IN NS FEDEX.ai.mit.edu. ai.mit.edu. 21600 IN NS LIFE.ai.mit.edu. ai.mit.edu. 21600 IN NS ALPHA-BITS.ai.mit.edu. ai.mit.edu. 21600 IN NS BEET-CHEX.ai.mit.edu. ;; ADDITIONAL SECTION: FEDEX.ai.mit.edu. 21600 IN A 192.148.252.43 LIFE.ai.mit.edu. 21600 IN A 128.52.32.80 ALPHA-BITS.ai.mit.edu. 21600 IN A 128.52.32.5 BEET-CHEX.ai.mit.edu. 21600 IN A 128.52.32.22
Esta vez obtenemos una "ANSWER SECTION", y una respuesta para
nuestra pregunta. La "AUTHORITY SECTION" contiene
información sobre a qué servidores hacer las
preguntas sobre ai.mit.edu la próxima vez.
Así les puede preguntar directamente la próxima vez
que necesite algo de sobre los nombres de ai.mit.edu,
es decir, cuando preguntamos por w.ww.mit.edu
estaremos mucho mas cerca de obtener la respuesta.
Así, empezando en . encontramos los
sucesivos servidores de nombres para cada nivel por referencia. Si
has usado tu propio servidor DNS en lugar de usar todos esos
servidores, tu named, por supuesto, guardará en el cache
toda la información que encuentre mientras consulta para ti,
y no tendrá que preguntar de nuevo durante cierto
tiempo.
En la analogía con el árbol, cada
``.'' del mismo nombre es un punto de rama. Y cada
parte entre ``.'' son los nombres de ramas
individuales del árbol. Uno sube por el árbol tomando
el nombre que queremos (prep.ai.mit.edu) preguntando a
la raíz (.) o a cualquier servidor más
arriba de la raíz hacia prep.ai.mit.edu cuya
información tuviéramos en el cache. Una vez que
llegamos a los límites del caché las
resolución recursiva continúa preguntando a
servidores, obteniendo referencias más lejanas del
nombre.
Aunque se hable mucho menos, un dominio tan importante es
in-addr.arpa. También se anida como los
dominios `normales'. in-addr.arpa nos permite obtener
el nombre de host cuando tenemos su dirección. Una cosa
importante que tenemos que observar es que las direcciones IP se
escriben en orden inverso en el dominio in-addr.arpa.
Si tiene la dirección de una máquina:
192.186.203.77 named procede igual que para el ejemplo
de prep.ai.mit.edu: encuentra servidores
arpa.. Busca servidores in-addr.arpa.,
busca servidores 192.in-addr.arpa., busca servidores
186.192.in-addr.arpa., busca
servidores203.186.192.in-addr.arpa.. Busca los
registros que necesitamos para
77.203.186.192.in-addr.arpa. como haría para
prep.ai.mit.edu. Ejemplo: Al no encontrar una entrada
en el cache adecuada salvo `.', pregunta al servidor raíz,
m.root-servers.net que te envía a otro servidor
raíz. b.root-servers.net nos envia directamente
a bitsy.mit.edu/. Se debería poder tomar ya desde
allí.
Ahora vamos a definir nuestro propio dominio. Vamos a crear el
dominio linux.bogus y definir máquinas en
él. Uso un nombre de dominio totalmente falso para estar
seguro de que no molestamos a nadie de fuera.
Una cosa más antes de empezar: No se permiten todos los
caracteres en nombres de máquina. Estamos restringidos a los
caracteres del alfabeto inglés: a-z, números 0-9 y el
carácter '-' (guión). Manténte en estos
caracteres. Las mayúsculas y minúsculas son
indistintas para el DNS, así pat.uio.no es
idéntico a Pat.UiO.No.
Ya hemos comenzado esta parte con la siguiente línea en
named.conf:
zone "0.0.127.in-addr.arpa" {
type master;
file "pz/127.0.0";
};
Por favor, observa la ausencia de `.' al final de
los nombres de dominio en este fichero. Esto dice que ahora vamos a
definir la zona 0.0.127.in-addr.arpa, de la que somos
servidor principal ("master") y que está definida en un
fichero llamado pz/127.0.0. Ya hemos configurado este
fichero, en el que podemos leer:
$TTL 3D
@ IN SOA
ns.linux.bogus.
hostmaster.linux.bogus. (
1 ; Serie
8H ; Refresco
2H ; Reintento
4W ; Expira
1D) ; Minimo TTL
NS ns.linux.bogus.
1 PTR localhost.
Por favor observa los `.' al final de los nombres
de dominio completo en contraste con el archivo
named.conf anterior. A algunas personas les gusta
iniciar cada zona del archivo con una directiva
$ORIGIN, pero esto es superfluo. El origen (lugar de
la jerarquía DNS a donde pertenece) de un fichero de zona se
especifica en la seccion zona del archivo
named.conf; en este caso es
0.0.127.in-addr.arpa.
Este ``fichero de zona'' contiene tres registros de
recursos (RRs): Un RR SOA, Un RR NS y
un RR PTR. SOA es una abreviatura de
Start Of Authority. La `@' es una
notación especial que simboliza el origen, y como la columna
dominio para este archivo indica
0.0.127.in-addr.arpa. La primera línea
realmente significa:
0.0.127.in-addr.arpa. IN SOA ...
NS es el RR Name Server (Servidor de
Nombres). No hay '@' al comienzo de esta línea; es
implícita ya que la línea previa comenzaba con '@'.
Eso ahorra algo de tecleo. Así la línea NS se
podría haber escrito también como:
0.0.127.in-addr.arpa. IN NS ns.linux.bogus
Esto le indica a DNS qué máquina es el servidor de
nombres del dominio 0.0.127.in-addr.arpa este es
ns.linux.bogus. 'ns' es un nombre habitual para
servidores de nombres, pero como con los servidores web que
habitualmente se llaman www.loquesea el
nombre puede ser cualquiera.
Y finalmente el registro PTR (Domain Name Pointer,
Puntero de nombre de dominio) le dice que el host con
dirección 1 (igual a
1.0.0.127.IN-ADDR.ARPA, esto es,
127.0.0.1) es el llamado localhost.
El registro SOA es el preámbulo de
todos los archivos de zona y debe haber uno exactamente en
cada archivo de zona,(pero tras la directiva $TTL ).
El registro SOA describe la zona, de dónde
proviene (una máquina llamada linux.bogus),
quién es el responsable de su contenido
(hostmaster@linux. bogus, deberías
poner su dirección de correo aquí, qué
versión del archivo de zona es (Número de
Serie, 1), y otras cosas que tienen que ver con
el caché y los servidores secundarios DNS. Para el resto de
los campos (Tasa de Refresco, Tasa de
Reintento, Caducidad para secundario y
Tiempo de Validez para Clientes) usa los valores que
aparecen aquí para mayor seguridad. Antes de SOA viene una
línea obligatoria, la línea $TTL 3D
Ponla en todos tus ficheros de zona.
Ahora reinicia tu named (la orden es rndc stop o
/etc/init.d/named restart) y usa dig para examinar tu
trabajo. -x pregunta por resolución
inversa:
$ dig -x 127.0.0.1 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30944 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;1.0.0.127.in-addr.arpa. IN PTR ;; ANSWER SECTION: 1.0.0.127.in-addr.arpa. 259200 IN PTR localhost. ;; AUTHORITY SECTION: 0.0.127.in-addr.arpa. 259200 IN NS ns.linux.bogus. ;; Query time: 3 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Dec 23 03:02:39 2001 ;; MSG SIZE rcvd: 91
Así gestiona para obtener localhost de
127.0.0.1, bien. Ahora para nuestro tarea principal, el dominio
linux.bogus,inserta una nueva sección 'zone' en
named.conf:
zone "linux.bogus" {
notify no;
type master;
file "pz/linux.bogus";
};
Observa de nuevo la ausencia de `.' final en el
nombre de dominio en el fichero named.conf.
En el fichero de zona linux.bogus pondremos datos
totalmente ficticios
N del T:
Por si no lo has notado todavía, bogus en inglés significa precisamente falso.
;
; Fichero de zona para linux.bogus
;
; El fichero de zona completo
;
$TTL 3D
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; serie, fecha de hoy + serie de hoy #
8H ; refresco, segundos
2H ; reintento, segundos
4W ; expira, segundos
1D ) ; mínimo, segundos
;
NS ns ; Dirección Inet del servidor de nombres
MX 10 mail.linux.bogus ; Relay de correo primario
MX 20 mail.friend.bogus. ; Relay de correo secundario
;
localhost A 127.0.0.1
ns A 192.168.196.2
mail A 192.168.196.4
Deben de observarse dos cosas sobre los registros
SOA. ns.linux.bogus debe ser una
máquina actual con un registro A. No es legal
tener un registro CNAME para la máquina
mencionada en el registro SOA. Su nombre no necesita
ser ns, podría ser cualquier nombre legal de
máquina. A continuación, en
hostmaster.linux.bogus deberá aparecer algo
como hostmaster@linux.bogus; esto
sería un alias de email, o una cuenta de correo, donde la(s)
persona(s) que realizan el mantenimiento de DNS deberían
leer con frecuencia el correo. Cualquier email respecto del dominio
será mandado a la dirección aquí indicada. El
nombre no tiene por que ser hostmaster, puede ser
cualquier dirección email legal, pero la dirección
email hostmaster funcionará también.
Hay un nuevo tipo de RR en este archivo, el
MX, o Mail eXchanger. Este indica el sistema de
correo a donde mandar el correo dirigido a
alguien@linux.bogus, pudiendo ser
también mail.linux.bogus o
mail.friend.bogus. El número que precede a cada
nombre de máquina es la prioridad del RR MX. El
RR con el número más bajo
(10) es aquel al que el correo será enviado
primero. Si este falla, puede ser mandado a otro con un
número más alto, que será gestor secundario de
correo, como mail.friend.bogus que tiene una prioridad
20 aquí.
Reinicia named ejecutando rndc reload.
Examina los resultados con dig:
$ dig any linux.bogus ; <<>> DiG 9.1.3 <<>> any linux.bogus ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55239 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;linux.bogus. IN ANY ;; ANSWER SECTION: linux.bogus. 259200 IN SOA ns.linux.bogus. \ hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400 linux.bogus. 259200 IN NS ns.linux.bogus. linux.bogus. 259200 IN MX 20 mail.friend.bogus. linux.bogus. 259200 IN MX 10 mail.linux.bogus.linux.bogus. ;; AUTHORITY SECTION: linux.bogus. 259200 IN NS ns.linux.bogus. ;; ADDITIONAL SECTION: ns.linux.bogus. 259200 IN A 192.168.196.2 ;; Query time: 4 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Dec 23 03:06:45 2001 ;; MSG SIZE rcvd: 184 $ dig any linux.bogus ; <<>> DiG 9.1.3 <<>> any linux.bogus ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55239 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;linux.bogus. IN ANY ;; ANSWER SECTION: linux.bogus. 259200 IN SOA ns.linux.bogus. \ hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400 linux.bogus. 259200 IN NS ns.linux.bogus. linux.bogus. 259200 IN MX 20 mail.friend.bogus. linux.bogus. 259200 IN MX 10 mail.linux.bogus.linux.bogus. ;; AUTHORITY SECTION: linux.bogus. 259200 IN NS ns.linux.bogus. ;; ADDITIONAL SECTION: ns.linux.bogus. 259200 IN A 192.168.196.2 ;; Query time: 4 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Dec 23 03:06:45 2001 ;; MSG SIZE rcvd: 184$ dig any linux.bogus ; <<>> DiG 9.1.3 <<>> any linux.bogus ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55239 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;linux.bogus. IN ANY ;; ANSWER SECTION: linux.bogus. 259200 IN SOA ns.linux.bogus. \ hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400 linux.bogus. 259200 IN NS ns.linux.bogus. linux.bogus. 259200 IN MX 20 mail.friend.bogus. linux.bogus. 259200 IN MX 10 mail.linux.bogus.linux.bogus. ;; AUTHORITY SECTION: linux.bogus. 259200 IN NS ns.linux.bogus. ;; ADDITIONAL SECTION: ns.linux.bogus. 259200 IN A 192.168.196.2 ;; Query time: 4 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Dec 23 03:06:45 2001 ;; MSG SIZE rcvd: 184 $ dig any linux.bogus ; <<>> DiG 9.1.3 <<>> any linux.bogus ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55239 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;linux.bogus. IN ANY ;; ANSWER SECTION: linux.bogus. 259200 IN SOA ns.linux.bogus. \ hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400 linux.bogus. 259200 IN NS ns.linux.bogus. linux.bogus. 259200 IN MX 20 mail.friend.bogus. linux.bogus. 259200 IN MX 10 mail.linux.bogus.linux.bogus. ;; AUTHORITY SECTION: linux.bogus. 259200 IN NS ns.linux.bogus. ;; ADDITIONAL SECTION: ns.linux.bogus. 259200 IN A 192.168.196.2 ;; Query time: 4 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Dec 23 03:06:45 2001 ;; MSG SIZE rcvd: 184
Con un examen cuidadoso puede descubrir fallos. La línea
linux.bogus. 3D IN MX 10 mail.linux.bogus.linux.bogus.
está completamente equivocada. Debería ser
linux.bogus. 3D IN MX 10 mail.linux.bogus.
Deliberadamente cometí un error para que pudieras aprender de él. :-) Mirando en el fichero de zona encontramos la línea:
MX 10 mail.linux.bogus ; Relay de correo primario
Falta un punto. O tiene demasiados 'linux.bogus'. Si una nombre
de máquina no termina en punto, en un fichero de zona, se le
añade el origen al final ocasionado el doble
linux.bogus.linux.bogus. Entonces, o bien
MX 10 mail.linux.bogus. ; Relay de correo primario
o
MX 10 mail ; Relay de correo primario
es correcto. Prefiero la última forma, hay que teclear
menos. Hay algunos expertos den BIND que no están de acuerdo
con esto y otros que sí. En un fichero de zona el dominio
debería de escribirse bien finalizado con un
`.' o no debería incluirse, en cuyo caso toma
como valor predeterminado el origen.
Tengo que insistir que en el fichero named.conf no se
tiene que poner `.'s tras los nombres de dominio. No
tienes ni idea de cuantas veces un `.' por ponerlo o
por no ponerlo ha estropeado todo y ha vuelto loca a la gente.
Y habiendo incluido mi punto,aquí está el nuevo fichero de zona, con alguna información extra también:
;
; Fichero de zona para linux.bogus
;
; Fichero de zona completo
;
$TTL 3D
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; seriel, fecho de hoy + serie de hoy #
8H ; refresco, segundos
2H ; reintento, segundos
4W ; expira, segundos
1D ) ; mínimo, segundos
;
TXT "Linux.Bogus, sus consutas DNS"
NS ns ; Inet Address of name server
NS ns.friend.bogus.
MX 10 mail ; Relay primario de correo
MX 20 mail.friend.bogus. ; Relay secundario de correo
localhost A 127.0.0.1
gw A 192.168.196.1
TXT "El router"
ns A 192.168.196.2
MX 10 mail
MX 20 mail.friend.bogus.
www CNAME ns
donald A 192.168.196.3
MX 10 mail
MX 20 mail.friend.bogus.
HINFO "i486" "Linux 2.0"
TXT "DEK"
mail A 192.168.196.4
MX 10 mail
MX 20 mail.friend.bogus.
ftp A 192.168.196.5
MX 10 mail
MX 20 mail.friend.bogus.
El registro TXT es un texto en formato libre que
puede usar para cualquier cosa que le interese. CNAME
(Canonical NAME) es una forma de dar a cada máquina
varios nombres. Por tanto www es un alias para
ns.
El uso de registros CNAME es controvertido. Pero es más
seguro seguir la norma de que los registros MX,
CNAME y SOA nunca deben hacer
referencia a un registro CNAME, sólo deben
referirse a registros A, en consecuencia es
desaconsejable tener
foobar CNAME www ; NO!
lo correcto sería tener
foobar CNAME ns ; Si!
También es mejor suponer que un CNAME no es
un nombre de máquina legal para direcciones de correo:
webmaster@www.linux.bogus es una
dirección email ilegaldada en la configuración
anterior. Encontrarás muy pocos administradores de correo de
Ahí Afuera que recomienden esta regla, incluso si te
funciona. La forma de evitar esto es usar un registro
A (y quizá algunos otros también, como
un registro MX) en su lugar:
www A 192.168.196.2
Algunos gurús de named recomiendan no usar
CNAME. Por tanto considera el no utilizarlo seriamente. Pero la
discusión de por qué o no está más
allá de los objetivos de este documento.
Pero como puede ver, en este COMO y en muchos sitios no siguen esta regla.
Cargue la nueva base de datos ejecutando rndc
reload, esto provoca la lectura de sus archivos de
nuevo.
$ dig linux.bogus axfr ; <<>> DiG 9.1.3 <<>> linux.bogus axfr ;; global options: printcmd linux.bogus. 259200 IN SOA ns.linux.bogus. hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400 linux.bogus. 259200 IN NS ns.linux.bogus. linux.bogus. 259200 IN MX 10 mail.linux.bogus. linux.bogus. 259200 IN MX 20 mail.friend.bogus. donald.linux.bogus. 259200 IN A 192.168.196.3 donald.linux.bogus. 259200 IN MX 10 mail.linux.bogus. donald.linux.bogus. 259200 IN MX 20 mail.friend.bogus. donald.linux.bogus. 259200 IN TXT "DEK" ftp.linux.bogus. 259200 IN A 192.168.196.5 ftp.linux.bogus. 259200 IN MX 10 mail.linux.bogus. ftp.linux.bogus. 259200 IN MX 20 mail.friend.bogus. gw.linux.bogus. 259200 IN A 192.168.196.1 gw.linux.bogus. 259200 IN TXT "The router" localhost.linux.bogus. 259200 IN A 127.0.0.1 mail.linux.bogus. 259200 IN A 192.168.196.4 mail.linux.bogus. 259200 IN MX 10 mail.linux.bogus. mail.linux.bogus. 259200 IN MX 20 mail.friend.bogus. ns.linux.bogus. 259200 IN MX 10 mail.linux.bogus. ns.linux.bogus. 259200 IN MX 20 mail.friend.bogus. ns.linux.bogus. 259200 IN A 192.168.196.2 www.linux.bogus. 259200 IN CNAME ns.linux.bogus. linux.bogus. 259200 IN SOA ns.linux.bogus. hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400 ;; Query time: 41 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Dec 23 03:12:31 2001 ;; XFR size: 23 records
Está bien. Como ves, se parece bastante al propio
ficheros de zona. Comprobamos que dice para www
solo:
$ dig www.linux.bogus ; <<>> DiG 9.1.3 <<>> www.linux.bogus ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16633 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.linux.bogus. IN A ;; ANSWER SECTION: www.linux.bogus. 259200 IN CNAME ns.linux.bogus. ns.linux.bogus. 259200 IN A 192.168.196.2 ;; AUTHORITY SECTION: linux.bogus. 259200 IN NS ns.linux.bogus. ;; Query time: 5 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Dec 23 03:14:14 2001 ;; MSG SIZE rcvd: 80
En otras palabras, el nombre real de
www.linux.bogus es ns.linux.bogus, y te
da parte de la información que tiene de ns también,
suficiente si fueras un programa.
Ahora estamos a mitad de camino.
Ahora los programas pueden convertir los nombres de linux.bogus a direcciones a las que poder conectarse. Pero también se necesita una zona inversa, una para hacer que DNS sea capaz de convertir de direcciones a nombres. Ese nombre lo utilizan distintos tipos de servidores (FTP, IRC, WWW y otros) para decidir si quieren o no hablar contigo, y en caso afirmativo, qué prioridad se le debería dar. Para un acceso completo a los servicios de internet se necesita una zona inversa.
Pon esto en named.conf:
zone
"196.168.192.in-addr.arpa" {
notify no;
type master;
file "pz/192.168.196";
};
Esto es exactamente como en 0.0.127.in-addr.arpa, y
los contenidos son similares:
$TTL 3D
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; Serial, todays date + todays serial
8H ; Refresco
2H ; Reintento
4W ; Expira
1D) ; Minimo TTL
NS ns.linux.bogus.
1 PTR gw.linux.bogus.
2 PTR ns.linux.bogus.
3 PTR donald.linux.bogus.
4 PTR mail.linux.bogus.
5 PTR ftp.linux.bogus.
Ahora reinicia tu named (rndc reload) y examina el
trabajo con dig de nuevo:
$ dig -x 192.168.196.4 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58451 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;4.196.168.192.in-addr.arpa. IN PTR ;; ANSWER SECTION: 4.196.168.192.in-addr.arpa. 259200 IN PTR mail.linux.bogus. ;; AUTHORITY SECTION: 196.168.192.in-addr.arpa. 259200 IN NS ns.linux.bogus. ;; ADDITIONAL SECTION: ns.linux.bogus. 259200 IN A 192.168.196.2 ;; Query time: 4 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Dec 23 03:16:05 2001 ;; MSG SIZE rcvd: 107
y parece correcto, vuelca todo y examínalo también:
$ dig 196.168.192.in-addr.arpa. AXFR
; <<>> DiG 9.1.3 <<>> 196.168.192.in-addr.arpa. AXFR
;; global options: printcmd
196.168.192.in-addr.arpa. 259200 IN SOA ns.linux.bogus. \
hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400
196.168.192.in-addr.arpa. 259200 IN NS ns.linux.bogus.
1.196.168.192.in-addr.arpa. 259200 IN PTR gw.linux.bogus.
2.196.168.192.in-addr.arpa. 259200 IN PTR ns.linux.bogus.
3.196.168.192.in-addr.arpa. 259200 IN PTR donald.linux.bogus.
4.196.168.192.in-addr.arpa. 259200 IN PTR mail.linux.bogus.
5.196.168.192.in-addr.arpa. 259200 IN PTR ftp.linux.bogus.
196.168.192.in-addr.arpa. 259200 IN SOA ns.linux.bogus. \
hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400
;; Query time: 6 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 23 03:16:58 2001
;; XFR size: 9 records
¡Parece bien! Si tu salida no se parece, busca algún mensaje de error en tu syslog, explico como hacerlo en la primera sección en la cabecera Starting named
Hay algunas cosas que añadiría aquí. Las
direcciones IP utilizadas en los ejemplos se han tomado del rango
de 'redes privadas',i.e., no se permite usarlas públicamente
en internet. Esto es más seguro para usar en un ejemplo en
el COMO. Las segunda cosa es la línea notify
no;. Esta le dice a named que no notifique a sus servidores
secundarios (eslave, esclavos) cuando haya realizado una
actualización de uno de sus ficheros de zona. En BIND-8 y
posteriores named puede notificar al resto de servidores listados
en registros NS de la zona cuando se actualiza una zona. Es bueno
para el uso ordinario. Pero para experimentos privados con zonas,
se debería deshabilitar esta característica. No
queremos que los experimentos contaminen internet ¿no?.
Y por supuesto, este dominio es ficticio y en consecuencia, todas las direcciones que hay en él. Para tener un ejemplo de dominio de la vida real mira la sección correspondiente.
Hay una serie de pegas que normalmente se evitan con búsquedas de nombres que se ven con frecuencia cuando se configuran las zonas inversas. Ante de proseguir, necesitas que funcionen las búsquedas inversas en tu propio servidor de nombres. Si aun no funciona vuelve atrás y corrígelo antes de continuar.
Discutiré dos fallos de las búsquedas inversas tal y como se ven desde fuera de tu red:
Cuando le solicita a un proveedor de servicios un rango de red y un nombre de dominio, el nombre de dominio normalmente se delega. Una delegación es el registro NS que te ayuda a obtener de un servidor de nombres otro servidor de nombres, como se explicaba en la anterior sección "Un poco de teoría a secas". ¿La has leído? Si tu zona inversa no funciona, vuelve y léela. Ahora.
La zona inversa también necesita ser delegada. Si tienes
la red 192.168.196 con el dominio
linux.bogus de tu proveedor, ellos tienen que poner
registros NS para tu zona inversa también como
para tus zonas de reenvío. Si sigues la cadena desde
in-addr.arpa hasta llegar a tu red, probablemente
encontrarás una ruptura en la cadena, los más
probable en tu proveedor de servicios. Cuando hayas encontrado la
ruptura de la cadena, contacta con tu proveedor de servicios y
pídeles que corrijan el error.
Esta es una cuestión avanzada, pero las subredes sin clase son muy comunes hay día, y probablemente tendrás una si tienes una pequeña empresa.
Las subredes sin clase es lo que mantiene internet en funcionamiento hoy día. Hace algunos años. Hace no mucho tiempo había mucha dificultad para acortar las direcciones IP. La gente inteligente del IETF (Internet Engineering Task Force, ellos mantienen internet en funcionamiento) se devanaron juntos los sesos y resolvieron el problema. A un precio. El precio es que obtienes menos que una subred de clase ``C'' y ciertas cosas pueden no funcionar. Por favor mira Preguntar a Mr. DNS (Ask Mr. DNS at) para tener una buena explicación sobre todo esto y como gestionarlo.
¿Lo has leído? No lo voy a explicar, por favor léelo.
La primera parte del problema es que tu ISP tiene que entender la técnica descrita por Mr. DNS. No todos los pequeños proveedores comprenden esto de forma práctica. Si es así, tendrías que explicárselo tú y ser insistente. Pero primero asegúrate de entenderlo tú :-). Así ellos configurarán un bonita zona inversa en sus servidores que tú puedes examinar con dig para posibles correcciones.
La segunda y última parte del problema es que tienes que entender la técnica. Si no estás seguro, vuelve y lee todos esto de nuevo. Ahora puedes configurar tu propia zona inversa sin clases como lo describe Mr. DNS.
Hay otra trampa escondida aquí. Los resolutores (muy)
viejos no podrán seguir el truco CNAME
en la cadena de resolución y fallarán en la
resolución inversa de tu máquina. Esto puede
ocasionar en el servicio la asignación de una clase de
acceso incorrecta, denegación de acceso o algo similar. Si
tropiezas con este servicio la única solución (que yo
sepa) es que tu ISP inserte tu registro PTR directamente en su
fichero de zona sin clase en lugar del truco del registro
CNAME.
Algunos ISP te pueden ofrecer otras formas de gestionar esto, como formularios Web para que introduzca las relaciones inversas u otros sistema automágicos.
Una vez que hayas configurado tus zonas correctamente en el servidor principal, necesitas configurar al menos un servidor esclavo. Los servidores esclavos son necesarios por motivos de robustez. Si cae el servidor principal, la gente de la red todavía podrá obtener información sobre tu dominio a partir del esclavo. Tu servidor esclavo debería estar tan alejado de ti como sea posible. El principal y el esclavo deberían compartir los menos posibles de entre estos aspectos: Suministro eléctrico, red local, ISP, ciudad país. Si todas estas cosas son diferentes para sus servidores principal y esclavo, ha encontrado realmente un buen esclavo.
Un esclavo es simplemente un servidor de nombres que copia los ficheros de zona de un principal. Lo puedes poner como:
zone "linux.bogus" {
type slave;
file "sz/linux.bogus";
masters { 192.168.196.2; };
};
Para copiar los datos se usa un mecanismo llamado transferencias de zona. La transferencia de zona esta controlada por su registro SOA:
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; serie, fecha de hoy + serie de hoy #
8H ; refresco, segundos
2H ; reintento, segundos
4W ; expira, segundos
1D ) ; minimo, segundos
Una zona solo se transfiere si el numero de serie del principal es mayor que el del esclavo. En cada intervalo de refresco el esclavo comprueba si el principal se ha actualizado. Si la comprobación falla (porque el principal no esté disponible) intentará comprobarlo cada intervalo de reintento. Si el fallo continúa hasta el intervalo de expiración el esclavo eliminará la zona de su sistema de ficheros y ya no volverá a estar disponible.