Source: https://klickea.wordpress.com/2016/12/29/dns-en-centos-7/
Timestamp: 2017-12-16 08:52:41+00:00

Document:
Configuración de un DNS en Linux (BIND) – Klickea
Date: 29 diciembre, 2016Author: Oriol Santos 0 Comentarios
En el siguiente tutorial procederemos a configurar un servidor DNS sobre una máquina con sistema operativo Centos 7, concretamente con la versión 3.10.0 del Kernel 64 bits.
Para configurar el servició DNS, en el equipo indicado, hemos escogido el paquete Bind, uno de los más extendidos, por no decir el más extendido, si bien es cierto que hay otros, como por ejemplo PowerDNS.
En cualquier caso, nosotros hemos preferido realizar la configuración con Bind.
Algo sobre Bind
BIND (Berkeley Internet Name Domain) es el servidor de DNS más comúnmente usado, especialmente en sistemas Unix.
Una nueva versión de BIND (BIND 9) fue escrita desde cero para superar las dificultades arquitectónicas presentes anteriormente al auditar el código en las primeras versiones de BIND, y también para incorporar DNSSEC (DNS Security Extensions).
https://es.wikipedia.org/wiki/BIND
Algo sobre DNS
Trabajar con direcciones IP es incómodo para las personas, ya que requeriría conocer en todo momento las direcciones IP de los equipos a los que queremos conectarnos. En su lugar utilizamos nombres de dominio que son más fáciles de recordar y utilizar.
Cada equipo y cada servidor conectado a Internet, dispone de una dirección IP y de un nombre perteneciente a un dominio. Internamente, la comunicación entre los PCs se realiza utilizando direcciones IP por eso es necesario algún sistema que permita, a partir de los nombres de los PCs, averiguar las direcciones IPs de los mismos.
http://www.ite.educacion.es/formacion/materiales/85/cd/linux/m2/servidor_dns.html
Antes de empezar, debemos puntualizar que la seguridad no es uno de los puntos que hemos decidido tratar en este post.
Hay aspectos que debemos tener en cuenta a la hora de securizar nuestro servidor DNS, si no queremos sufrir denegaciones de servicio, inconsistencia de datos o consultas e ingresos indeseados. Por ello y si este tutorial tiene cierto número de visitas realizaremos una segunda parte para la configuración de DNSSEC, delimitación de zonas, creación de un HA y reglas de firewall especificas para evitar sustos.
En primer lugar deberemos descargar el paquete e instalarlo en nuestro servidor, para ellos ejecutaremos:
Instalación de esenciales:
Instalación del repositorio epel y actualización de los paquetes.
Instalación del los paquete Bind necesarios
bind: Paquete de instalación del servidor DNS, versión 9.9.4.
bind-utils: Aplicaciones necesarias para comprobar el correcto funcionamiento de un servicio DNS: nslookup, dig y host, que veremos más adelante.
Una vez finalice la instalación, de los paquetes indicados, deberemos proceder a la configuración.
En primer lugar, deberemos dirigirnos al fichero de configuración, ubicado en /etc/named.conf, e identificar todos los elementos que el fichero nos muestra.
A pesar de estar explicado en la documentación de Bind, daremos un repaso a los principales contenidos de dicho fichero. No entraremos en un detalle exhaustivo acerca de todas las opciones del fichero named.conf, puesto que el post se alargaría y como ya hemos explicado la principal idea es configurar un servidor DNS básico. En cualquier caso, el fichero named.conf cuenta de las siguientes declaraciones:
controls declares control channels to be used by the rndc utility.
key specifies key information for use in authentication and authorization using TSIG.
logging specifies what the server logs, and where the log messages are sent.
lwres configures named to also act as a light-weight resolver daemon (lwresd).
masters defines a named masters list for inclusion in stub and slave zone masters clauses.
options controls global server configuration options and sets defaults for other statements.
statistics-channels declares communication channels to get access to named statistics.
trusted-keys defines trusted DNSSEC keys.
managed-keys lists DNSSEC keys to be kept up to date using RFC 5011 trust anchor maintenance.
view defines a view.
Configuración del fichero named.conf
De todas las opciones definidas en la tabla anterior únicamente nos centraremos en :
Declaración options: Delimitada por {}, contiene:
A continuación podemos ver un ejemplo, el que hemos utilizado para crear nuestro servidor dns, de la declaración options. Esta declaración permite definir los parámetros generales del funcionamiento del servidor DNS, como por ejemplo, el puerto, quien puede realizar consultas, si el activamos el DNSSEC, etc…
Para entender un poco que es cada parámetro, a continuación, mostramos una pequeña descripción de cada campo.
listen on port 53 { 127.0.0.1; 192.168.1.250; };
Puerto donde escucha peticiones
listen-on-v6 port 53{ ::1; };
Puerto donde escucha peticiones en Ipv6
Directorio donde se almacenan las configuraciones de zonas.
Define la ruta absoluta donde BIND vuelca la base de datos (caché). El valor predeterminado es NAMED_DUMP.DB
Indica el nombre del fichero en el que se escribirán los datos cuando se ejecute el comando rndc stats. Si el parámetro no está definido la información se almacena en el fichero named.stats en la path /var/name/data/, por defecto.
Define el nombre del archivo en el cual se escribirán las estadísticas de uso de memoria. Si el parámetro no está presente las estadísticas se escriben en named.memstats.
Permite definir los origines (hosts o redes) que podrán consultar nuestro servidor
recursion yes/no;
La recursividad se activa de manera predeterminada en Bind. Esto permite que el servidor DNS pregunte a otros servidores DNS en nombre del cliente solicitante para resolver completamente el nombre solicitado, antes de enviar la respuesta al cliente. Se debe tener en cuenta que esta configuración puede aumentar la vulnerabilidad de un servidor DNS.
dnssec-enable yes/no;
Indica soporte DNSSEC como servidor autoritativo de un dominio
dnssec-validation yes/no;
Activará la validación de respuestas DNSSEC como servidor recursivo.
Repositorio alternativo para claves de confianza, donde podemos presentar las claves de zona. El valor por defecto de DLV es dlv.isc.org.
Indica el directorio utilizado para almacenar las llaves administrados. Por defecto es el directorio de trabajo.
Define la path al fichero donde el servicio escribe su ID de proceso. Si no se especifica, el valor predeterminado es /var/run/named/named.pid. El archivo de PID es utilizado por programas que desean enviar señales al servidor de nombres. Especificando pid-file no inhabilita el uso de un archivo PID.
Indica la path de acceso al archivo donde escribir una clave TSIG de sesión generada por named para ser utilizada por nsupdate -l . Si no se especifica, el valor predeterminado es /var/run/named/session.key.
Declaración logging: Delimitada por {}, contiene:
La siguiente declaración que definiremos, en el fichero named.conf, es el logging. Esto nos permite indicar el nivel de logs que queremos obtener, o como gestionarlos. Como hemos hecho anteriormente mostramos el ejemplo utilizado:
A continuación, mostramos una pequeña descripción de cada campo.
channel default_debug (default_syslog | default_stderr | default_null )
Indica el canal de logging, fichero, syslog, salida de error o ninguno.
file “data/named.run”
Definimos la path donde escribir el fichero named.run, que contiene toda la información de depuración.
severity dynamic (critical | error | worning | notice | info| debug [level]]
Severity permite indicar el nivel de registro de logs. dynamic registra los mensajes coincidentes con el nivel debug especificado.
Declaración zonas: Delimitadas por {}, contiene:
El siguiente paso, será definir las zonas necesarias de resolución. Las zonas nos permiten definir ficheros que contendrán la relación entre los nombres y las IPS y/o viceversa. Ejemplo utilizado:
zone “server.yes” IN {
file “directa.server”;
zone “1.168.192.in-addr-arpa” IN {
file “inversa.server”;
Descripción de los campos indicados:
Especifica los ficheros de la zona root (zona raiz)
zone “server.yes” IN
Zona de resolución directa, en este caso server.yes.
En esta declaración observamos,el tipo de zona (master), el nombre del fichero y el tipo de actualizaciones, en este caso no definidas.
zone “1.168.192.in-arpa” IN
Zona de resolución inversa, en este caso haría referencia a 192.168.1.
En esta declaración observamos, el tipo de zona (master), el nombre de fichero y el tipo de actualizaciones, el mismo que en la zona directa.
Declaración de includes:
Por ultimo, definiremos los includes mínimos necesarios. Los includes nos permiten indicar ficheros con configuraciones que el servicio bind debe terne en cuenta a la hora iniciarse. Ejemplo utilizado:
Descripción del include indicado:
Sin ser obligatorio, este include, nos permite indicar las zonas localhost recomendadas por el RFC1912, tanto para ipv4 como para ipv6.
Foto Final del fichero /etc/named.conf
Configuración de las Zonas de Resolución
Realizada la instalación de los paquetes Bind y la definición del fichero /etc/named.conf, procederemos a realizar la configuración de los ficheros de resolución, tanto directa como inversa.
En primer lugar aclararemos un concepto básico:
Resolución directa: es la relación directa entre un nombre y una IP. El servidor por tanto, relaciona el nombre consultado con la ip asociada.
Ejemplo: quiero obtener la IP de un host:
nslookup host.server.yea – > 192.168.1.223
Resolución inversa: Por el contrario, una resolución inversa, como su propio nombre indica, establece la relación entre una IP y el nombre asociado. Consulto una IP y me retorna el nombre.
Ejemplo: quiero obtener el nombre de un host:
nslookup192.168.1.223 – > host.server.yea
Si no indicamos lo contrario en el fichero de configuración del bind (named.conf), las zonas se almacenan en /var/named/, con el nombre que deseemos, aunque siempre es bueno que sea aclarador. En nuestro ejemplo, hemos creado las zonas directa e inversa server.yea y 1.168.192 con los nombres directa.server y inversa.server.
Creación de ficheros de zonas
Como hemos dicho, los ficheros de zona se almacenan en /var/named/, así que nos dirigiremos a esa ubicación y crearemos los ficheros de zona, tal y como se muestra a continuación:
touch directa.server
touch inversa.server
chown root:named directa.server
chown root:named inversa.server
chmod 644 directa.server
chmod 644 inversa.server
Zona de resolución directa: directa.server
A continuación, se muestra el ejemplo del fichero de resolución directa que hemos creado para este post. Se debe tener en cuenta que, en los fichero de bind, los “;” indican comentario.
@ IN SOA srvdns.server.yes. root.server.yes. (
86400 ; Minimun TTL
@ IN NS srvdns.server.yes.
@ IN A 192.168.1.250
srvdns IN A 192.168.1.250
gromek IN A 192.168.1.105
Zona de resolución inversa: inversa.server
A continuación, se muestra el ejemplo del fichero de resolución inversa que hemos creado.
@ IN PTR inversa.yes.
250 IN PTR srvdns.server.yes.
105 IN PTR gromek.server.yes.
Los ficheros de zona, son muchos más sencillos, pero debemos conocer ciertos aspectos como son:
La mayoría de registros tiene el formato: nombre/IP IN tipo_registro contenido_registro
Los campos que deben indicarse son (todos los tiempos están definidos en segundos para este ejemplo):
TTL: Tiempo de vida en cache.
Serial: Permite diferenciar servidores maestros de esclavos. Si el numero de serie no cambia el servidor esclavo no actualiza su fichero de zona.
Refresh: indica al servidor esclavo cada cuanto tiempo tiene que consultar el servidor maestro para actualizar sus registros.
Retry: Indica al servidor esclavo cada cuanto tiene que intentar un conexión si se produce un fallo al conectar con el servidor maestro.
Expire: Indica al servidor esclavo durante cuanto tiempo debe enviar datos si no logra conectar con el servidor maestro.
Minimun TTL: Indica el tiempo mínimo de almacenamiento de un registro en cache a un cliente que solicita una resolución.
Los tipos de registro principales son:
NS: Proporciona el nombre del servidor DNS para el dominio.
A: Vincula un nombre de equipo con una dirección ip, se puede especificar el nombre fqdn, o sólo en nombre del host.
AAAA: Son equivalentes a los registros A, pero para ipv6
PTR: Es la inversa del registro A. Vincula las direcciones IP con nombres de equipos.
MX: Registro de intercambio de correo.
CNAME: Registro de nombre canónico. Permite vincular nombres de hosts con otros nombres de hosts, conocidos como alias.
SOA: Registro de inicio de autoridad. Debe ser el primero.
TXT: Este registro permite añadir texto explicativo asociado al dominio.
Foto Final del fichero de las zonas creadas
El siguiente paso, consistirá en: comprobar la sintaxis del fichero named.conf, registrar el servicio named en el systemctl y arrancarlo. Para ello, ejecutaremos los siguientes comandos:
Si el proceso de checkeo es correcto, nos debería retornar una salida como se muestra en la captura siguiente.
Está instrucción nos creará, en /usr/lib/systemd/system/named.service, el fichero con los datos de configuración de inició de named. Esto permitirá que el sistema operativo, pueda gestionar el servicio named, durante el proceso de arranque.
Con las dos instrucciones anteriores podremos arrancar el servicio y comprobar el estado del mismo. Si todo es correcto debería aparecer algo similar a esto:
Para comprobar que todo está bien disponemos una batería de comandos, que nos pueden ayudar a ver que sucede en caso de fallo o a comprender el funcionamiento de un servidor DNS. Pero antes debemos tener presente que, si no disponemos de un servidor DHCP para indicar cuál es nuestro servidor DNS a los clientes de la red, deberemos configurarlo manualmente en cada host. Esto se puede hacer de manera sencilla, por ejemplo, editando el fichero /etc/resolv.conf.
Este fichero se encarga de indicar el servidor DNS y el nombre de domino, entre otras cosas. Lo que parámetros que debemos conocer básicamente son:
domain: Indicamos el nombre del dominio principal. server.yes
search: Domino para completar y poder formar un fqdn. Dominio por defecto
nameserver: Ip del servidor dns.
Ejemplo /etc/resolv.conf utilizado:
domain server.yes
search server.yes
Modificado el fichero anterior, volvemos a las comprobaciones. Básicamente podemos utilizar los comandos siguientes (Deben retornar lo mismo que en las capturas adjuntadas en cada uno de ellos) :
ping : permite identificar si un host está operativo (protocolo ICMP) y por tanto su resolución es correcta.
nslookup: permite, entre otras cosas, comprobar la resolución directa e inversa mediante la realización de consultas al servidor DNS.
dig: (domain information groper) permite solicitar información a un servidor DNS. Más exhaustivo que nslookup.
host: utilidad de consultas DNS.
No vamos a entrar a definir todos los parámetros de cada uno de los comandos, si bien es cierto, que probablemente en próximos artículos detallaremos el uso de todos ellos.
http://ortr.blogspot.com.es/2015/01/instalacion-y-configuracion-de-dns-en.html
https://nnc3.com/mags/Networking2/dns/ch07_05.html
http://www.linuxfromscratch.org/blfs/view/svn/basicnet/avahi.html
http://blog.punto.hn/wp-content/uploads/2016/05/DNSSEC.pdf
https://ftp.isc.org/isc/bind/9.8.0-P4/doc/arm/Bv9ARM.ch06.html
Anterior Entrada anterior: Contactless/NFC ¿Seguros?
Siguiente Entrada siguiente: SSH seguro con Fail2ban

References: resolución 
 resolución 
 Resolución

Resolución 

Resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución