d3 Admin DNS

ADMINISTRACION DE

SERVIDORES LINUX

ENTERPRISE

SERVIDOR DE RESOLUCION DE NOMBRES

DNS - BIND

Instructor: Pedro Vargas

E-Mail: [email protected]

SERVIDOR DE RESOLUCION DNS

TOPICOS CLASE 3:

SERVIDOR DE RESOLUCION DE NOMBRES DNS

Introduccin a DNS-BIND

Instalacin de paquetes necesarios.

Configuracin inicial del servicio.

Creacin de las zonas del dominio: named.conf

Creacin de los archivos de resolucin de

nombres por zona.

Configuracin de Mail y VirtualHost

Comprobacin del servicio DNS y servicio de red

local.

Solucin de problemas frecuentes.


INTRODUCCION A DNS - BIND

Introduccin

BIND (acrnimo de Berkeley Internet Name Domain) es una

implementacin del protocolo DNS (Domain Name System) y provee

una implementacin 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 operacin adecuada del servidor

DNS (bind-utils).

El servidor DNS BIND es ampliamente utilizado en la Internet (99% de los

servidores DNS) proporcionando una robusta y estable solucin.


INTRODUCCION A DNS BIND

Introduccin

El Domain Name System (DNS) es una base de datos distribuida y jerrquica que almacena informacin asociada a nombres de dominio en redes como Internet. Aunque como base de datos el DNS es capaz de asociar distintos tipos de informacin a cada nombre, los usos ms comunes son la asignacin de nombres de dominio a direcciones IP y la localizacin de los servidores de correo electrnico de cada dominio.

La asignacin de nombres a direcciones IP es ciertamente la funcin ms conocida de los protocolos DNS. Por ejemplo, si la direccin IP del sitio WWW de ucbcba.edu.bo es 166.114.106.105, la mayora de la gente llega a este equipo especificando www.ucbcba.edu.bo y no la direccin IP. Adems de ser ms fcil de recordar, el nombre es ms fiable. La direccin numrica podra cambiar por muchas razones, sin que tenga que cambiar el nombre.

Inicialmente, el DNS naci de la necesidad de recordar fcilmente los nombres de todos los servidores conectados a Internet. En un inicio, SRI (ahora SRI International) alojaba un archivo llamado HOSTS.TXT que contena todos los nombres de dominio conocidos (tcnicamente, este archivo an existe - la mayora de los sistemas operativos actuales todava pueden ser configurados para revisar su archivo hosts).



Cmo funciona el DNS

El DNS organiza los nombres de mquina (hostname) en una jerarqua de dominios. Un dominio es una coleccin de nodos relacionados de alguna forma porque estn en la misma red, tal como los nodos de una universidad Por ejemplo, las universidades americanas se agrupan en el dominio edu. Cada universidad tiene all un subdominio, tal como la universidad Groucho Marx, que posee el subdominio groucho.edu. A su vez, podemos encontrar nuevos subdominios dentro, como el Departamento de Matemticas (maths). Finalmente, un nodo de ese departamento llamado erdos tendr un nombre completo (conocido como totalmente cualificado) tal como erdos.maths.groucho.edu. Este nombre totalmente cualificado tambin se conoce por las siglas FQDN.

En Figura vemos una parte del espacio de nombres. La raz del rbol, que se identifica con un punto sencillo, es lo que se denomina dominio raz y es el origen de todos los dominios. Para indicar que un nombre es FQDN, a veces se termina su escritura en un punto. Este punto significa que el ltimo componente del nombre es el dominio raz.



Una parte del espacio de nombres de dominios



Funcionamiento de DNS

El Domain Name System (DNS) o Sistema de Nombres de Dominio

permite a los usuarios de una red TCP/IP utilizar nombres jerrquicos y

descriptivos para localizar fcilmente ordenadores (hosts) y otros

recursos en dicha red, evitando de esta manera tener que recordar la

direccin IP de cada ordenador al que se desea acceder. En esencia,

DNS es una base de datos distribuida que contiene asociaciones de

nombres simblicos (de hosts) a direcciones IP. El hecho de que sea

distribuida permite delegar el control sobre diferentes segmentos de la

base de datos a distintas organizaciones, pero siempre de forma que

los datos de cada segmento estn disponibles en toda la red, a travs

de un esquema cliente-servidor.

Los programas denominados servidores de nombres (name servers)

constituyen la parte servidora del esquema cliente-servidor. Los

servidores de nombres contienen informacin sobre algunos

segmentos de la base de datos y los ponen a disposicin de los

clientes, llamados solucionadores o resolvers.



El Espacio de Nombres de Dominio

La base de datos distribuida de DNS est indexada por nombres de dominio.

Cada nombre de dominio es esencialmente una trayectoria en un rbol

invertido denominado espacio de nombres de dominio. La estructura jerrquica del rbol es similar a la estructura del sistema de ficheros LINUX. El

rbol tiene una nica raz en el nivel superior llamada raz (root). Cada nodo del

rbol puede ramificarse en cualquier nmero de nodos de nivel inferior. La

