Source: http://docplayer.es/2298662-Como-configurar-un-servidor-de-nombres-de-dominio-dns-parte-i.html
Timestamp: 2017-08-21 07:09:13+00:00

Document:
Cómo configurar un servidor de nombres de dominio (DNS), parte I. - PDF
Cómo configurar un servidor de nombres de dominio (DNS), parte I.
Download "Cómo configurar un servidor de nombres de dominio (DNS), parte I."
Ignacio Herrera Franco
1 1 de 7 18/09/ :30 a.m. Ingresar Registrarse Enviar Nota Twitter Google+ Descargas Servicios Portada Foros Manuales Servicios Cursos Linux Buscar al 19 de octubre, Curso Global de Servidores con CentOS 6. Disponible ALDOS Nuestro sistema operativo para escritorio. Sondeo Cómo configurar un servidor de nombres de dominio (DNS, parte I. Si ya probaste GNOME 3... Te gustó GNOME 3? Si No Este sondeo tiene 5 preguntas más. Iniciar Sondeo Resultados Más sondeos 15,959 votos 9 comentarios Autor: Joel Barrios Dueñas Correo electrónico: darkshram en gmail punto com Sitio de Red: Jabber ID: Creative Commons Reconocimiento-NoComercial-CompartirIgual 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. bind bind-libs bind-chroot bind-utils cachingnameserver Descripción. Incluye el Servidor DNS (named, y herramientas para verificar su funcionamiento. Bibliotecas compartidas, que consisten en rutinas para aplicaciones para utilizarse cuando se interactúe con Servidores DNS. Contiene un árbol de archivos que puede ser utilizado como una jaula chroot para named añadiendo seguridad adicional al servicio. Colección de herramientas para consultar Servidores DNS. Archivos de configuración que harán que el Servidor DNS actúe como un caché para el servidor de nombres. Este paquete desaparece en CentOS 6 y Red Hat Enterprise Linux 6, pues su contenido se incorporó en el paquete principal de bind.
2 2 de 7 18/09/ :30 a.m. Instalación a través de yum. Si se utiliza CentOS 6, o Red Hat Enterprise Linux 6, se puede instalar Bind 9.7 utilizando lo siguiente: yum -y install bind bind-chroot bind-utils Si se utiliza CentOS 5, o Red Hat Enterprise Linux 5, se puede instalar Bind utilizando lo siguiente: yum -y install bind bind-chroot bind-utils caching-nameserver Si se utiliza CentOS 5, o Red Hat Enterprise Linux 5, puede instalar, de manera opcional, Bind 9.7, el cual incluye soporte para DNSSEC, utilizando lo siguiente: yum remove bind-libs bind-utils bind bind-chroot caching-nameserver yum -y install bind97 bind97-chroot bind97-utils Ajustes para Bind 9.7. En los sistemas operativos que utilicen Bind 9.7, y versiones posteriores, para poder hacer uso del paquete bind-chroot, se requiere generar la firma digital de 512 bits (el valor predeterminado es 128 bits para el servidor. 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 y grupo named: chown named: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 Mueva los componentes del paquete bind hacia las rutas correspondientes dentro del directorio /var/named/chroot, para luego generar los enlaces simbólicos correspondientes, los cuales serán utilizados por las herramientas de configuración como systemconfig-bind o bien Webmin. Cambie hacia el directorio /var/named: cd /var/named Ejecute lo siguiente: for f in named.* data dynamic slaves do mv $f./chroot/var/named/ ln -s /var/named/chroot/var/named/$f./ done Cambie hacia el directorio /etc: cd /etc Ejecute lo siguiente: for f in named.* rndc.key do mv $f /var/named/chroot/etc/ ln -s /var/named/chroot/etc/$f./ done Regrese al directorio de inicio de root. cd /root 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 P1, P1, y 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
3 3 de 7 18/09/ :30 a.m. 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. A fin de 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, utilice el siguiente mandato: setsebool -P named_write_master_zones 1 Lo anterior aplica para CentOS 5 y 6, y Red Hat Enterprise Linux 5 y 6. Nota. Sólo para CentOS 5 y Red Hat Enterprise Linux 5: Para definir que se desactive la protección de SELinux para el servicio named, haciendo que todo lo anteriormente descrito en esta sección pierda sentido, y que el servidor sea parcialmente susceptible a la vulnerabilidad descubierta por Kaminski, utilice el siguiente mandato: setsebool -P named_disable_trans 1 Sí realiza el procedimiento anterior, es importante configurar la función de consultas recursivas exclusivamente para redes en la que se confíe plenamente. Esta política, al igual que otras similares, fue eliminada en CentOS 6 y Red Hat Enterprise Linux 6. Cualquier archivo de zona que se vaya a utilizar a través del servicio named, debe contar con los contextos de SELinux de usuario de sistema (system_u, rol de objeto (object_r y tipo zona del servicio named (named_zone_t. En el siguiente ejemplo se utiliza el mandato chcon para cambiar los contextos del archivo denominado mi-dominio.zone, con el fin de definir los contextos de SELinux que requiere éste: cd /var/named/chroot/var/named/data/ chcon -u system_u -r object_r -t named_zone_t mi-dominio.zone Lo anterior solamente es necesario si el archivo mi-dominio.zone fue creado fuera del directorio /var/named/chroot/var/named /data/, y fue movido hacia este último. Nota. Sí se utiliza CentOS 5 o Red Hat Enterprise Linux 5 y se va a configurar un DNS dinámico, SELinux impedirá crear los archivos *.jnl (journal, archivos de registro por diario correspondientes. Las zonas de DNS dinámicas deben ser almacenadas en directorios específicos que solamente contengan zonas dinámicas. Se debe crear el directorio /var/named /chroot/var/named/dynamic para tal fin,y configurar éste para qué pertenezca al usuario, y grupo, named, y tenga permisos de lectura, escritura y ejecución para el usuario y grupo named (770 y tenga los contextos de SELinux de usuario de sistema (system_u, rol de objeto (object_r, y tipo cache del servicio named (named_cache_t, con el fin de permitir escritura en este directorio. cd /var/named/chroot/var/named/ mkdir dynamic/ chmod 770 dynamic/ chown named:named dynamic/ chcon -u system_u -r object_r -t named_cache_t dynamic/ Este directorio viene incluido en la instalación estándar de Bind 9.7 en CentOS 6, o Red Hat Enterprise Linux 6, por lo cual es innecesario realizar el procedimiento anterior con estos sistemas operativos. Configuración mínima para el archivo /etc/named.conf. Puede descargar un archivo plantilla desde AlcanceLibre.org, ejecutando lo siguiente: cd /var/named/chroot/etc/ mv named.conf named.conf.original wget restorecon named.conf cd 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:
4 4 de 7 18/09/ :30 a.m. 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"; forwarders { ; ; forward first; dnssec-enable yes; dnssec-validation yes; dnssec-lookaside auto; bindkeys-file "/etc/named.iscdlv.key"; logging { channel default_debug { file "data/named.run"; severity dynamic; controls { inet allow { ; } keys { "rndc-key"; include "/etc/rndc.key"; view "local" { match-clients { /8; /8; /12; /16; recursion yes; include "/etc/named.rfc1912.zones"; zone "." IN { type hint; file "named.ca"; Lo anterior define como opciones que el directorio predeterminado será /var/named (ruta relativa a /var/named/chroot, 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 y /24, se definen como ejemplos de servidores DNS para reenviar consultas a y , que corresponden a los 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 que los controles se realizan solamente desde , hacia , utilizando la firma digital única; Se define que se utilizará DNSSEC, utilizando la firma digital localizada en el archivo /etc/named.iscdlv.key. Tome en consideración que los cambios en CentOS 6 y Red Hat Enterprise Linux 6 respecto de CentOS 5 y Red Hat Enterprise Linux 5, consisten en que se utiliza rndc-key en lugar de rndckey en la configuración de la firma digital, se añaden las líneas correspondientes a la configuración de DNSSEC, se añade configuración para el registro en bitácora y la zona de los servidores raíz va separada del archivo named.rfc1912.zones. CentOS 5 y Red Hat Enterprise Linux 5 puede utilizar exactamente la misma configuración instalando los paquetes bind97, bind97-chroot, bind97-libs y bind97-utils (desaparece el paquete caching-nameserver, cuyo contenido se integró al paquete bind97. 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 /var/named/chroot/etc/named.conf 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.
5 5 de 7 18/09/ :30 a.m. 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. Como regla general, se generará una zona de reenvío por cada dominio sobre el cual se tenga autoridad plena y absoluta y se generará una zona de resolución inversa por cada red sobre la cual se tenga plena y absoluta autoridad. Es decir, si se es el propietario del dominio «cualquiercosa.com», se deberá generar 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 deberá generar 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 la autoridad plena y absoluta sobre dichas direcciones IP. 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 /var/named/chroot/etc/named.conf en CentOS 5 y Red Hat Enterprise Linux 5. La configuración mínima del archivo /var/named/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"; forwarders { ; ; forward first; include "/etc/rndc.key"; controls { inet allow { ; } keys { "rndckey"; view "local" { match-clients { /8; /8; /12; /16; recursion yes; include "/etc/named.rfc1912.zones"; Lo anterior define como opciones que el directorio predeterminado será /var/named (ruta relativa a /var/named/chroot, 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 , y /24; se definen como ejemplos de servidores DNS para reenviar consultas a , y , 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 , hacia , utilizando la firma digital única. Conviene asegurarse que el archivo /var/named/chroot/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 /var/named/chroot/etc/named.conf Ejemplo de Zona de reenvío red local IN SOA dns.red-local. alguien.gmail.com. ( ; número de serie
6 6 de 7 18/09/ :30 IN NS IN MX 10 IN TXT "v=spf1 a mx IN A intranet IN A maquina2 IN A maquina3 IN A maquina4 IN A www IN A mail IN A ftp IN CNAME intranet dns IN CNAME intranet Zona de resolución inversa red local IN SOA dns.red-local. alguien.gmail.com. ( ; número de 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/chroot/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 IN SOA fqdn.dominio.tld. alguien.gmail.com. ( ; número de IN NS IN MX 10 IN TXT "v=spf1 a mx IN A servidor IN A www IN A mail IN A ftp IN CNAME servidor dns IN CNAME servidor Zona de resolución inversa del dominio /var/named/chroot/var/named/data/ in-addr.arpa.zone Suponiendo que hipotéticamente se es la autoridad para el segmento de red /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 IN SOA fqdn.dominio.tld. alguien.gmail.com. ( ; número de 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 parámetros en el archivo /etc/named.conf options { directory "/var/named"; dump-file "/var/named/data/cache_dump.db";
7 7 de 7 18/09/ :30 a.m. statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; forwarders { ; ; forward first; dnssec-enable yes; dnssec-validation yes; dnssec-lookaside auto; bindkeys-file "/etc/named.iscdlv.key"; logging { channel default_debug { file "data/named.run"; severity dynamic; controls { inet allow { ; } keys { "rndc-key"; include "/etc/rndc.key"; view "local" { match-clients { /8; /8; /12; /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 " in-addr.arpa" { type master; file "data/ in-addr.arpa.zone"; allow-update { none; Continúa en Cómo configurar un servidor de nombres de dominio (DNS, parte II. Última Edición 30/08/2012, 12:17 198,334 Accesos Noticias Recientes Comentarios Recientes Enlaces Recientes Censura de términos en libr... SUSE lanza la primera soluc... Excelente oportunidad laboral SUSE realizará la primera c... Foxconn mejora las condicio... Red Hat presente en Sinergi... LiveCD de ServOS 1.3 liberada Linux ecológico en español > [+186] Excelente oportunidad lab... > [+9] [+4] [+2] [+2] * 3CXphone Dezoft.com Soluciones TI El Rincón de Tux Bitácora Personal de.::k... Gomezbjesus. Desarrollo,... Comunidad Salud Libre Comunidad de Software Libre Geeklog Hispano Derechos de autor 2012 Alcance Libre Todas las marcas y logotipos mencionados en este sitio de Internet son propiedad de sus respectivos dueños Joel Barrios Dueñas. Salvo que se indique lo contrario, todo el contenido está disponible bajo los términos de la licencia Creative Commons Reconocimiento 2.5. Visite nuestro Directorio de noticias y Delti.com.mx.
Cómo configurar un servidor de nombres de dominio (DNS), parte II.
1 de 9 18/09/2012 11:41 a.m. Ingresar Registrarse Enviar Nota Twitter Google+ Descargas Servicios Portada Foros Manuales Servicios Cursos Linux Buscar... 15 al 19 de octubre, Curso Global de Servidores
ADMINISTRACION DE SERVIDORES LINUX ENTERPRISE RESOLUCION DNS
ADMISTRACION DE SERVIDORES LUX ENTERPRISE SERVIDOR DE RESOLUCION DE NOMBRES DNS - BD Dictado por: Ing. Carlos Alcalá Helguero Consultas: alcalaucbcba.edu.bo TOPICOS CLASE 3: SERVIDOR DE RESOLUCION DE NOMBRES

References: resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 Resolución 
 resolución 
 resolución