practica no6 instalacion de dns-dhcp dinamico en centos

Universidad Tecnológica de El Salvador Facultada de Informática y Ciencias Aplicada ETS2- SABADO 1630-1930

DNS-DHCP DINAMICO Página 1 de 22

Cátedra

REDES

Asignatura

ELECTIVA II

Docente

Lic. Otto R. Olivares S.

1. Práctica No. 6 Instalación de DNS-DHCP DINAMICO en CentOs 6.5

Introducción.

Es importante el poder configurar un servidor dns bajo una distro gnu/Linux.

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 utilizado de manera amplia en Internet (99% de los servidores DNS)

proporcionando una robusta y estable solución.

Propósito. Que el estudiante sea capaz de implementar una infraestructura de red , en este caso

implementar el componente de DNS.

Que el estudiante tenga la capacidad de configurar un dns interno y/o externo, bajo la

distro de gnu/linux CentOS 6.5

UTEC



Realización Esta guía se realizará en forma individual.

Entregable. Se deberá entregar un juego de DVD que contenga la información de esta práctica.

Requerimiento. Puede configurar una nueva máquina virtual de centos.

Fecha de Entrega. Sábado 14 de febrero en el horario de 16:30-19:30

Documentación adicional.

Indicación general

La mayoría de pasos realizados en esta guía son dentro de asistentes, por lo que se

omitido la expresión presionar siguiente por considerarse que se entiende.

Parte 1. Instalación y configuración de virtual box.

Esta práctica de laboratorio se puede realizar en computadores que funcionen bajo un

sistema operativo Windows XP,Vista, Windows Seven, Windows 8 que posean un

programa de virtualización como VirtulBox 4.1.x ó anteriores y un hardware como

mínimo de Intel Pentium IV 1.80 GHz, 2 GB de RAM, 80 GB H.D.

Configuración de la maquina virtual sugerida:

Asignación de Memoria: 512 mb. Asignarla en este rango de acuerdo a capacidad de equipo. , dependiendo de la capacidad de memoria física se recomienda configurarla maquina con 1024 mb de memoria.

Asignación de Disco Duro: 12 Gb, al momento de configurar el disco virtual debe seleccionar que la partición sea dinámica.

Tarjeta de red de la máquina virtual configurarla, en modo bridge (puente) si configura una ip determinada

Tarjeta de red de la máquina virtual configurarla, en modo NAT (si solo se comunicara con el sistema operativo anfitrión) y no con otras máquinas de la red.

Para efectos de actualización y de administración será necesaria configurar una segunda tarjeta o modo adaptador solo anfitrión.

PARTE 1. INTRODUCCION AL PROTOCOLO DNS

Conceptos.



Acerca del protocolo DNS (Domain Name System). DNS (acronimo de Domain Name System) es una base de datos distribuida y jerárquica, que almacena la información necesaria para los nombres de dominio. Sus usos principales son la asignación de nombres de dominio a direcciones IP y la localización de los servidores de correo electrónico correspondientes para cada dominio. El DNS nació de la necesidad de facilitar a los seres humanos el acceso hacia los servidores disponibles a través de Internet permitiendo hacerlo por un nombre, algo más fácil de recordar que una dirección IP. Los Servidores DNS utilizan TCP y UDP, en el puerto 53 para responder las consultas. Casi todas las consultas consisten de una sola solicitud UDP desde un Cliente DNS, seguida por una sola respuesta UDP del servidor. Se realiza una conexión TCP cuando el tamaño de los datos de la respuesta exceden los 512 bytes, tal como ocurre con tareas como transferencia de zonas.

