Comenzaremos preguntándonos porque necesitamos un servidor DNS en nuestro hogar, bien, en realidad no lo necesitamos, porque ya existen cientos de miles de servidores, desde los famosos de Google, hasta los de nuestra operadora de ADSL, entre otros muchos.
¿ Pero… y para que quiero un servidor DNS? Para contestar esta pregunta, lo primero que debo de hacer es explicarte para que sirve un servidor DNS ( Domain Name Server = Servidor de nombres de dominio).
Cuando entramos en internet y escribimos http://www.binaryworld.es , un servidor DNS, es el encargado de resolver esa dirección en la verdadera, que es en IPV4, 4 octetos de 256 bits cada uno, pero que en breve, pasaremos a IPV6 (ya que las IPv4 se han agotado).
Resumiendo, cuando entramos a www.binaryworld.es, realmente estamos llamando a http://217.160.225.123, ya que el servidor DNS es el encargado de “traducir” estas direcciones.
Una vez os he explicado muy superficialmente la función principal de un servidor DNS, os voy a contestar a la primera pregunta… ¿ para qué quiero un servidor DNS en mi casa?
Si en casa tienes 2 pc, no tiene mucho sentido, pero si te pasa como a mi, que tienes 2 Mac, 1 Pc de sobremesa, 6 puntos de acceso, discos multimedia de red, 1 media-center, marcos digitales que acceden a tu red…, seguro que al final te cuesta recordar en que ip lo habías configurado….
Para ello, vamos a configurar un servidor local DNS, con un dominio virtual (ficticio), en el que podremos olvidarnos de las ips, y llamar a cada equipo por el nombre que deseemos… ¿suena bien no?
De paso mejoraremos nuestros tiempos de respuesta a la hora de acceder a internet, y al final de este tutorial veréis porque…
Comencemos!!!!
Para empezar, necesitaremos:
1 Synology preparado para instalar paquetes mediante IPKG.
Y un poco de paciencia 😉
(((Como un servidor DNS debe de estar operativo las 24horas, vamos a usar nuestro Synology para tal fin, y como incorpora un pequeño Linux, necesitaremos instalar BIND)))
Lo primero es logearnos como administradores, bajo el usuario root y la contraseña maestra.
Una vez dentro vamos a instalar el servidor DNS Bind.
Actualizamos la lista de paquetes disponibles :
ipkg update
Instalamos ahora el servidor DNS con esta sencilla operación 😉
ipkg install bind
Ahora el sistema está instalado con sus herramientas adicionales, de las cuales haremos uso al final de este tutorial para comprobar que todo marcha como debe.
Pero antes de esto, debemos de poner en marcha nuestro servidor de nombre, y para ello deberemos de crear nuestros ficheros configuración.
Como son varios, vamos a ir por partes y lo más estructurado posible para no liaros.
Nos vamos a la carpeta principal de bind.
cd /opt/etc/named/
y vamos a crear ciertos ficheros…
El primero, named.conf que será el encargado de distribuir los ficheros de configuración:
nano named.conf
( pongo nano porque es mi editor favorito, si lo prefieres puedes editar los ficheros con vi )
Escribimos dentro de este fichero estas líneas:
include “/opt/etc/named/named.conf.options”;
include “/opt/etc/named/named.conf.zonas”;
include “/opt/etc/named/rndc.key”;
ahora vamos a ir creando cada uno de los archivos a los que llama el fichero principal named.conf
por orden:
nano named.conf.options
acl “redes_permitidas” { 192.168.1.0/24; 127.0.0.1/8; ::1/128; };
options {
directory “/opt/etc/named/”;
forwarders {
87.216.1.65; //DNS primaria
8.8.8.8; //DNS secundaria
};
forward first;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { ::1; };
listen-on port 53 { redes_permitidas; };
allow-query { redes_permitidas; };
allow-query-cache { redes_permitidas; };
dump-file “/opt/etc/named/log/cache_dump.db”;
};
Os voy a realizar una pequeña nota aclaratoria a este fichero, que será el encargado de las opciones generales del servidor de nombres:
En la primera línea, veis que comienzo creando una “acl”, bien, dentro de la acl, debemos de escribir nuestra subred, y su correspondiente máscara, en donde os he puesto 192.168.1.0/24, el resto dejarlo tal y como está, ya que así os evitaréis problemas con los IPv6, y la resolución local de nombres.
En la línea “forwarders”, escribo dos DNS adicionales, superiores a mi servidor, para que, en caso de que haga una petición al servidor, y este no sepa traducir, acudirá a un servidor superior para que pueda ser resuelto, y nuestro servidor, lo almacenará en su cache ;), con lo que no deberá volver a consultarlo hasta un cierto tiempo, o que reiniciemos el demonio BIND. En este ejemplo he usado como DNS primaria la mi operador (Jazztel) y como secundario el de Google, pero vosotros podéis utilizar el que queráis.
Las opciones Listen-on port 53, es para hacer un poco más seguro nuestro server, ya que así, aseguramos que cualquier equipo que esté en la subred de la acl, podrá solicitar resolución de nombres, y denegar las externas, lo mismo para allow-query, y allow-query-cache.
Ahora pasemos a configurar el fichero relacionado con las que llamaremos zonas:
En mi caso he optado por crear 2 sub-carpetas, dentro de la carpeta named, una llamada “logs” y otra llamada “zonas“, para así poder tenerlo todo bien colocadito 😉
Creamos las carpetas :
mkdir /opt/etc/named/log
mkdir /opt/etc/named/zonas
Vamos a por las zonas;
cd /opt/etc/named/zonas/
nano named.conf.zonas
// Root servers
zone “.” {
type hint;
file “/opt/etc/named/zonas/db.root”;
};
zone “localhost” {
type master;
file “/opt/etc/named/zonas/db.local”;
};
zone “127.in-addr.arpa” {
type master;
file “/opt/etc/named/zonas/db.127”;
};
zone “0.in-addr.arpa” {
type master;
file “/opt/etc/named/zonas/db.0”;
};
zone “255.in-addr.arpa” {
type master;
file “/opt/etc/named/zonas/db.255”;
};
zone “binaryworld.es” {
type master;
file “/opt/etc/named/zonas/db.binaryworld.es “;
};
zone “1.168.192.in-addr.arpa” {
type master;
file “/opt/etc/named/zonas/db.192.168.1.rev”;
};
//Logs del servidor DNS
logging {
category lame-servers{ null; };
channel “query.log” {
file “/opt/etc/named/log/query.log” versions 1 size 500k;
severity debug;
print-severity yes;
print-category yes;
print-time yes;
};
channel “named_log” {
file “/opt/etc/named/log/named.log” versions 2 size 500k;
severity dynamic;
print-category yes;
print-severity yes;
print-time yes;
};
category queries { query.log; };
category default { named_log; };
};
Al final de este fichero, hemos creado dos ficheros de log, uno para las querys que hagamos al server (query.log), y otro para ver el funcionamiento del sistema (named.log), ya que así, si algo nos va mal, podremos encontrar más rápidamente el error que si buscamos en el syslog.
Ahora pasaremos a crear las zonas a las que hemos hecho mención en este último fichero de configuración y el fichero rndc.key ( que explicaré más adelante )
Sigamos paso a paso para no perdernos…
El fichero db.root debemos de descargarlo de internet, ya que es generado exteriormente por los servidores primarios.
Podemos descargarlo fácilmente así :
wget http://www.internic.net/zones/named.root -O /opt/etc/named/zonas/db.root
Luego podemos añadirlo a cron, para que lo mantenga siempre actualizado 😉 ( por ejemplo cada 2 semanas )
Sigamos ahora con la zona localhost:
nano /opt/etc/named/zonas/db.local
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA localhost. root.localhost. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost.
@ IN A 127.0.0.1
@ IN AAAA ::1
Antres de seguir, y aunque BIND es muy extenso, debéis de conocer unos pequeños parámetros por encima, que son el TTL, SERIAL, REFRESH, RETRY, y EXPIRE, ya que los veréis en todos los ficheros de zonas…
TTL = Time to live; Tiempo de vida, establecerá en segundos el tiempo de vida del fichero de la zona antes de “recargarse”.
SERIAL = un número de identificador, que si utilizamos un servidor DNS maestro y otro esclavo, al aumentar un número, aumenta su revisión, y por tanto lo comunica a su DNS esclavo.
REFESH = Indica cada cuanto tiempo los servidores esclavos, refrescarán la zona con el servidor maestro.
RETRY = Define el tiempo entre los reintentos del esclavo (secundario) si no puede ponerse en contacto con el servidor maestro (primario) cuando se ha alcanzado el tiempo de refresh
EXPIRE = Indica cuando los datos de la zona ya no son autoritativos. Válido sobre todo para los servidores esclavos, que dejarán de responder solicitudes, si alcanza ese tiempo, y no ha refrescado el fichero de zonas con el servidor primario.
Ahora que sabemos lo que estamos escribiendo, sigamos con el fichero inverso local.
nano /opt/etc/named/zonas/db.127
;
; BIND reverse data file for local loopback interface
;
$TTL 604800
@ IN SOA localhost. root.localhost. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost.
1.0.0 IN PTR localhost.
Ahora el db.0 ( de red)
nano /opt/etc/named/zonas/db.0
;
$TTL 604800
@ IN SOA localhost. root.localhost. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
@ IN NS localhost.
;
Ahora el db.255 ( de broadcast )
nano /opt/etc/named/zonas/db.255
;
; BIND reverse data file for broadcast zone
;
$TTL 604800
@ IN SOA localhost. root.localhost. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost.
Y ahora vamos a configurar la que será nuestra zona tanto la directa como la inversa.
Comencemos por la directa :
nano /opt/etc/named/zonas/db.binaryworld.es
;Configuracion DNS BIND dominio binaryworld.es
$TTL 86400 ; Time to live ( refresco cada 24 horas)
@ IN SOA binaryworld.es. eventos.binaryworld.es. (
2011110101 ; serial
7200 ; refresh (2 hours)
3600 ; retry (1 hour)
604800 ; expire (1 week)
86400 ) ; minimum (1 day)
;Servidores DNS Locales
@ NS synology.binaryworld.es.
;Mapeo de la red interna
net IN A 192.168.1.0
router-adsl IN A 192.168.1.1
nanostation IN A 192.168.1.2
nanobridge IN A 192.168.1.3
vozip IN A 192.168.1.4
wag320n IN A 192.168.1.5
timecapsule IN A 192.168.1.6
synology IN A 192.168.1.7
imac IN A 192.168.1.8
sergio-port IN A 192.168.1.9
pc-tdt IN A 192.168.1.10
pc-estudio IN A 192.168.1.11
iphone-sergio IN A 192.168.1.12
hdd-multimedia IN A 192.168.1.13
marcofotos IN A 192.168.1.14
dm500s IN A 192.168.1.15
itgate IN A 192.168.1.16
dhcp1 IN A 192.168.1.21
dhcp2 IN A 192.168.1.22
dhcp3 IN A 192.168.1.23
bcast IN A 192.168.1.254
;Fin de mapeo de red
En este fichero que habéis visto, los nombres de los equipos los ponemos a la izquierda, y las ip`s a las que corresponde dicho nombre a la derecha.
En el lugar donde pone synology.binaryworld.es. podéis poner el nombre que halláis asignado a vuestro Synology o servidor DNS.
Y ahora su fichero inverso:
nano db.192.168.50.rev
;Configuracion DNS BIND para bw.com
$TTL 86400 ; 1 dia para refrescarse
@ IN SOA binaryworld.es. eventos.binaryworld.es. (
2011110102 ; serial
7200 ; refresh (2 hours)
3600 ; retry (1 hour)
604800 ; expire (1 week)
86400 ) ; minimum (1 day)
;Servidores DNS LOCALES
@ NS synology.binaryworld.es.
;
;Mapeo de la red interna
0 IN PTR net.binaryworld.es.
1 IN PTR router-adsl.binaryworld.es.
2 IN PTR nanostation.binaryworld.es.
3 IN PTR nanobridge.binaryworld.es.
4 IN PTR vozip.binaryworld.es.
5 IN PTR wag320n.binaryworld.es.
6 IN PTR timecapsule.binaryworld.es.
7 IN PTR synology.binaryworld.es.
8 IN PTR imac.binaryworld.es.
9 IN PTR sergio-port.binaryworld.es.
10 IN PTR pc-tdt.binaryworld.es.
11 IN PTR pc-estudio.binaryworld.es.
12 IN PTR iphone-sergio.binaryworld.es.
13 IN PTR hdd-multimedia.binaryworld.es.
14 IN PTR marcofotos.binaryworld.es.
15 IN PTR dm500s.binaryworld.es.
16 IN PTR itgate.binaryworld.es.
21 IN PTR dhcp1.binaryworld.es.
22 IN PTR dhcp2.binaryworld.es.
23 IN PTR dhcp3.binaryworld.es.
254 IN PTR bcast.bw.com.
;Fin del mapeo
Con esto tendrímos nuestro server casi a punto, ya que nos faltaría generar un fichero llamado rndc.key que será el encargado de generar una clave única para el servidor, encriptada por supuesto en MD5.
Vamos a crearla entonces 😉
rndc-confgen -a -c /opt/etc/named/rndc.key
Ahora ya podemos arrancar nuestro servidor DNS.
/opt/etc/init.d/S09named start
para testear que el servidor esté funcionando podemos utilizar las herramientas que os hablé al principio.
por ejemplo:
dig @ns www.google.es
nslookup www.google.es o rndc status para ver si el servidor está operativo.
Como podéis observar, cuando usamos estas herramientas de resolución de nombres, vemos que quien responde a las solicitudes es nuestro servidor y no uno externo.
Ahora bien, ¿habéis notado que la primera consulta tarda lo mismo que cuando lo hacemos normalmente a un DNS externo, pero si la repites, tarda apenas 1ms?
Así que al montar un DNS en casa, no sólo conseguimos llamar a los equipos por el nombre que deseemos, sino que conseguimos mejorar los tiempos de respuesta a la hora de resolver nombres, ya que cuando nuestro servidor no sabe resolver un host en concreto, este, consulta a los de nivel superior (forwarders) y almacena en su propio cache la respuesta, con lo que no deberá preguntar hasta que la consulta no expire.
Ahora solo tenéis que cambiar el DNS primario en cada uno de vuestros equipos para que utilice vuestro servidor local.
Si os ha gustado este artículo sobre Synology, podéis visitar nuestro MANUAL PASO A PASO PARA SYNOLOGY, donde encontraréis muchos más tutoriales.