profundidad del rbol est limitada a 127 niveles.

Cada nodo en el rbol se identifica mediante una etiqueta no nula que puede

contener hasta 63 caracteres, excepto el nodo raz, identificado mediante una

etiqueta nula. El nombre de dominio completo de cualquier nodo est

formado por la secuencia de etiquetas que forman la trayectoria desde dicho

nodo hasta la raz, separando cada etiqueta de la siguiente mediante un

punto. De esta forma, el nombre del nodo especifica de forma unvoca su

localizacin en la jerarqua. A este nombre de dominio completo o absoluto se

le conoce como nombre de dominio completamente cualificado o Fully

Qualified Domain Name (FQDN). Al ser nula la etiqueta que identifica el nodo

raz, el FQDN de cualquier nodo del rbol siempre acaba con un punto. La

nica restriccin que se impone en el rbol de nombres es que los nodos hijos

del mismo padre tengan etiquetas diferentes.



Arbol jerarquico DNS



Relacion DNS vs Linux/Unix



Dependiendiendo de su localizacin en la jerarqua, un dominio

puede ser de primer nivel (top-level), segundo nivel o tercer nivel. Se

pueden aadir todos los niveles que queramos, pero no son

habituales. Los que siguen son los dominios de primer nivel que

veremos con frecuencia:

Inicialmente los cuatro primeros dominios de la lista anterior

pertenecan solo a los Estados Unidos, sin embargo, los cambios de

poltica posteriores han hecho que estos dominios, llamados de

dominios globales primer nivel (gTLD) sean realmente globales.

Adems se estn negociando nuevos dominios de primer nivel.

Fuera de los Estados Unidos, cada pas suele tener su propio dominio de primer

nivel codificado con las dos letras del pas definidas en la tabla ISO-3166.

Finlandia, por ejemplo, usa el dominio fi; en Espaa se usa el dominio es; en

Mxico se usa mx; en Bolivia, bo, etc. Por debajo de cada dominio de primer

nivel, cada pas organiza los dominios a su manera. Algunos crean a segundo

nivel una serie de dominios similares a los gTLD. Por ejemplo, en Bolivia

encontramos los dominios com.bo para las empresas, y org.bo para las

organizaciones sin nimo de lucro. Otros pases, como Espaa, ponen

directamente como nombres de segundo nivel las instituciones o empresas que

los solicitan. Por ejemplo, tenemos hispalinux.es.



Tipos de servidores de nombres

Los servidores de nombres que mantienen oficialmente la informacin

de una zona se conocen como autorizados de la zona, y a veces se

conocen como servidores principales o maestros. Cualquier peticin

de nodos de esa zona ir a parar a uno de estos servidores principales.

Los servidores principales deben estar bien sincronizados. Es decir, uno

de ellos ser llamado primario, que carga su informacin de un

fichero, y hacer a los dems secundarios, que obtienen su informacin

pidindosela peridicamente al primario.

El objetivo de tener varios servidores principales es distribuir la carga y

dar cierta tolerancia a fallos. Cuando uno de los servidores principales

falla, todas las peticiones acabarn en los dems. Por supuesto, este

esquema no nos protege de fallos del servidor que produzcan errores

en todas las peticiones DNS, como podran ser errores del software.

Tambin podemos instalar un servidor de nombres que no es maestro

de ninguna zona. Esto es til, para dar servicio de nombres a una red

local aprovechando sus caractersticas de ahorro de ancho de banda

gracias a su cach. Estos servidores se conocen como de slo-cach.



La base de datos DNS

Hemos visto que el DNS no slo sabe de direcciones IP de mquinas,

pero tambin almacena otras informaciones.

Cada unidad de informacin del DNS se llama Registro de Recurso

(RR). Cada registro tiene un tipo asociado que describe el dato que

contiene, y una clase que especifica el tipo de red al que se aplica.

Esto ltimo se adapta a diferentes esquemas de direccin, como

direcciones IP (la clase IN), direcciones Hesiod (utilizadas por el sistema

Kerberos del MIT) y algunas ms. El RR tpico es el registro A, que asocia

un nombre completamente cualificado con una direccin IP.

Un nodo puede ser conocido por ms de un nombre. Por ejemplo,

podemos tener un servidor que proporciona tanto servicio FTP como

WWW, y tendr dos nombres: ftp.maquinas.org y www.maquinas.org.

Sin embargo, uno de estos nombres debe ser identificado como oficial

o cannico. La diferencia es que el cannico es el nico registro A

que debe existir apuntando a esa direccin IP, mientras que el resto

de los nombres deben ser alias (registros CNAME), que apuntan al

nombre cannico.



Registros de Recursos (RR)

Para resolver nombres, los servidores consultan sus zonas. Las zonas contienen

registros de recursos que constituyen la informacin de recursos asociada al

dominio DNS. Por ejemplo, ciertos registros de recursos asignan nombres

descriptivos a direcciones IP. El formato de cada registro de recursos es el

siguiente:

