Definicin de DNS

BIND (Berkeley Internet Name Domain), como implementacin del protocolo DNS, es el servidor de este tipo ms comnmente usado en internet. La necesidad administrativa de montar un servidor de nombres DNS hacen de BIND una de las primeras opciones a tener en cuenta y desde este artculo se explotar la instalacin y configuracin del mismo.

Un poco de historia BIND es uno de los primeros servidores DNS creados al albor de internet. Encargado y patrocinado por la DARPA (Defense Advanced Research Projects Agency) a principios de los aos ochenta, cuando el Departamento de Defensa estadounidense estaba implicado en el desarrollo de la red de redes, el proyecto queda finalmente en manos de DEC/Digital (Digital Equipment Corporation), que se encarga de desarrollarlo casi por completo. Finalmente es uno de los empleados de Digital, Paul Vixie, quien retomar el proyecto y lo incluir en el consorcio ISC (Internet Software Consortium), responsable actual del mantenimiento del programa. Si bien las primeras implementaciones del servidor BIND (en concreto las versiones 4 y 8) mostraban una cantidad de vulnerabilidades exagerada (como casi todo el software nacido a la par que internet), la versin 9 del producto ya no presenta tantas complicaciones. Escrita desde cero para superar las dificultades tcnicas de antiguos desarrollos, dicha versin fue impulsada por proveedores UNIX, deseosos de que BIND mantuviera la competencia con Microsoft en igualdad de condiciones y por el Ejrcito de los Estados Unidos, que desarroll funcionalidades relativas a la seguridad como DNSSEC ( DNS Security Extensions), al darse cuenta de que la seguridad dentro del servicio DNS es algo a tener muy en cuenta.

Caractersticas BIND 9 ofrece un servidor de nombres de dominio a travs de named, una biblioteca de resolucin de sistemas de nombres de dominio y un paquete de herramientas para monitorizar el correcto funcionamiento de todo el sistema (bind-utils). Entre sus principales caractersticas se incluyen los protocolos de seguridad como DNSSEC o TSIG (Transaction SIGnature) y el soporte de IPv6, nsupdate (actualizaciones dinmicas), notificacin DNS, rndc flush, vistas y procesamiento en paralelo. Gracias a su arquitectura mejorada se ha conseguido una mejor portabilidad entre sistemas.

Introduccin a DNS DNS (Domain Name System) es una base de datos distribuida y jerrquica que almacena informacin relativa a los nombres de dominio en internet o gestiona nombres de equipos y servicios en redes locales. El uso ms comn de una base de datos DNS es la de asignacin de nombres de dominio o de servidores de correo a direcciones IP. Dicha asignacin se utilizar para la localizacin de dichos equipos/servicios de una manera sencilla y sin tener que recordar cada vez la direccin real. La informacin dada se puede consultar a la inversa (una direccin IP se traduce en un nombre almacenado en la base de datos). Los componentes principales de un sistema DNS son los siguientes:

Clientes DNS - Encargados de realizar las consultas pertinentes a las bases de datos de los servidores DNS. Servidores DNS - Contestan a las peticiones realizadas por los clientes. Dicha contestacin se har consultando la base de datos propia o haciendo una consulta recursiva a otro servidor DNS. Zonas de autoridad - Son los espacios de nombres de dominio donde se almacenan los datos. Generalmente, una zona de autoridad comprende, al menos, un nombre de dominio y todos sus subdominios, pudiendo estos ltimos estar en sus zonas de autoridad propias.

Servidores DNS

Dentro de este apartado, contamos con dos tipos de servidores:

Servidor Maestro/Primario - Consulta los datos del dominio en la base de datos del propio servidor donde se aloja. Servidor Esclavo/Secundario - Consulta los datos de una cach que rellena a partir de los datos de un servidor Primario. Dicho proceso se denomina Trasferencia de zona.

Es muy recomendable tener, al menos, tres servidores DNS configurados ( RFC 2182) para un correcto funcionamiento del sistema de resolucin. Un servidor actuara como nodo DNS Primario y los otros dos como nodos secundarios, que replicaran y respaldaran la base de datos principal. Obviamente, en un entorno local que no necesita servir datos fuera de la red (internet) no es tan necesario. Como hemos apuntado anteriormente, un servidor DNS puede hacer dos tipos de consultas:

Cmo funcionan las consultas recursivas Una consulta recursiva es aqulla realizada a un servidor DNS, en la que el cliente DNS solicita al servidor DNS que proporcione una respuesta completa a la consulta El servidor DNS comprueba la zona de bsqueda directa y la cach para encontrar una respuesta a la consulta. Cmo funcionan las consultas iterativas Una consulta iterativa es aqulla efectuada a un servidor DNS en la que el cliente DNS solicita la mejor respuesta que el servidor DNS puede proporcionar sin buscar ayuda adicional de otros servidores DNS. El resultado de una consulta iterativa suele ser una referencia a otro servidor DNS de nivel inferior en el rbol DNS Consulta iterativa Sugerencias Raiz(.)

Zonas de Autoridad Un servidor DNS Primario carga su informacin desde una Zona de Autoridad. Dicha zona abarca un nombre de dominio y, si los nombres de los subdominios no estn delegados, tambin los incluir. Toda la informacin se almacenar localmente en un fichero que contendr alguno de estos tipos de registros: A (Address) - Registro de direccin que resuelve un nombre de un anfitrin hacia una direccin IPv4 de 32 bits. AAAA - Registro de direccin que resuelve un nombre de un anfitrin hacia una direccin IPv6 de 128 bits. CNAME (Canonical Name) - Registro de nombre cannico que hace que un nombre sea alias de otro. Los dominios con alias obtiene 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, as como la prioridad entre stos. PTR (Pointer) - Registro de apuntador que resuelve direcciones IPv4 hacia el nombre anfitriones. Es decir, hace lo contrario al registro A. Se utiliza en zonas de Resolucin 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 que especifica el Servidor DNS Maestro (o Primario) que proporcionar la informacin con autoridad acerca de un dominio de Internet, direccin de correo electrnico del administrador, nmero de serie del dominio y parmetros de tiempo para la zona. SRV (Service) - Registro de servicios que especifica informacin acerca de servicios disponibles a travs del dominio. Protocolos como SIP (Session Initiation Protocol) y XMPP (Extensible Messaging and Presence Protocol) suelen requerir registros SRV en la zona para proporcionar informacin a los clientes. TXT (Text) - Registro de texto que permite 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 filtracin de Spam. Otro ejemplo de uso son las VPN, donde suele requerirse un registro TXT para definir una llave que ser utilizada por los clientes.

