Instalación de un servidor DNS con Bind

Transcripción

Martes, 09 de Diciembre de 2008 21:04
BIND (Berkeley Internet Name Domain), como implementación del prorocolo DNS, es el
servidor de este tipo más comunmente usado en internet. La necesidad administrativa de
montar un servidor de nombres DNS hacen de BIND una de las primeras opciones a tener en
cuenta y desde este artículo se explotará la instalación y configuración del mismo.
Un poco de historia
BIND es uno de los primeros servidores DNS creados al albor de internet. Encargado y
patrocidano por la DARPA (Defense Advanced Research Projects Agency) a principios de los
años ochenta, cuando el Departameto de Defensa estadounidense estaba implicado en el
desarrollo de la red de redes, el proyecto queda finalmente en manos de DEC/Digital (
Digital Equipment Corporation
), que se encarga de desarrollarlo casi por completo. Finalmente es uno de los empleados de
Digital, Paul Vixie, quien retomará el proyecto y lo incluirá en el consorcio ISC (
Internet Software Consortium
), responsable actual del mantenimiento del programa.
Si bien las primeras implementaciones del servidor BIND (en concreto las versiones 4 y 8)
mostraban una cantidad de vulnerabilidades exagerada (como casi todo el software nacido a la
par que internet), la versión 9 del producto ya no presenta tantas complicaciones. Escrita desde
cero para superar las dificultades técnicas de antiguos desarrollos, dicha versión fue impulsada
por proveedores UNIX, deseosos de que BIND mantuviera la competencia con Microsoft en
igualdad de condiciones y por el Ejército de los Estados Unidos, que desarrolló funcionalidades
relativas a la seguridad como DNSSEC (DNS Security Extensions), al darse cuenta de que la
seguridad dentro del servicio DNS es algo a tener muy en cuenta.
Características
BIND 9 ofrece un servidor de nombres de dominio a través de named, una bibioteca de
resolución de sistemas de nombres de dominio y un paquete de herramientas para monitorizar
el correcto funcionamiento de todo el sistema (
bind-utils
1 / 17
).
Entre sus principales características se incluyen los protocolos de seguridad como DNSSEC o
TSIG (Transaction SIGnature) y el soporte de IPv6, nsupdate (actualizaciones dinámicas),
notificación DNS, rndc flush, vistas y procesamiento en paralelo. Gracias a su arquitectura
mejorada se ha conseguido una mejor portabilidad entre sistemas.
Introducción a DNS
DNS (Domain Name System) es una base de datos distribuida y jerárquica que almacena
información relativa a los nombres de dominio en internet o gestiona nombres de equipos y
servicios en redes locales. El uso más común de una base de datos DNS es la de asignación
de nombres de dominio o de servidores de correo a direcciones IP. Dicha asignación se
utilizará para la localización de dichos equipos/servicios de una manera sencilla y sin tener que
recordar cada vez la dirección real. La información dada se puede consultar a la inversa (una
dirección IP se traduce en un nombre almacenado en la base de datos).
Los componentes principales de un sistema DNS son los siguientes:
- Clientes DNS - Encargados de realizar las consultas pertinentes a las bases de datos de
los servidores DNS.
- Servidores DNS - Contestan a las peticiones realizadas por los clientes. Dicha
contestación se hará consultando la base de datos propia o haciendo una consulta recursiva a
otro servidor DNS.
- Zonas de autoridad - Son los espacios de nombres de dominio donde se almacenan los
datos. Generalmente, una zona de autoridad comprende, al menos, un nombre de dominio y
todos sus subdominios, pudiendo estos últimos estar en sus zonas de autoridad propias.
Servidores DNS
2 / 17
Dentro de este apartado, contamos con dos tipos de servidores:
- Servidor Maestro/Primario - Consulta los datos del dominio en la base de datos del
propio servidor donde se aloja.
- Servidor Esclavo/Secundario - Consulta los datos de una caché que rellena a partir de
los datos de un servidor Primario. Dicho proceso se denomina Trasferencia de zona.
Es muy recomendable tener, al menos, tres servidores DNS configurados (RFC 2182) para un
correcto funcionamiento del sistema de resolución. Un servidor actuaría como nodo DNS
Primario y los otros dos como nodos secundarios, que replicarían y respaldarían la base de
datos principal. Obviamente, en un entorno local que no necesita servir datos fuera de la red
(internet) no es tan necesario.
Como hemos apuntado anteriormente, un servidor DNS puede hacer dos tipos de consultas:
- Consultas Iterativas - El servidor DNS responde a la consulta del cliente desde los datos
guardados en su base de datos o en las bases de los sistemas locales. Si dicha información no
se encuentra disponible, la petición se reenviará hacia otros servidores, hasta encontrar la
Zona de Autoridad válida que resuelva la petición. En principio, la carga de la consulta recae
sobre el cliente.
- Consultas Recursivas - El servidor DNS proporciona, si existe, la respuesta a la
solicitud. Para ello, hará tantas consultas iterativas como sea necesario hasta dar con el dato
solicitado. Las peticiones son transparentes a la máquina del cliente.
Zonas de Autoridad
Un servidor DNS Primario carga su información desde una Zona de Autoridad. Dicha zona
abarca un nombre de dominio y, si los nombres de los subdominios no están delegados,
también los incluirá. Toda la información se almacenará localmente en un fichero que
contendrá alguno de estos tipos de registros:
A (Address) - Registro de dirección que resuelve un nombre de un anfitrión hacia una
3 / 17
dirección IPv4 de 32 bits.
AAAA - Registro de dirección que resuelve un nombre de un anfitrión hacia una dirección
IPv6 de 128 bits.
CNAME (Canonical Name) - Registro de nombre canónico que hace que un nombre sea alias
de otro. Los dominios con alias obtiene los sub-dominios y registros DNS del dominio original.
MX (Mail Exchanger) - Registro de servidor de correo que sirve para definir una lista de
servidores de correo para un dominio, así como la prioridad entre éstos.
PTR (Pointer) - Registro de apuntador que resuelve direcciones IPv4 hacia el nombre
anfitriones. Es decir, hace lo contrario al registro
A. Se utiliza en zonas de
Resolución Inversa.
NS (Name Server) - Registro de servidor de nombres que sirve para definir una lista de
servidores de nombres con autoridad para un dominio.
SOA (Start of Authority) - Registro de inicio de autoridad que especifica el Servidor DNS
Maestro (o Primario) que proporcionará la información con autoridad acerca de un dominio de
Internet, dirección de correo electrónico del administrador, número de serie del dominio y
parámetros de tiempo para la zona.
SRV (Service) - Registro de servicios que especifica información acerca de servicios
disponibles a través del dominio. Protocolos como SIP (
Session Initiation
Protocol
) y XMPP (Ex
tensible Messaging and Presence Protocol
) suelen requerir registros SRV en la zona para proporcionar información a los clientes.
TXT (Text) - Registro de texto que permite al administrador insertar texto arbitrariamente en
un registro DNS. Este tipo de registro es muy utilizado por los servidores de listas negras
DNSBL (
DNS-based Blackhole List) para la filtración de Spam. Otro ejemplo de
uso son las VPN, donde suele requerirse un registro
TXT
para definir una llave que será utilizada por los clientes.
Las zonas a resolver serán las siguientes:
- Zonas de Reenvío - Devuelven direcciones IP para búsquedas sobre nombres FQDN
(Fully Qualified Domain Name). Es importante apuntar aquí que, en el caso de tratarse de
dominios públicos, hay una responsabilidad por parte de la autoridad misma del dominio (el
Registrar del WHOIS) para crear dicha zona de reenvío.
- Zonas de Resolución Inversa - Devuelven nombres FQDN para búsquedas sobre
direcciones IP. Como en el caso anterior, la responsabilidad de crear la Zona de Autoridad
recae sobre la autoridad misma del segmento (si hacemos un WHOIS sobre una dirección IP,
obtendremos a la autoridad de todo el segmento de direcciones).
4 / 17
Instalación de BIND
La gran mayoría de distribuciones de linux ya tienen un paquete precompilado de BIND en sus
repositorios, así que haremos uso de herramientas como yum o apt-get para su instalación (no
obstante, podemos descargar y compilar la última versión de BIND de la dirección www.isc.or
g/index.pl?/sw/bind/
):
[root@jeke ~]# yum -y install bind bind-utils caching-nameserver
Configuración
Antes de comenzar con los ficheros de configuración del programa, es preciso tener claros los
datos siguientes:
- Nombre de dominio a resolver.
- Servidor de nombres principal (DNS Maestro/SOA). Dicho nombre tiene que estar
plenamente resuelto y, por supuesto, tiene que ser FQDN.
- Lista de servidores de nombres (NS) para la redundancia. Igual que en el caso anterior,
deberán estar plenamente resueltos y ser FQDN.
- Cuenta de correo del administrador de la zona. Cuenta real y distinta de la zona a
resolver.
- Servidor de correo (MX) con registro A (no vale un CNAME).
- IP predeterminada del dominio.
- Subdominios y direcciones IP asociadas a los mismos (www, mail, ftp, ...).
+ Ficheros de zonas
Un fichero de zonas tiene, en principio, el siguiente aspecto:
$TTL 43200
@ IN SOA server.mydomain.name. user.server.mydomain.name. (
200583909; Número de serie
3600 ; Tiempo de refresco (1 hora)
300
; Tiempo entre reintentos de consulta (5 min)
5 / 17
17200 ; Tiempo de expiración de zona (2 days)
43200 ) ; Tiempo total de vida (TTL) (12 hours)
;
@ IN NS server.mydomain.name.
pc1 IN A xxx.xxx.xxx.xxx
pc2 IN A yyy.yyy.yyy.yyy
nombre1 IN CNAME pc1
nombre2 IN CNAME pc2
Los nombres de dominio terminan en un punto para indicar que son nombres absolutos.
Los registros del fichero son los siguientes:
- IN SOA - Información sobre el dominio:
sever.mydomain.name.: Servidor de nombres al cual pertenece la zona.
user.server.mydomain.name.: Indica el usuario responsable a administrar el servidor DNS.
Además también hace referencia a su dirección de correo
n //
-->
u
[email protected]
document.write( '
' );
Esta dirección de correo electrónico está protegida contra los robots de spam, necesita tener
Javascript activado para poder verla
.
Nº Serie: Es el número de serie correspondiente a la última actualización. Este campo es
utlizado por los servidores DNS secundarios, los cuales solamente actualizarán los datos de su
zona si su número de série es menor que el del primario.
Refresco: Tiempo en que el seridor secundario debe preguntar al primario si ha habido
cambios.
Reintentos: Periodo de tiempo que ha de esperar un servidor secundario antes de reintentar la
conexión con el servidor primario, suponiendo que el último intento haya fallado.
Expiración: Máximo tiempo que ofrece servicio el servidor secundario, en caso de no poder
contactar con el primario.
TTL: Tiempo máximo que se mantienen los datos del dominio en un servidor de caché antes
de volver ha hacer una consulta al servidor autorizado.
6 / 17
- IN NS - Relaciona un nombre de subdominio con un servidor de nombres responsable
de la zona. Podremos formar así una jerarquía de nombres DNS. Hay que poner el
correspondiente registro A para traducir el nombre del servidor a una dirección IP si se usa este
registro.
- IN A - Traducción de máquina a dirección IP.
- IN PTR - Traducción de dirección IP a máquina.
- IN CNAME - Alias de las máquinas.
Los distintos ficheros de zonas se encuentran, en una distribución tipo Red-Hat / Fedora en la
rama /var/named (o /var/named/chroot/var/named). A continuación vamos a ver un fichero de
zona para la configuración típica de un dominio:
$TTL 86400
@
IN
SOA dominio_ejemplo.org. postmaster.dominio_ejemplo.org. (
42
; serial
3H
; refresh
15M
; retry
1W
; expiry
1D )
; minimum
@
IN
NS
ns1.dominio_ejemplo.org.
@
IN
NS
@
IN
MX
10
mx1.dominio_ejemplo.org.
@
IN
MX
20
mx2.dominio_ejemplo.org.
@
IN
TXT "dominio_ejemplo.org"
@
IN
HINFO "Intel Pentium IV" "Fedora Core"
@
ns1
ns2
mx1
mx2
www
www2
webmail
smtp
redirect
IN
A
215.127.55.12
IN
A
214.125.33.41
IN
A
215.127.55.12
IN
A
215.127.55.12
IN
A
214.125.33.41
IN
A
215.127.55.12
IN
A
215.127.55.12
IN
A
215.127.55.12
IN
A
215.127.55.12
IN
CNAME dominio_ejemplo.no-ip.info
smtp.tcp SRV
http.tcp SRV
http.tcp SRV
https.tcp SRV
pop3s.tcp SRV
0
0
0
1
0
0
3
1
0
0
25 mx1.dominio_ejemplo.org.
80 dominio_ejemplo.org.
80 www2.dominio_ejemplo.org.
443 dominio_ejemplo.org.
995 mx1.dominio_ejemplo.org.
7 / 17
*.tcp SRV 0 0 0 .
*.udp SRV 0 0 0 .
Se observa claramente cómo se han creado dos servidores de nombre con autoridad mediante
la sentencia NS (con @ se evita tener que escribir el dominio completo de nuevo), ns1.dominio
_ejemplo.org.
y
y se crean también dos redirectores de correo
MX
con prioridad de 10 y 20.
Tras el espacio, comienza la traducción de los nombres en direcciones IP. Si atendemos a la
última línea, podemos observar el uso claro de la sentencia CNAME. En este caso, el servidor
DNS traduciría la dirección
redirect.dominio_ejemplo.org
hacia la dirección apuntada en
dominio_ejemplo.no-ip.info
, lo cual puede resultar tremendamente útil en caso de tener que hacer uso de alguna IP
dinámica en alguno de los servidores.
En último lugar, nos encontramos con un listado de localización de servicios que hace uso de la
sentencia SRV. Dicha sentencia permite la consulta de un dominio y un servicio asociado al
mismo. La asociación de servicios se define en el estándar
RFC 2052.
+ Traducción inversa
Es requerido en un servidor DNS que las direcciones IP se conviertan igualmente en nombres (
reverse lookup
). Dicha traducción se usará por parte de diferentes servidores y es muy aconsejable tener
definida una zona de este tipo en un servidor DNS. Para la resolución inversa usaremos el
pseudo-dominio
in-addr.arpa.
quedando la dirección pública
55.127.215.in-addr.arpa.
(la parte de red de la dirección IP escrita al revés más el dominio). Un fichero de zona de
8 / 17
resolución inversa para el dominio anterior quedaría como sigue:
$TTL 604800
@ IN SOA dominio_ejemplo.org. postmaster.dominio_ejemplo.org. (
42
; serial
3H
; refresh
15M
; retry
1W
; expiry
1D )
; minimum
@ IN NS
NS
12 IN PTR ns1.dominio_ejemplo.org.
Para la zona inversa de localhost podríamos generar un fichero parecido al siguiente:
$TTL 604800
@ IN SOA localhost. postmaster.dominio_ejemplo.org. (
42
; serial
3H
; refresh
15M
; retry
1W
; expiry
1D )
; minimum
IN NS ns1.dominio_ejemplo.org.
1 IN PTR localhost.ns1.dominio_ejemplo.org.
Hay que tener en cuenta que la zona de resolución inversa del dominio sólo funcionará en el
caso de que ésta quede delegada convenientemente por el proveedor de servicios que se
ocupa del rango de direcciones. Si es imprescindible, y el autor de este artículo considera que
siempre debería serlo, tener una zona de resolución inversa para nuestra dirección o rango de
direcciones, será imperativo contactar con el proveedor de servicios para que de de alta un
registro NS para la zona en concreto.
+ El archivo named.conf
El archivo named.conf se sitúa en la rama /etc o /etc/bind y estructura toda la información de
zonas del servidor DNS. A grandes rasgos, podemos dividir el fichero en tres secciones:
options
, que define opciones de configuración general,
9 / 17
loggin
, que especifica la salida de la información y
zone
, donde se incorporan los datos generales de los archivos de zonas que ya hemos explicado en
los puntos anteriores.
- options
Habitualmente, las opciones incluidas por defecto en los ficheros de configuración de cada
distribución para el apartado options son más que suficientes para arrancar el servidor DNS sin
ningún tipo de problema. Dichas opciones son demasiado extensas para explicarlas en este
artículo, así que es muy recomendable acceder a la página del manual referente a
named.conf
y leer para qué sirve cada opción y si alguna de ellas puede servir a nuestros propósitos. Una
opción importante a tener en cuenta es la de
fordwarders
, que se usará para suministrar al servidor DNS las direcciones IP de los redireccionadores
encargados de consultar ciertas direcciones a otros servidores DNS, cuando éstas no esten
disponibles de forma local. De usarse el apartado, deberá quedar como el ejemplo siguiente:
forwarders {
200.33.146.209;
200.33.146.217;
};
- zone
Bajo la definición de zone se darán de alta todas las zonas para nuestros dominios. Habrá que
definir siempre una primera zona raíz (un punto), que informará de todos los servidores raíz a
nuestro servidor DNS, y seguidamente se darán de alta todas y cada una de las zonas
necesarias para el funcionamiento correcto de nuestro servidor. La zona raíz quedará como
sigue (el fichero de zona puede consguirse en la dirección
ftp.interni
c.net/domain/named.cache
):
zone "." {
10 / 17
type hint;
file "named.ca";
};
Un ejemplo de definición de zona general podría ser el siguiente:
zone "dominio_ejemplo.org" {
type master;
file "/var/named/dominio_ejemplo.org.zone";
allow-query { any; };
allow-transfer { slaves; };
};
Con type master se establece el servidor como maestro/primario (slave establecerá el tipo
secundario).
file indica
la ruta de acceso al fichero de configuración de la zona declarada.
allow-query { any; }
especifica que es posible hacer consultas externas a la zona.
allow-transfer { slaves; }
transfiere la configuración de la zona hacia los servidores secundarios especificados en el ACL
slaves
dentro del fichero de configuración de la forma siguiente:
acl "slaves" {
215.66.73.59;
};
La deficinión de un servidor esclavo, que se limitará a replicar los ficheros de zonas del servidor
maestro, podría seguir el ejemplo siguiente para una de sus zonas:
zone "sec.dominio_ejemplo.org" {
type slave;
file "/var/named/sec.dominio_ejemplo.org.zone";
allow-query { any; };
11 / 17
masters { 60.89.100.1; };
};
El fichero sigue las mismas trazas que el ejemplo del maestro, a excepción de la sentencia ma
sters
, donde es aconsejable especificar la dirección IP del servidor primario para que el servidor
esclavo solicite la transferencia de zonas (puede usarse
acl
, pero sólo suele existir un servidor maestro en la red en casi la mayoría de los casos).
- logging
Bajo la sentencia logging se definen los canales y archivos hacia donde se dirigirán los
mensajes de auditoría de BIND. Una sentencia
logging se contruye
de la forma siguiente:
logging {
definición_de_canal;
definición_de_canal;
...
category nombre_categoría {
nombre_canal;
nombre_canal;
...
};
};
A continuación ponemos un ejemplo de logging para establecer los mensajes de aviso y las
consultas al servidor y redirigirlos hacia distintos ficheros de texto:
logging {
channel warning
{
file "/var/log/server-dns/warning" versions 3 size 100k;
severity warning;
12 / 17
print-category yes;
print-severity yes;
print-time yes;
};
channel general_dns
{
file "/var/log/server-dns/log" versions 3 size 100k;
severity info;
print-category yes;
print-severity yes;
print-time yes;
};
category default { warning; } ;
category queries { general_dns; } ;
};
Para profundizar más en la configuración de mensajes consultaremos el manual oficial de BIND
en la página de la ISC ( www.isc.org ).
Transferencia de zonas, seguridad y rndc
Habiéndose establecido la configuración correcta para cada uno de los servidores secundarios
y corriendo ya el primario, se establecerá una transferencia segura de zonas del servidor
maestro a cada uno de los servidores secundarios. Dicha transferencia generará de forma
automática los ficheros de zonas en los servidores secundarios, siempre y cuando se hayan
establecido las opciones allow-transfer { slaves; } y masters { x.x.x.x; } en las distintas
definiciones de zonas del fichero
named.conf
, tanto en el servidor maestro como en los esclavos. La transferencia se hará de forma segura y
será preciso añadir al fichero
named.conf
los siguientes parámetros, que se encargarán de controlar las tranferencias mediante una
certificado de seguridad:
controls {
inet 127.0.0.1 allow { localhost; } keys { "2007041102.liberaliatempus.com.tsigkey."; };
};
13 / 17
server 215.66.73.59 {
keys { "2007041102.liberaliatempus.com.tsigkey."; };
};
key "2007041102.liberaliatempus.com.tsigkey." {
algorithm hmac-md5;
secret "bsty5LYDsO8infm+n2JNsw==";
};
En el servidor secundario (215.66.73.59) también han de añadirse los parámetros siguientes:
controls {
inet 127.0.0.1 allow { localhost; } keys { "2007041102.liberaliatempus.com.tsigkey."; };
};
server 60.89.100.1 {
keys { "2007041102.liberaliatempus.com.tsigkey."; };
};
algorithm hmac-md5;
};
Con la sentencia controls se limita el uso de BIND al entorno localhost, generalmente tras
haber realizado una conexión mediante SSH y ejecutado el comando
rndc
, que servirá para administrar el demonio
named
. Mediante la sentencia
server
establecemos que la comunicación con cierta dirección IP ha de realizarse utilizando una clave
única y cifrada. Las direcciones en el servidor primario (
60.89.100.1
) y el secundario (
215.66.73.59
) se apuntaran entre ellas para permitir la comunicación mediante claves. La sentencia
key
establece la configuración de la clave de seguridad. Dicha configuración se obtiene durante el
proceso de generación de la clave que se hace mediante la ejecución del siguiente comando:
14 / 17
[root@jeke ~]# dnssec-keygen -a HMAC-MD5 -b 512 -n HOST
2007041102.liberaliatempus.com.tsigkey.
Tras la ejecución se habrán generado dos ficheros: K2007041102.liberaliatempus.com.tsigkey..
+157+41204.key
y K2007041102.liberaliate
mpus.com.tsigkey..+157+41204.private
. El contenido de la clave se encuentra en el fichero con extensión
private
después de la etiqueta
Key:
. Dicho contenido se entrecomillará tras el parámetro
secret
, tal y como aparece en el ejemplo.
Para finalizar, hay que completar la configuración de rndc mediante la edición del fichero /etc/r
ndc.conf
, que quedará de la forma siguiente si atendemos a los ejemplos dados más arriba:
options {
default-server localhost;
default-key "2007041102.liberaliatempus.com.tsigkey.";
};
server localhost {
key "2007041102.liberaliatempus.com.tsigkey.";
};
algorithm hmac-md5;
};
Tanto en el fichero named.conf como en el fichero rndc.conf se puede omitir por seguridad la
declaración de
key y suministrar dicha información a través de
un fichero externo. Dicho fichero contendrá las líneas de declaración utilizadas para definir la
clave y éstas serán sustituidas por la sentencia
include "fichero_clave";
El ejemplo anterior quedaría como sigue:
15 / 17
options {
default-server localhost;
default-key "2007041102.liberaliatempus.com.tsigkey.";
};
server localhost {
key "2007041102.liberaliatempus.com.tsigkey.";
};
include "/etc/rndc.key";
El fichero /etc/rndc.key contendrá todas las líneas sustituidas tal cual y su uso debería ser muy
restringido (
# chmod 600 /etc/rndc.key).
Podemos comprobar que todo es correcto a nivel de rndc mediante la ejecución del siguiente
comando, debiendo repasar los ficheros de configuración si la salida difiere de la mostrada:
[root@jeke ~]# rndc reload
server reload successful
Con esta configuración, la transferencia de zonas qeudará transferida a petición de los
servidores secundarios, que verán actualizadas sus zonas sin tener que reescribir los ficheros.
Apuntar igualmente que el software de servidor DNS de Microsoft no es compatible con el
algoritmo HMAC-MD5, al menos a día de la escritura de este artículo, por lo que no
comunicará correctamente con los servidores configurados con BIND.
Puertos
BIND utiliza dos puertos en sus comunicaciones, el 53 TCP, que se usa para las transferencias
y el
53 UDP, que se utiliza para las
consultas. Será necesario no alicar reglas de cortafuegos sobre estos puertos si queremos que
el servicio DNS funcione de forma correcta. La herramienta
rndc
utiliza el puerto
953 UDP
para el control remoto, pero no es recomendable redireccionarlo a través del
16 / 17
router
si se siguen las indicaciones del artículo a nivel de seguridad.
17 / 17

Instalación de un servidor DNS con Bind

Transcripción

Documentos relacionados

creación de un servidor de dns esclavo

OBTENER DNS DE FORMA AUTOMÁTICA