Propietario TTL Clase Tipo RDATA

Propietario: nombre de host o del dominio DNS al que pertenece este recurso. Puede contener un nombre de host/dominio (completamente cualificado o

no), el smbolo "@" (que representa el nombre de la zona que se est

describiendo) o una cadena vaca (en cuyo caso equivale al propietario del

registro de recursos anterior).

TTL: (Time To Live) Tiempo de vida, generalmente expresado en segundos, que

un servidor DNS o un resolver debe guardar en cach esta entrada antes de

descartarla. Este campo es opcional. Tambin se puede expresar mediante

letras indicando das (d), horas (h), minutos (m) y segundos (s). Por ejemplo:

"2h30m".

Clase: define la familia de protocolos en uso. Suele ser siempre "IN", que

representa Internet.

Tipo: identifica el tipo de registro.



Registro de Recurso SOA

Cada zona contiene un registro de recursos denominado Inicio de Autoridad o

SOA (Start Of Authority) al comienzo de la zona. Los registros SOA incluyen los

siguientes campos (slo se incluyen los que poseen un significado especfico

para el tipo de registro):

Propietario: nombre de dominio de la zona.

Tipo: "SOA".

Persona responsable: contiene la direccin de correo electrnico del

responsable de la zona. En esta direccin de correo, se utiliza un punto en el

lugar del smbolo "@".

Nmero de serie: muestra el nmero de versin de la zona, es decir, un nmero que sirve de referencia a los servidores secundarios de la zona para saber

cundo deben proceder a una actualizacin de su base de datos de la zona

(o transferencia de zona). Cuando el nmero de serie del servidor secundario

sea menor que el nmero del maestro, esto significa que el maestro ha

cambiado la zona, y por tanto el secundario debe solicitar al maestro una

transferencia de zona. Por tanto, este nmero debe ser incrementado

(manualmente) por el administrador de la zona cada vez que realiza un

cambio en algn registro de la zona (en el servidor maestro).

Actualizacin: muestra cada cunto tiempo un servidor secundario debe

ponerse en contacto con el maestro para comprobar si ha habido cambios en



Registro de Recurso SOA

Reintentos: define el tiempo que el servidor secundario, despus de enviar una

solicitud de transferencia de zona, espera para obtener una respuesta del

servidor maestro antes de volverlo a intentar.

Caducidad: define el tiempo que el servidor secundario de la zona, despus de la transferencia de zona anterior, responder a las consultas de la zona antes

de descartar la suya propia como no vlida.

TTL mnimo: este campo especifica el tiempo de validez (o de vida) de las

respuestas "negativas" que realiza el servidor. Una respuesta negativa significa

que el servidor contesta que un registro no existe en la zona.

Un ejemplo de registro SOA sera el siguiente:

admon.com. IN pc0100.admon.com hostmaster.admon.com.

( 1 ; nmero de serie

3600 ; actualizacin 1 hora

600 ; reintentar 10 minutos

86400 ; caducar 1 da

60 ; TTL 1 minuto

)



Registro de Recurso NS

El registro de recursos NS (Name Server) indica los servidores de

nombres autorizados para la zona. Cada zona debe contener registros

indicando tanto los servidores principales como los secundarios. Por

tanto, cada zona debe contener, como mnimo, un registro NS.

Por otra parte, estos registros tambin se utilizan para indicar quines

son los servidores de nombres con autoridad en subdominios

delegados, por lo que la zona contendr al menos un registro NS por

cada subdominio que haya delegado.

Ejemplos de registros NS seran los siguientes:

admon.com. IN NS pc0100.admon.com.

valencia.admon.com. IN NS pc0102.valencia.admon.com.



Registro de Recurso A

El tipo de registro de recursos A (Address) asigna un nombre de

dominio completamente cualificado (FQDN) a una direccin IP, para

que los clientes puedan solicitar la direccin IP de un nombre de host

dado.

Un ejemplo de registro A que asignara la direccin IP 158.42.178.1 al

nombre de dominio pc0101.valencia.admon.com., sera el siguiente:

pc0101.valencia.admon.com. IN A 158.42.178.1

Registro de Recurso PTR

El registro de recursos PTR (PoinTeR) o puntero, realiza la accin

contraria al registro de tipo A, es decir, asigna un nombre de dominio

completamente cualificado a una direccin IP. Este tipo de recursos

se utilizan en la denominada resolucin inversa, descrita en Servidores de nombres y zonas.

Un ejemplo de registro PTR que asignara el nombre

pc0101.valencia.admon.com. a la direccin IP 158.42.178.1 sera el

siguiente:



Registro de Recurso CNAME

El registro de nombre cannico (CNAME, Canonical NAME) crea un

alias (un sinnimo) para el nombre de dominio especificado.

Un ejemplo de registro CNAME que asignara el alias controlador al

nombre de dominio pc0102.valencia.admon.com, sera el siguiente: controlador.valencia.admon.com. IN CNAME pc0101.valencia.admon.com.

Registro de Recurso MX

El registro de recurso de intercambio de correo (MX, Mail eXchange)