¿Qué es un NIC (Network Information Center)? NIC (acrónimo de Network Information Center o Centro de Información sobre la Red) es una institución encargada de asignar los nombres de dominio en Internet ya sean nombres de dominio genéricos o por países, permitiendo personas o empresas, montar sitios de Internet a través de un ISP, mediante un DNS. Técnicamente existe un NIC por cada país en el mundo y cada uno de estos es responsable por todos los dominios con la terminación correspondiente a su pais. Por ejemplo: NIC México es la entidad encargada de gestionar todos los dominios con terminación .mx, la cual es la terminación correspondiente asignada a los dominios de México. ¿Qué es un FQDN (Fully Qualified Domain Name)? FQDN (acrónimo de Fully Qualified Domain Name o Nombre de Dominio Plenamente Calificado) es un Nombre de Dominio ambiguo que especifica la posición absoluta del nodo en el árbol jerárquico del DNS. Se distingue de un nombre regular porque lleva un punto al final.

Como ejemplo: suponiendo que se tiene un dispositivo cuyo nombre de anfitrión es ≪maquina1

≫ y un dominio llamado ≪dominio.com≫, el FQDN seria ≪maquina1.dominio.com.≫, asi es que se define de forma única al dispositivo mientras que pudieran existir muchos anfitriones

llamados ≪maquina1≫, solamente puede haber uno llamado ≪maquina1.dominio.com.≫. La

ausencia del punto al final definiría que se pudiera tratar solamente de un prefijo, es decir ≪

maquina1.dominio.com≫ pudiera ser un dominio de otro más largo como ≪

maquina1.dominio.com.mx≫. La longitud máxima de un FQDN es de 255 bytes, con una restricción adicional de 63 bytes para cada etiqueta dentro del nombre del dominio. Solamente se permiten los caracteres A-Z de ASCII,

dígitos y el carácter ≪-≫ (guion medio). Sin distinción de mayúsculas y minúsculas. Desde 2004, a solicitud de varios países de Europa, existe el estándar IDN (acrónimo de Internationalized Domain Name) que permite caracteres no-ASCII, codificando caracteres Unicode dentro de cadenas de bytes dentro del conjunto normal de caracteres de FQDN. Como resultado, los límites de longitud de los nombres de dominio IDN dependen directamente del contenido mismo del nombre

Componentes de DNS. DNS opera a través de tres componentes: Clientes DNS, Servidores DNS y Zonas de Autoridad.



Clientes DNS. Son programas que ejecuta un usuario y que generan peticiones de consulta para resolver nombres. Básicamente preguntan por la dirección IP que corresponde a un nombre determinado. Servidores DNS. Son servicios que contestan las consultas realizadas por los Clientes DNS. Hay dos tipos de servidores de nombres:

• Servidor Maestro: También denominado Primario. Obtiene los datos del dominio a partir de un archivo alojado en el mismo servidor.

• Servidor Esclavo: También denominado Secundario. Al iniciar obtiene los datos del dominio a través de un Servidor Maestro (o primario), realizando un proceso denominado transferencia de zona. Un gran número de problemas de operación de servidores DNS se atribuyen a las pobres opciones de servidores secundarios para las zonas de DNS. De acuerdo al RFC 2182, el DNS requiere que al menos tres servidores existan para todos los dominios delegados (o zonas). Una de las principales razones para tener al menos tres servidores para cada zona, es permitir que la información de la zona misma esté disponible siempre y de forma confiable, hacia los Clientes DNS, a través de Internet cuando un servidor DNS de dicha zona falle, este fuera de servicio y/o este inalcanzable. Contar con múltiples servidores también facilita la propagación de la zona y mejoran la eficiencia del sistema en general al brindar opciones a los Clientes DNS si acaso encontraran dificultades para realizar una consulta en un Servidor DNS. En otras palabras: tener múltiples servidores para una zona permite contar con redundancia y respaldo, del servicio. Con múltiples servidores, por lo general uno actúa como Servidor Maestro o Primario y los demás como Servidores Esclavos o Secundarios. Correctamente configurados y una vez creados los datos para una zona, es innecesario copiarlos a cada Servidor Esclavo o Secundario, pues este se encargara de transferir los datos de manera automática cada vez que sea necesario.4 Los Servidores DNS responden dos tipos de consultas: • Consultas Iterativas (no recursivas): El cliente hace una consulta al Servidor DNS y este le responde con la mejor respuesta que pueda darse basada sobre su cache o en las zonas locales. Si es imposible dar una respuesta, la consulta se reenvía hacia otro Servidor DNS repitiéndose este proceso hasta encontrar al Servidor DNS que tiene la Zona de Autoridad capaz de resolver la consulta. • Consultas Recursivas: El Servidor DNS asume toda la carga de proporcionar una respuesta completa para la consulta realizada por el Cliente DNS. El Servidor DNS desarrolla entonces Consultas Iterativas separadas hacia otros Servidores DNS (en lugar de hacerlo el Cliente DNS) para obtener la respuesta solicitada. Zonas de Autoridad.