Las zonas a resolver sern las siguientes:

Zonas de Reenvo - Devuelven direcciones IP para bsquedas sobre nombres FQDN (Fully Qualified Domain Name). Es importante apuntar aqu que, en el caso de tratarse de dominios pblicos, hay una responsabilidad por parte de la autoridad misma del dominio (el Registrar del WHOIS) para crear dicha zona de reenvo. Zonas de Resolucin Inversa - Devuelven nombres FQDN para bsquedas sobre direcciones IP. Como en el caso anterior, la responsabilidad de crear la Zona de Autoridad recae sobre la autoridad misma del segmento (si hacemos un WHOIS sobre una direccin IP, obtendremos a la autoridad de todo el segmento de direcciones).

La siguiente ilustracin muestra un uso bsico de DNS, consistente en la bsqueda de la direccin IP de un equipo basada en su nombre.

En este ejemplo, un equipo cliente consulta a un servidor DNS, preguntando la direccin IP de un equipo configurado para utilizar host-a.ejemplo.microsoft.comcomo nombre de dominio. Como el servidor puede utilizar la base de datos local para responder la consulta, contesta con una respuesta que contiene la informacin solicitada, un registro de recursos de host (A) que contiene la informacin de direccin IP para host-a.ejemplo.microsoft.com.

La lista que puede leerse de acciones dentro de la imagen es esta:

1. Navegador web pregunta: Quin es ejemplo.com? 2. El sistema conecta con el cliente DNS interno. 3. El cliente consulta en su cach si tiene la respuesta. 4. Si la respuesta no est en cach, el cliente preguntar a un servidor definido. 5. El servidor tambin consulta su propia cach. 6. Si no tiene la solucin en cach, consultar a los root servers cul es el servidor que resuelve ejemplo.com 7. Los root servers no resuelven el FQDN (Full Qualified Domain Name) sino solo registros NS segn zona (quin tiene la respuesta a la consulta). ftp://ftp.internic.net/domain/named.cache 8. Una vez nuestro servidor DNS sabe quin resuelve la peticin, solicita la resolucin. 9. El servidor DNS entrega la respuesta al cliente. 10. El sistema ya tiene respuesta. 11. El navegador ya puede ir a ejemplo.com

Ejemplo de archivo de zona

En un archivo de zona, hacen falta al menos tres registros bsicos: SOA, NS y A.
o

SOA: Proporciona informacin sobre la zona y las opciones de configuracin como cada cuanto expira y la ltima vez que se modific (si est bien definida)

NS: Un nombre de un servidor DNS en el que se aloja la zona.

A: Concretamente, deberemos especificar como poco la direccin del servidor DNS al que hemos nombrado en el registro NS.

A partir de ah, podemos aadir cualquier tipo de registro. Los registros siguen esta sintaxis:
name IN NS address

Con un nombre que apunta a una direccin a travs de un tipo de