especifica un servidor de intercambio de correo para un nombre de

dominio. Puesto que un mismo dominio puede contener diferentes

servidores de correo, el registro MX puede indicar un valor numrico

que permite especificar el orden en que los clientes deben intentar

contactar con dichos servidores de correo.

Un ejemplo de registro de recurso MX que define al servidor pc0100

como el servidor de correo del dominio admon.com, sera el siguiente:

admon.com. IN MX 0 pc0100.admon.com.



Registro de Recurso HINFO

Este registro da informacin sobre el hardware y el software de la

mquina. Su sintaxis es:

[domain] [ttl] [class] HINFO hardware software

El campo hardware identifica el hardware usado en este nodo. Para

indicarlo, se siguen ciertas convenciones, especificadas en el RFC

1700. Si el campo contiene blancos, debe encerrarse entre comillas

dobles. El campo software indica el sistema operativo que ejecuta el

nodo, que tambin est normalizado.

Por ejemplo, un registro HINFO para describir un sistema Intel

ejecutando Linux podra ser:

tao 36500 IN HINFO IBM-PC LINUX2.2

y para el caso de que se tratara de un sistema basado en DELL:

orion 36500 IN HINFO DELL POWEREDGE2500 LINUX CENTOS

ENTERPRISE 4.3


INSTALACION DE BIND

Software Requerido.

bind

bind-chroot

bind-utils

caching-nameserver

La instalacin puede hacerse a travs de yum para satisfacer

todas las dependencias necesarias.

yum -y install bind bind-chroot bind-utils caching-nameserver


INSTALACION DE BIND

Preparativos.

Idealmente se deben definir primero los siguientes datos:

Dominio a resolver.

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

plenamente resuelto.

Lista de todos los servidores de nombres (NS) que se utilizarn para efectos

de redundancia. stos deben ser nombres que ya estn plenamente

resueltos.

Cuenta de correo del administrador responsable de esta zona. Dicha

cuenta debe existir y no debe pertenecer a la misma zona que se est

tratando de resolver.

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

IP predeterminada del dominio.

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

IP que estarn asociadas a estos.

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 no pueden utilizar datos que sean parte o dependan del

mismo dominio que se pretende resolver. De igual modo, el servidor donde se

implementar el servicio de DNS deber contar con un nombre previa y


INSTALACION DE BIND

Preparativos.

Como regla general se generar una zona de reenvo por cada

dominio sobre el cual se tenga autoridad plena y absoluta y se

generar una zona de resolucin inversa por cada red sobre la cual se

tenga plena y absoluta autoridad. es decir, si se es propietario del

dominio cualquiercosa.com, se deber generar el fichero de zona

correspondiente a fin de resolver dicho dominio.

Por cada red con direcciones IP privadas sobre la cual se tenga

control y plena y absoluta autoridad, se deber generar un fichero de

zona de resolucin inversa a fin de resolver inversamente las

direcciones IP de dicha zona. Regularmente la resolucin inversa de

las direcciones IP pblicas es responsabilidad de los proveedores de

servicio ya que son estos quienes tienen la autoridad plena y absoluta

sobre dichas direcciones IP.

Todos los ficheros de zona deben pertenecer al usuario named a fin

de que el daemon named pueda acceder a estos o bien modificarlos

en el caso de tratarse de zonas esclavas.


INSTALACION DE BIND

Creacin de los ficheros de zona.

Los siguientes corresponderan a los contenidos para los ficheros de

zona requeridos para la red local y por el NIC con el que se haya

registrado el dominio. Note por favor que en las zonas de reenvo

siempre se especifica al menos un Mail Exchanger (MX) y que se

utilizan tabuladores (tecla TAB) en lugar de espacio. Solo necesitar

sustituir nombres y direcciones IP, y quiz aadir nuevas entradas para

complementar su red local.


INSTALACION DE BIND

Zona de reenvo red local

/var/named/chroot/var/named/mi-red-local.edu.bo.zone

$TTL 86400

@ IN SOA mi-red-local.edu.bo. jperez.mi-red-local.edu.bo. (

8 ; serial

28800 ; refresh

7200 ; retry

604800 ; expire

86400 ; ttl

)

@ IN NS dns

@ IN MX 10 mail

@ IN A 192.168.1.1

intranet IN A 192.168.1.1

maquina2 IN A 192.168.1.2



www IN CNAME intranet

mail IN A 192.168.1.1

ftp IN CNAME intranet

dns IN CNAME intranet


INSTALACION DE BIND

Zona de resolucin inversa red local

/var/named/chroot/var/named/1.168.192.in-addr.arpa.zone

$TTL 86400

@ IN SOA mi-red-local.edu.bo. jperez.mi-red-local.edu.bo. (

2005030401 ; serial

28800 ; refresh

7200 ; retry

604800 ; expire

86400 ; ttl

)

@ IN NS dns.mi-red-local.edu.bo.

1 IN PTR intranet.mi-red-local.edu.bo.

2 IN PTR maquina2.mi-red-local.edu.bo.




