Ya había mantenido relaciones íntimas en un pasado y núnca lo había explicado, cuando en una operación de transferencia de un dominio (de un registrar a otro), el nuevo registrar pensó sin consultar a nadie que, al haber contratado un Servidor Dedicado, montaríamos nuestro propio dns y no lo dieron de alta en los suyos. ¿Resultado? El que todos conocemos: el dominio desaparece de la faz de la Red y, por ende, la/s web/s asociada/s al mismo (a menos que accedas por IP, algo impensable para gente no mega-friki y que no funciona con sites que usan VHosts). Como el fin de semana se venía encima y ya sabemos todos cuantas y cuán grandes ganas tenemos todos de trabajar esos días, tocaba sacar a flote esa web para que fuera accesible por nombre de dominio cuanto antes. ¿La solución? Montar un servidor DNS, p. ej., en la propia máquina (una debian estable). La opción elegida no fue otra que BIND (en ese momento no conozcía de ninguna otra). No contaré los detalles porque apenas me acuerdo, pero el caso es que núnca había tocado BIND antes. En ese momento la versión presente en Debian estable (la anterior a Etch) era la 8, y por algún extraño milagro lo conseguí configurar. Estuve a punto de hacerme creyente. Rollos a parte, como ya he contado en algún otro post reciente, hace poco tocó limpieza del PDC y pensé en qué podía hacer con todo aquello que estaba en el M$ DNS. Como tenía ganas de ver si lo de BIND 8 fue un milagro, me puse con BIND 9, el actual estable (tanto en Debian como en la Red). Y realmente me sorprendió por la relativa sencillez de la configuración (ojo porque monté algo muy básico, claro). El pastel Como ya sabréis, a tiempo de crear un dominio Microsoft, éste puede bien ser un dominio válido en Internet, o bien uno que actúa a nivel local (aunque esto es cierto sea un dominio M$ o no). ¿Cómo saber cuál es cual? Bueno, está claro que si ponemos que nuestro dominio es cucuruchosperez tal cual, esto no es un dominio Internet (¿dónde está el Top Level Domain, sino?). Como la LAN de mi empresa está basada en un dominio Microsoft y sólo queremos que sea válido a nivel local, si el dominio es cucuruchosperez, los subdominios tendran la forma de correo.cucuruchosperez, servidordearchivos.cucuruchosperez, impresoralaser.cucuruchosperez, y así un largo etcétera. ¿Cómo hacer esto con BIND? Espera, no corramos tanto. El hecho de usar BIND no va a suponer el podernos deshacer del servidor DNS de Microsoft, puesto que seguiremos necesitándolo para las autenticaciones y recursos que se encuentren en el mismo (Active Directory, aka Microsoft LDAP). Entonces lo que haremos (al menos en estaciones Windows) será usar la IP del servidor DNS de Microsoft como DNS primario, y la IP del servidor con BIND como secundario. Aquello que no sepa resolver el DNS primario será consultado al secundario, y a su vez, lo que este no sepa, irá a parar al gateway (p.ej. al router, que tendrá sus propias fuentes dns). Y la guinda Vamos a suponer que queremos configurar el dominio y subdominios mencionados arriba (dominio cucuruchosperez y subdominios correo.cucuruchosperez, servidordearchivos.cucuruchosperez, impresoralaser.cucuruchosperez), y que cada subdominio apunta a una máquina distinta. ¿Cómo quedaría la configuración de BIND 9? En /etc/bind/ tendremos varios archivos, además de los que ya existen en la configuración por defecto. Tendremos que modificar los ficheros named.conf.local, named.conf.options y crear uno para el dominio (tal que db.cucuruchosperez). -rw-r--r-- root bind 536 2009-07-09 db.cucuruchosperez -rw-r--r-- root bind 624 2009-07-11 named.conf.local -rw-r--r-- root bind 920 2009-07-11 named.conf.options El contenido del archivo named.conf.local sería como el siguiente:
//
// Do any local configuration here
//
zone "cucuruchosperez" {
type master;
file "/etc/bind/db.cucuruchosperez";
allow-query { any; };
};
Esto está claro: para la zona cucuruchosperez atentedemos a lo que esté definido en el archivo db.cucuruchosperez. ¿Y qué habría dentro?
;
; BIND data file for zone cucuruchosperez
;
$TTL 604800
@ IN SOA cucuruchosperez. hostmaster.cucuruchosperez. (
2007062801 ; Serial yyyy/mm/dd/id
10800 ; Refresh (3 hours)
7200 ; Retry (2 hours)
1296000 ; Expire (15 days)
172800 ) ; Negative Cache TTL (2 days)
;
@ IN NS ns0.cucuruchosperez
@ IN MX 10 mail.cucuruchosperez
@ IN TXT "Servidor"
@ IN HINFO "Servidor dns privado" "PIV"
;
@ IN A 192.168.1.200
; Los subdominios apuntan a otras maquinas...
correo IN A 192.168.1.197
servidordearchivos IN A 192.168.1.198
impresoralaser IN A 192.168.1.199
; Y cualquier otro subdominio apuntará a la máquina principal
* IN A 192.168.1.200
Finalmente, en el archivo named.conf.options definiremos servidores DNS de terceros (¡que sean confiables, no queremos un sencillo pero desastroso ataque MITM!) para resolver aquellos dominios que no esten contemplados en nuestra LAN:
options {
directory "/var/cache/bind";
// 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.
// Servidores de redireccion para cuando se quieran resolver
// nombres de dominio de fuera de nuestro ambito.
forwarders {
62.151.2.65;
80.58.0.33;
80.58.0.97;
62.36.225.150;
213.4.132.1;
};
auth-nxdomain no; // conform to RFC1035
listen-on-v6 { any; };
};
Hemos dado unos primeros y básicos pasos con BIND, si bien me dejo en el tintero muchas cosas como las vistas, la seguridad (acl's), y demás parafernalia que aún desconozco. Referencias:
Comentarios (3) |