Si algunos de nuestros foros, manuales, ALDOS, paquetería o proyectos te han resultado de ayuda, apreciaremos mucho nos apoyes con un donativo.
Configuración de servidor de nombres de dominio (DNS), parte I.
Correo electrónico: darkshram en gmail punto com Sitio de Red: http://www.alcancelibre.org/
Jabber ID: darkshram@jabber.org
Creative Commons Reconocimiento-NoComercial-CompartirIgual 2.1
© 1999-2015 Joel Barrios Dueñas. Usted es libre de copiar, distribuir y comunicar públicamente la obra y hacer obras derivadas bajo las condiciones siguientes: a) Debe reconocer y citar al autor original. b) No puede utilizar esta obra para fines comerciales (incluyendo su publicación, a través de cualquier medio, por entidades con fines de lucro). c) Si altera o transforma esta obra o genera una obra derivada, sólo puede distribuir la obra generada bajo una licencia idéntica a ésta. Al reutilizar o distribuir la obra, tiene que dejar bien claro los términos de la licencia de esta obra. Alguna de estas condiciones puede no aplicarse si se obtiene el permiso del titular de los derechos de autor. Los derechos derivados de usos legítimos u otras limitaciones no se ven afectados por lo anterior. Licencia completa en castellano. La información contenida en este documento y los derivados de éste se proporcionan tal cual son y los autores no asumirán responsabilidad alguna si el usuario o lector, hace mal uso de éstos.
Introducción.
Es imprescindible primero estudiar y comprender, los conceptos descritos en el documento titulado «Introducción al protocolo DNS.»
Acerca de Bind (Berkeley Internet Name Domain).
BIND (acrónimo de Berkeley Internet Name Domain) es una implementación del protocolo DNS y provee una implementación libre de los principales componentes del Sistema de Nombres de Dominio, los cuales incluyen:
- Un servidor de sistema de nombres de dominio (named).
- Una biblioteca resolutoria de sistema de nombres de dominio.
- Herramientas para verificar la operación adecuada del servidor DNS (bind-utils).
El Servidor DNS BIND es utilizado de manera amplia en Internet en aproximadamente el 99% de los servidores DNS del mundo, proporcionando una robusta y estable solución.
Equipamiento lógico necesario.
Paquete. | Descripción. |
bind | Incluye el Servidor DNS (named) y herramientas para verificar su funcionamiento. |
bind-libs | Bibliotecas compartidas, que consisten en rutinas para aplicaciones para utilizarse cuando se interactúe con Servidores DNS. |
bind-chroot | Contiene un árbol de archivos que puede ser utilizado como una jaula chroot para named añadiendo seguridad adicional al servicio. |
bind-utils | Colección de herramientas para consultar Servidores DNS. |
Instalación a través de yum.
Ejecute lo siguiente para instalar Bind 9.9 en CentOS 7 o Red Hat™ Enterprise Linux 7:
yum -y install bind bind-chroot bind-utils |
Ejecute lo siguiente para instalar Bind 9.8 en CentOS 6 o Red Hat™ Enterprise Linux 6:
yum -y install bind bind-chroot bind-utils |
Si se utiliza CentOS 5 o Red Hat™ Enterprise Linux 5 se puede instalar Bind 9.7 ejecutando lo siguiente:
yum remove bind-libs bind-utils bind bind-chroot caching-nameserver |
Crear firma digital del servidor.
Con la finalidad de mejorar la seguridad, genere una firma digital de 512 bits (el valor predeterminado es 128 bits) para el servidor DNS. Ejecute lo siguiente:
rndc-confgen -a -r /dev/urandom -b 512 -c /etc/rndc.key |
Cambie las pertenencias para que este archivo sea propiedad del usuario root y grupo named:
chown root:named /etc/rndc.key |
Asegure que los permisos de acceso sean lectura y escritura para usuario, sólo lectura para grupo y nada para otros, es decir un permiso 640 (rw-r-----):
chmod 640 /etc/rndc.key |
Actualizar el archivo de cache con los servidores DNS raíz.
El archivo /var/named/named.ca contiene la información de los servidores DNS raíz necesaria para poder iniciar el cache de todo servidor DNS de Internet. Actualice este archivo para evitar problemas para la resolución de algunas zonas ejecutando la siguiente línea:
|
También puede ejecutar lo siguiente para lograr el mismo fin.
|
Conviene verificar periódicamente si hay alguna actualización de este archivo. La versión más reciente al momento de redactar este documento corresponde al 3 de enero de 2013.
El archivo debe pertenecer a root y el grupo named.
|
Asigne permiso de lectura y escritura para usuario, sólo lectura para grupo y nada para otros (rw-r-----).
|
Procedimientos.
SELinux y el servicio named.
A mediados de 2008, Common Vulnerabilities and Exposures List y US-CERT, reportaron que el investigador Dan Kaminsky descubrió una vulnerabilidad que afectaba a varias implementaciones de DNS (BIND 8 y 9 antes de 9.5.0-P1, 9.4.2-P1 y 9.3.5-P1; Microsoft DNS en todas las versiones de Windows 2000 SP4, XP SP2 y SP3, así como Server 2003 SP1 y SP2).
Esta vulnerabilidad permite a cualquier atacante remoto el poder falsificar tráfico DNS a través de ciertas técnicas de contaminación de cache en servidores que realizan resolución recursiva (es decir cuando se usa la opción allow-recursion abierta a todo el mundo, como ocurre en los servidores DNS públicos) y se relaciona a insuficiente aleatoriedad de las identidades de transacción y de los puertos de origen. Es decir, una vulnerabilidad de entropía de insuficiencia de zócalos (sockets) de DNS (conocido como DNS Insufficient Socket Entropy Vulnerability). A través de esta vulnerabilidad un atacante puede contaminar el cache de un servidor DNS y hacer que los clientes se conecten hacia direcciones falsas. Es importante aclarar que en realidad se trata de una vulnerabilidad en el diseño del protocolo DNS.
SELinux protege casi por completo al servicio named contra la vulnerabilidad anteriormente descrita. Es por tal motivo que es importante utilizar SELinux.
Ejecute lo siguiente para que SELinux permita al servicio named trabajar con permisos de escritura para zonas maestras, es decir un esquema de servidor maestro con servidores esclavos o bien como servidor DNS dinámico:
setsebool -P named_write_master_zones=1 |
Lo anterior aplica para cualquier versión de CentOS y Red Hat Enterprise Linux.
Cualquier archivo de zona que se vaya a utilizar a través del servicio named debe tener el contexto de SELinux tipo named_zone_t. El contexto se hereda automáticamente al copiar o crear nuevos archivos dentro de este directorio.
Cualquier archivo de zona dentro de los directorios /va/named/dynamic y /var/named/slaves debe tener el contexto de SELinux tipo named_cache_t. El contexto se hereda automáticamente al copiar o crear nuevos archivos dentro de estos directorios.
Cuando las circunstancias lo ameriten, es posible corregir los contextos a los correctos ejecutando lo siguiente.
restorecon -Rv /var/named |
Descargue configuración mínima para el archivo /etc/named.conf.
Respalde el archivo /etc/named.conf que se instaló originalmente con el paquete:
mv /etc/named.conf /etc/named.conf.original |
Ejecute lo siguiente para descargar un archivo plantilla desde AlcanceLibre.org:
|
Asegure que el archivo tiene los contextos de SELinux correcto ejecutando lo siguiente:
|
El archivo debe pertenecer a root y el grupo named.
|
Asigne permiso de lectura y escritura para usuario, sólo lectura para grupo y nada para otros (rw-r-----).
|
Personalice el archivo /etc/named.conf.
Edite el archivo /etc/named.conf:
vim /etc/named.conf |
La configuración mínima de este archivo y la cual permitirá utilizar el servicio para todo tipo de uso, es la siguiente. Personalice los valores resaltados.
options { |
Lo anterior define lo siguiente.
- El directorio predeterminado será /var/named.
- Se define como archivo para almacenar la información del caché a /var/named/data/cache_dump.db.
- Se define como archivo para almacenar estadísticas generales a /var/named/data/named_stats.txt.
- Se define como archivo para almacenar estadísticas específicas en lo concerniente al uso de la memoria a /var/named/data/named_mem_stats.txt.
- Se definen como ejemplos de servidores DNS para reenviar consultas a 8.8.8.8 y 8.8.4.4, los cuales corresponden a los servidores DNS públicos de Google. Puede reemplazar éstos por los servidores DNS del proveedor de acceso a Internet utilizado.
- Se define que la primera opción al realizar consultas será reenviar éstas hacia los servidores DNS que se acaban de definir.
- Se incluyen los archivos de configuración /etc/named.rfc1912.zones, que corresponde a las zonas del RFC 1912 y la firma digital única que se generó automáticamente tras instalar el paquete bind.
- Se define que los controles se realizan solamente desde 127.0.0.1, hacia 127.0.0.1 y utilizando la firma digital.
- Se definen dos zonas de consulta. Local y Public.
- La zona local sólo permite realizar consultas desde 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0712 y 192.168.0.0/26. En esta misma zona se define que las consultas recursivas sólo están permitidas para éstas mismas redes.
- la zona public sólo permite acceso desde cualquier parte excepto las redes definidas en la zona local.
Personalice lo siguiente:
- Servidores DNS de forwarders.
- Redes definidas en la sección match-clients de la vista local. Deje intacto 127.0.0.0/8.
- Defina yes o no para los valores de dnssec-enable y dnssec-validation. Para utilizar DNSSEC se requiere que los servidores DNS definidos en la sección forwaredes tengan soporte para DNSSEC.
Inicie el servicio y añada al arranque del sistema.
CentOS 7 y Red Hat™ Enterprise Linux 7 y versiones posteriores.
Ejecute lo siguiente para iniciar el servicio la primera vez:
|
Ejecute lo siguiente para habilitar el servicio:
|
CentOS 6 y Red Hat™ Enterprise Linux 6 y versiones anteriores.
|
Ejecute lo siguiente para habilitar el servicio:
|
Comprobaciones.
Compruebe que el servidor DNS recién configurado es capaz de resolver nombres por si mismo. Ejecute lo siguiente:
|
La salida debe ser similar a la siguiente:
[root@cursocentos ~]# host www.google.com 127.0.0.1 |
Si algo salió mal, por favor revise de nuevo las opciones que personalizó en el archivo /etc/named.conf y repita procedimientos.
Configure 127.0.0.1 como único DNS del sistema.
Si lo anterior funciona, edite el archivo /etc/resolv.conf:
|
Establezca a 127.0.0.1 como único servidor DNS. Ejemplo:
|
Edite el archivo de configuración de la interfaz principal de su servidor. Ejemplo:
|
Establezca a 127.0.0.1 como único servidor DNS. Ejemplo:
DEVICE=enp0s3 |
Si la interfaz está configurada por DHCP, añada la opción PEERDNS con valor no y DNS1 con valor 127.0.0.1. Ejemplo:
DEVICE=enp0s3 |
Reinicie el servicio de red para aplicar los cambios:
|
Verifique el el DNS predeterminado del sistema puede resolver nombres. Por favor, ejecute lo siguiente:
|
La salida debe ser similar a la siguiente:
[root@cursocentos ~]# host www.google.com |
Si algo salió mal, por favor revise de nuevo las opciones que personalizó en el archivo /etc/named.conf y repita procedimientos.
Preparativos para añadir dominios.
Idealmente se deben definir primero los siguiente datos:
- Dominio a resolver.
- Servidor de nombres principal (SOA). Éste debe ser un nombre que ya esté plenamente resuelto, y debe ser un FQDN (Fully Qualified Domain Name).
- Lista de todos los servidores de nombres (NS) que se utilizarán para efectos de redundancia. Éstos deben ser nombres que ya estén plenamente resueltos y deben ser además FQDN (Fully Qualified Domain Name).
- Cuenta de correo del administrador responsable de esta zona. Dicha cuenta debe existir y debe ser independiente de la misma zona que se está tratando de resolver.
- Al menos un servidor de correo (MX), con un registro A, nunca CNAME.
- IP predeterminada del dominio.
- Sub-dominios dentro del dominio (www, mail, ftp, ns, etc.) y las direcciones IP que estarán asociadas a éstos.
Es importante tener bien en claro que los puntos 2, 3 y 4, involucran datos que deben existir previamente y estar plenamente resueltos por otro servidor DNS; Lo anterior quiere decir que jamás se deben utilizar datos que sean parte o dependan, del mismo dominio que se pretende resolver. De igual modo, el servidor donde se implementará el DNS deberá contar con un nombre FQDN y que esté previa y plenamente, resuelto en otro DNS.
Se debe crear una zona de reenvío por cada dominio sobre el cual se tenga autoridad plena y absoluta y se creará una zona de resolución inversa por cada red sobre la cual se tenga plena y absoluta autoridad. Es decir, si usted es el propietario del dominio «cualquiercosa.com», debe crear el archivo de zona correspondiente con el fin de resolver dicho dominio. Por cada red con direcciones IP privadas, sobre la cual se tenga control y absoluta autoridad, se debe crear un archivo de zona de resolución inversa a fin de resolver inversamente las direcciones IP de dicha zona.
Regularmente la resolución inversa de las direcciones IP públicas es responsabilidad de los proveedores de servicio ya que son éstos quienes tienen el control sobre éstas.
Todos los archivos de zona deben pertenecer al usuario «named» a fin de que el servicio named pueda acceder a éstos o bien modificar éstos en el caso de tratarse de zonas esclavas.
Creación de los archivos de zona.
Los siguientes corresponderían a los contenidos para los archivos de zona requeridos para la red local y por el NIC con el que se haya registrado el dominio. Cabe señalar que en las zonas de reenvío siempre se especifica al menos un registro SOA y un registro NS. De manera opcional y en caso de que exista un servicio de correo electrónico, añada al menos un registro MX (Mail Exchanger o intercambiador de correo). Solamente necesitará sustituir nombres y direcciones IP y quizá añadir nuevos registros para complementar su red local.
Configuración mínima para /etc/named.conf en CentOS 5 y Red Hat™ Enterprise Linux 5.
La configuración mínima del archivo /chroot/etc/named.conf y que permitirá utilizar el servicio para todo tipo de uso, es la siguiente:
options { directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; managed-keys-directory "/var/named/dynamic"; version "BIND"; forwarders { 8.8.8.8; 8.8.4.4; }; forward first; // Solo habilitar lo siguiente si se va a utilizar DNSSEC y si los // servidores DNS del proveedor tienen soporte para DNSSEC. dnssec-enable yes; dnssec-validation yes; dnssec-lookaside auto; bindkeys-file "/etc/named.iscdlv.key"; }; include "/etc/rndc.key"; include "/etc/named.root.key"; logging { channel default_debug { file "data/named.run"; severity dynamic; }; category lame-servers { null; }; }; controls { inet 127.0.0.1 allow { 127.0.0.1; } keys { "rndckey"; }; }; view "local" { match-clients { 127.0.0.0/8; 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; }; recursion yes; include "/etc/named.rfc1912.zones"; }; |
Lo anterior define como opciones que el directorio predeterminado será /var/named, se define un archivo donde se almacena la información del caché en /var/named/data/cache_dump.db; un archivo de estadísticas en /var/named/data/named_stats.txt, un archivo de estadísticas específicas en lo concerniente al uso de la memoria en /var/named/data/named_mem_stats.txt; consultas recursivas permitidas solamente a 127.0.0.1 y 192.168.1.0/24; se definen como ejemplos de servidores DNS para reenviar consultas a 8.8.8.8 y 8.8.4.4, que corresponden a servidores DNS públicos de Google, los cuales puede reemplazar por los servidores DNS del proveedor de acceso a Internet utilizado; se define que la primera opción al realizar una consulta será reenviar a los DNS que se acaban de definir; se incluyen los archivos de configuración /etc/named.rfc1912.zones, que corresponde a las zonas del RFC 1912 y la firma digital única que se generó automáticamente tras instalar el paquete bind; Se define también que los controles se realizan solamente desde 127.0.0.1, hacia 127.0.0.1, utilizando la firma digital única.
Conviene asegurarse que el archivo /etc/named.conf tenga los contextos correspondientes para SELinux a fin de evitar potenciales problemas de seguridad.
chcon -u system_u -r object_r -t named_conf_t /etc/named.conf
|
Ejemplo de Zona de reenvío red local /var/named/data/red-local.zone.
$TTL 3600 @ IN SOA dns.red-local. alguien.gmail.com. ( 2015090901; número de serie 1800 ; tiempo de refresco 900 ; tiempo entre reintentos de consulta 604800 ; tiempo tras el cual expira la zona 3600 ; tiempo total de vida ) @ IN NS dns.red-local.net. @ IN MX 10 mail @ IN TXT "v=spf1 a mx -all" @ IN A 192.168.1.1 intranet IN A 192.168.1.1 maquina2 IN A 192.168.1.2 maquina3 IN A 192.168.1.3 maquina4 IN A 192.168.1.4 www IN A 192.168.1.1 mail IN A 192.168.1.1 ftp IN CNAME intranet dns IN CNAME intranet |
Zona de resolución inversa red local /var/named/data/1.168.192.in-addr.arpa.zone
$TTL 3600 @ IN SOA dns.red-local. alguien.gmail.com. ( 2015090901 ; número de serie 1800 ; tiempo de refresco 900 ; tiempo entre reintentos de consulta 604800 ; tiempo tras el cual expira la zona 3600 ; tiempo total de vida ) @ IN NS dns.red-local. 1 IN PTR intranet.red-local. 2 IN PTR maquina2.red-local. 3 IN PTR maquina3.red-local. 4 IN PTR maquina4.red-local. |
Zona de reenvío del dominio /var/named/data/dominio.com.zone
Suponiendo que hipotéticamente se es la autoridad para el dominio «dominio.com», se puede crear una Zona de Reenvío con un contenido similar al siguiente:
$TTL 3600 @ IN SOA fqdn.dominio.tld. alguien.gmail.com. ( 2015090901; número de serie 1800 ; tiempo de refresco 900 ; tiempo entre reintentos de consulta 604800 ; tiempo tras el cual expira la zona 3600 ; tiempo total de vida ) @ IN NS fqdn.dominio.tld. @ IN MX 10 mail @ IN TXT "v=spf1 a mx -all" @ IN A 201.161.1.226 servidor IN A 201.161.1.226 www IN A 201.161.1.226 mail IN A 201.161.1.226 ftp IN CNAME servidor dns IN CNAME servidor |
Zona de resolución inversa del dominio /var/named/data/1.161.201.in-addr.arpa.zone
Suponiendo que hipotéticamente se es la autoridad para el segmento de red 201.161.1.0/24 (regularmente lo debe de hacer el proveedor de servicio de acceso hacia Internet), se puede crear una Zona de Resolución Inversa con un contenido similar al siguiente:
$TTL 3600 @ IN SOA fqdn.dominio.tld. alguien.gmail.com. ( 2015090901 ; número de serie 1800 ; tiempo de refresco 900 ; tiempo entre reintentos de consulta 604800 ; tiempo tras el cual expira la zona 3600 ; tiempo total de vida ) @ IN NS fqdn.dominio.tld. 1 IN PTR servidor.dominio.com. 2 IN PTR maquina2.dominio.com. 3 IN PTR maquina3.dominio.com. 4 IN PTR maquina4.dominio.com. |
Cada vez que haga algún cambio en algún archivo de zona, deberá cambiar el número de serie a fin de que tomen efecto los cambios de inmediato cuando se reinicie el servicio named, ya que de otro modo tendría que reiniciar el equipo, algo poco conveniente.
Las zonas de resolución inversa que involucran direcciones IP públicas son responsabilidad de los ISP (proveedores de servicio de acceso hacia Internet). Crear una zona de resolución inversa sin ser la autoridad de dicha zona tiene efecto sólo para quien use el servidor DNS recién configurado como único DNS.
Configuración de opciones del archivo /etc/named.conf
options { directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; managed-keys-directory "/var/named/dynamic"; version "BIND"; forwarders { 8.8.8.8; 8.8.4.4; }; forward first; // Solo habilitar lo siguiente si se va a utilizar DNSSEC y si los // servidores DNS del proveedor tienen soporte para DNSSEC. dnssec-enable yes; dnssec-validation yes; dnssec-lookaside auto; bindkeys-file "/etc/named.iscdlv.key"; }; include "/etc/rndc.key"; include "/etc/named.root.key"; logging { channel default_debug { file "data/named.run"; severity dynamic; }; category lame-servers { null; }; }; controls { inet 127.0.0.1 allow { 127.0.0.1; } keys { "rndc-key"; }; }; view "local" { match-clients { 127.0.0.0/8; 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; }; recursion yes; include "/etc/named.rfc1912.zones"; zone "." IN { type hint; file "named.ca"; }; zone "red-local" { type master; file "data/red-local.zone"; allow-update { none; }; }; zone "1.168.192.in-addr.arpa" { type master; file "data/1.168.192.in-addr.arpa.zone"; allow-update { none; }; }; }; |
Continúa en Configuración de servidor de nombres de dominio (DNS), parte II.