INSTALACION DE BIND

Zona de reenvo del dominio

/var/named/chroot/var/named/mi-dominio.edu.bo.zone

$TTL 86400

@ IN SOA nombre-plenamente-resuelto. jperez.cuenta.existente. (

8 ; serial

28800 ; refresh

7200 ; retry

604800 ; expire

86400 ; ttl

)

@ IN NS dns

@ IN MX 10 mail

@ IN A 148.243.59.1

servidor IN A 148.243.59.1

www IN CNAME servidor

mail IN A 148.243.59.1

ftp IN CNAME servidor

dns IN CNAME servidor


INSTALACION DE BIND

Zona de resolucin inversa del dominio

/var/named/chroot/var/named/1.243.148.in-addr.arpa.zone $TTL 86400

@ IN SOA nombre-plenamente-resuelto. jperez.cuenta.existente. (

2005030401 ; serial

28800 ; refresh

7200 ; retry

604800 ; expire

86400 ; ttl

)

@ IN NS dns.mi-dominio.edu.bo.

1 IN PTR servidor.mi-dominio.edu.bo.

2 IN PTR maquina2.mi-dominio.edu.bo.



Recuerde que cada vez que haga algn cambio en algn fichero de

zona, deber cambiar el nmero de serie (serial) a fin de que tomen

efecto los cambios de inmediato cuando se reinicie el daemon

named, ya que de otro modo tendra que reiniciar el equipo, algo

poco conveniente.


INSTALACION DE BIND

Fichero de Configuracin de Zonas de resolucin

/var/named/chroot/etc/named.conf options {

directory "/var/named/";

forwarders { 200.33.146.209; 200.33.146.217; };

forward first;

};

zone "." {

type hint;

file "named.ca";

};

zone "0.0.127.in-addr.arpa" {

type master;

file "0.0.127.in-addr.arpa.zone";

allow-update { none; };

};

zone "localhost" {

type master;

file "localhost.zone";


};


INSTALACION DE BIND

Fichero de Configuracin de Zonas de resolucin

/var/named/chroot/etc/named.conf zone "mi-dominio.edu.bo" {

type master;

file "mi-dominio.edu.bo.zone";


};


type master;



};

zone "mi-red-local.edu.bo" {

type master;

file "mi-red-local.edu.bo.zone";


};


type master;



};


INSTALACION DE BIND

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 parmetro allow-query, el cual servir para especificar que

solo ciertas direcciones podrn realizar consultas al servidor de nombres de

dominio. Se pueden especificar directamente direcciones IP, redes completas

o listas de control de acceso que debern definirse antes de cualquier otra

cosa en /var/named/chroot/etc/named.conf:

acl "redlocal" { 192.168.1.0/24; 192.168.2.0/24; 192.168.3.0/24; }

options {

directory "/var/named/";

forwarders { 200.33.146.209; 200.33.146.217; };

forward first;

allow-query { redlocal; 192.168.1.15; 192.168.1.16; };

};

zone "mi-red-local.edu.bo" {

type master;

file "mi-red-local.edu.bo.zone";


};


INSTALACION DE BIND

Seguridad adicional en DNS para uso exclusivo en red local.


type master;



};


SERVICIO NAMED

Reinicializacin y depuracin del servicio.

Al terminar de editar todos los ficheros involucrados, solo bastar

reiniciar el servidor de nombres de dominio.

/sbin/service named restart

Tambin se puede reiniciar el servicio llamando al binario named

usando el usuario named.

named u named

Si queremos que el servidor de nombres de dominio quede aadido

entre los servicios en el arranque del sistema, deberemos ejecutar lo

siguiente a fin de habilitar named junto con el arranque del sistema:

/sbin/chkconfig named on

Realice prueba de depuracin y verifique que la zona haya cargado

con nmero de serie:

tail -50 /var/log/messages |grep named


SERVICIO NAMED

Reinicializacin y depuracin del servicio.

Lo anterior, si est funcionando correctamente, debera devolver algo

parecido a lo mostrado a continuacin:

Aug 17 17:15:15 linux named[30618]: starting BIND 9.2.2 -u named

Aug 17 17:15:15 linux named[30618]: using 1 CPU

Aug 17 17:15:15 linux named: Iniciacin de named succeeded

Aug 17 17:15:15 linux named[30622]: loading configuration from '/etc/named.conf'

Aug 17 17:15:15 linux named[30622]: no IPv6 interfaces found

Aug 17 17:15:15 linux named[30622]: listening on IPv4 interface lo, 127.0.0.1#53

Aug 17 17:15:15 linux named[30622]: listening on IPv4 interface eth0, 192.168.1.1#53

Aug 17 17:15:15 linux named[30622]: command channel listening on 127.0.0.1#953

Aug 17 17:15:16 linux named[30622]: zone 0.0.127.in-addr.arpa/IN: loaded serial 3

Aug 17 17:15:16 linux named[30622]: zone 1.168.192.in-addr.arpa/IN: loaded serial

2004022602