registro DNS (en este caso NS). Un ejemplo de archivo perfectamente viable sera este:
$TTL @ 604800 IN SOA dns1 ejemplo.org. 2011012501 ; 604800 ; 86400 ; 2419200 ; 604800 ) ; dns1 dns2 mail mailbackup 192.168.1.254 192.168.1.254 192.168.1.122 192.168.1.254 192.168.1.200 ::1 CNAME www ( Serial Refresh Retry Expire Negative Cache TTL

; @ @ @ @

IN IN IN IN

NS NS MX 10 MX 40 A A A A A AAAA IN

www IN dns1 IN dns2 IN mail IN mailbackup IN ;@ IN intranet

Ah definimos que el dominio ejemplo.org con una semana de refresco, veintiocho das de expiracin, y los siguientes subdominios:
o

dns1.ejemplo.org - Servidor DNS (registros A y NS)

dns2.ejemplo.org - Servidor DNS (registros A y NS)

mail.ejemplo.org - Servidor de correo (registros A y MX con prioridad mxima - 10 -)

mailbackup.ejemplo.org - Servidor de backup de correo (registros A y MX con prioridad menor - 40 -)

www.ejemplo.org - Redireccin seguramente a un servicio web (registro A)

intranet.ejemplo.com - redirecciona directamente a www (registro CNAME)

Un registro IPv6 (AAAA) que redirecciona a la IPv4.

En este fichero, @ equivale al nombre del dominio tal y como se especifica en el archivo en que se crea la zona (/etc/named.conf o cualquier incluido). Si se modifican las zonas, habr que utilizar el comando rndc reload para recargar los archivos de base de datos.

Tipos de registros DNS

A; Address (Direccin) - Este registro se usa para traducir nombres de hosts a direcciones IPv4.

AAAA; Address (Direccin) - Este registro se usa para traducir nombres de hosts a direcciones IPv6.

CNAME; Canonical Name (Nombre Cannico) - Se usa para crear nombres de hosts adicionales, o alias, para los hosts de un dominio. Es usado cuando se estn corriendo mltiples servicios (como ftp y web server) en un servidor con una sola direccion ip. Cada servicio tiene su propia entrada de DNS (como ftp.ejemplo.com. y www.ejemplo.com.).

NS; Name Server (Servidor de Nombres) - Define la asociacin que existe entre un nombre de dominio y los servidores de nombres que almacenan la informacin de dicho dominio. Cada dominio se puede asociar a una cantidad cualquiera de servidores de nombres.

MX; Mail Exchange (Registro de Intercambio de Correo) Asocia un nombre de dominio a una lista de servidores de intercambio de correo para ese dominio.

PTR; Pointer (Indicador) - Tambin conocido como 'registro inverso', funciona a la inversa del registro A, traduciendo IPs en nombres de dominio.

SOA; Start of authority (Autoridad de la zona) - Proporciona informacin sobre la zona.

HINFO; Host INFOrmation (Informacin del sistema informtico) - Descripcin del host, permite que la gente conozca el tipo de mquina y sistema operativo al que corresponde un dominio.

TXT; TeXT ( Informacin textual) - Permite a los dominios identificarse de modos arbitrarios.

LOC; LOCalizacin - Permite indicar las coordenadas del dominio.

WKS; Generalizacin del registro MX para indicar los servicios que ofrece el dominio. Obsoleto en favor de SRV.

SRV; SeRVicios - Permite indicar los servicios que ofrece el dominio. RFC 2782

SPF; Sender Policy Framework - Ayuda a combatir el Spam. En este registro se especifica cual o cuales hosts estn autorizados a enviar correo desde el dominio dado. El servidor que recibe consulta el SPF para comparar la IP desde la cual le llega, con los datos de este registro.

SOA

Serial: es un identificador del archivo, puede tener un valor arbitrario pero se recomienda que tenga la fecha con una estructura AAAA-MM-DD y un consecutivo. El nmero de serie debe siempre crecer, y se debe incrementar toda vez que se modifica el archivo, para que otros servidores sepan que ha habido cambios

Refresco: nmero de segundos que un servidor de nombres secundario debe esperar para comprobar de nuevo los valores de un registro.

Reintentos: nmero de segundos que un servidor de nombres secundario debe esperar despus de un intento fallido de recuperacin de datos del servidor primario. Expiracin: nmero de segundos mximo que los servidores de nombre secundarios retendrn los valores antes de expirarlos.

TTL mnimo: Significa Time To Live y es el nmero de segundos que los registros se mantienen activos en los servidores NS cach antes de volver a preguntar su valor real.

Herramientas de consulta DNS Tenemos principalmente tres herramientas para consultar registros DNS relacionados con un nombre de dominio, como el servidor en el que se aloja la zona (registro NS), la redireccin DNS para correo electrnico (registro MX), o cualquier otro registro como los de definicin de servidor (registros A). Estas tres herramientas son host, dig y nslookup, si bien vamos a olvidarnos de esta ltima, pues es actualmente obsoleta. As pues, vamos a hacer consultas con dig y host...
Consultas con dig
[root@localhost ~]# dig google.com ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3 <<>> google.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25200 ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 4, ADDITIONAL: 0 ;; QUESTION SECTION: ;google.com. ;; ANSWER SECTION: google.com. google.com. google.com. google.com. google.com. google.com. ;; AUTHORITY SECTION: google.com. google.com. google.com. google.com. ;; ;; ;; ;; 48 48 48 48 48 48 169910 169910 169910 169910 IN IN IN IN IN IN IN IN IN IN IN A A A A A A A NS NS NS NS 209.85.146.147 209.85.146.99 209.85.146.103 209.85.146.104 209.85.146.105 209.85.146.106 ns2.google.com. ns3.google.com. ns4.google.com. ns1.google.com.

Query time: 174 msec SERVER: 127.0.0.1#53(127.0.0.1) WHEN: Fri Feb 11 19:09:58 2011 MSG SIZE rcvd: 196

Como vemos, dig nos escupe por pantalla toda la informacin de una zona DNS definida segn el nombre de dominio que hemos especificado. Con -t podemos especificar qu registros queremos ver, por ejemplo:

Registros NS:
[root@localhost ~]# dig -t ns google.com ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3 <<>> -t ns google.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49885 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;google.com. ;; ANSWER SECTION: google.com. google.com. google.com. google.com. ;; ;; ;; ;; 278549 278549 278549 278549 IN IN IN IN IN NS NS NS NS NS ns4.google.com. ns1.google.com. ns2.google.com. ns3.google.com.

Query time: 0 msec SERVER: 127.0.0.1#53(127.0.0.1) WHEN: Fri Feb 11 19:13:38 2011 MSG SIZE rcvd: 100

Registros MX
[root@localhost ~]# dig -t mx google.com ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3 <<>> -t mx google.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60649 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 0 ;; QUESTION SECTION: ;google.com. ;; ANSWER SECTION: google.com. 882 google.com.s9b2.psmtp.com. google.com. 882 google.com.s9a1.psmtp.com. google.com. 882 google.com.s9a2.psmtp.com. google.com. 882 google.com.s9b1.psmtp.com. ;; AUTHORITY SECTION: google.com. google.com. google.com. google.com. 278411 278411 278411 278411 IN IN IN IN IN MX MX MX MX MX 400 100 200 300

IN IN IN IN

NS NS NS NS

ns2.google.com. ns3.google.com. ns4.google.com. ns1.google.com.

;; Query time: 434 msec ;; SERVER: 127.0.0.1#53(127.0.0.1)

;; WHEN: Fri Feb 11 19:15:56 2011 ;; MSG SIZE rcvd: 234

Volver al indice

Consultas con host

host es una herramienta un poco ms til que dig, ya que los resultados son ms explcitos y tan completos como el usuario quiera, permitiendo ver mejor las diferencias entre zonas, incluso pudiendo copiar una zona con su texto plano mediante los registros AXFR (Las siglas AXFR hace referencia a la
transferencia por zonas de un DNS primario a un DNS secundario o de un DNS primario a un server maestro y de un server maestro a un DNS secundario, si llegara a existir algn problema de configuracin o actualizacin del software de cualquiera de estos servidores se podran explotar una serie de vulnerabilidades como por ejemplo un DoS y la integridad y confidencialidad de la base de datos del DNS primario se veran comprometidas, se estima que alrededor de un 60% de los servidores DNS en internetson vulnerables.)-

dig

tiene una presentacin muy parecida, pero sui generis -. Ejemplos usando host: Consultar servidores DNS de Google.com:
[root@localhost google.com name google.com name google.com name google.com name ~]# host -t ns google.com server ns1.google.com. server ns2.google.com. server ns3.google.com. server ns4.google.com.

Consultar servidores de correo:

[root@localhost google.com mail google.com mail google.com mail google.com mail ~]# host -t mx google.com is handled by 300 google.com.s9b1.psmtp.com. is handled by 400 google.com.s9b2.psmtp.com. is handled by 100 google.com.s9a1.psmtp.com. is handled by 200 google.com.s9a2.psmtp.com.

Consultar una zona completa de dominio para copiarla:

[root@localhost postfix]# host -t AXFR ejemplo.org localhost Trying "ejemplo.org" Using domain server: Name: localhost Address: 127.0.0.1#53 Aliases: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17947

;; flags: qr aa ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;ejemplo.org. IN AXFR SOA NS MX A CNAME A A A SOA dns1.ejemplo.org. dns1.ejemplo.org. 10 mail.ejemplo.org. 192.168.1.123 www.ejemplo.org. 192.168.1.123 192.168.1.123 192.168.1.123 dns1.ejemplo.org.

;; ANSWER SECTION: ejemplo.org. 604800 IN root.localhost. 2011012701 604800 86400 2419200 604800 ejemplo.org. 604800 IN ejemplo.org. 604800 IN ejemplo.org. 604800 IN *.ejemplo.org. 604800 IN dns1.ejemplo.org. 604800 IN mail.ejemplo.org. 604800 IN www.ejemplo.org. 604800 IN ejemplo.org. 604800 IN root.localhost. 2011012701 604800 86400 2419200 604800

Received 238 bytes from 127.0.0.1#53 in 3 ms

Archivo /etc/resolv.conf
Es necesario configurar correctamente el archivo /etc/resolv.conf para poder resolver los nombres de los servidores en Internet. Aqu se muestra un ejemplo de configuracin de este archivo:
domain jerocu.net nameserver 194.179.50.2 nameserver 194.179.1.100

domain: dominio de Internet al que pertenece la mquina nameserver: direccin IP del servidor de nombres a usar. Si no se conoce este dato, se debe preguntar al proveedor. Es posible usar ms de un servidor de nombres, siendo habitual usar dos, uno como primario y otro como secundario.

Escritura-protegida de resolv.conf
Otra manera de proteger el archivo resolv.conf de ser editado sin intencin del root-user, es aplicando el atributo de escritura-protegida: chattr +i /etc/resolv.conf Para eliminar la proteccin del archivo: chattr -i /etc/resolv.conf

Configuracin Antes de comenzar con los ficheros de configuracin del programa, es preciso tener claros los datos siguientes:

Nombre de dominio a resolver. Servidor de nombres principal (DNS Maestro/SOA). Dicho nombre tiene que estar plenamente resuelto y, por supuesto, tiene que ser FQDN. Lista de servidores de nombres (NS) para la redundancia. Igual que en el caso anterior, debern estar plenamente resueltos y ser FQDN. Cuenta de correo del administrador de la zona. Cuenta real y distinta de la zona a resolver. Servidor de correo (MX) con registro A (no vale un CNAME). IP predeterminada del dominio. Subdominios y direcciones IP asociadas a los mismos (www, mail, ftp, ...).

Ficheros de zonas Un fichero de zonas tiene, en principio, el siguiente aspecto: $TTL 43200 @ IN SOA server.mydomain.name. user.server.mydomain.name. ( 200583909; Nmero de serie 3600 ; Tiempo de refresco (1 hora) 300 ; Tiempo entre reintentos de consulta (5 min) 17200 ; Tiempo de expiracin de zona (2 days) 43200 ) ; Tiempo total de vida (TTL) (12 hours) ; @ IN NS server.mydomain.name. pc1 IN A xxx.xxx.xxx.xxx pc2 IN A yyy.yyy.yyy.yyy nombre1 IN CNAME pc1 nombre2 IN CNAME pc2

Los nombres de dominio terminan en un punto para indicar que son nombres absolutos. Los registros del fichero son los siguientes:

IN SOA - Informacin sobre el dominio:

sever.mydomain.name.: Servidor de nombres al cual pertenece la zona. user.server.mydomain.name.: Indica el usuario responsable a administrar el servidor DNS. Adems tambin hace referencia a su direccin de correo user@mydomain.name user@mydomain.name . N Serie: Es el nmero de serie correspondiente a la ltima actualizacin. Este campo es utilizado por los servidores DNS secundarios, los cuales solamente actualizarn los datos de su zona si su nmero de serie es menor que el del primario. Refresco: Tiempo en que el servidor secundario debe preguntar al primario si ha habido cambios. Reintentos: Periodo de tiempo que ha de esperar un servidor secundario antes de reintentar la conexin con el servidor primario, suponiendo que el ltimo intento haya fallado. Expiracin: Mximo tiempo que ofrece servicio el servidor secundario, en caso de no poder contactar con el primario. TTL: Tiempo mximo que se mantienen los datos del dominio en un servidor de cach antes de volver ha hacer una consulta al servidor autorizado.

IN NS - Relaciona un nombre de subdominio con un servidor de nombres responsable de la zona. Podremos formar as una jerarqua de nombres DNS. Hay que poner el correspondiente registro A para traducir el nombre del servidor a una direccin IP si se usa este registro. IN A - Traduccin de mquina a direccin IP.

IN PTR - Traduccin de direccin IP a mquina. IN CNAME - Alias de las mquinas.

Los distintos ficheros de zonas se encuentran, en una distribucin tipo Red-Hat / Fedora en la rama /var/named (o/var/named/chroot/var/named). A continuacin vamos a ver un fichero de zona para la configuracin tpica de un dominio: $TTL 86400 @ IN SOA dominio_ejemplo.org. postmaster.dominio_ejemplo.org. ( 42 ; serial 3H ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum @ IN NS ns1.dominio_ejemplo.org. @ IN NS ns2.dominio_ejemplo.org. @ IN MX 10 mx1.dominio_ejemplo.org. @ IN MX 20 mx2.dominio_ejemplo.org. @ IN TXT "dominio_ejemplo.org" @ IN HINFO "Intel Pentium IV" "Fedora Core" @ IN A 215.127.55.12 ns1 IN A 214.125.33.41 ns2 IN A 215.127.55.12 mx1 IN A 215.127.55.12 mx2 IN A 214.125.33.41 www IN A 215.127.55.12 www2 IN A 215.127.55.12 webmail IN A 215.127.55.12 smtp IN A 215.127.55.12 redirect IN CNAME dominio_ejemplo.no-ip.info smtp.tcp SRV 0 0 25 mx1.dominio_ejemplo.org. http.tcp SRV 0 3 80 dominio_ejemplo.org. http.tcp SRV 0 1 80 www2.dominio_ejemplo.org. https.tcp SRV 1 0 443 dominio_ejemplo.org. pop3s.tcp SRV 0 0 995 mx1.dominio_ejemplo.org. *.tcp SRV 0 0 0 . *.udp SRV 0 0 0 .

Se observa claramente cmo se han creado dos servidores de nombre con autoridad mediante la sentencia NS (con @ se evita tener que escribir el dominio completo de nuevo), ns1.dominio_ejemplo.org. y ns2.dominio_ejemplo.org. y se crean tambin dos redirectores de correo MX con prioridad de 10 y 20. Tras el espacio, comienza la traduccin de los nombres en direcciones IP. Si atendemos a la ltima lnea, podemos observar el uso claro de la sentencia CNAME. En este caso, el servidor DNS traducira la direccin redirect.dominio_ejemplo.org hacia la direccin apuntada en dominio_ejemplo.no-ip.info, lo cual puede resultar tremendamente til en caso de tener que hacer uso de alguna IP dinmica en alguno de los servidores. En ltimo lugar, nos encontramos con un listado de localizacin de servicios que hace uso de la sentencia SRV. Dicha sentencia permite la consulta de un dominio y un servicio asociado al mismo. La asociacin de servicios se define en el estndar RFC 2052. + Traduccin inversa Es requerido en un servidor DNS que las direcciones IP se conviertan igualmente en nombres (reverse lookup). Dicha traduccin se usar por parte de diferentes servidores y es muy aconsejable tener definida una zona de este tipo en un servidor DNS. Para la resolucin inversa usaremos el pseudo-dominio inaddr.arpa. quedando la direccin pblica55.127.215.in-addr.arpa. (la parte de red de la direccin IP escrita al revs ms el dominio). Un fichero de zona de resolucin inversa para el dominio anterior quedara como sigue:

$TTL 604800 @ IN SOA dominio_ejemplo.org. postmaster.dominio_ejemplo.org. ( 42 ; serial 3H ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum @ IN NS ns1.dominio_ejemplo.org. NS ns2.dominio_ejemplo.org. 12 IN PTR ns1.dominio_ejemplo.org.

Para la zona inversa de localhost podramos generar un fichero parecido al siguiente: $TTL 604800 @ IN SOA localhost. postmaster.dominio_ejemplo.org. ( 42 ; serial 3H ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum IN NS ns1.dominio_ejemplo.org. 1 IN PTR localhost.ns1.dominio_ejemplo.org.

Hay que tener en cuenta que la zona de resolucin inversa del dominio slo funcionar en el caso de que sta quede delegada convenientemente por el proveedor de servicios que se ocupa del rango de direcciones. Si es imprescindible, y el autor de este artculo considera que siempre debera serlo, tener una zona de resolucin inversa para nuestra direccin o rango de direcciones, ser imperativo contactar con el proveedor de servicios para que de de alta un registro NS para la zona en concreto. + El archivo named.conf El archivo named.conf se sita en la rama /etc o /etc/bind y estructura toda la informacin de zonas del servidor DNS. A grandes rasgos, podemos dividir el fichero en tres secciones: options, que define opciones de configuracin general, loggin, que especifica la salida de la informacin y zone, donde se incorporan los datos generales de los archivos de zonas que ya hemos explicado en los puntos anteriores.

options

Habitualmente, las opciones incluidas por defecto en los ficheros de configuracin de cada distribucin para el apartado options son ms que suficientes para arrancar el servidor DNS sin ningn tipo de problema. Dichas opciones son demasiado extensas para explicarlas en este artculo, as que es muy recomendable acceder a la pgina del manual referente a named.conf y leer para qu sirve cada opcin y si alguna de ellas puede servir a nuestros propsitos. Una opcin importante a tener en cuenta es la de forwarders, que se usar para suministrar al servidor DNS las direcciones IP de los redireccionadores encargados de consultar ciertas direcciones a otros servidores DNS, cuando stas no estn disponibles de forma local. De usarse el apartado, deber quedar como el ejemplo siguiente: forwarders { 200.33.146.209; 200.33.146.217; };

zone

Bajo la definicin de zone se darn de alta todas las zonas para nuestros dominios. Habr que definir siempre una primera zona raz (un punto), que informar de todos los servidores raz a nuestro servidor DNS, y seguidamente se darn de alta todas y cada una de las zonas necesarias para el funcionamiento correcto de nuestro servidor. La zona raz quedar como sigue (el fichero de zona puede conseguirse en la direccin ftp.internic.net/domain/named.cache): zone "." { type hint;

file "named.ca"; }; Un ejemplo de definicin de zona general podra ser el siguiente: zone "dominio_ejemplo.org" { type master; file "/var/named/dominio_ejemplo.org.zone"; allow-query { any; }; allow-transfer { slaves; }; }; Con type master se establece el servidor como maestro/primario (slave establecer el tipo secundario). file indica la ruta de acceso al fichero de configuracin de la zona declarada. allow-query { any; } especifica que es posible hacer consultas externas a la zona. allow-transfer { slaves; } transfiere la configuracin de la zona hacia los servidores secundarios dentro del fichero de configuracin de la forma siguiente: acl "slaves" { 215.66.73.59; }; La definicin de un servidor esclavo, que se limitar a replicar los ficheros de zonas del servidor maestro, podra seguir el ejemplo siguiente para una de sus zonas: zone "sec.dominio_ejemplo.org" { type slave; file "/var/named/sec.dominio_ejemplo.org.zone"; allow-query { any; }; masters { 60.89.100.1; }; }; El fichero sigue las mismas trazas que el ejemplo del maestro, a excepcin de la sentencia masters, donde es aconsejable especificar la direccin IP del servidor primario para que el servidor esclavo solicite la transferencia de zonas

Primary Master Server configuration

In this section BIND9 will be configured as the primary master for the domain example.com. Simply replace example.com with your fully qualified domain name.

Zone File
To add a DNS zone to BIND9, turning BIND9 into a Primary Master server, all you have to do is edit named.conf.local: [...] zone "example.com" { type master; file "/etc/bind/db.example.com"; }; [...] Now use an existing zone file as a template: sudo cp /etc/bind/db.local /etc/bind/db.example.com Edit the new zone file /etc/bind/db.example.com change localhost. to the FQDN of your server, leaving the additional "." at the end. Change 127.0.0.1 to the nameserver's IP Address and root.localhost to a valid email address, but with a "." instead of the "@". also leaving the "." at the end. Also, create an A record for ns.example.com the name server in this example: ; ; BIND data file for local loopback interface ; $TTL 604800 @ IN SOA example.com. root.example.com. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; @ IN NS ns.example.com. ns IN A 192.168.1.10 @ IN A 192.168.1.10 box IN A 192.168.1.10 You must increment the serial number every time you make changes to the zone file. If you make multiple changes before restarting BIND9, simply increment the serial once. Now, you can add DNS records to the bottom of the zone. Tip: Many people like to use the last date edited as the serial of a zone, such as 2005010100 which is yyyymmddss (where s is serial)

Once you've made a change to the zone file BIND9 will need to be restarted for the changes to take effect: sudo /etc/init.d/bind9 restart

Reverse Zone File

Now that the zone file is setup and resolving names to IP Adresses a Reverse zone is also required. A Reverse zone allows DNS to convert from an address to a name. Edit /etc/bind/named.conf.local and add the following: zone "1.168.192.in-addr.arpa" { type master; notify no; file "/etc/bind/db.192"; }; Note: replace 1.168.192 with the first three octets of whatever private network you are using. Also, name the zone file db.192 in the example appropriately. Now create the db.192 file: sudo cp /etc/bind/db.127 /etc/bind/db.192 Next edit /etc/bind/db.192 changing the basically the same options as in /etc/bind/db.example.com: ; ; BIND reverse data file for local loopback interface ; $TTL 604800 @ IN SOA ns.example.com. root.example.com. ( 2 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; @ IN NS ns. 10 IN PTR ns.example.com. The serial number in the reverse zone needs to be incremented on each changes as well. For each A record you configure in/etc/bind/db.example.com you need to create a PTR record in /etc/bind/db.192. After creating the reverse zone file restart bind9: sudo /etc/init.d/bind9 restart

Testing
You should now be able to ping example.com and have it resolve to the host configured above: ping example.com You can also use the named-checkzone utility that is part of the bind9 package: named-checkzone example.com /etc/bind/db.example.com and named-checkzone example.com /etc/bind/db.192 This is a great way to make sure you haven't made any mistakes before restarting bind9. You can use the dig utility to test the reverse zone as well as the new domain name: dig 1.168.192.in-addr.arpa. AXFR You should see output resolving 1.168.192.in-addr.arpa. to your nameserver.

Bsqueda inversa
En la mayor parte de las bsquedas DNS, los clientes normalmente realizan una bsqueda directa, que es la que se basa en el nombre DNS de otro equipo segn se almacen en un registro de recursos de direccin (A). Este tipo de consulta espera una direccin IP como datos de recurso para la respuesta a la consulta. DNS tambin proporciona un proceso de bsqueda inversa, que permite a los clientes utilizar una direccin IP conocida durante la bsqueda de un nombre y busca un nombre de equipo en funcin de su direccin. Una bsqueda inversa tiene forma de pregunta, como "Puede decirme el nombre DNS del equipo que utiliza la direccin IP 192.168.1.20?". DNS no se dise originalmente para aceptar este tipo de consulta. Un problema de compatibilidad con el proceso de consulta inversa es la diferencia en la forma en que el espacio de nombres DNS organiza e indiza los nombres, y cmo se asignan las direcciones IP. Si el nico mtodo para responder a la pregunta anterior fuera buscar en todos los dominios del espacio de nombres DNS, una consulta inversa llevara demasiado tiempo y requerira un procesamiento demasiado largo como para ser til. Para resolver este problema, en el estndar DNS se defini y se reserv un dominio especial, el dominio in-addr.arpa, en el espacio de nombres DNS de Internet con el fin de proporcionar una forma prctica y confiable para realizar las consultas inversas. Al crear el espacio de nombres inverso, los subdominios del dominio in-addr.arpa se crean con el orden inverso de los nmeros en la notacin decimal con puntos de las direcciones IP.

Este orden inverso de los dominios para el valor de cada octeto es necesario porque, a diferencia de los nombres DNS, cuando se leen las direcciones IP de izquierda a derecha se interpretan al contrario. Cuando se lee una direccin IP de izquierda a derecha, se ve desde su informacin ms general (una direccin IP de red) en la primera parte de la direccin a la informacin ms especfica (una direccin IP de host) que contienen los ltimos octetos. Por esta razn, se debe invertir el orden de los octetos de las direcciones IP cuando se crea el rbol del dominio in-addr.arpa. Las direcciones IP del rbol DNS in-addr.arpa se pueden delegar a las organizaciones ya que se les asigna un conjunto de direcciones IP especfico o limitado en las clases de direcciones definidas en Internet. Finalmente, el rbol del dominio in-addr.arpa, tal como se crea en DNS, requiere que se defina un tipo de registro de recursos (RR) adicional, el registro de recursos de puntero (PTR). Este registro de recursos se utiliza para crear una asignacin en la zona de bsqueda inversa que, normalmente, corresponde a un registro de recurso de direccin (A) de host con nombre para el nombre del equipo DNS de un host en su zona de bsqueda directa. Nota El dominio in-addr.arpa se usa en todas las redes TCP/IP que se basan en el direccionamiento del Protocolo de Internet versin 4 (IPv4). El Asistente para crear zona nueva supone de forma automtica que se usa este dominio cuando se crea una zona de bsqueda inversa nueva. Si est instalando DNS y configurando zonas de bsqueda inversa en una red con el Protocolo de Internet versin 6 (IPv6), puede especificar un nombre exacto en el Asistente para crear zona nueva. Esto le permitir crear zonas de bsqueda inversa en la consola DNS que se puedan usar para admitir redes IPv6, que usan un nombre de dominio especial diferente, el dominio ip6.arpa. Hay ms informacin disponible acerca de IPv6 y DNS, con ejemplos acerca de cmo crear y usar nombres de dominio ip6.arpa, en el documento Solicitud de comentario (RFC) 3596, "Extensiones DNS compatibles con IP versin 6" ("DNS Extensions to support IP version 6"). Para obtener ms informacin, vaya directamente a este RFC, que puede obtener desde el sitio Web de RFC Editor.

Ejemplo: consulta inversa (para redes IPv4)

En el grfico siguiente se muestra un ejemplo de una consulta inversa iniciada por un cliente DNS (host-b) para aprender el nombre de otro host (host-a) basndose en su direccin IP, 192.168.1.20.

El proceso de bsqueda inversa que se muestra en este grfico se produce en los siguientes pasos:

1.

2.

El cliente, "host-b", consulta al servidor DNS un registro de recursos de puntero (PTR) que asigna la direccin IP 192.168.1.20 a "host-a". Ya que esta consulta se realiza en los registros de puntero, el solucionador invierte la direccin y agrega el dominio in-addr.arpa al final de la direccin inversa. De esta manera, forma el nombre de dominio completo ("20.1.168.192.in-addr.arpa.") que se va a buscar en una zona de bsqueda inversa. Una vez localizado, el servidor DNS con autoridad en "20.1.168.192.in-addr.arpa" puede responder con la informacin del registro de puntero PTR. Esto incluye el nombre de dominio DNS para "host-a", lo que completa el proceso de bsqueda inversa.

Tenga en cuenta que, si el servidor DNS no puede responder el nombre de la consulta inversa, se puede utilizar la resolucin DNS normal (ya sea la recursividad o la iteracin) para localizar un servidor DNS con autoridad para la zona de bsqueda inversa y que contenga el nombre consultado. En este sentido, el proceso de resolucin de nombres utilizado en una bsqueda inversa es idntico al de una bsqueda directa.

Secondary Master Server configuration

Once a Primary Master has been configured a Secondary Master is needed in order to maintain the availability of the domain should the Primary become unavailable. First, on the primary master server, the zone transfer needs to be allowed. Add the allowtransfer option to the sample Forward and Reverse zone definition in /etc/bind/named.conf.local: [...] zone "example.com" { type master; file "/etc/bind/db.example.com";

allow-transfer { @ip_secondary; };
}; [...] zone "1.168.192.in-addr.arpa" { type master; notify no; file "/etc/bind/db.192";

allow-transfer { @ip_secondary; };
}; [...] Note: replace @ip_secondary with the actual IP Address of your secondary server. Next, on the Secondary Master, install the bind9 package the same way as the primary. Then edit the/etc/bind/named.conf.local and add the following declarations for the Forward and Reverse zones: [...] zone "example.com" { type slave; file "/var/cache/bind/db.example.com";

masters { @ip_master; };
}; [...] zone "1.168.192.in-addr.arpa" { type slave; file "/var/cache/bind/db.192";

masters { @ip_master; };
}; [...]

Note: replace @ip_master with the IP Address of the Primary. Restart the server, and in /var/log/syslog you should see something similar to: syslog.5.gz:May 14 23:33:53 smith named[5064]: zone example.com/IN: transferred serial 2006051401 syslog.5.gz:May 14 23:33:53 smith named[5064]: transfer of 'example.com/IN' from 10.0.0.202#53: end of transfer syslog.5.gz:May 14 23:33:35 smith named[5064]: slave zone "1.168.192.in-addr.arpa" (IN) loaded (serial 2006051401)

Note: A zone is only transfered if the Serial Number on the Primary is larger than the one on the Secondary.
Testing
Testing the Secondary Master can be done using the same methods as the Primary. Also, you could shutdown BIND9 on the Primary then try pinging example.com from a host configured to use the Secondary as well as the Primary for name resolution. If all goes well the Secondary should resolve example.com.

MAS INFORMACION (Probar si no funciona el taller anterior) Configuracin del servidor como DNS esclavo Si deseamos configurar nuestro servidor DNS para que acte como esclavo de un servidor DNS maestro, la configuracin es mucho ms sencilla que en el caso anterior ya que nicamente ser necesario indicar en el DNS esclavo quin es el servidor DNS maestro, y en el DNS maestro, la IP del DNS esclavo. Ejemplo, supongamos que el nombre del DNS maestro es sandra-PC.XXmicentro.com (IP 192.168.2.202) y que el nombre del DNS esclavo es dns2.XXmicentro.com. En el archivo db.XXmicentro.com' de zona de bsqueda directa del maestro aadiremos la lnea del segundo dns justo debajo de donde est la del primero: // Aadir lnea en /etc/bind/db.XXmicentro.com del maestro .... IN NS IN NS .... sandra-PC.XXmicentro.com. dns2.XXmicentro.com. // Nueva lnea

de esta forma indicaremos que existen ms servidores DNS para dicha zona. Lo mismo haremos en el archivo db.192 de la zona inversa del maestro: // Aadir lnea en /etc/bind/db.192 del maestro .... IN NS IN NS .... En el archivo /etc/bind/named.conf.local del servidor DNS esclavo debemos indicar que se trata de un servidor esclavo y tambin debemos indicar quin es el maestro: // Aadir en /etc/bind/named.conf.local del esclavo zone "XXmicentro.com" { type slave; file "/etc/bind/db.XXmicentro.com"; masters { 192.168.2.202; }; }; zone "2.168.192.in-addr.arpa" { type slave; file "/etc/bind/db.192"; masters { 192.168.2.202; }; }; sandra-PC.XXmicentro.com. dns2.XXmicentro.com. // Nueva lnea

En el archivo /etc/bind/named.conf.local del servidor DNS maestro podemos utilizar also-notify para mantener los DNS sincronizados. Con also-notify pasamos los cambios de zonas del maestro al esclavo: // Archivo /etc/bind/named.conf.local del maestro zone "XXmicentro.com" { type master;

file "/etc/bind/db.XXmicentro.com"; also-notify {ip_del_esclavo;} }; zone "2.168.192.in-addr.arpa" { type master; file "/etc/bind/db.192"; also-notify {ip_del_esclavo;} }; De sta forma dispondremos en la red de un servidor DNS esclavo que podr satisfacer las peticiones DNS al igual que lo hara el maestro. Es interesante si el nmero de peticiones es muy elevado y se requiere distribuir la carga entre los dos servidores, o si deseamos disponer de servicio DNS de alta disponibilidad de forma que aunque el servidor maestro deje de funcionar, el servidor esclavo podr seguir ofreciendo el servicio. NOTA: Cada vez que hagamos un cambio en los archivos /etc/bind/db.XXmicentro.com y /etc/bind/db.192 del maestro, debemos acordarnos de actualizar el parmetro serial (incrementar en una unidad) para que los dns dependientes del maestro sepan que ha cambiado y actualicen su informacin para mantenerse perfectamente sincronizados.

COMPROBACION DNS Dig NOMBREdeMAQUINA COMPROBACION RESOLUCION INVERSA Dig -x 192.168.1.164

EJERCICIO: Que ocurre en esta resolucin inversa? Porque no devuelve resultado?

; <> DiG 9.6.1-P2 <> -x 148.208.141.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 7399 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;1.141.208.148.in-addr.arpa. IN PTR ;; Query time: 0 msec ;; SERVER: 148.208.141.1#53(148.208.141.1) ;; WHEN: Wed Apr 21 20:41:31 2010 ;; MSG SIZE rcvd: 44

Independientemente de que esta no sea la panacea para evitar un ataque a un servidor DNS, siempre es recomendable ocultar toda la informacin que sea posible sobre versiones de servicios instalados en una mquina, y por supuesto siempre es recomendable mantener el servicio a la ltima versin estable. Para ocultar la versin de Bind, debemos editar el fichero de configuracin named.conf:

$ vi /etc/named.conf (EN RED HAT) $vi /etc/bind/named.conf.options

Aadiremos la siguiente lnea (con el texto que os apetezca) dentro de la seccin de opciones:

version "Seguramente estas bromeando";

Reiniciamos named y ya debera aparecer enmascarada la versin de Bind: /etc/init.d/bind9 restart Podemos testearlo as:

$ dig @servidordns version.bind txt chaos

; <<>> DiG 9.4.2 <<>> @xxxxx version.bind txt chaos ; (1 server found) ;; global options: ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33774 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available printcmd

;; QUESTION SECTION:

;version.bind.

CH

TXT

;; ANSWER SECTION: version.bind. bromeando" 0 CH TXT "Seguramente estas

;; Query time: 247 msec ;; SERVER: xx.xx.xx.xx#53(xx.xx.xx.xx) ;; WHEN: Mon Sep ;; MSG SIZE 1 22:55:41 2008

rcvd: 70

RFC de DNS
Las solicitudes de comentarios (RFC, Requests for Comments) son un conjunto de informes, propuestas de protocolos y estndares de protocolos utilizados por la comunidad de Internet. Las especificaciones del Sistema de nombres de dominio (DNS) estn basadas en las RFC aprobadas y publicadas por el Grupo de trabajo de ingeniera de Internet (IETF, Internet Engineering Task Force) y otros grupos de trabajo.

RFC para el servicio Servidor DNS

Los siguientes RFC contienen especificaciones para disear e implementar los servicios de Servidor y Cliente DNS:

RFC Ttulo
1034 Nombres de dominio: conceptos y servicios 1035 Nombres de dominio: implementacin y especificacin 1123 Requisitos para hosts de Internet: aplicacin y soporte 1886 Extensiones DNS para admitir IP Versin 6 (DNS Extensions to Support IP Version 6) 1995 Transferencia incremental de zona en DNS (Incremental Zone Transfer in DNS) 1996 Un mecanismo para la notificacin de los cambios de zona (A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)) 2136 Actualizaciones dinmicas en el Sistema de nombres de dominio (DNS UPDATE) (Dynamic Updates in the Domain Name System) 2181 Aclaraciones respecto a la especificacin DNS (Clarifications to the DNS Specification) 2308 Almacenamiento en cach de las consultas DNS (DNS NCACHE) negativas (Negative Caching of DNS Queries) 2535 Extensiones de seguridad del sistema de nombres de dominio (DNSSEC) 2671 Mecanismos de extensin para DNS (EDNS0) 2782 Un registro de recursos DNS para especificar la ubicacin de los servicios (SRV DNS) (A DNS RR for Specifying the Location of Services (DNS SRV)) 2930 Definicin de claves secretas para DNS (TKEY RR) (Secret Key Establishment

for DNS (TKEY RR)) 3645 Algoritmo de servicio de seguridad genrico para Autenticacin de transacciones con clave secreta para DNS (GSS-TSIG) 3646 Opciones de configuracin DNS para Protocolo de configuracin dinmica de host para IPv6 (DHCPv6)
Se pueden encontrar las RFC en

http://www.rfc-editor.org/rfcxx00.html

RNDC
BIND incluye una utilidad llamada rndc la cual permite la administracin de lnea de comandos del demonio named desde el host local o desde un host remoto. Para prevenir el acceso no autorizado al demonio named, BIND utiliza un mtodo de autenticacin de llave secreta compartida para otorgar privilegios a hosts. Esto significa que una llave idntica debe estar presente en los archivos de configuracin /etc/named.conf.local y en el rndc, /etc/rndc.conf.

Configuracin de /etc/rndc.conf
La declaracin controls mostrada abajo en el ejemplo siguiente, permite a rndc conectarse desde un host local.
1. vi /etc/rndc.conf and following line ---options { default-server 127.0.0.1; default-key "rndckey"; }; server 127.0.0.1 { key "rndckey"; }; key "rndckey" { algorithm "hmac-md5"; secret "secret key will be placed here"; }; ---

Esta declaracin permite comandos rndc provenientes del host local, si se proporciona la llave correcta. El ejemplo siguiente ilustra la declaracin key. key "<key-name>" { algorithm hmac-md5; secret "<key-value>"; }; En este caso, el <key-value> utiliza el algoritmo HMAC-MD5. Utilice el comando siguiente para generar llaves usando el algoritmo HMAC-MD5: dnssec-keygen -r /dev/urandom -a HMAC-MD5 -b 256 -n HOST rndc Una llave con al menos un largo de 256-bit es una buena idea. La llave que debera ser colocada en el rea <key-value> se puede encontrar en el archivo <key-file-name> generado por este comando.

EJ: Krndc.+157+18780.private Copia la clave del fichero prvate y ponla en /etc/rndc.conf en la lnea secret vi /etc/named.conf.local y escribe lo siguiente :

---controls { inet 127.0.0.1 allow { 127.0.0.1; } keys { rndckey; }; };

key "rndckey" { algorithm "hmac-md5"; secret "replace_keyhere"; };

En named.conf.local insertar tiene que quedar algo as:

---controls { inet 127.0.0.1 allow { 127.0.0.1; } keys { rndckey; }; }; key "rndckey" { algorithm "hmac-md5"; secret "replace_keyhere"; }; ----

En RNDC.KEY tambin hay que meter la clave privada 12.4.3. Opciones de lnea de comandos
Un comando rndc toma la forma siguiente: rndc <options> <command> <command-options> Cuando est ejecutando rndc en una mquina local configurada de la forma correcta, los comandos siguientes estn disponibles:

halt

Para inmediatamente el servicio named. Registra todas las peticiones hechas a este servidor de

querylog

nombres.
refresh reload

Refresca la base de datos del servidor de nombres.

Recarga los archivos de zona pero mantiene todas las respuestas precedentes situadas en cach. Esto le permite realizar cambios en los archivos de zona sin perder todas las resoluciones de nombres almacenadas. Si los cambios slo afectaron una zona especfica, vuelva a cargar solamente esa una zona especfica aadiendo el nombre de la zona despus del comando reload.

Descarga las estadsticas actuales de named al archivo /var/named/named.stats.

stats

Detiene al servidor salvando todas las actualizaciones dinmicas y los datos de las Transferencias de zona incremental (IXFR) antes de salir.
stop

Ocasionalmente, puede ser necesario ignorar las configuraciones por defecto en el archivo /etc/rndc.conf. Estan disponibles las siguientes opciones:
-c <configuration-file>

Especifica la ubicacin alterna de un

archivo de configuracin.

Especifica la utilizacin de un nmero de puerto diferente del predeterminado 953 para la conexin del comando rndc.
-p <port-number>

Especifica un servidor diferente al defaultserver listado en /etc/rndc.conf.

-s <server>

Le permite especificar una llave distinta de la opcin default-key en el archivo /etc/rndc.conf.

-y <key-name>

Se puede encontrar informacin adicional sobre estas opciones en la pgina del manual de rndc.

CACHING SERVER Por defecto bind esta configurado como caching server, por lo que si realizamos la misma consulta, veremos como tira de la cache..

If you have configured BIND9 as a Caching nameserver "dig" an outside domain to check the query time: dig ubuntu.com Note the query time toward the end of the command output: ;; Query time: 49 msec After a second dig there should be improvement: ;; Query time: 1 msec

COMANDO COMPROBACIN named-checkzone A great way to test your zone files is by using the named-checkzone utility installed with the bind9 package. This utility allows you to make sure the configuration is correct before restarting BIND9 and making the changes live. To test our example Forward zone file enter the following from a command prompt: named-checkzone example.com /etc/bind/db.example.com If everything is configured correctly you should see output similar to: zone example.com/IN: loaded serial 6 OK Similarly, to test the Reverse zone file enter the following: named-checkzone example.com /etc/bind/db.192 The output should be similar to: zone example.com/IN: loaded serial 3 OK