Permiten al Servidor Maestro o Primario cargar la información de una zona. Cada Zona de Autoridad abarca al menos un dominio y, posiblemente, sus sub-dominios, si estos últimos son imposibles de delegar a otras zonas de autoridad. La información de cada Zona de Autoridad es almacenada de forma local en un archivo en el Servidor DNS. Este archivo puede incluir varios tipos de registros: Tipo de Registro. Descripción. A (Address) :Registro de dirección que resuelve un nombre de un anfitrión hacia una 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 obtienen 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, asi como la prioridad entre estos. PTR (Pointer): Registro de apuntador que resuelve direcciones IPv4 hacia los nombres 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, encargado de especificar el Servidor DNS Maestro (o Primario) que proporcionara 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): Registros de servicios, encargados de especificar informacion acerca de servicios disponibles a traves del dominio. Protocolos como SIP (Session Initiation Protocol) y XMPP (Extensible Messaging and Presence Protocol) suelen requerir registros SRV en la zona para proporcionar información a los clientes. TXT (Text): Registros de texto, encargados de permitir 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 sería el caso de las VPN, donde suele requerirse un registro TXT, para definir una firma digital que será utilizada por los clientes.

1. Equipamiento Lógico Necesario.

Instale los paquetes bind-utils y jwhois.

yum -y install bind-utils jwhois



2. Algunas herramientas ( deje constancia)

El mandato host es una herramienta simple para hacer consultas en Servidores DNS. Es utilizado para obtener las direcciones IP de los nombres de anfitrión y viceversa

Utilice el mandato host con las siguientes direcciones.

host www.utec.edu.sv

host www.google.com

host www.elsalvador.com

host www.lapagina.com.sv

host www.mh.gob.sv

host www.siman.com

3. Mandato dig. ( deje constancia del resultado de cada mandato ejecutado) El mandato dig (domain information groper) es una herramienta flexible para realizar consultas en Servidores DNS. Realiza búsquedas y muestra las respuestas que son regresadas por los servidores que fueron consultados. Debido a su flexibilidad y claridad en la salida, es que la mayoría de los administradores utilizan dig para diagnosticar problemas de DNS.

dig www.utec.edu.sv

dig www.google.com

dig www.elsalvador.com

dig www.lapagina.com.sv

dig www.mh.gob.sv

dig www.siman.com

4. Iptables. ( esto por si es necesario la configuración de iptables)

Servicio iptables. Puede utilizar directamente el mandato iptables, ejecutando lo siguiente: iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 53 -j ACCEPT iptables -A INPUT -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT service iptables save O bien edite el archivo /etc/sysconfig/iptables: vim /etc/sysconfig/iptables Y agregue el siguiente contenido: -A INPUT -m state --state NEW -m tcp -p tcp --dport 53 -j ACCEPT -A INPUT -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT

http://www.utec.edu.sv/

http://www.google.com/

http://www.elsalvador.com/

http://www.lapagina.com.sv/

http://www.mh.gob.sv/

http://www.siman.com/

http://www.utec.edu.sv/

http://www.google.com/

http://www.elsalvador.com/

http://www.lapagina.com.sv/

http://www.mh.gob.sv/

http://www.siman.com/



Para aplicar los cambios, reinicie el servicio iptables: service iptables restart

PARTE 2. Configuración de servidor de nombres de dominio (DNS).