Aug 17 17:15:16 linux named[30622]: zone localhost/IN: loaded serial 1

Aug 17 17:15:16 linux named[30622]: zone mi-dominio.com.mx/IN: loaded serial

2004022602

Aug 17 17:15:16 linux named[30622]: running

Aug 17 17:15:16 linux named[30622]: zone 1.168.192.in-addr.arpa/IN: sending notifies

(serial 2004022602)

Aug 17 17:15:16 linux named[30622]: zone mi-dominio.com.mx/IN: sending notifies

(serial 2004022602)


COMPROBACION DEL SERVICIO NAMED

Dig: consultando la configuracin dns

Dig es una herramienta (linea de comandos) disponible en

prcticamente cualquier distribucin linux (aunque tambin hay

alguna versin para windows) que te permite hacer consultas a un

servidor dns. Tras su instalacin, y antes de ejecutarlo, necesitars

editar resolv.conf y aadir el servidor dns (nameserver que recibir las

consultas.

Crea o modifica resolv.conf para utilizar el nuevo servidor de nombres

con los siguientes comandos:

Sustituye yourdomain.com con el nombre vlido de tu propio dominio,

y XX por el numero IP de tu servidor DNS local, de esta manera se

registra el servidor DNS principal del equipo.

mc e /etc/resolv.conf

search yourdomain.com

nameserver XX.XX.XX.XX



Comprobacin de BIND

Comprueba la nueva instalacin de BIND. Primero consulta la

direccin de la mquina local con dig (sustituyendo XX por el numero

IP de la maquina):

dig -x 127.0.0.1

dig -x XX.XX.XX.XX

Ahora prueba la bsqueda de un nombre externo, tomando nota de

la diferencia de velocidad en repetidas consultas debido al cach.

Lanza el comando dig dos veces sobre la misma direccin:

dig servidor.midominio.edu.bo &&

dig servidor.midominio.edu.bo

Vers que el resultado es casi instantneo cuando named consulta las

direcciones almacenadas. Para saber todas las opciones de

configuracin consulta el Manual de Referencia del Administrador de

BIND.



Opciones digdig tu_dominio.com +trace

Similar al tracert TCP/IP, pero para dns

dig tu_dominio.com. NS

Te indica los servidores dns de tu_dominio:

;; ANSWER SECTION:

ignside.net. 132119 IN NS ns2.nexen.net.

ignside.net. 132119 IN NS ns1.nexen.net.

El primer nmero (132119) indica el TTL (tiempo de vida en cache) de la consulta

dig tu_dominio.com. MX

Te indica los servidores de correo (Mail e[X]change) que gestionan los mails dirigidos

a [email protected]. Por ejemplo:

;; ANSWER SECTION:

ignside.net. 3600 IN MX 10 pouilly.nexen.net.

ignside.net. 3600 IN MX 20 champagne.nexen.net.

Estn listados por orden de precedencia, los nmeros mas bajos (10, 20) primero.



Opciones dig dig tu_dominio.com

devuelve la IP del dominio

dig midominio.com. @dns1.nrc.ca

consulta los datos dns en un servidor @especifico.

La mayora de los servidores DNS estn configurados para, si no

conocen la respuesta al query, encargarse ellos mismos de reformular

la pregunta a otro servidor distinto. Esto se llama configuracin

recurrente o amistosa (friendly, recursive).

dig -x numero_ip

DNS inverso



Descifrando las respuestas

Una orden como dig www.ignside.net genera el siguiente resultado:

shell>dig www.ignside.net;

DiG 9.4.0-(Hawk)-8.02 www.ignside.net

;; global options: printcmd

;; Got answer:

;; ->>HEADER




Veamos la respuesta linea por linea, teniendo en cuenta que aquellas que

comienzan con ; son comentarios introducidos por dig, no vienen del servidor

dns:

En las dos primeras lneas, dig se limita a informar de la versin del programa en

ejecucin y del dominio objeto de consulta. La lnea ;; global options: printcmdse refiere a las opciones generales usadas en la consulta. Puedes evitar estas

dos lineas utilizando la sintaxis de consulta dig +nocmd nombredominio.com

La siguiente seccin Got Answer nos ofrece detalles de la consulta recibida,

entre ellos, el nmero de respuestas recibidas, y si nos la ha dado o no una

"autoridad" en dns.

Las 'banderas' (flags) nos dan detalles de la consulta y respuesta: QR

(Query/Response) sirve para diferenciar la consulta de la respuesta. RD

(Recursion Desired), es una modalidad de la consulta, que es replicada en la

respuesta con la bandera RA (Recursion Allowed), y significa que pedimos al

server que si no puede resolver la respuesta por si mismo, consulte

recursivamente a otro server.




La aceptacin de la peticin por el server es opcional. AA significara

que la respuesta es de un server autorizado. Otras flags son: TC

(Truncated Response), que significa que la respuesta se ha

fraccionado por ser de mayor tamao del permitido, AD (Authentic

Data) y CD (Checking Disabled).

La tercera seccin nos da detalles de la consulta; adems como es

obvio del dominio consultado, nos informa que estamos consultando

en los registros A.

Como ya sabemos, si indicase MX en su lugar querria decir que

estamos consultando una direccin de email. IN indica que la

bsqueda se realiza en el mbito de internet.



Las consultas posibles que podemos hacer, comenzando por

las ya conocidas son:

dig midominio.com NS para los servidores dns (nombre)

dig midominio.com MX para los servidores de correo

dig midominio.com A para la ip del servidor que aloja al dominio

dig midominio.com ANY reune las anteriores

dig midominio.com AAAA nos indica el numero IP en ipv6 (si es que lo tiene,

claro):

dig www.ipv6.org AAAA +short

shake.stacken.kth.se.

2001:6b0:1:ea:202:a5ff:fecd:13a6

En el ejemplo que hemos puesto mas arriba, la respuesta tiene varias lineas. La

lnea www.ignside.net. 2886 IN CNAME irvnet.nexenservices.com. nos dice que

el dominio por el que preguntamos es un alias (CNAME) de

irvnet.nexenservices.com; La siguiente lnea nos indica que

irvnet.nexenservices.com es un alias de sauterne.nexen.net, y la tercera lnea

nos indica la IP de sauterne.nexen.net.



El porque tres respuestas ?

porque www no es mas que un subdominio de ignside.net y este

subdominio es un alias de irvnet.nexenservices.com (apunta a la

misma IP) que a su vez es un alias del dominio del ISP (nexen),

obteniendo finalmente la Ip de este.

El que ninguna de las respuestas que hemos obtenido sea AUTHORITY

no dice nada sobre la fiabilidad de la respuesta, simplemente que el

server que nos la ha dado no es responsable del dominio.

Finalmente podemos encontrarnos con una seccin de respuestas

adicionales, que tpicamente nos informara de las IPS de los

nameserves devueltos en la seccin AUTHORITY, si los hubiera.

La ltima seccin nos explica el tiempo que ha tardado en resolverse

la consulta, el nmero en bytes de la respuesta, la fecha y el servidor

dns consultado.



Acotando las respuestas:

dig admite varias opciones que modalizan la cantidad de informacin

obtenida. Todas las secciones de la respuesta pueden ser eliminadas con las

opciones +nocmd, +[no]comments, +[no]question, +[no]answer, +[no]authority,

+[no]additional y +[no]stats.

Existe una forma abreviada, que es la de excluir todo y indicar concretamente

lo que quieres: dig midominio.com A +noall +answer.

Otra opcin para limitar la informacin es short. Y si al contrario quieres mas

detalles de los standard, prueba +multiline

TTL

La respuesta dns incluye un valor TTL expresado en segundos: por ejemplo, en

esta linea, 2886 segundos: www.ignside.net. 2886 IN CNAME

irvnet.nexenservices.com.

TTL, o Time To Live, es el tiempo mximo durante el cual un server almacenar en su cache una respuesta obtenida de un server con "autoridad". Mientras

dure el TTL, el server en cuestin no volver a realizar consultas dns sobre ese

dominio, respondiendo con los datos guardados. Expirado el TTL, consultar de

nuevo a la autoridad en la materia ...




Zonas DNS

Hemos venido hablando de respuestas autorizadas o no. El servidor

DNS, al contestar las consultas, busca en primer lugar en los registros

dns de su zona local (aquellos de los que el server es responsable). Si

encuentra alli la respuesta, ser una respuesta autorizada. Si no la

encuentra, buscar en su cache de consultas anteriores. Si aqu se

encuentra una coincidencia, el servidor responde con esta

informacin. Esta respuesta ya no es autorizada. Finalmente si el

servidor est configurado para la bsqueda recursiva, consultar -en

nuestro nombre- a otro server dns.

Por ello el concepto de autoridad, en dns, es similar al de

administracin: la respuesta es autorizada si el dominio est en una

zona administrada por ese server. La respuesta tambin es autorizada

si nuestro server dns no tiene la respuesta en cache y hace una

consulta recursiva. A partir de ese momento, y mientras conserve la

respuesta en cache, no sera respuesta autorizada.




PTR

Pointer Record. Tambien llamado reverse record (registro inverso).

Un registro PTR asocia una direccin IP con su nombre de dominio real, debiendo apuntar a un nombre de dominio que se resuelva a esa IP. La IP se indica invirtiendo sus cuatro grupos de nmeros y aadiendo IN-ADDR.ARPA.

SOA record

SOA son las iniciales de Start Of Authority. Un Registro SOA identifica la mejor fuente de informacin sobre un dominio dado, y solo puede haber un registro por dominio. La informacin que obtenemos con dig midominio.com SOA incluye:

Hostname.Domain.Name, que es el nombre del servidor primario para este dominio (donde reside la respuesta autorizada): por ejemplo, en el caso de google.com, es ns1.google.com..

Mailbox.Domain.Name es (tericamente) el correo del responsable del DNS de este dominio; en el mismo ejemplo de google.com, dns-admin.google (sustituye el primer punto por @ para formar el email).




serno se refiere el numero de serie, que identifica cuando ha habido una actualizacin de la base de datos: por ejemplo numeros de serie vlidos serian 1, 2, 3 etc .... Tpicamente se usa como serial number la fecha inversa de la ultima actualizacin (ao-mes-dia). Por ejemplo, 2005072601

Refresh indica al servidor secundario cada cuanto tiempo debe consultar al primario sobre actualizaciones

Retry indica el lapso que debe respetar el servidor secundario para tratar de reconectar con el primario, en el momento de Refresh

Expire es el numero de segundos durante los cuales el servidor secundario mantiene los datos, si no puede conectar con el primario

TTL es el tiempo de vida que los datos deben conservarse en cache al ser solicitados.



Ejemplo de Dig en www.ucbcba.edu.bo[root@hades ~]# dig www.ucbcba.edu.bo;

DiG 9.2.5 www.ucbcba.edu.bo

;; global options: printcmd

;; Got answer:

;; ->>HEADER



Usando NSLOOKUP

Se puede usar "nslookup" para verificar el funcionamiento del DNS.

shell> nslookup

Note: nslookup is deprecated and may be removed from future releases.

Consider using the `dig' or `host' programs instead.

Run nslookup with

the `-sil[ent]' option to prevent this message from appearing.

> centauro.labos.ucbcba.edu.bo

Server: 192.168.3.100

Address: 192.168.3.100#53

Non-authoritative answer:

Name: inge36.labos.ucbcba.edu.bo

Address: 192.168.3.136

Se puede consultar diferentes servidores DNS editando el archivo

resolve.conf.



Usando NSLOOKUP

nslookup es una estupenda utilidad para comprobar el funcionamiento de un

servidor de nombres. Se puede usar interactivamente o pasndole la pregunta

por la lnea de rdenes. En este ltimo caso podemos invocar la orden as:

shell> nslookup nombre-de-host

nslookup enva sus peticiones al servidor citado en resolv.conf. Si este fichero

tiene ms de un servidor, nslookup eligir uno al azar.

El modo interactivo es mucho ms interesante. No slo sirve para buscar la IP

de un nodo, sino que tambin podemos interrogar acerca de cualquier tipo de

registro DNS y transferirnos toda la informacin de una zona si queremos.

Si se invoca sin argumentos, nslookup muestra el nombre del servidor elegido y

entra en modo interactivo. En el prompt > podemos escribir cualquier nombre

de dominio. Al principio preguntar slo por registros A, es decir, obtencin de

la IP asociada.

Podemos elegir un tipo de registro diferente con la orden:

set type=tipo

donde tipo es uno de los tipos de RR descritos antes, o ANY.



Usando NSLOOKUP

Veamos una posible sesin de nslookup:

shell> nslookup

Default Server: tao.linux.org.au

Address: 203.41.101.121

> metalab.unc.edu

Server: tao.linux.org.au

Address: 203.41.101.121

Name: metalab.unc.edu

Address: 152.2.254.81

>

La salida muestra el servidor DNS interrogado y el resultado obtenido.



Si preguntamos por algo que no tiene IP asociada pero s otros registros de otra clase, el programa nos devolver una advertencia del tipo No type A records found. Sin embargo, podemos usar el citado comando set type para buscar registros de otras clases. Por ejemplo, el registro SOA de un dominio puede ser pedido as:

> unc.edu Server: tao.linux.org.au

Address: 203.41.101.121

*** No address (A) records available for unc.edu

> set type=SOA

> unc.edu


Address: 203.41.101.121

unc.edu

origin = ns.unc.edu

mail addr = host-reg.ns.unc.edu

serial = 1998111011

refresh = 14400 (4H)

retry = 3600 (1H)

expire = 1209600 (2W)

minimum ttl = 86400 (1D)



unc.edu name server = ns2.unc.edu

unc.edu name server = ncnoc.ncren.net

unc.edu name server = ns.unc.edu

ns2.unc.edu internet address = 152.2.253.100

ncnoc.ncren.net internet address = 192.101.21.1


ns.unc.edu internet address = 152.2.21.1



De manera parecida, para preguntar por registros MX haremos: > set type=MX

> unc.edu


Address: 203.41.101.121

unc.edu preference = 0, mail exchanger = conga.oit.unc.edu

unc.edu preference = 10, mail exchanger = imsety.oit.unc.edu

unc.edu name server = ns.unc.edu

unc.edu name server = ns2.unc.edu

unc.edu name server = ncnoc.ncren.net

conga.oit.unc.edu internet address = 152.2.22.21

imsety.oit.unc.edu internet address = 152.2.21.99

ns.unc.edu internet address = 152.2.21.1

ns2.unc.edu internet address = 152.2.253.100



Con el tipo ANY obtendremos todos los registros existentes asociados al nombre

dado.

Para ver el conjunto completo de comandos, podemos usar help dentro de

nslookup.

d3 Admin DNS

Documents

Transcript of d3 Admin DNS