DNS el acrónimo de Domain Name System, nos permite entre otras cosas asociar los nombres de dominio a direcciones ip y la localización de los servidores de correo.
Bind es por su parte, el servidor de DNS más comúnmente usado en Internet, especialmente en sistemas Linux y Unix. (Antes de continuar quiero aclarar que este tutorial lo he desarrollado con mi poca experiencia con servidores, y basado en otros tutoriales, que al final hago referencia, por lo que si cuenta con algun error, porfavor haganmelo saber para así, irlo mejorando.)
Para fines prácticos de este tutorial se usara una dirección ficticia al igual que la ip.
El dominio que usaremos sera: debianix.com.mx
La dirección ip: 74.125.95.104
Modificamos las siguientes líneas del /etc/resolv.conf para que haga las búsquedas en él mismo que sera el DNS.
domain debianix.com.mx
search debianix.com.mx
nameserver 74.125.95.104
— Agregamos a /etc/hosts nuestro nombre de servidor+dominio interno vinculado con su IP.
127.0.0.1 localhost
74.125.95.104 server01.debianix.com.mx server01
— Añadimos las 2 últimas linias en /etc/network/interfaces para que busque en nuestro propio DNS.
auto eth0
iface eth0 inet static
address 192.168.1.254
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.1
dns-nameserver 74.125.95.104
dns-search 74.125.95.104
Instalación de los paquetes necesarios de Bind9:
# apt-get install bind9 bind9-doc dnsutils
Primero veremos el archivo principal de bind cuyo nombre es named.conf, que en realidad en Debian no se modifica, ya que este direccionara a otro(named.conf.local), sin embargo otros sistemas Linux y Unix, no usan tal redirección. Solo lo veremos como un punto de referencia y para conocer de manera general como funciona.
Al abrir el archivo podremos ver algo como esto:
// 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";
};
// 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";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
include "/etc/bind/named.conf.local";
¡Extraño!, pues no tanto si se comprende el funcionamiento, vamos por partes(tomando en cuenta que las “//” son los comentarios), la primera linea:
Una redirección al archivo named.conf.options, siendo una de sus funciones el de indicar los fordwardes, cuya funcion se mecionará mas adelante.
include "/etc/bind/named.conf.options";
zone “.” es el inicio de la búsqueda, es decir, cuando el dns está tratando de resolver un nombre de dominio, el comienzo de la búsqueda son los servidores raíz, hay 13 en el mundo y estos servidores tienen la información de la siguiente parte de la búsqueda.
De zone “localhost” a zone “225.in-addr.arpa” permite traducir a localhost.
En la ultima linea:
include “/etc/bind/named.conf.local”;
En esta ultima linea podemos ver que hay una redirección al archivo named.conf.local, en este archivo es donde pondremos nuestro dominio(Al parecer en otros linux, se configura el dominio directamente en el archivo named.conf).
Comencemos con la configuración del dominio:
abrimos el archivo
#nano /etc/bind/named.conf.local
usaremos el dominio ficticio debianix.com.mx
zone "debianix.com.mx" {
type master;
file "/etc/bind/zones/db.debianix.com.mx";
allow-query { any; };
allow-transfer { slaves; };
};
El orden de las zonas es completamente irrelevante, pero se recomienda dejarlas en orden alfabético para una más fácil localización en el futuro (por ejemplo, por tareas de mantenimiento). Nótese que el nombre de la zona no termina en "."
(punto). Este es el cometido de los parámetros de cada zona:
1. type master; significa que el servidor de dominios es primario o maestro de la zona. Al configurar servidores secundarios, se usará type slave;.
2. file "/etc/bind/zones/db.debinaix.com.mx"; es el fichero donde especificaremos la configuración de esa zona.
3. allow−query { any; }; significa que se permiten consultas (del inglés, queries) externas a la zona. Esto es algo útil y necesario, a menos que se quiera ser muy paranoico con la seguridad. Simplemente se ofrece de forma técnicamente ordenada la información que es públicamente accesible.
4. allow−transfer { slaves; }; posibilita la transferencia automática de esta configuración a los servidores secundarios de las zonas bajo nuestro control que se especifiquen en la lista slaves.
Ahora hay que crear el fichero de definición de zona, el primero es que indicamos en la linea file "/etc/bind/zones/db.debianix.com.mx"; como podemos ver se creo una carpeta llamada zones, así que abrimos un terminal y procedemos a a crearlo(zones es una carpeta, esto es para tener una mejor organización de zonas en caso de que sean mas):
;
; BIND data file for zone debianix.com.mx
;
$TTL 604800
@ IN SOA ns.debianix.com.mx. hostmaster.debianix.com.mx. (
2009030401 ; Serial yyyy/mm/dd/id
10800 ; Refresh (3 hours)
7200 ; Retry (2 hours)
1296000 ; Expire (15 days)
172800 ) ; Negative Cache TTL (2 days)
;
NS ns1.debianix.com.mx.
NS ns2.debianix.com.mx.
MX 1 ns1.debianix.com.mx.
MX 2 ns2.debianix.com.mx.
TXT "Debianix"
HINFO "pemtium III" "Debian GNU/Linux"
LOC 39 34 58 N 2 38 2 E 100m 10000m 20m 100m
;
localhost A 127.0.0.1
debianix.com.mx. A 74.125.95.104
ns1 A 74.125.95.104
ns2 A 74.125.95.104
www A 74.125.95.104
pop3 A 74.125.95.104
smtp A 74.125.95.104
ftp A 74.125.95.104
server01 A 74.125.95.104
Se comentan acto seguido todas y cada una de las directivas y opciones de estos ficheros de configuración (un punto y coma, ";", indica que todo lo que hay a su derecha es un comentario):
1. $TTL 604800: directiva obligatoria a partir de la versión 9 de Bind (RFC1035 y RFC2308), indica el tiempo de vida (TTL, del inglés, Time To Live) de la información contenida en el fichero. Es decir, el tiempo máximo de validez, tras el cual deberá refrescarse o actualizarse (para comprobar que no haya cambiado). Es lo que se conoce como caché positiva/negativa (del inglés, positive/negative caching), como se especifica en el RFC2308. Por defecto se usan segundos (604800 segundos equivale a siete días exactos), pero pueden usarse también semanas ($TTL 1w), días ($TTL 7d), horas ($TTL 168h) y minutos ($TTL 10080m). Estas abreviaturas se usan asimismo en el registro SOA, que se explica a continuación. Otra directiva interesante, aunque no se use en los ejemplos, es $INCLUDE , que hace que named incluya otro fichero de zona en el lugar donde la directiva se usa. Esto permite almacenar parámetros de configuración comunes a varias subzonas en un lugar separado del fichero de la zona principal.
2. @ IN SOA ns.debianix.com.mx. hostmaster.debianix.com.mx.: el registro SOA (del inglés, Start Of Authority) se encuentra siempre tras las directivas y proclama información relevante sobre la autoridad de un dominio al servidor de nombres. Es siempre el primer recurso en un fichero de zona. El símbolo "@" (arroba) equivale a la directiva $ORIGIN (o el nombre de la zona si dicha directiva no se ha usado − caso más frecuente) como espacio de nombres de dominio definido por este registro. Este sería el esqueleto de este registro:
@ IN SOA (primary−name−server) (hostmaster−email) (
(-serial−number)
(time−to−refresh)
(time−to−retry)
(time−to−expire)
(minimum−TTL) )
El servidor de nombres primario que es el autorizado de este dominio se usa en (primary−name−server) y el correo electrónico de la persona a contactar acerca de este espacio de nombres (del inglés, namespace) se sustituye en (hostmaster−email).
El campo (serial−number) es un número que se incrementa cada vez que se modifica un fichero de una zona, de forma que Bind se dé cuenta de que tiene que recargar esta zona. Se recomienda usar la fecha de modificación en formato AAAAMMDD, donde AAAA es el año en formato de cuatro cifras, MM es el mes en dos cifras, y DD es el día de mes en dos cifras, seguido de un número de dos cifras, empezando por el 01. De este modo se podrán realizar hasta cien cambios por día
El campo (time−to−refresh) le dice a los servidores secundarios (esclavos) cuánto tiempo deben esperar antes de preguntar a su servidor principal (maestro) si se ha hecho algún cambio en la zona.
El valor del campo (serial−number) es usado por los esclavos para determinar si se está usando información anticuada que deba actualizarse.
El campo (time−to−retry) especifica a los servidores esclavos el intervalo de tiempo a esperar antes de solicitar una actualización en el caso de que el servidor de nombres principal no esté respondiendo. Si el servidor maestro no ha respondido a la petición de actualización antes de que expire el tiempo del campo (time−to−expire), el esclavo dejará de actuar como servidor el autorizado de ese espacio de nombres (zona).
El campo (minimum−TTL) solicita a otros servidores de dominio que almacenen en su caché la información de esta zona durante al menos la cantidad de tiempo en él especificada.
Nótese que el campo (primary−name−server) termina en un punto, que es obligatorio poner, y que representa, según lo explicado en el apartado introductorio del artículo, el servidor de nombres raíz.
Asimismo, este punto aparecerá en todas las referencias explícitas al dominio a lo largo del fichero. Cuando se configura un host o subdominio, por ejemplo ftp, se hace una referencia implícita y Bind añade automáticamente el dominio, que saca de la "@" del registro SOA. En cualquier caso, es posible usar referencias implícitas o explícitas indistintamente.
3. NS ns1.debianix.com.mx. y NS ns2.debianix.com.mx.: indican los servidores de nombre que tienen autoridad sobre el dominio.
4. MX 1 ns1.debianix.com.m.: se trata de un registro MX (del inglés, Mail eXchanger) e indica dónde mandar el correo destinado a un espacio de nombres controlado por esta zona. El dígito que sigue a la palabra MX representa la prioridad respecto a otros registros MX para la zona, que se especificarían en posteriores líneas (MX 2 debianix.com.mx.), siguiendo el mismo formato pero variando dicho dígito (incrementándolo a medida que pierdan prioridad frente a anteriores registros). Es decir, cuanto más bajo es el valor de preferencia, mayor prioridad adquiere.
5. TXT "Debianix": este es un registro a descriptivo, en texto plano (del inglés, plain text), del servidor. Puede usarse libre y arbitrariamente para propósitos diversos. Aparecerá como resultado de una consulta sobre este tipo de registro hecha al servidor de nombres sobre esta zona.
6. HINFO "pentium III" "Debian GNU/Linux" : otro registro, también a título informativo y totalmente opcional (del inglés, Host INFOrmation), cuyo propósito es informar sobre el hardware y el sistema operativo, en este orden, delimitados por dobles comillas y separados por un espacio o tabulador, de la máquina sobre la cual el servidor de nombres se ejecuta. Tanto este tipo de registro (HINFO) como el anterior (TXT) pueden usarse en cada uno de los subdominios (no únicamente en el dominio principal de la zona), como se verá más abajo.
7. LOC 39 34 58 N 2 38 2 E 100m 10000m 20m 100m: registro de localización geográfica del servidor, de nuevo opcional, que es usado por las herramientas de representación gráfica de localizaciones de servidores, por ejemplo las de la asociación CAIDA(10) (del inglés, Cooperative Association for Internet Data Analysis) y otras. Puede encontrarse información sobre este tipo de registro en el RFC1876. Las coordenadas (latitud, longitud y diámetro del objeto) se encuentran en formato WGS−84(11) (del inglés, World Geodetic System, del año 1984).
8. localhost A 127.0.0.1: registro que relaciona el host local con su IP de loopback.
9. debianix.com.mx. A 74.125.95.104: registro que relaciona el nombre de dominio de segundo nivel (el "principal" de la zona) con la IP donde está hospedado. Este es el registro más usado, pues cualquier petición a debianix.com.mx será resuelta mediante este registro, se use el protocolo de comunicaciones que se use (por ejemplo, http://debianix.com.mx).
10. ns1 A 74.125.95.104: a partir de aquí empieza la traducción de subdominios del dominio para el cual somos el autorizado: los dominios de tercer nivel y sucesivos. Fíjese en que debe crearse un registro para cada uno, sin posibilidad de "agrupar" de ningún modo. Asimismo, nótese que, al ser subdominios de la zona, se ha omitido el sufijo debianix.com.mx., que se encuentra implícito debido a que no termina en "." (punto). Es simplemente una cuestión de claridad y ahorro de espacio, pues las representaciones en ambas zonas son (repetimos de nuevo) igualmente correctas. Otros registros similares se citan, agrupados, a continuación:
ns2 A 213.96.79.79
TXT "debianix.com.mx secondary nameserver"
HINFO "Intel Pentium MMX" "Debian Linux"
www A 217.127.38.156
pop3 A 217.127.38.156
smtp A 217.127.38.156
ftp A 217.127.38.156
ts A 213.96.79.79
TXT "debianix.com.mx "
HINFO "Intel Pentium MMX" "Debian Linux"
Notar que se han usado dos direcciones IP distintas, lo que indicaría a priori que, en realidad, todos estos hosts (dominios de tercer nivel) se encuentran tan sólo en dos máquinas distintas. Pero esto no tiene porqué ser cierto, pues podría tenerse una misma IP pública pero varias máquinas sirviendo los distintos puertos usados en estos servicios, gracias a la acción de un router.
A propósito del concepto de alias (www, pop3, smtp y ftp son de hecho el mismo host) existe una controvertida discusión sobre si es mejor usar el tipo de registro CNAME (del inglés, Canonical NAME) o IN A. Muchos gurús de Bind recomiendan no usar registros CNAME en absoluto, si bien esa discusión se escapa de los objetivos de este artículo. En cualquier caso, es muy recomendable seguir la regla de que los registros MX, CNAME y SOA nunca deben referenciar un registro CNAME, sino exclusivamente algo con un registro tipo "A". Por lo tanto, no es aconsejable usar:
web CNAME www
Pero sí sería correcto:
web CNAME ns
También es seguro asumir que un CNAME no es un host adecuado para una dirección de correo electrónico: webmaster@www.linuxsilo.net, sería incorrecta dada la configuración de arriba. La manera de evitar esto es usar registros "A" (y quizás algunos otros también, como el registro MX) en su lugar. El autor de este artículo se decanta por el uso de IN A y recomienda dicha práctica.
Tipos de registros del DNS
Tipo Nombre Función
Zona SOA Start Of Authority Define una zona representativa del DNS
NS Name Server Identifica los servidores de zona, delega subdominios
Básicos
A Dirección IPv4 Traducción de nombre a dirección
AAAA Dirección IPv6 original Actualmente obsoleto
A6 Dirección IPv6 Traducción de nombre a dirección IPv6
PTR Puntero Traducción de dirección a nombre
DNAME Redirección Redirección para las traducciones inversas IPv6
MX Mail eXchanger Controla el enrutado del correo
Seguridad
KEY Clave pública Clave pública para un nombre de DNS
NXT Next Se usa junto a DNSSEC para las respuestas negativas
SIG Signature Zona autenticada/firmada
Opcionales
CNAME Canonical Name Nicks o alias para un dominio
LOC Localización Localización geográfica y extensión
RP Persona responsable Especifica la persona de contacto de cada host
SRV Servicios Proporciona la localización de servicios conocidos
TXT Texto Comentarios o información sin cifrar
En nuestro caso definimos los NS, MX y los A.
Traducción inversa
En estos momentos, los programas son ya capaces de convertir el nombre debianix.com.mx a direcciones a las cuales pueden conectarse. Pero también se requiere una zona inversa, capaz de permitir al DNS convertir una dirección en un nombre. Este nombre es usado por muchos servidores de diferentes clases (FTP, IRC, WWW y otros) para decidir si quieren "hablar" con el cliente o no y, si es el caso, quizás incluso cuánta prioridad se le debe asignar. Para poder tener acceso completo a todos estos servicios en Internet es necesario una zona inversa.
El in-addr.arpa, que contiene las direcciones IP de todos los sistemas en una notación de puntos invertida. Por ejemplo, a la dirección 1.2.3.4 le corresponde el nombre 4.3.2.1.in-addr.arpa. El registro de recurso (RR) que define esto se llama registro PTR.
PTR - Es el registro inverso, a la inversa del registro a (direcciones ip), traduce direcciones ip a nombres.
Proseguimos a realizar la configuración de la resolución inversa de nombres en el archivo “/etc/bind/named.conf.local”.
#74.125.95.104 solo como referencia pongo mi ip original, no es necesario ponerla
#Aquí definimos la zona de resolución inversa. Cambia 95.125.74 por la dirección de tu red
zone “95.125.74.in-addr.arpa” {
type master;
file “/etc/bind/zones/db.74.125.95″;
allow-query { any; };
};
Ahora Editamos el Archivo “/etc/bind/zones/db.74.125.95”
;
;
; BIND reverse data file for zone 74.125.95
;
$TTL 604800
@ IN SOA ns.debianix.com.mx. hostmaster.debianix.com.mx. (
2009031501 ; Serial
10800 ; Refresh (3 hours)
7200 ; Retry (2 hours)
1296000 ; Expire (15 days)
172800 ) ; Negative Cache TTL (2 days)
@ IN NS ns1.debianix.com.mx.
NS ns2.debianix.com.mx.
104 IN PTR ns1.debianix.com.mx.
1.@ IN NS ns1.debianix.com.mx. y NS ns2.debianix.com.mx.: indican a qué servidores de nombres debe preguntarse por la traducción inversa de una dirección IP de esta zona.
2.104 IN PTR ns1.debianix.com.mx.: este es el registro que se usará para devolver el nombre que queremos que corresponda con la dirección IP que nos pertenece (cuidado al crear estos registros, pues debe hacerse referencia exclusivamente a direcciones IP que sean de nuestra propiedad o provocaríamos un conflicto). En este caso se indica que la dirección 104 (implícitamente se le añade el sufijo .95.125.74.in−addr.arpa, lo que indica que se trata de "nuestra" dirección IP 74.125.95.104) equivale al host ns1.debianix.com.mx.
Ahora hay que configura el archivo /etc/bind/named.conf.options modificamos el archivo
// forwarders {
//0.0.0.0;
// };
Y dejarlo en algo como esto:
forwarders {
200.23.242.193;
200.23.242.201;
};
En este caso perteneciente al servidor dns de telmex, pero si no tienes a la mano la dns de tu proveedor de internet, o simplemente no los quieres usar (si queremos evitar el caótico servicio de telmex :s) podemos emplear, el servicio de opendns.
Ahora hay que reinicar al servidor
#/etc/init.d/bind9 reload
Realizaremos una verificación del funcionamiento de la resolución de IP a nombre con nslookup:
#nslookup 74.125.95.104
Server: 74.125.95.104
Adress: 74.125.95.104#53
104.95.125.74.in-addr.arpa name= ns1.debianx.com.mx.
Después de realizar una instalación y configuración de nuestro DNS Bind9 con las zones de resolución de nombres a IP y con la resolución de nombres inversa, tenemos que realizar una verificación de nuestros ficheros de configuración por posibles fallos.
Para ello tenemos un comando que nos ayudará a realizar esta tarea tan sencilla, es “named-checkconf”, que todo seguido mostraremos como utilizarla.
Para revisar nuestro o nuestros ficheros de configuración:
#named-checkconf ubicación_del_fichero_de_configuración
Ejemplo:
#named-checkconf /etc/bind/named.conf.local
#named-checkconf /etc/bind/named.conf
Para verificar la zona DNS
#named-checkzone nombre_zona_dns archivo_de_la_zona
Ejemplo:
#named-checkzone debianix.com.mx /etc/bind/zones/db.debianix.com.mx
zone debianix.com.mx/IN: loaded serial 2009031101
OK
Basado en :
Alejandrox
Bulma
Nekan
NIC Mexico
GPLTarragona