1. 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.

caching-

nameserver

Archivos de configuración que harán que el Servidor DNS actué como un cache 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. Si se utiliza CentOS 6 o Red Hat™ Enterprise Linux 6, se puede instalar Bind 9.8 utilizando lo

siguiente:

yum -y install bind bind-chroot bind-utils

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, solo lectura para grupo y nada para otros, es decir un permiso 640 (rw-r-----): chmod 640 /etc/rndc.key 3. Actualice 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 lo siguiente:

wget -N http://www.internic.net/domain/named.root -O /var/named/named.ca

Asigne permiso de lectura y escritura para usuario, solo lectura para grupo y nada para otros (rw-r-----).

chmod 640 /var/named/named.ca

El archivo debe pertenecer a root y el grupo named.

chown root:named /var/named/named.ca

También puede ejecutar lo siguiente para lograr el mismo fin. dig +bufsize=1200 +norec NS . @a.root-servers.net > /var/named/named.ca

4. SELinux y el servicio named.

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 dinamico, utilice el siguiente mandato:

setsebool -P named_write_master_zones 1

5. Cualquier archivo de zona que se vaya a utilizar a traves 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).

Las siguientes líneas de condigo son necesarias si el archivo mi-dominio.zone fue

creado fuera del directorio/var/named/data/ y fue movido hacia este último.

http://www.internic.net/domain/named.root%20-O%20/var/named/named.ca



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 este:

cd /var/named/data/ chcon -u system_u -r object_r -t named_zone_t mi-dominio.zone

6. Preparativos.

Idealmente se deben definir primero los siguiente datos:

1. Dominio a resolver. 2. Servidor de nombres principal (SOA). Éste debe ser un nombre que ya esté plenamente

resuelto, y debe ser un FQDN (Fully Qualified Domain Name). 3. 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).

4. 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.

5. Al menos un servidor de correo (MX), con un registro A, nunca CNAME. 6. IP predeterminada del dominio. 7. Sub-dominios dentro del dominio (www, mail, ftp, ns, etc.) y las direcciones IP que estarán

asociadas a estos. 8. Para nuestras implementación.

item Descripcion Ip a ocupar

1 RANGO DE RED 192.168.6.0/24

2. SERVIDOR DNS 192.168.6.2

3. GATEWAY 192.168.6.2

4. SERVIDOR DE CORREO 192.168.6.2

5. RANGO DE IP PARA CONFIGURACION DE CLIENTES WINDOWS

192.168.6.50-253

6. Nombre del dominio ets2.edu.sv

7. Zona a configurar Ets2.edu.sv

8. Configurar dns con la opción de servidor interno Esto lo puede hacer a través de webmin en la opción de servidores.

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 estos 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 estos o bien modificar éstos en el caso de tratarse de zonas esclavas.

7. Configuración mínima para el archivo /etc/named.conf

Edite el archivo /etc/named.conf. vim /etc/named.conf , o con nano /etc/named.conf, o gedit /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:

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 { 8.8.8.8; 8.8.4.4;

}; forward first; // Solo habilite lo siguiente si va a utilizar DNSSEC y si los servidores de // la seccion de forwarders tienen soporte para DNSSEC.

dnssec-enable no; dnssec-validation no;

// dnssec-lookaside auto; // bindkeys-file "/etc/named.iscdlv.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"; }; }; include "/etc/rndc.key"; view "local" {

match-clients { 127.0.0.0/8; 10.0.0.0/8; 192.168.0.0/16;

}; recursion yes; include "/etc/named.rfc1912.zones"; zone "." IN {

type hint; file "named.ca";

}; }

8. Configuración mínima para el archivo /etc/named.conf

Edite el archivo /etc/named.conf. vim /etc/named.conf , o con nano /etc/named.conf, o gedit /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:

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 { 8.8.8.8; 8.8.4.4;

}; forward first; // Solo habilite lo siguiente si va a utilizar DNSSEC y si los servidores de // la seccion de forwarders tienen soporte para DNSSEC.


