Copy Link
Add to Bookmark
Report
4x12 Configuracion del Sistema de Nombre de Dominio
~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
kSh kSh kSh kSh kSh kSh
~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
Configuracion del Sistema de Nombre de Dominio
(DNS: Domain Name System)
by Byte64
El Servidor de Nombres de Dominio (DNS)
----------------------------------------
El surgimiento del Servidor de Nombres de Dominio esta estrechamente vinculado
con Internet, al resolver uno de los primeros problemas que sepresentaron en
sus primeros a¤os. Su importancia es tal, que en la actualidad todos los
servicios de Internet trabajan con el DNS.
---[ 1.1 Historia del Sistema de Nombre de Dominios ]----
En los a¤os 1970, ARPNet fue peque¤a, una comunidad amigable de unos pocos
cientos de hosts. Un solo archivo, HOSTS.TXT contenia toda la informacion
necesaria para conocer a estos hosts. El Sistema Operativo mantenia mapa de
nombres con sus direcciones asociadas para cada hosts conectado a ARPNet; la
familiar tabla de hosts de UNIX
/etc/hosts.
Este archivo era mantenido por el Instituto de Investigacion de Stanford (SRI)
en el NIC (Centro de Informacion de la Red) y distribuido en un solo archivo.
El administrador de ARPNet hacia los cambios en este, via correo electronico y
periodicamente hacia un FTP al SRI-NIC en el actual HOSTS.TXT. Luego estos
cambios eran compilados en un nuevo archivo HOSTS.TXT una o dos veces a la
semana. A medida como ARPANet crecio, este esquema era inmanejable. El tama¤o
del archivo crecio proporcionalmente al numero de hosts de la Red. El trafico
generado por la actualizacion se incremento en lugar de ser mas rapido; cada
hosts adicional no solo significaba otra linea en el archivo HOSTS.TXT, sino
otra actualizacion en el archivo del SRI-hot.
Al moverse ARPNet hacia el protocolo TCP/IP, el numero de hosts hizo
explosion. Es ahora que existia el problema del archivo HOSTS.TXT:
- Trafico y Carga
Esto aplicado sobre el SRI-NIC, en terminos de trafico en la Red la carga del
procesador lo hacia inoperable.
- Colisiones de Nombre
Dos hosts en el archivo HOSTS.TXT no podian tener el mismo nombre. Por un lado
el NIC asignaba direcciones IP, aunque no tenia control que dos hosts le
pusiesen el mismo nombre. No tenian ningun medio para prevenir estos
conflictos.
- Consistencia
La consistencia del mantenimiento de un archivo a traves de toda la Red se fue
poniendo cada vez mas dificil de manejar.
El problema principal era que el mecanismo del HOSTS.TXT no era bien
escalable.
Ante este problema ARPNet se dio a la tarea de buscar una solucion a esto.
Donde se pensaba crear un sistema que resolviera la inherencia y la
unificacion en un sistema de tablas de hosts. Este nuevo sistema deberia
permitir la administracion local de los datos que se pondrian disponibles
globalmente. La descentralizacion de la administracion podrian eliminar los
cuellos de botellas en un solo hosts y aliviar el problema del trafico. Una
administracion local podria hacer las tareas de actualizacion de los datos
mucho mas facil. Esto deberia usar un espacio de nombres jerarquicos para los
nombres de los hosts. Debiendo asegurar los nombres unicos de los hosts.
Paul Mockapetris, del Instituto de Ciencias de Informacion, fue el responsable
de dise¤ar la arquitectura del nuevo sistema. En 1984, se emitieron los
primeros RFC sobre DNS (Documentos para Comentarse), numeros 882 y 883 hasta
llegar a los actuales el 1034 y 1035.
---[ 1.2 El sistema de Nombres de Dominios ]----
El Sistema de Nombres de Dominios es una base de datos distribuida. Esto
permite un control local de los segmentos de toda la gran base de datos, los
datos son mantenidos disponibles en cada segmento bajo el modelo cliente
servidor. Una adecuada y consistente ejecucion es lograda a traves de replicas
y copias.
El programa llamado Servidor de Nombres comprende el cliente y el servidor
DNS. El servidor de nombres contiene informacion sobre los segmentos de la
base de datos y los pone a la disposicion del cliente. Este consulta rutinas
que crean consultas y envios hacia la red de servidores de nombres.
La estructura de la Base de Datos del DNS (Sistema de Nombres de Dominio) es
muy similar a la estructura de los sistemas de archivos de UNIX , ver figura
2.1.
-----
| / |
|_____|
|
-------------------------------------
| | | |
----- ----- ----- -----
| etc | | bin | | usr | | var |
|_____| |_____| |_____| |_____|
/ \ / \ / \ / \
/ \ / \ / \ / \
--- --- --- --- --- --- --- ---
| | | | | | | | | | | | | | | |
|___| |___| |___| |___| |___| |___| |___| |___|
/ \ / \ / \ / \
/ \ / \ / \ / \
--- --- --- --- --- --- --- ---
| | | | | | | | | | | | | | | |
|___| |___| |___| |___| |___| |___| |___| |___|
Figura 2.1: Sistema de archivos UNIX
Donde cada nodo en la representacion del arbol representa una porcion de la
gran base de datos.
De esta manera se resuelven los problemas del HOSTS.TXT. Por ejemplo haciendo
nombres jerarquicos se elimina el riesgo de colisiones de nombre. Los nombres
de dominio son unicos, sin embargo las organizaciones puede escoger el nombre
mas adecuado. Al escoger el mismo nombre de sub-dominio no se tendran
conflictos de nombres de dominio, ya que estos son unicos.
El DNS no siempre es necesario que este activado, dependera de las condiciones
de la red de computadoras. Existen los siguientes casos.
_________________________________________________________________________
| CASO | APLICACION |
|----------------------------------|--------------------------------------|
| - Sin conexion a Internet | No es necesario activarlo. |
|----------------------------------|--------------------------------------|
| - Conexion del tipo UUCP | Seria una buena idea aunque no es |
| | obligatorio. |
|----------------------------------|--------------------------------------|
| - Usted tiene una red basada en | Solo en el caso de que tenga |
| TCP/IP | maquinas homogueneas. |
|----------------------------------|--------------------------------------|
| - Tiene su propia Red de Area | Y no esta conectada a una gran Red. |
| Local | Si usted distrubuira la admon en la |
| | Red podria ser una buena alternativa|
---------------------------------------------------------------------------
---[ 1.3 Funcionamiento del DNS ]----
El Sistema de Nombres de Dominios es básicamente una base de datos de
informacion de hosts (Servidores anfitriones) que se utiliza para mantener
informacion de cada numero IP con el cual se identifica una maquina en una red
de redes y de esa forma poder direccionar mejor los paquetes.
Para entender mejor el funcionamiento del DNS, se describiron los terminos
usados en el mismo.
- Espacio de Nombres:
Cada unidad de datos en la base de datos distribuida del DNS es indexada por
un nombre. Estos nombres son esencialmente caminos en un gran arbol invertido,
llamado el Espacio de Nombres de Dominio. Este arbol con estructura
jerarquica es similar a la estructura de los sistemas de archivos de UNIX ver
Figura 2.2.
-----
| / |
|_____|
|
-------------------------------------
| | | |
----- ----- ----- -----
| COM | | EDU | | GOV | | ORG |
|_____| |_____| |_____| |_____|
/ \ / \ / \ / \
/ \ / \ / \ / \
--- --- --- --- --- --- --- ---
| | | | | | | | | | | | | | | |
|___| |___| |___| |___| |___| |___| |___| |___|
/ \ / \ / \ / \
/ \ / \ / \ / \
--- --- --- --- --- --- --- ---
| | | | | | | | | | | | | | | |
|___| |___| |___| |___| |___| |___| |___| |___|
Figura 2.2: Base de Datos - DNS
- Nombres de Dominios:
Cada nodo en el arbol esta etiquetado con un nombre sencillo sin puntos con
una longitud maxima de 63 caracteres. El dominio raiz (principal) es una
etiqueta nula (longitud cero), la cual es reservada. El nombre de dominio
completo de cualquier nodo en el arbol es la secuencia de etiquetas del camino
desde del nodo al raiz. Los nombres de dominio siempre se leen del nodo hacia
la raiz (parte superior del arbol), los puntos separan los nombres en el
camino.
- Dominios:
Un dominio es un sub arbol del espacio de Nombres de dominios. El nombre de un
dominio es el mismo que el nombre de dominio al nodo raiz del sub arbol.
- Dominios del nivel principal:
El sistema de nombres de dominios no impone ninguna regla sobre los nombres de
los nombres de dominios.
Los dominios originales del nivel superior son:
com : Organizaciones comerciales
edu : Organizaciones educativas
gov : Organizaciones gubernamentales
mil : Organizaciones Militares
net : Organizaciones de Redes de computadoras.
org : Organismos no comerciales
int : Organismos Internacionales.
- Delegacion:
Recordemos que uno de los principales objetivos del dise¤o de los Sistemas de
Nombres de Dominios fue la descentralizacion de la administracion. Esto es
logrado a traves de la delegacion. La delegacion de dominios trabaja con un
set de tareas de delegacion de numeros IP manejados por cada NIC de cada pais
de esta forma el manejo por parte de INTERNIC es mas eficiente, al delegar las
consulta por pais.
----- Direccion de server.org __ ""
Respuesta | Consulta ______ |__|
| ----------| NS "" ||
| | ||
|___| \/
---- ORG
| | ||
| | ||
| | \/
| |---------|NS org server
| -|------ / \
| | _______________ / \
| |_____| NS.server.org | / \
| ns byte
| __________________
|____________________| byte.server.org |
Figura 2.3: Resolucion de un nombre en Internet
- Servidores de Nombres:
Es el programa que almacena la informacion acerca del espacio del nombre de
dominio. Estos generalmente tienen informacion completa sobre una parte del
espacio de nombres de dominio llamada zona. El servidor de nombres es tambien
llamado a tener autorizacion sobre la zona. Aunque tambien puede estar
autorizado a tener multiples zonas.
La diferencia entre zona y dominio es sustancial. Una zona contiene los
nombres de dominio y los datos de ciertos dominios, excepto los nombres de
dominio y los datos de las delegaciones.
- Tipos de Servidores de Nombres:
Estan definidos dos tipos de servidores de nombres, los maestros primarios y
los maestros secundarios. Los maestros primarios tienen los datos de las zonas
autorizadas. Un maestro secundario obtiene los datos de la zona de otro
servidor autorizado por la zona.
- Servidores de Nombres Raíces:
Se les conoce a los servidores de nombres autorizados para todos los dominios
del nivel principal, se llaman de nivel principal a aquellos servidores como
org, net, edu, mil, etc, todos estos son administrados por INTERNIC e incluso
el .ni es uno de nivel principal este es administrado por el NIC-NI cuya
oficinas estan en la UNI Universidad Nacional de Ingenieria.
1.4 Configuracion de un servidor de Nombres
Para tomar como ejemplo vamos a configurar el servidor de nombres para el Nodo
__ ""
|__|
|
_____|
|
ni
|
__________________________________
| | | |
com edu org gob
/ \ / \ / \ / \
/ \ / \ / \ / \
ibw tmx uni uam ops server mede mifin
/| / /\ | | /\
/ | / / \ | | / \
sprintf ns ns sunlab ns tigre ns ns byte
Figura 2.5: Base de Datos - DNS Nicaragua
- Nuestro dominio:
Bajo las reglas vigentes de nombres de dominio en nicaragua, reglamentadas por
el NIC-NI (Network Information Service de nicaragua), bajo la responsabilidad
de la Universidad Nacional de Ingenieria a la RDS - Nicaragua le corresponde
el dominio server.org por ser un organismo no gubernamental en nicaragua.
Los datos de configuracion de la red TCP/IP son listados en la Tabla 2.1
_______________________________________________
| Numeros IP | clase C: 127.0.0.130 |
| Netmask | 255.255.255.128 (interna) |
| dominio | Server.org |
| sub-redes | 2 |
|______________|______________________________|
- Asignacion de IP de la red RDS - Nicaragua.
La RDS - Nicaragua cuenta con una red TCP/IP en topologia estrella, y posee
los siguientes equipos figura 2.6,
+ Cuatro servidores.
+ ns es el servidor de nombre y servidor de correo.
+ www servidor web
+ ns1 servidor UUCP
+ verde servidor de prueba
+ byte servidor para tesis.
+ Un enrutador Cisco 2500
+ Rack de modem Microcom 4000
+ Red interna con 8 maquinas.
----- -----
| PC1 |-----\ | NS1 |---\ /--------------- INTERNET
----- | ----- | |
| | --------
----- | ------- | | Router |
| PC2 |-----| | VERDE |--| --------
----- | ------- | |
| | |
----- | | ----- ------------
| PC3 |-----|-------------------|-----| HUB |--| Rack-Modem |
----- | | ----- ------------
| | |
----- | ------- | |
| PC4 |-----| | WWW |--| -----------------
----- | ------- | | PortMaster PM2e |
| | -----------------
----- | ---- |
| PC5 |-----/ | NS |----|
----- ---- |
|
------ |
| byte |---/
------
Figura 2.6: Distribucion de la red de computadoras RDS - Nicaragua
---[ 1.5 Configurando los datos del DNS ]----
Lo primero que se hace es trasladar la tabla de hosts a su equivalente en los
datos del DNS. El cual tiene varios archivos:
- Un archivo de mapas de los nombres de hosts con sus direcciones
- Un archivo de mapas de las direcciones inversas con los nombres de los
hosts.
- El nombre de las direcciones loopback alguna veces llamada mapa de
reversa.
- Cada sub-red tiene sus propios archivos de mapas de reversas.
Para nombrar los archivos no existe ninguna regla. Sin embargo la mayoria de
los administradores siguen algunos nombres estandar.
En este caso se mantiene la siguiente convencion:
+ El archivo de mapas de los nombres con las direcciones es: DOMAIN.zone,
donde DOMAIN es el dominio y Zone la zona de trabajo para el dominio X.
ejemplo:
en server.org : server.zone
en byte.nom : byte.zone
+ El archivo de mapa de las direcciones de reversa de los nombres de hosts
es: ADDR.rev, ADDR es la direccion del clase IP pero sin el ultimo
bloque que lo ocupa la palabra rev (reversa)
ejemplo:
127.0.0.130 : 127.0.0.rev
+ Otros archivos: Estos otros archivos el named.root contiene los ip de
los principales servidores y el named.local es el que se sustituye
por domain.zone, el cual mantiene los IP de todas nuestras maquinas
named.root
DOMAIN.local
Named.conf
Para conocer que archivos usara el servidor de nombres, puede revisar su
archivo de inicializacion, que por lo general esta en: /etc/named.boot este
archivo contiene la inicializacion de los dominios asi como los archivos de
reversa, tambien esta el named.conf en el cual se encuentra la direccion y
carga del DNS.
+ Los Archivos db
Muchas entradas en los archivos son llamadas registros de recursos DNS. El
servidor de nombres no diferencia entre minusculas y mayusculas, ni tampoco el
orden de los registros. Pero se recomienda para una mejor legibilidad de los
archivos el siguiente orden:
REGISTROS:
* SOA Indican la autorizacion para los datos del dominio
* NS Lista de los servidores de nombres para este dominio
* Other Datos sobre el host en este dominio
Estos ultimos cubren:
* A Mapeos de Nombres a direcciones
* PTR Mapeos de Direcciones a nombres
* CNAME Nombres canonicos (para alias)
* TXT Informacion Textual
Los archivos db estan en formato texto y el servidor de nombres ignora las
lineas que inician con ";" y las lineas en blanco.
Registros SOA: (Autorizacion para los datos del dominio)
La primera entrada en los archivos son los registros SOA. Los que indican que
el servidor de nombres en ns.server.org es el mejor recurso de informacion de
los datos dentro del dominio. Este registro es requerido en server.zone,
byte.zone y 205.2182.248.rev.
server.org IN SOA ns.server.org root.server.org (
20000501 ; Numero Serial
10800 ; Refresh after 3 hours
3600 ; Retry after 1 hour
604800 ; Expire after 1 week
86400 ) ; Minimum TTL of 1 day
El registro debe comenzar con el nombre del dominio server.org con un punto al
final. La palabra IN se¤ala que la clase de datos es Internet.
El segundo nombre root.server.org es una direccion electronica que resulta al
sustituir el primer punto con "@", es decir root@ns.server.org
Esta dirección electronica es para permitir el envio de correos al
administrador del Servidor de Nombres.
Los parentesis son para permitir que existan multiples lineas dentro de un
registro SOA.
Este mismo registro fue agregado en los archivos 127.0.0.rev con el unico
cambio que en lugar de poner server.org se puso 248.218.205.in-addr.arpa.
respectivamente.
Registros NS:
La proxima entrada son los registros NS (Servidores de Nombre). Donde se dice
que existe un servidor de nombres accesibles para el dominio server.org que es
ns.server.org
server.org IN NS ns.server.org
Estas lineas fueron tambien agregadas en los archivos 127.0.0.rev
Direcciones y Registros de Alias:
Ahora se crearan los mapeos de nombres con direcciones, en el archivo
server.zone
;
; Direcciones Host
;
localhost.server.org IN A 127.0.0.1
ns.server.org IN A 127.0.0.130
; Alias
;
www IN CNAME 127.0.0.130.
Las lineas que tienen una A significa que lo que sigue es una direccion IP. El
segundo bloque definen las maquinas que tiene mas de una interface de red
conectada. El siguiente bloque define los alias donde se creo el alias www
para el web que se le asocia al IP de la maquina ns.server.org La manera en
que maneja los alias el servidor de nombres a como la maneja la tabla hosts.
Cuando un servidor de nombres busca un nombre de maquina y encuentra un
registro CNAME, este reemplaza el nombre por el del nombre canonico y busca el
nuevo nombre.
Registros PTR:
Los mapas de direcciones a nombres en los archivos 127.0.0.rev Los registros
usados para estos mapas son punteros a estos registros. Hay un registro por
cada interface de host sobre la red. Estas son las direcciones de reversa.
127.0.0.205.in-addr.arpa. IN PTR ns.server.org
127.0.0.205.in-addr.arpa. IN PTR verde.server.org
127.0.0.205.in-addr.arpa. IN PTR ns1.server.org
Para el archivo 127.0.0.rev
Ahora todos los archivos completos:
Archivo server.zone
server.org IN SOA ns.server.org root.server.org (
20000501 ; Numero Serial
10800 ; Regresh after 3 hours
3600 ; Retry after 1 hour
604800 ; Expire after 1 week
86400) ; Minimum TTL of 1 day
; Servidores de Nombres
server.org IN NS ns.server.org
IN NS ni.
;
; Direcciones Host
localhost.server.org IN A 127.0.0.1
ns.server.org IN A 127.0.0.130
ns1.server.org IN A 127.0.0.135
verde.server.org IN A 127.0.0.131
;
; Alias
www IN CNAME ns.server.org
Archivo 127.0.0.rev
&TTL 86400
130.12.0.207.in-addr.arpa. IN SOA ns.server.org root.server.org (
2000051501 ; Numero Serial
10800 ; Regresh after 3 hours
3600 ; Retry after 1 hour
604800 ; Expire after 1 week
;
; Servidores de Nombres
;
130.12.0.207.in-addr.arpa. IN NS ns.server.org
;
; Punteros de direcciones a nombres canonicos
;
127.0.0.205.in-addr.arpa. IN PTR ns.sdnhot.org
127.0.0.205.in-addr.arpa. IN PTR verde.sdnhot.org
127.0.0.205.in-addr.arpa. IN PTR ns1.sdnhot.org
La direccion Loopback
Un servidor de nombres requiere un archivo adicional para la red loopback; la
cual es una direccion especial para que el host (Maquina anfitrion) pueda
direccionar el trafico hacia el mismo. La red es siempre la 127.0.0 y el
numero del host siempre sera el 127.0.0.1. Es por eso que este archivo no se
debe eliminar
Contenido del archivo
server.local
0.0.127.in-addr.arpa. IN SOA ns.server.org root.server.org (
20000501 ; Numero Serial
10800 ; Regresh after 3 hours
3600 ; Retry after 1 hour
604800 ; Expire after 1 week
86400) ; Minimum TTL of 1 day
;
; Servidores de Nombres
;
0.0.127.in-addr.arpa. IN NS ns.server.org
0.0.127.in-addr.arpa. IN NS byte.nom .
;
; Punteros de direcciones a nombres canonicos
;
1.0.0.127.in-addr.arpa. IN PTR localhost.
Los Datos del Cache:
Asi como su servidor necesita informacion local, el servidor tambien necesita
conocer los servidores de nombre del nodo raiz. Esta informacion debe ser
traida de Internet en la maquina hot.ddn.mil, accesando via ftp anonymous el
archivo /netinfo/root-servers.txt.
El contenido de este archivo root-server.txt:
. 99999999 IN NS ns c.ddn.mil
. 99999999 IN NS ns.nasa.gov
ns c.ddn.mil. 99999999 IN A 192.112.36.4
ns.nasa.gov. 99999999 IN A 192.52.195.10
El nombre de dominio "." se refiere al dominio raiz.
El servidor de Nombres usa el tiempo establecido para realizar consultas con
los servidores de nombre del raiz de la lista actual en el archivo named.root
. Cuando esta lista expira vuelve a leer los tiempos en el archivo. Cuando el
tiempo es de 99999999 quiere decir que los datos se mantendran un largo tiempo
aunque estos datos una vez que son leidos los guarda en un lugar de donde no
se borran aun que ya hayan expirado.
---[ 1.5 Configurando el archivo de inicializacion del Servidor de Nombres ]--
Con los archivos de configuracion creados resta decirle al Servidor de Nombres
que lea los archivos, mediante un archivo de configuracion llamado named.boot
y named.conf.
Usualmente este archivo contiene la ubicacion de los archivos del Servidor.
;
; boot file for name server
; server.org
; Last update 15/Abril/2000
;
directory /etc/domain
; type domain source host/file backup file
;domain server.org
primary server.org server.zone
primary 130.12.0.207.in-addr.arpa 127.0.0.rev
primary 0.0.127.in-addr.arpa server.local
cache . named.root
;
Por lo general este archivo esta almacenado en el directorio /etc/ y se llama
named.boot.
En la configuracion anterior se¤ala:
+ El directorio de los archivos del DNS es /etc/domain
+ El host es el servidor primario del dominio y que el archivo de
los nombres de host es server.zone
+ Los mapas de direcciones inversas estan en el archivo 127.0.0.rev
+ Las direcciones lookup estan en el archivo server.local
+ Los datos del cache estan en el archivo named.root
Para conocer las variables que usa su version de DNS lea el archivo
/etc/named.boot antes de crear el nuevo archivo con los datos del sistema.
Agregando Dominios:
El segundo campo el archivo de inicializacion del Servidor de Nombres tiene el
dominio, este dominio es agregado a todos los nombres que no terminan con un
punto dentro de los archivos db.* Sin embargo esta variable no es aceptada
por todas las versiones disponibles del DNS.
En el archivo server.zone
ns.server.org IN A 127.0.0.130
quedaria:
ns IN A 127.0.0.130
En el archivo db.127.0.0.0
127.0.0.205.in-addr.arpa. IN PTR ns.server.org
quedaria:
130 IN A ns.server.org
Notacion @:
Si el nombre del dominio es el mismo que el origen, este puede ser
especificado por "@". Por lo que los registros SOA, quedarian:
@ IN SOA ns.server.org root.ns.server.org (
2000051501 ; Numero Serial
10800 ; Refresh after 3 hours
3600 ; Retry after 1 hour
604800 ; Expire after 1 week
86400) ; Minimum TTL of 1 day
; Repitiendo el ultimo nombre:
Si el nombre de un registro (que inicie en una sola columna) es un espacio o
un tabulador, entonces el nombre del ultimo registro es usado.
Por ejemplo:
ns IN A 127.0.0.130
podria quedar como:
ns IN A 127.0.0.130
A continuacion se muestran los archivos completos del DNS, los cuales se dan
como ejemplo en archivos compactados, en formato zip:
Archivo server.zone
@ IN SOA ns.server.org root.server.org (
2000051501 ; Numero Serial
10800 ; Refresh after 3 hours
3600 ; Retry after 1 hour
604800 ; Expire after 1 week
86400) ; Minimum TTL of 1 day
;
; Servidores de Nombres esta implicito el "@"
;
IN NS ns.server.org
IN NS ns .
;
;
; Hosts del dominio
localhost IN A 127.0.0.1
sdn1 IN A 127.0.0.129
ns IN A 127.0.0.130
verde IN A 127.0.0.131
iguana IN A 127.0.0.136
leon IN A 127.0.0.137
ipn IN A 127.0.0.138
prolena IN A 127.0.0.139
ns1 IN A 127.0.0.135
www IN A 127.0.0.146
proxy IN A 127.0.0.146
pm IN A 127.0.0.142
marlon IN A 127.0.0.148
byte IN A 127.0.0.147
bosawas IN A 127.0.0.152
siapaz IN A 127.0.0.153
miraflores IN A 127.0.0.154
webmail IN A 127.0.0.146
correo IN A 127.0.0.147
metadatos IN A 127.0.0.146
; Alias
smtp IN CNAME ns.server.org
pop IN CNAME ns.server.org
;Algoritmo MX
server.org IN MX 1 ns.server.org
Archivo 127.0.0.rev
@ IN SOA ns.server.org root.server.org (
2000.51501 ; Numero Serial
10800 ; Regresh after 3 hours
3600 ; Retry after 1 hour
604800 ; Expire after 1 week
86400) ; Minimum TTL of 1 day
;
; Servidores de Nombres
;
IN NS ns.server.org
;
; Punteros de direcciones a nombres canonicos
;
$ORIGIN 130.12.0.207.in-addr.arpa.
129 IN PTR sdn1.server.org
130 IN PTR ns.server.org
131 IN PTR verde.server.org
132 IN PTR www.server.org
133 IN PTR www.undp.org
134 IN PTR www.conades.gob
136 IN PTR iguana.server.org
137 IN PTR leon.server.org
138 IN PTR ipn.server.org
139 IN PTR prolena.server.org
135 IN PTR ns1.server.org
146 IN PTR proxy.server.org
145 IN PTR www.cybernet.com
147 IN PTR byte.server.org
148 IN PTR marlon.server.org
150 IN PTR www.tns.org
152 IN PTR bosawas.server.org
153 IN PTR siapaz.server.org
154 IN PTR miraflores.server.org
155 IN PTR www.marena.gob
server.local:
@ IN SOA ns.server.org root.ns.server.org
(
2000012001 ; Serial a¤o|mes|dia|version
10800 ; Refresh every 3 hours
3600 ; Retry every hour
3600000 ; Expire after 1000 hs.
604800 ; Minim TTL=1 week
)
; Quienes son los servidores de nombres para este dominio
IN NS ns.server.org
; Hosts de este dominio
IN NS ns.server.org
1 IN PTR localhost.
; Punteros de direcciones a nombres canonicos
;
1 IN PTR localhost.
---[ 1.6 Ejecutando el Servidor de Nombres Primario ]----
Luego que se configuraron todos los archivos necesarios, se esta preparado
para inicializar el Servidor de Nombres. La ubicacion del archivo binario
varia de un sistema Operativo a otro:
Linux: /sbin/named
SUN OS: /sbin/named
Este debe ser ejecutado como supervisor por defecto busca su archivo de
inicializacion en /etc/named.boot al menos que se le diga donde esta.
# /sbin/named
Donde named es el demonio o proceso que manda a reconocer la configuracion
realizada en el proceso de inicializacion del servidor en el archivo
named.boot.
---[ 1.6 Chequeo de errores ]----
Los mensajes de error del trabajo de los programas demonios del sistema se
almacenan en el archivo /var/log/messages, aunque dependera de donde se
localice dicho archivo dentro de la configuracion del syslog.conf
Cada error producido por el Servidor de Nombres tendra el nombre del programa
seguido del nombre del proceso por ejemplo:
Feb 28 12:30:10 terminator named[9292]: Line13: Unknown type:
Para eliminar el proceso se debe buscar con:
# ps -aux | grep named
# kill -9 <numero_de_proceso> del named
---[ 1.7 Prueba de Servidor de Nombres con el nslookup ]----
Esta utilidad del Servidor de Nombres permite la busqueda de cualquier tipo de
registro y puede realizar consultas directas con un servidor de nombres.
Si todo esta bien podriamos obtener la siguiente secuencia:
$nslookup
>
Default Server: ns.server.org
Address: 127.0.0.130
En caso contrario puede tener el siguiente error:
$nslookup
> *** Can't find initialize address for server: Non-existent domain
Nota: En caso de error se debe revisar el archivo /var/log/messages y/o
revisar minuciosamente la configuracion recien creada.
---[ 1.8 Editando archivos de inicializacion del host ]----
Los nombres y ubicacion de los archivos de inicializacion dependeran del
Sistema Operativo y en algunos casos de la version de este. Por ejemplo:
SUN OS: /etc/rc.local
Linux: /etc/rc.d/rc.inet?
Lineas tipicas de inicializacion serian:
if test -x /sbin/named -a -f /etc/named.boot
then
echo "Starting named"
/sbin/named
fi
---[ 1.9 Servidor de Nombres Secundario ]----
Para fortalecer los Servidores de Nombres, es recomendable activar al menos un
Servidor de Nombres Secundario. Este permitira compartir la carga con el
Servidor de Nombres principal o manejar todo el trabajo cuando el principal
este fuera de servicio. No es recomendable activar dos servidores como
primarios.
Cuando se activa un servidor de Nombres en el archivo named.boot se especifica
si trabaja como primario o secundario de la zona. El resto de registros son
iguales para un servidor primario o secundario.
La diferencia crucial entre los servidores primarios o secundarios es que
datos mantiene. Un servidor primario lee datos de los archivos de
configuracion. El servidor secundario toma los datos de la Red de otro
Servidor de Nombres. Este proceso es llamado transferencia de zona.
Un servidor secundario no esta limitado a cargar los datos de un Servidor de
Nombres, sino que puede hacerlo de otro Servidor de Nombres que le pueda
brindar la informacion para actualizar sus zonas. Los servidores secundarios
tiene una gran ventaja ya que solo debe hacer el mantenimiento de un set de
Bases de Datos. Estos servidores no requieren cargar todos las bases de Datos,
los archivos named.root y server.local. son los mismos que el primario. De
esta manera un secundario es primario de 0.0.127.in-addr.arpa.
Como ejemplo el dominio server.org es un servidor secundario para el dominio
linux.org, para esto se agrega al archivo tal a como se ve.
Archivo named.boot
; boot file for name server
; Actualizado 20/Ene/2000
;
directory /etc/domain
; type domain source host/file backup file
cache . root.cache
;domain server.org
primary server.org server.zone
primary 0.0.127.IN-ADDR.ARPA named.local
primary 130.12.0.207.IN-ADDR.ARPA 127.0.0.rev
;
primary conades.gob conades.zone
primary undp.org undp.zone
primary cybernet.com cybernet.zone
primary tns.org tns.zone
secundary linux.org linux.zone
El objetivo de tener un servidor secundario es que al momento de caerse el
dominio o que no pueda rasolver las direcciones para su zona, en este caso
quien responde o lo auxilia es quien hace el trabajo por el, o sea el servidor
de nombre secundario.
Archivos de Respaldo:
Los secundarios no requieren tener copias de respaldo de los datos de la zona.
Ya que el respaldo lo realiza el primario, y el secundario solo los lee al
inicializarse luego de chequear los datos del servidor primario.
Para prevenir fallas en el sistema es necesario tener una copia de los
archivos de datos, cuando el sistema primario este fuera de servicio.
Multiples Servidores Maestros:
Otra manera de fortalecer los servidores secundarios es teniendo multiples
servidores primarios. Las actuales inplementaciones permiten hasta 10
servidores primarios. El servidor secundario ira probando los servidores en el
orden en que estan listados en los archivos de configuracion.
---[ 1.9 Significado de los Valores SOA ]----
Serial:
Se aplica a todos los datos dentro de la zona. Cuando un servidor secundario
consulta a un primario lo primero que pregunta es el numero de serie, de
manera que si este es menor toma la informacion del servidor primario, pero si
encuentra que son identicos en este caso el mismo lo resuelve.
Refresh:
Este el tiempo que se aplica en el secundario para chequear la consistencia de
los datos.
Retry:
Si el secundario falla en la consulta del servidor maestro despues del periodo
de refrescamiento, el host debe estar fuera de servicio, entonces toma este
tiempo para tratar de conectarse, cada <retry> segundos.
Expire:
Si el secundario falla en contactar al primario en el tiempo de expiracion
estos datos que mantenia seran eliminados.
TTL:
Este valor se aplica a todos los registros de datos. El servidor de Nombres
aplica este valor a las respuestas de los requerimientos. Entradas adicionales
en los archivos:
Ademas de los registros del tipo SOA, NS, A ,CNAME, PTR hay otros tipos de
registros como el MX, para la manipulacion de correo. Existen otros tipos de
registros como el HINFO, TXT que son usados para decir el tipo de maquina y su
localizacion. El otro tipo de registro es el WKS, que indica el tipo de
servicio well-known que provee el host.
---[ 1.10 El DNS y el correo electronico ]----
El DNS usa un solo tipo de registro para implementar un avanzado enrutamiento
de correo, el MX. Originalmente esto funcionaba en dos registros el MD (Mail
destination) y el MF ( Mail forwarder).
Experiencias con el DNS, mostraron que funcionando de esta manera era muy
ineficiente. Por lo que la mejor opcion era usar un solo registro, el MX.
Estos registros especifican un intercambiador de correos para los dominios de
nombre. Donde un host procesa el correo o retransmite este a otro servidor de
correos. Llamese procesamiento el almacenamiento del correo en una casilla de
correo valida y su retransmision a conexiones del tipo uucp.
Para prevenir los ciclos en estos registros se incluyen parametros adicionales
un valor sin signo (0-65535), el cual indica la preferencia del MX, teniendo
mayor preferencia el de menor valor.
El algoritmo MX:
El algoritmo MX es el metodo utilizado por DNS y Sendmail para enrutar correos
de una maquina a otra, el registro MX es creado por una sola linea en uno de
los archivos named.
La idea basica de los registros MX es que al momento que el Servidor de
Nombres envia los mensajes hay un intercambiador de correos que en caso de
fallar pasa al siguiente hasta enviarlo satisfactoriamente.
Por ejemplo.
HostA IN MX 10 HostB
En esta linea se dice que todos los correos destinados al HostA pueden ser
entregados por el HostB
Ejemplo.
cybernet.com IN MX 0 ns.server.org
Aqui nos dice que todo correo que llegue a cybernet.com se entrega a
ns.server.org para que este los distribuya.
El IN indica que es un tipo de registro de Internet y el valor 0 o 10 es el
valor de prioridad para resolver la entrega de mensajes.
Tambien un registro MX puede apuntar o direccionar a otro host o a el mismo de
la siguiente manera.
HostA IN MX 0 HostA
Aqui decimos que los correos recibidos o direccionados al HostA seran
entregados por el HostA, quizas esto pueda verse un poco redundante pero no lo
es. ejemplo
server.org IN MX 0 ns.server.org
Tambine un host puede tener multiples registros MX (Apuntandose a si mismo o
no)
HostA IN MX 0 HostA
IN MX 10 HostB
Ejemplo.
server.org IN MX 0 ns.server.org
IN MX 10 ns.byte.nom
Observemos aqui que el HostA tiene un valor menor que HostB, y despues hay
otro registro para otro domino, lo que sucede aqui es, primeramente trata de
resolver por si mismo, pero si el hostA esta caido entonces busca entonces
quien resuelve seria el HostB. Usualmente los registros MX apuntan al mismo
dominio, pero también lo pueden hacer haciendo que otro dominio resuelva en
caso de no estar disponible, esto se hace solicitando permiso al administrador
del otro dominio, ya que en caso contrario seria ilegal.
Apuntando a un registro A.
El registro A para un host es una linea que informa del IP del host, esto es
diferente a tener MX. Ejemplo
HostC IN A 127.0.0.130
Esta linea dice que el hostC es el nombre del Host, el IN dice que es un tipo
de registro de internet que indica la direccion IP del HostC 127.0.0.130
Otra forma es que un registro MX tambien puede apuntar a un hostname que tiene
un registro A, pero se debe de tener cuidado de hacer este tipo de apuntador o
resolver direcciones.
HostA IN MX 10 HostB <- Ilegal
IN MX 20 HostC
HostB IN MX 10 HostC
HostC IN A 205.218.252.129
Aqui lo que sucede es que el HostB carece de registro para A , pero HostC si
tiene uno, esto es ilegal ya que apuntamos a un registro MX de un Host que
carece de un registro A, en donde la primera linea es ilegal pero la segunda
esta bien.
Los registros MX son utilizados en los siguientes casos :
1. Mantener la redundancia del sistema de correo electronico para evitar que
el correo electronico se rebote a los remitentes por problemas en alguna
maquina del sistema.
2. Mantener la redundancia del sistema de correo electronico del Nodo al
evitar que el correo electronico se rebote a los remitentes, aun en el
caso de perder la comunicacion con Internet por un lapso de tiempo
prudencial, el cual dependera de la configuracion que tenga el programa
servidor de correos.
---[ 1.11 Listas MX para conexiones del tipo UUCP ]----
Si se tiene acceso del tipo UUCP es necesario que el nodo tenga los registros
correspondientes para que pueda recibir la correspondencia del nodo UUCP, como
ejemplo tenemos.
server.org IN A 0 ns.server.org
*.server.org IN A 10 ns.server.org
En la seguda linea decimos que todo aquello que venga antes de server.org sea
entregado a ns.server.org, ya que en los dominios uucp, lo primero es el
nombre del host uucp. Por ejemplo uubyte@uubyte.server.org .
---[ 1.12 Direcciones de dominio internas ]----
Otras de las caracteristicas de los registros MX, es que permite acortar la
direccion de correo con solo el nombre del dominio. Para esto luego de
declarar los registros MX colocamos la direccion IP asociada con el dominio en
cuestion, aqui podemos ver la diferencia con respecto al ejemplo anterior,
como podemos ver el host si cuenta con un registro A.
server.org IN MX ns.server.org
server.org IN A 127.0.0.130
Las direcciones de dominio internas tienen las siguientes ventajas:
1. Administracion de grandes cantidades de usuarios, de manera que aunque
todos tengan una direccion de correo similar, excepto su login, cada
usuario esta en una maquina diferente fuera de la vista del usuario
final. Esto es muy usado por compa¤ias comerciales del tipo America Online
(EUA), Compuserve (EUA), IBW (NICARGUA).
2. Facilita recordar a los usuarios su direccion de correo, al ser solo el
dominio del sistema.
---[ 1.13 Configurando los registros MX y direcciones de dominio internas ]--
Luego de haber agregado estos nuevos registros en los archivos DOMAIN.zone,
restaria configurar el programa servidor de correos y para finalizar
reinicializar los servidores DNS y de correo para probar dichos cambios.
Los registros agregados al archivo server.zone :
;
; Direcciones de dominio interna :server.org
;
server.org IN A 127.0.0.130
;
; Registro MX para server.org
; Sin *.server no saca recibe correos tipo xxx@xxxx.server.org
; Registro MX para server.org
server.org IN MX 0 ns.server.org
*.server.org IN MX 1 ns.server.org
---[ 1.13 Configurando las direcciones de dominio internas en el programa
servidor de correo ]----
En el archivo de configuracion por defecto que trae el programa servidor de
correo (sendmail v 8.9.3) no se contempla el uso de direcciones de dominio
internas por lo que es necesario darles los valores adecuados a estas
variables, cuyos nombres pueden cambiar en dependencia de la version del
programa servidor de correo.
Variables modificadas en el archivo /etc/sendmail.cf (sendmail v. 8.93) :
##################
# local info #
##################
# Cwlocalhost (valor por defecto )
Cwlocalhost
Cwserver.org
# "Smart" relay host (may be null)
# host despachador de correo por defecto
#DS (valor por defecto)
DSns.server.org
# who I masquerade as (null for no masquerading) (see also $=M)
# Mascara o dominio interno a usar por el host
#DM (no activa por defecto )
DMserver.org
###############
# Options #
###############
# maximum hop count
#maximo numero de maquinas intermedias para mensajes que fueron retransmitidos
al host
#O MaxHopCount=17 (por defecto)
#
O MaxHopCount=17
# who (if anyone) should get extra copies of error messages
# A quien se le envian los errores de correo electronico
#O PostMasterCopy=Postmaster Parche (no activa por defecto)
# No es necesaria para activar los registros MX ni dominios internos
pero es necesaria para controlar
# los errores del sistema de correo electronico
O PostMasterCopy=Postmaster
# timeouts (many of these)
#O Timeout.queuereturn=5d (por defecto 5 dias)
# Maximo tiempo de espera para poder entregar entregar un mensaje,
en caso de excederlo rebota el
# mensaje a su remitente avisando que no pudo entregar el mensaje
con una peque¤a descripcion del
# posible error, el que por lo general es muy escueto.
O Timeout.queuereturn=2d
---[ 1.14 Comprobando los registros MX y direcciones de dominio internas ]----
Los registros MX se prueban mediante la utilidad nslookup. Para mas
informacion desde la linea de comando pedir ayuda sobre los registros MX.
Las direcciones de correo internas deben ser probadas desde un sistema externo
(con dominio diferente) al sistema que estamos configurando enviando correos a
una cuenta usando la direccion real y luego la direccion reducida.
Ejemplo:
host: ns.server.org
Dominio: server.org
Enviar correo a byte@ns.server.org y byte@server.org
Ambos correos deben llegar al mismo destinatario, en caso de que la
configuracion esta correcta sino se debe revisar minuciosamente y leer los
errores del DNS y servidor de correo electronico en el archivo
/var/adm/messages.
Una vez que se demostro que ambos correos llegaron a su destinatario se puede
decir que todo esta correcto, se debe recordar que la configuracion del DNS es
una de las principales configuraciones que se deben hacer, ya que si esta
configuracion esta mala nuestro servidor trabajaria mal tambien, tanto en la
administracion de la red con en el sistema de correo.
Byte64
byte64@kshezine.org
~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
kSh kSh kSh kSh kSh kSh
~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
