Preparación para el examen LPI: Sistema de nombres de dominio (DNS)

Administración nivel intermedio (LPIC-2) tema 207

Este es el tercero de siete tutoriales que cubren la administración de red inmediata en Linux®. En este tutorial, David Mertz presenta DNS y habla de cómo utilizar Linux como servidor DNS, principalmente utilizando BIND 9. Muestra cómo preparar y configurar el servicio, cómo crear zonas de búsqueda hacia adelante e inversas, y cómo garantizar que el servidor sea seguro contra ataques.

David Mertz, Developer, Gnosis Software

David MertzDavid Mertz es Turing completo, pero probablemente no apruebe la Prueba de Turing. Para conocer más acerca de su vida, consulte su página Web personal. David escribe las columnas developerWorks Charming Python y XML Matters desde el año 2000. Consulte su libro Text Processing in Python [Procesamiento de texto en Python].



29-07-2011

Antes de comenzar

Aprenda lo que pueden enseñarle estos tutoriales y cómo aprovecharlos al máximo.

Acerca de esta serie

El Linux Professional Institute (LPI) certifica a los administradores de sistema Linux en dos niveles:nivel junior(también llamado “nivel de certificación 1") y nivel intermedio (también llamado “nivel de certificación 2”). Para obtener el nivel de certificación 1, debe aprobar los exámenes 101 y 102; para obtener el nivel de certificación 2, debe aprobar los exámenes 201 y 202.

developerWorks ofrece tutoriales para cada uno de los cuatro exámenes. Cada examen cubre varios temas, y cada tema tiene un tutorial de autoestudio correspondiente sobre developerWorks. Para el examen LPI 202, los siete temas y tutoriales developerWorks correspondientes son:

Tabla 1. Examen LPI 202: Tutoriales y temas
Tema del examen LPI 202Tutorial developerWorksResumen del tutorial
Tema 205Preparación para el examen LPI 202 (tema 205):
Configuración de redes
Aprenda cómo configurar una red TCP/IP básica, desde el nivel de hardware (por lo general Ethernet, modem, ISDN, o 802.11) a través del ruteo de direcciones de red.
Tema 206Preparación para el examen LPI 202 (tema 206):
Correo y noticias
Aprenda a utilizar Linux como servidor de correo y servidor de noticias. Aprenda sobre transporte de correo, filtro local de correo, software de mantenimiento de listas de correo y software de servidor para el protocolo NNTP.
Tema 207Preparación para el examen LPI 202 (tema 207):
DNS
(Este tutorial) Aprenda a utilizar Linux como servidor DNS, principalmente utilizando BIND. Aprenda a realizar una configuración BIND básica, administrar zonas DNS, y asegurar un servidor DNS. Ver los objetivos detallados a continuación.
Tema 208Preparación para el examen LPI 202 (tema 208):
servicios web
Próximamente
Tema 210Preparación para el examen LPI 202 (tema 210):
Gestión de cliente de redes
Próximamente
Tema 212Preparación para el examen LPI 202 (tema 212):
Seguridad de sistemas
Próximamente
Tema 214Preparación para el examen LPI 202 (tema 214):
Solución de problemas de red
Próximamente

Para comenzar a prepararse para el nivel de certificación 1, consulte los tutoriales de developerWorks para el examen LPI 101. Para prepararse para el otro examen en el nivel de certificación 2, consulte los tutoriales de developerWorks para el examen LPI 201. Lea más sobre todo el conjunto de tutoriales LPI de developerWorks.

El Linux Professional Institute no apoya ningún material o técnica de preparación para exámenes de terceros en particular. Para obtener detalles, contáctese a info@lpi.org.

Acerca de este tutorial

Bienvenido a "Domain Name System," el tercero de siete tutoriales que cubren la administración inmediata de redes sobre Linux. En este tutorial, obtendrá un buen panorama general de los fundamentos de DNS y aprenderá a usar Linux como servidor DNS. Aprenderá a preparar y configurar un servidor BIND, incluso a trabajar con named.conf y otros archivos de configuración; también aprenderá sobre zonas DNS hacia adelante e inversas, y lo básico sobre seguridad DNS, inclusive ejecutar BIND en una jaula chroot y las extensiones de seguridad de DNS.

Este tutorial Está organizado conforme a los objetivos LPI para este tema. En líneas generales, espere en el examen más preguntas para objetivos con mayor ponderación.

Tabla 2. Sistema de nombres de dominio: Objetivos de examen incluidos en este tutorial
Objetivo del examen LPIPonderación del objetivoResumen del objetivo
2.207.1
Configuración básica de BIND 8
Ponderación 2Configure BIND para que funcione como un servidor DNS de almacenamiento en cache únicamente. Este objetivo incluye la capacidad de convertir un archivo named.boot BIND 4.9 al formato BIND 8.x named.conf, y recargar el DNS utilizando kill o ndc. Este objetivo incluye también inicio de sesión y opciones como ubicación directoryh para archivos de zona.
2.207.2
Crear y mantener zonas DNS
Ponderación 3Cree un archivo de zona hacia adelante o zona inversa o un servidor a nivel raíz. Este objetivo incluye configurar valores adecuados para el registro de recurso SOA, los registros NS y los registros MX. También se incluye el agregado de hosts con registros de recursos A y registros CNAME según corresponda, agregar hosts a zonas reverse con registros PTR, y agregar la zona al archivo /etc/named.conf utilizando la instrucción zone con los valores tipo, archivo y maestros adecuados. También debe poder delegar una zona a otro servidor DNS.
2.207.3
Cómo asegurar un servidor DNS
Ponderación 3Configure BIND para ejecutarse como usuario no raíz, y configure BIND para ejecutarse en una jaula chroot. Este objetivo incluye configurar instrucciones DNSSEC como por ejemplo clave y claves de confianza para evitar la falsificación de dominios. También se incluye la capacidad de configurar una configuración DNS dividida utilizando la instrucción forwarders, y especificar una cadena de número de versión no estándar en respuesta a consultas.

Requisitos previos

Para aprovechar al máximo este tutorial, ya debe contar con un conocimiento básico de Linux y un sistema Linux en funcionamiento en el cual pueda practicar los comandos que se cubren en este tutorial.


Acerca de DNS

El sistema de nombres de dominio permite a los usuarios de aplicaciones TCP/IP referirse a los servidores por nombre simbólico en vez de por dirección IP numérica. El software Berkeley Internet Name Domain (BIND) provee un daemon de servidor llamado named que responde pedidos de información sobre la dirección IP asignada a un nombre simbólico (un una búsqueda inversa u otra información). Del lado del cliente del sistema DNS, un resolutor es un conjunto de bibliotecas que pueden utilizar las aplicaciones para comunicarse con los servidores DNS. El paquete BIND viene con varias utilidades para el cliente que ayudan a configurar, consultar y depurar un servidor BIND 9: dig, nslookup, host, y rndc(anteriormente ndc). En esencia, estas utilidades llaman a las mismas bibliotecas que otras aplicaciones de clientes, pero dan información directa sobre las respuestas proporcionadas por los servidores DNS.

Acerca de BIND

Al momento de esta redacción, la versión actual de BIND es 9.3.1. La primera versión estable de la serie BIND 9 salió en octubre de 2000. Puede encontrar BIND 8, que aún se mantiene por los parches de seguridad (actualmente de la versión 8.4.6), en algunas instalaciones más antiguas, pero como norma, actualice a BIND 9 donde sea posible. Los sistemas muy antiguos podrían tener instalado BIND 4, pero debe actualizarlos lo antes posible ya que BIND 4 ya no se soporta en las versiones actuales.

Todas las versiones de BIND se pueden obtener del Consorcio de Sistemas de Internet (ISC; ver Recursos para obtener un enlace). La documentación y otros recursos sobre BIND también están en ese sitio.

Debido a que los objetivos LPI requieren específicamente conocimientos de la configuración de BIND 8, y aquí cubrimos BIND 9, la recomendamos que revise la información de BIND 8 en el sitio USC antes de dar el examen LPI 202.

Otros recursos

Al igual que con la mayoría de las herramientas de Linux, siempre es útil examinar las páginas del manual para ver toda utilidad tratada. Las versiones y los conmutadores pueden cambiar entre la utilidad o la versión del kernel o con las distintas distribuciones de Linux. Para obtener información más detallada, el Proyecto de documentación Linux (ver Recursos para obtener un enlace) tiene una cantidad de instructivos útiles. Se han publicado una variedad de buenos libros sobre redes Linux, en particular TCP/IP Network Administration de O'Reilly es bastante útil (fíjese qué edición es la más actual cuando lea esto; ver Recursos para obtener un enlace).

Para obtener específicamente información sobre DNS y BIND, DNS and BIND, Fourth Edition de O’Reilly es un buen recurso (ver Recursos para obtener un enlace); en 622 páginas cubre más detalles de los que puede abarcar este tutorial. También hay otros libros sobre BIND de diversos editores.


Cómo comprender las consultas del sistema de nombres de dominio

La topología de DNS

DNS es un sistema jerárquico de zonas de dominio. Cada zona brinda un conjunto limitado de respuestas sobre mapeos de nombres de dominio, aquellos dentro de su propio subdominio. Cierto servidor consulta un servidor más general cuando no conoce un mapeo y, de ser necesario, sigue las sugerencias de redireccionamiento hasta que encuentra la respuesta correcta (o determina que no se puede encontrar una respuesta, lo que produce un error). Cuando un servidor local named encuentra la respuesta a una consulta DNS, almacena en caché esa respuesta durante una cantidad de tiempo configurable (generalmente en el orden de horas en vez de segundos o días). Al almacenar en caché las consultas DNS, la demanda general de red se reduce considerablemente, sobre todo en los servidores de dominio de nivel superior (TLD). El artículo sobre DNS que figura en Wikipedia (ver la sección Recursos para obtener un enlace) es un punto de partida excelente para comprender la arquitectura general. Este tutorial toma prestado un diagrama de dominio público de ese sitio (ver la Figura 1 a continuación).

Un diagrama de una consulta DNS hipotética facilita comprender el proceso de búsqueda general. Suponga que su máquina desea contactar el nombre simbólico de dominio www.wikipedia.org. Para encontrar la dirección IP correspondiente, su máquina consultaría primero el servidor de nombres que ha configurado para la máquina de un cliente. Este servidor de nombres local puede ejecutarse en la misma máquina que la aplicación del cliente; puede ejecutarse en un servidor DNS en su LAN local; o puede proporcionarlo su proveedor de servicios de Internet. En casi todos los casos, es una instancia del named del BIND. Este servidor de nombres local primero verifica su caché, pero suponiendo que no haya información almacenada en caché disponible, realizará los pasos que se muestran en el siguiente diagrama:

Figura 1. Ejemplo de recursividad de DNS
An example of DNS recursion

Comprenda que en este diagrama, el “DNS Recurser” es el servidor DNS real (named), no la aplicación del cliente que le habla.

DNS utiliza TCP y UDP en el puerto 53 para atender solicitudes. Casi todas las consultas DNS consisten en una solicitud UDP individual del cliente seguida de una respuesta UDP individual del servidor.

Cómo sabe una aplicación dónde encontrar un servidor DNS

Configurar el acceso de la aplicación de cliente a su servidor (o servidores) DNS es bastante sencillo. Toda la configuración está dentro del archivo /etc/resolve.conf, cuya tarea principal es especificar direcciones IP para uno o más servidores DNS "locales". Puede configurar /etc/resolve.conf manualmente con servidores DNS conocidos; sin embargo, si usa DHCP para configurar un cliente, el proceso de enlace agregará automáticamente esta información a /etc/resolve.conf (aún puede leerla o incluso modificarla después de que DHCP la configure, pero se restablecerá al reiniciar la máquina). El código de biblioteca modificado por /etc/resolv.conf se llama "solucionador DNS".

Si se configura más de un servidor DNS en un archivo /etc/resolv.conf, se consultarán servidores DNS secundarios y terciarios si el servidor primario no da respuesta dentro del tiempo de espera especificado. Se puede configurar un máximo de tres servidores DNS.

La entrada básica dentro de un archivo /etc/resolv.conf contiene las entradas nameserver <IP-addr>. Algunas otras entradas le permiten modificar las respuestas recibidas. Por ejemplo, las directivas domain y search le permiten expandir los nombres sin puntos en ellos (como por ejemplo máquinas de la LAN local). La directiva options le permite modificar tiempos de espera por servidor DNS, activar el depurador, decidir cuándo anexar nombres de dominio completos, y modificar otros aspectos del comportamiento del solucionador DNS. Por ejemplo, una de mis máquinas está configurada con:

Listado 1. Modificación de opciones para configurar servidores DNS
# cat
/etc/resolv.conf search gnosis.lan nameserver 0.0.0.0 nameserver 192.168.2.1
nameserver 151.203.0.84 options timeout:3

La primera directiva la permite a esta máquina saber que las máquinas de la LAN local usan el dominio privado gnosis.lan, así que el nombre simple bacchus se puede resolver como bacchus.gnosis.lan. Se puede listar más de un dominio separado por espacio en la directiva search.

A continuación, indico varios servidores DNS para probar. El primero es la máquina local misma, que se puede llamar 0.0.0.0 o por su dirección IP oficial, pero no con una dirección de bucle invertido. La siguiente directiva nameserver lista el router de la oficina hogareña que conecta mi LAN con Internet (y provee servicios DHCP y DNS). El servidor de nombres terciario lo proporciona mi proveedor de servicios de Internet. También configuro una opción para utilizar un tiempo de espera de tres segundos en cada servidor de nombres en lugar de los cinco segundos predeterminados.

Utilidades de cliente DNS

BIND 9 viene con cuatro utilidades de cliente principales. Tres de ellas: dig, nslookup y host -- realizan funciones similares, más o menos en orden de detalle descendente. Las tres utilidades son simplemente utilidades de línea de comandos para ejercitar el solucionador DNS. Básicamente hacen lo que muchas aplicaciones de cliente hacen internamente; estas utilidades tan sólo proveen datos de salida sobre los resultados de las búsquedas en STDOUT. La más poderosa de las tres utilidades, dig, también tuene la mayor cantidad de opciones para limitar o configurar su salida.

Estas utilidades se usan con mayor frecuencia para buscar una dirección IP de un nombre de dominio simbólico, pero puede realizar búsquedas inversas u otros tipos de registro que no sean registros “A” predeterminados. Por ejemplo, el comando host -t MX gnosis.cx le muestra servidores de correo asociados a gnosis.cx. Algunos ejemplos podrían ser de ayuda:

Listado 2. Consulta de host en google.com
$ host google.com google.com has
address 72.14.207.99 google.com has address 64.233.187.99
Listado 3. Consulta de host MX en gnosis.cx
$ host -t MX gnosis.cx gnosis.cx
mail is handled by 10 mail.gnosis.cx.

Para la utilidad:nslookup

Listado 4. nslookup usando servidor predeterminado (máquina local)
$ nslookup
gnosis.cx Server: 0.0.0.0 Address: 0.0.0.0#53 Non-authoritative answer: Name:
gnosis.cx Address: 64.41.64.172

O una búsqueda inversa usando la utilidad dig y especificando un servidor de nombres no predeterminado:

Listado 5. Indagar búsqueda inversa especificando un servidor de nombres no predeterminado
$ dig @192.168.2.2 -x 64.233.187.99 ;
<<>> DiG 9.2.4 <<>>
@192.168.2.2 -x 64.233.187.99 ;; global options: printcmd ;; Got answer: ;;
->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id:
3950 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;;
QUESTION SECTION: ;99.187.233.64.in-addr.arpa. IN PTR ;; AUTHORITY SECTION:
187.233.64.in-addr.arpa. 2613 IN SOA ns1.google.com. dns-admin.google.com.
2004041601 21600 3600 1038800 86400 ;; Query time: 1 msec ;; SERVER:
192.168.2.2#53(192.168.2.2) ;; WHEN: Thu Nov 10 02:00:27 2005 ;; MSG SIZE rcvd:
104

La utilidad BIND 9 restante para recordar es rndc. La utilidad rndc controla el funcionamiento de un servidor de nombres. Sustituye la utilidad ndc que se brindaba en versiones BIND anteriores. Si se invoca rndc sin opciones de línea de comando o argumentos, imprime un breve resumen de comandos soportados. Ver la manpage para rndc para obtener información completa sobre su uso.


Configuración BIND básica y ejecución de un name server

Configuraciones BIND

Cuando ejecuta el daemon con nombre para brindar un servidor DNS, puede elegir entre tres modos de operación: maestro, esclavo y almacenamiento en caché únicamente. El mismo daemon con nombre busca en sus archivos de configuración, principalmente /etc/bind/named.conf, para determinar su modo de operación.

En modo maestro, el servidor con nombre actúa como la fuente autoritativa de toda la información sobre su zona. La información de dominio proporcionada por el servidor se carga de un archivo de disco local que se modifica o actualiza en forma manual. Cada zona de DNS debería tener exactamente un servidor maestro.

En modo esclavo, el servidor con nombre trasfiere su información de zona desde el servidor maestro para su zona. Técnicamente, un servidor multi zona puede ser maestro de una zona y esclavo de otra, pero con mayor frecuencia una instalación Lan tiene una única jerarquía de servidores entre los servidores maestro y esclavo o de almacenamiento en caché únicamente. Un servidor esclavo transfiere información de zona completa desde su servidor maestro, para que las respuestas proporcionadas por un servidor esclavo se sigan considerando autoritativas.

En el modo almacenamiento en caché únicamente, el servidor con nombre no guarda archivos de zona. Cada consulta depende de otro servidor con nombre para obtener una respuesta inicial, pero para minimizar el uso de ancho de banda, el servidor de almacenamiento en caché únicamente almacena en caché consultas anteriores. Sin embargo, toda consulta nueva se debe responder mediante una consulta enviada por la red. Los servidores de almacenamiento en caché únicamente son más comunes en máquinas locales donde las aplicaciones de cliente a menudo pueden realizar una búsqueda sin tráfico de red.

En la configuración de /etc/resolv.conf que ofrecí como ejemplo antes en Listado 1, 0.0.0.0 es un servidor de almacenamiento en caché únicamente, 192.168.2.1 es un servidor esclavo, y 151.203.0.84 es un servidor maestro. No puede saber con seguridad solo basándose en el orden o en las direcciones IP utilizadas, pero el uso de la dirección pseudo IP 0.0.0.0 de la máquina local sugiere que está ejecutando un servidor de almacenamiento en caché únicamente.

Cómo configurar named.conf

Hay algunas funciones estándar que tienen casi todos los archivos /etc/bind/named.conf. Una directiva inicial options configura alguna información básica. Después, varias directivas zone brindan información sobre cómo manejar diversas solicitudes de zonza. Los dominios indicados en las directivas zone como direcciones IP representan porciones iniciales de rangos de dirección IP, pero si indican “hacia atrás”. Los nombres simbólicos también pueden definir zonas, permitiendo otros subdominios especificados.

Los archivos named.conf (y otros archivos de configuración BIND) siguen convenciones de formato tipo C, en gran parte. Los comentarios de bloque estilo C (/* comment */) y los comentarios de línea estilo C++ (// comment) se permiten, al igual que los comentarios de línea estilo shell (# comment). Las directivas son seguidas por instrucciones divididas por punto y coma entre llaves.

Para empezar, aquí hay algunas opciones comunes. Mi /etc/bind/named.conf local comienza con:

Listado 6. Mi named.conf local comienza así
ncluir
"/etc/bind/named.conf.options";

Pero también puede utilizar la directiva options directamente:

Listado 7. Configuración de opciones named.conf
options { directory
"/var/bind"; forwarders { 192.168.2.1; 192.168.3.1}; // forward only; }

Esta configuración permite a los archivos especificados sin ruta completa ser ubicados en un directorio relativo; también le dice al servidor con nombre local que busque primero en 192.168.2.1 y 192.168.3.1 resultados no almacenados en caché. La directiva forward only (comentada aquí) indica buscar sólo en esos servidores de nombres en la LAN local en lugar de consultar a los servidores raíz en Internet.

Una directiva especial zone está presente en casi todos los archivos named.conf:

Listado 8. Zona hint para servidores raíz
zone "." { type hint; file
"/etc/bind/db.root"; };

El contenido de db.root (a veces llamado named.ca por la "autoridad certificadora") es especial. Señala servidores raíz canónicos, los registradores de dominio mismos. Sus valores rara vez cambian, pero puede obtener la versión oficial más reciente en ftp.rs.internic.net. Este no es un archivo que modifica un administrador común.

Más allá de la pista zona raíz, un archivo named.conf debe contener algunas zonas maestro y/o esclavo. Por ejemplo, para el bucle invertido local:

Listado 9. Configuración de zona de bucle invertido
zone "127.in-addr.arpa" {
type master; file "/etc/bind/db.127"; };

Curiosamente, un servidor con nombre podría actuar como maestro para un dominio (y brindar búsqueda inversa):

Listado 10. Configuración de zona externa
zone "example.com" { type master;
file "example.com.hosts"; // file relative to /var/bind }; // Reverse lookup for
64.41.* IP addresses (backward IP address) zone "41.64.in-addr.arpa" { type
master; file "41.64.rev"; };

Para una configuración de esclavo, podría utilizar en cambio:

Listado 11. Configuración de zona externa (esclavo)
zone "example.com" { type
slave; file "example.com.hosts"; // file relative to /var/bind masters {
192.168.2.1; }; }; // Reverse lookup for 64.41.* IP addresses (backward IP
address) zone "41.64.in-addr.arpa" { type slave; file "41.64.rev"; masters {
192.168.2.1; }; };

Otros archivos de configuración

El archivo named.conf hace referencia a una cantidad de otros archivos de configuración con la directiva file. Estos nombres dependen de su configuración específica, pero en general contienen diversos registros de recursos que se definen en RFC 1033 (Guía de operaciones para administradores de dominios; ver Recursos para obtener un enlace). Los registros de recursos estándar son:

SOA
Inicio de autoridad. Parámetros que afectan a toda una zona.
NS
Servidor de nombres. El nombre del servidor de un dominio.
A
Dirección. Nombre de host a dirección IP.
PTR
Indicador. Dirección IP a nombre de host.
MX
Intercambio de correo. Dónde entregar correo para un dominio.
CNAME
Nombre canónico. Alias del nombre de host.
TXT
Texto. Almacena valores arbitrarios.

El formato de un registro es: <name><time-to-live>IN <type> <data>.

El nombre y el tiempo de vida son opcionales y predeterminados conforme a los últimos valore sutilizados. La cadena literal IN significa que siempre se utiliza Internet en la práctica. Los archivos de registro de recursos también pueden contener directivas, que comienzan con un signo de dólar. El más común quizás sea $TTL, que fija un tiempo de vida predeterminado. Por ejemplo, un archivo de registro algo trivial para el localhost 127.* se ve así:

Listado 12. Archivo de registro trivial
# cat /etc/bind/db.127 ; BIND reverse
data file for local loopback interface ; $TTL 604800 @ IN SOA localhost.
root.localhost. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire
604800 ) ; Negative Cache TTL ; @ IN NS localhost. 1.0.0 IN PTR
localhost.

Otras directivas son: $ORIGIN, que fija el nombre de dominio utilizado para completar todo nombre de dominio relativo; $INCLUDE, que lee un archivo externo; y $GENERATE, que crea una serie de registros de recursos que cubren una gama de direcciones IP.


Crear y mantener zonas DNS

Archivos de zona inversa

Los archivos de zona inversa (a menudo indicados con una extensión .rev) contienen mapeos de direcciones IP de zonas específicas a nombres simbólicos. Por ejemplo, podría tener un archivo /var/bind/41.64.rev que contiene:

Listado 13. Reverse zone file for 64.41.*
$TTL 86400 ; IP address to hostname @ IN SOA
example.com. mail.example.com. ( 2001061401 ; Serial 21600 ; Refresh 1800 ;
Retry 604800 ; Expire 900 ) ; Negative cach TTL IN NS ns1.example.com. IN NS
ns2.example.com. ; Define names for 64.41.2.1, 64.41.2.2, etc. 1.2 IN PTR
foo.example.com. 2.2 IN PTR bar.example.com. 3.2 IN PTR baz.example.com.

Archivos de zona hacia adelante

Los archivos de zona hacia adelante (a menudo llamados domain.hosts) contienen los registros cruciales "A" para nombres simbólicos de mapeo a direcciones IP. Por ejemplo, podría tener una archivo /var/bind/example.com.hosts que contiene lo siguiente:

Listado 14. Reenviar archivo de zona para example.com
$TTL 86400 ; Hostname to
IP address @ IN SOA example.com. mail.example.com. ( 2001061401 ; Serial 21600 ;
Refresh 1800 ; Retry 604800 ; Expire 900 ) ; Negative cach TTL IN NS
ns1.example.com. IN NS ns2.example.com. localhost IN A 127.0.0.1 foo IN A
64.41.2.1 www IN CNAME foo.example.com bar IN A 64.41.2.2 bar IN A
64.41.2.3

Cómo asegurar un servidor DNS

Cómo asegurar un servidor DNS

Al igual que con muchos servicios, es buena idea ejecutar BIND en una jaula chroot. , Esto limita el accedo de BIND a otros archivos o recursos del sistema si existiera una vulnerabilidad o un error en BIND. Encuentre un tutorial más detallado sobre ejecutar BIND con chroot en el instructivo "Chroot-BIND HOWTO" (ver Recursos para obtener un enlace).

La utilidad general de este procedimiento es que no es bueno ejecutar BIND co usuario raíz, o incluso como un usuario común especial como “nadie". A menudo se crea el usuario "named" para ejecutar BIND. Los archivos utilizados por este usuario especial se colocan en un directorio local como /chroot/named/ y subdirectorios relativos apropiados.

BIND 9 brinda soporte mucho más limpio para chroot de lo que lo hacía BIND 8; una compilación limpia debería ser suficiente sin conmutadores especiales o ajustes Makefile.

DNSSEC

Además de asegurar la máquina local que ejecuta BIND, también es deseable brindar garantías de seguridad para el protocolo DNS mismo. Las Extensiones de Seguridad DNS (DNSSEC) son un conjunto de extensiones que brindan autenticidad e integridad

DNS está basado en UPD en vez de TCP, y por ende no tiene un mecanismo para verificar una fuente paquete. Esta limitación hace posibles ataques de suplantación e intercepción. En otras palabras, los solicitantes de DNS pueden recibir información maliciosa, por ejemplo para redirigir comunicación al host de un intruso. Al agregar Firmas Transaccionales (TSIG) a solicitudes DNS, DNSSEC puede evitar la suplantación de respuestas DNS. Cada servidor BIND 9 que desea comunicarse en forma segura debe activar DNSSEC, pero el protocolo mejorado es compatible en forma inversa. Lo primero que deben hacer los servidores DNS (los que desean comunicarse de manera segura) es generar key pairs. Esto funciona de manera muy similar a las claves SSH para host y servidor. Por ejemplo:

Listado 15. Generación de claves DNSSEC
dnssec-keygen -r /dev/urandom -a
HMAC-MD5 -b 128 -n HOST \ primary-secondary.my.dom # ls
Kprimary-secondary.my.dom.* Kprimary-secondary.my.dom.+157+46713.key
Kprimary-secondary.my.dom.+157+46713.private

Como sugieren los nombres de archivo, esto general claves públicas y privadas para el host configurado, y la clave pública se distribuye a otros servidores. Obtenga una buena introducción a DNSSEC en "The Basics of DNSSEC" en la Red O'Reilly (ver Recursos para obtener un enlace).

Recursos

Aprender

Obtener los productos y tecnologías

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Linux
ArticleID=502373
ArticleTitle=Preparación para el examen LPI: Sistema de nombres de dominio (DNS)
publish-date=07292011