// dnssec-lookaside auto; // bindkeys-file "/etc/named.iscdlv.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"; }; }; include "/etc/rndc.key"; view "local" {

match-clients { 127.0.0.0/8; 10.0.0.0/8; 192.168.0.0/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, se define un archivo donde se almacena la información del cache en /var/named/data/cache_dump.db; un archivo de estadísticas en /var/named/data/named_stats.txt, un archivo de estadísticas especificas 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 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 127.0.0.1, hacia 127.0.0.1, utilizando la firma digital única. 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 integro 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. Digitar el siguiente mandato. chcon -u system_u -r object_r -t named_conf_t /etc/named.conf

9. Preparativos para añadir dominios. Idealmente se deben definir primero los siguientes datos: a. Dominio a resolver.

b. Servidor de nombres principal (SOA). Éste debe ser un nombre que ya esté plenamente

resuelto, y debe ser un FQDN (Fully Qualified Domain Name).

c. Lista de todos los servidores de nombres (NS) que se utilizaran para efectos de

redundancia.Éstos deben ser nombres que ya estén plenamente resueltos y deben ser

además FQDN (Fully Qualified Domain Name).

d. 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.

e. Al menos un servidor de correo (MX), con un registro A, nunca CNAME.

f. IP predeterminada del dominio.

g. Sub-dominios dentro del dominio (www, mail, ftp, ns, etc.) y las direcciones IP que

estarán asociadas a estos.

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 implementara el DNS deberá contar con un nombre FQDN y que este previa y plenamente, resuelto en otro DNS. Como regla general, se generara una zona de reenvió por cada dominio sobre el cual se tenga autoridad plena y absoluta y se generara 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 estos 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 estos o bien modificar estos en el caso de tratarse de zonas esclavas.

10. 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 reenvió 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 registró MX (Mail Exchanger o intercambiador de correo). Solamente necesitara sustituir nombres y direcciones IP y quizá añadir nuevos registros

para complementar su red local.

En este punto utilizar la herramienta de webmin para configurar las zonas respectivas.

Deberá realizar lo siguiente.

Crear Zona de reenvío red local

Crear Zona de resolución inversa red local

Crear Zona de reenvío del dominio

Zona de resolución inversa del dominio

Ejemplo: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"; forwarders {

8.8.8.8; 8.8.4.4;

}; forward first;

// Solo habilite lo siguiente si va a utilizar DNSSEC y si los servidores de // la seccion de forwarders tienen soporte para DNSSEC.


// dnssec-lookaside auto; // bindkeys-file "/etc/named.iscdlv.key"; }; include "/etc/rndc.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 }; 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; 192.168.0.0/16;

}; recursion yes; include "/etc/named.rfc1912.zones";

};

Lo anterior define como opciones que el directorio predeterminado sera /var/named, se define un archivo donde se almacena la información del cache en /var/named/data/cache_dump.db; un archivo de estadísticas en /var/named/data/named_stats.txt, un archivo de estadísticas especificas 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 sera 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

11. Seguridad adicional en DNS para uso público. Quienes hayan utilizado en recientes fechas los servicios de DNS Report, habrán notado que el diagnostico en línea devuelve ahora un error que, en resumen, indica que el servidor puede ser susceptible de sufrir/participar en un ataque DDoS (Distributed Denail of Service o denegación de servicio distribuido). Un DDoS (Distributed Denial of Service) es una ampliación del ataque DoS, se efectúa con la instalación de varios agentes remotos en muchas computadoras que pueden estar localizadas en diferentes puntos del mundo. El atacante consigue coordinar esos agentes para así, de forma masiva, amplificar el volumen de saturación de información (flood), pudiendo darse casos de un ataque de cientos o millares de computadoras dirigido a una maquina o red objetivo. Esta técnica se ha revelado como una de las mas eficaces y sencillas a la hora de colapsar servidores, la tecnología distribuida ha ido haciendo mas sofisticada hasta el punto de otorgar poder de causar danos serios a personas con escaso conocimiento técnico. La falla reportada por la herramienta en línea de DNS Report, para un servidor DNS que permite consultas recursivas, indicara algo como lo siguiente:



Significa que el servidor DNS puede permitir a cualquiera realizar consultas recursivas. Si se trata de un DNS que se desea pueda ser consultado por cualquiera, como puede ser el caso del DNS de un ISP, esto es normal y esperado. Si se trata de un servidor que solo debe consultar la red local o bien que se utiliza para propagar dominios alojados de manera local, si es conveniente tomar medidas al respecto. Solución al problema es modificar el archivo named.conf, donde se añade en la sección de vista local (view "local") la opción recursion yes; y una o más líneas que definan a la red o las redes que tendrán permitido realizar todo tipo de consultas.

El archivo named.conf deberá contener las siguientes lineas.

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 {192.168.0.1; };

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 127.0.0.1 allow { 127.0.0.1; } keys { "rndc-key"; };

};

include "/etc/rndc.key";

view "local" {

match-clients {

127.0.0.0/8;

10.0.0.0/8;

192.168.0.0/16;

};

recursion yes;

include "/etc/named.rfc1912.zones";

zone "." IN {

type hint;

file "named.ca";

};

};

Lo anterior hace que solo se puedan realizar consultas recursivas en el DNS desde 127.0.0.0/8, 10.0.0.0/8, 192.168.0.0/16, ya sea para un nombre de dominio alojado de manera local y otros dominios resueltos en otros servidores (ejemplo: www.yahoo.com, www.google.com, etc). El resto del mundo solo podrá realizar consultas sobre los dominios alojados de manera local y que estén configurado para permitirlo. 12. Seguridad adicional en DNS para uso exclusivo en red local.



Si se va a tratar de un servidor de nombres de dominio para uso exclusivo en red local y se quieren evitar problemas de seguridad de diferente índole, puede utilizarse el parametro allow-query, el cual servirá para especificar que solo ciertas direcciones podrán realizar consultas al servidor de nombres de dominio. Se pueden especificar directamente direcciones IP, redes completas o listas de control de acceso que deberán definirse antes de cualquier otra cosa en el archivo /etc/named.conf. 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";

forwarders {

8.8.8.8;

8.8.4.4;

};

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 127.0.0.1 allow { 127.0.0.1; } keys { "rndc-key"; };

};

include "/etc/rndc.key";

view "local" {

match-clients {

127.0.0.0/8;

10.0.0.0/8;

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; };

};

};



13. Reiniciar servicio y depuración de configuración. Al terminar de editar todos los archivos involucrados, solo bastara reiniciar el servidor de nombres de dominio. service named restart Si queremos que el servidor de nombres de dominio quede anadido entre los servicios en el arranque del sistema, deberemos realizar lo siguiente a fin de habilitar named junto con el arranque del sistema: chkconfig named on

Realice prueba de depuración y verifique que la zona haya cargado con número de serie: tail -80 /var/log/messages |grep named

deje constancia de estos pasos.

Parte 1 DHCP Introducción.

Acerca del protocolo DHCP. DHCP (acronimo de Dynamic Host Configuration Protocol, que se traduce Protocolo de configuración dinámica de servidores) es un protocolo que permite a dispositivos individuales en una red de direcciones IP obtener su propia información de configuración de red (dirección IP; mascara de sub-red, puerta de enlace, etc.) a partir de un servidor DHCP. Su propósito principal es hacer más fáciles de administrar las redes grandes. DHCP existe desde 1993 como protocolo estándar y se describe a detalle en el RFC 2131. Sin la ayuda de un servidor DHCP, tendrían que configurarse de forma manual cada dirección IP de cada anfitrión que pertenezca a una Red de Área Local. Si un anfitrión se traslada hacia otra ubicación donde existe otra Red de Área Local, se tendrá que configurar otra dirección IP diferente para poder unirse a esta nueva Red de Área Local. Un servidor DHCP entonces supervisa y distribuye, las direcciones IP de una Red de Área Local asignando una dirección IP a cada anfitrión que se una a la Red de Área Local. Cuando, por mencionar un ejemplo, una computadora portátil se configura para utilizar DHCP, a esta le será asignada una dirección IP y otros parámetros de red, necesarios para unirse a cada Red de Área Local donde se localice. Existen tres métodos de asignación en el protocolo DHCP:

• Asignación manual: La asignación utiliza una tabla con direcciones MAC (acrónimo de Media Access Control Address, que se traduce como dirección de Control de Acceso al Medio). Solo los anfitriones con una dirección MAC definida en dicha tabla recibirán el IP asignada en la misma tabla. Esto se hace a través del parámetro hardware ethernet combinado con deny unknown-clients. • Asignación automática: Una dirección de IP disponible dentro de un rango determinado se asigna permanentemente al anfitrión que la requiera. • Asignación dinámica: Se determina arbitrariamente un rango de direcciones IP y cada anfitrión conectado a la red está configurada para solicitar su dirección IP al servidor cuando se inicia el dispositivo de red, utilizando un intervalo de tiempo controlable



(parámetros default-lease-time y max-lease-time), de modo que la asignación de direcciones IP es de manera temporal y estas se reutilizan de forma dinámica. URL: http://www.ietf.org/rfc/rfc2131.txt y http://www.ietf.org/rfc/rfc2132.txt

PARTE 2. 1. Equipamiento Lógico.

CentOS, Fedora™ y Red Hat™ Enterprise Linux. Ejecute lo siguiente para instalar o actualizar todo necesario: yum -y install dhcp

2. Modificaciones necesarias en el muro cortafuegos. Por lo general, jamás se abren puertos de DHCP a las redes públicas. Es necesario abrir los puerto 67 y 68

(BOOTPS y BOOTPC) por UDP, tanto para trafico entrante como saliente.

3. Servicio iptables. Asumiendo que el servicio funcionara a través de la interfaz eth1, puede utilizar el mandato iptables del siguiente modo:

iptables -A INPUT -i eth1 -p udp -m state --state NEW -m udp --sport 67:68 --dport 67:68 -j ACCEPT luego digite los mandatos:

service iptables save service iptables restart

4. Iniciar, detener y reiniciar, el servicio dhcpd. Para hacer que el servicio de dhcpd este activo con el siguiente inicio del sistema, en todos los niveles de ejecución (2, 3, 4 y 5), ejecute lo siguiente:

chkconfig dhcpd on Para iniciar por primera vez el servicio dhcpd, ejecute:

service dhcpd start Para hacer que los cambios hechos a la configuración del servicio dhcpd surtan efecto, ejecute:

service dhcpd restart Para detener el servicio dhcpd, ejecute: service dhcpd stop

5. PROCEDIMIENTOS.

5.1. Archivo de configuración /etc/sysconfig/dhcpd. En el caso de disponer múltiples dispositivos de red en el servidor, se recomienda que el servicio dhcpd solamente funcione a través de la interfaz de red utilizada por la LAN. Edite el archivo /etc/sysconfig/dhcpd y agregue el valor eth0, eth1, eth2, etc., como argumento(s) del parámetro DHCPDARGS o bien lo que corresponda a la interfaz desde la cual accede la red local.

http://www.ietf.org/rfc/rfc2132.txt



Edite el archivo /etc/sysconfig/dhcpd: PARA NUESTRO CASO UTILIZAREMOS LA eth1 nano /etc/sysconfig/dhcpd

Para el siguiente ejemplo, considerando que eth1 es la interfaz correspondiente a la LAN: # Command line options here

DHCPDARGS=eth1

5.2 Archivo de configuración dhcpd.conf

La Dirección IP del segmento de red: 192.168.6.0 /24

Dirección IP de difusión: 192.168.6.2

Rango de direcciones IP a asignar de modo dinámico: 192.168.6.50 hasta 192.168.6.253

5.3 Configuración Básica

cd /etc/dhcp/

digite el mandato

mv dhcpd.conf dhcpd.conf.original

Descargue el archivo dhcp.conf que se le ha enviado al correo electrónico, este archivo

tiene que ser copiado a la dirección /etc/dhcp/ Y realice las modificaciones necesarias con

el segmento de red indicado en el punto 5.2, digite el mandato.

nano dhcpd.conf

deberá sustituir la red 192.16.1.1 por los datos que se indican el punto 5.2 y en la primera

guía en punto 8 # Si se tienen problemas con equipos con Windows Vista/7/8 omita el parametro

# server-identifier. Esto aunque rompe con el protocolo DHCP, permite a los

# clientes Windows Vista/7/8 poder comunicarse con el servidor DHCP y aceptar

# la direccion IP proporcionada.

# server-identifier 172.16.1.1;

ddns-update-style interim;

ignore client-updates;

authoritative;

default-lease-time 900;

max-lease-time 7200;

option ip-forwarding off;

option domain-name "red-local.net";

option ntp-servers 0.pool.ntp.org, 1.pool.ntp.org, 2.pool.ntp.org, 3.pool.ntp.org;

shared-network redlocal {

subnet 172.16.1.0 netmask 255.255.255.240 {

option routers 172.16.1.1;

option subnet-mask 255.255.255.240;

option broadcast-address 172.16.1.15;

option domain-name-servers 172.16.1.1;

option netbios-name-servers 172.16.1.1;

range 172.16.1.2 172.16.1.14;

}

}

Lo anterior corresponde a la configuración básica recomendada para un servidor DHCP básico. Una vez terminada la configuración, para iniciar el servicio ejecute:



service dhcpd start

5.4 Aspectos a considerar si se tienen ip estáticas ( esto es para efectos de conocimiento si usted desea lo implementa. Para definir equipos con direcciones IP estáticas, pueden añadirse también en la configuración de la siguiente forma, especificando el nombre de anfitrión, dirección MAC y dirección IP: Ejemplo si desea asignar una ip statica a un servidor como se muestra en este ejemplo.

host impresora { option host-name "epl5900.red-local.net"; hardware ethernet 00:24:2B:65:54:84; fixed-address 192.168.6.45; }

Debera editar el archivo /etc/dhcp/dhcpd.conf o bien /etc/dhcpd.conf, segun corresponda. Con los comandos que mejor maneje vi, nano, gedit.

Un ejemplo de la configuración quedaría del siguiente modo: # Si se tienen problemas con equipos con Windows Vista/7/8 omita el parametro # server-identifier. Esto aunque rompe con el protocolo DHCP, permite a los # clientes Windows Vista/7/8 poder comunicarse con el servidor DHCP y aceptar # la direccion IP proporcionada. # server-identifier 172.16.1.1;

ddns-update-style interim; ignore client-updates; authoritative; default-lease-time 900; max-lease-time 7200; option ip-forwarding off; option domain-name "red-local.net"; option ntp-servers 0.pool.ntp.org, 1.pool.ntp.org, 2.pool.ntp.org, 3.pool.ntp.org; shared-network redlocal {

subnet 172.16.1.0 netmask 255.255.255.240 ( aquí tiene que ir la ip de la red que estamos utilizando 192.168.6.0) option routers 172.16.1.1; option subnet-mask 255.255.255.240; option broadcast-address 172.16.1.15; option domain-name-servers 172.16.1.1; option netbios-name-servers 172.16.1.1; range 172.16.1.2 172.16.1.12;

} # Equipos con IP fija. host impresora { option host-name "epl5900.red-local.net"; hardware ethernet 00:24:2B:65:54:84; fixed-address 172.16.1.13;



} host pc14 { option host-name "pc14.red-local.net"; hardware ethernet 00:50:BF:27:1C:1C; fixed-address 172.16.1.14; }

} Si realizo cambios en la configuración, reinicie el servicio dhcpd a fin de que surtan efecto los cambios.

service dhcpd restart

practica no6 instalacion de dns-dhcp dinamico en centos

Documents