ADMISTRACION DE SERVIDORES LUX ENTERPRISE SERVIDOR DE RESOLUCION DE NOMBRES DNS - BD Dictado por: Ing. Carlos Alcalá Helguero Consultas: alcalaucbcba.edu.bo TOPICOS CLASE 3: SERVIDOR DE RESOLUCION DE NOMBRES DNS Introducción n a DNS-BD Instalación n de paquetes necesarios. Configuración n inicial del servicio. Creación n de las zonas del dominio: named.conf Creación n de los archivos de resolución n de nombres por zona. Configuración n de Mail y VirtualHost Comprobación n del servicio DNS y servicio de red local. Solución n de problemas frecuentes. Introducción BD (acrónimo de Berkeley Internet Name Domain) ) es una implementación n del protocolo DNS (Domain( Name System) ) y provee una implementación n libre de los principales componentes del Sistema de Nombres de Dominio, los cuales c incluyen: Un servidor de sistema de nombres de dominio (named( named). Una biblioteca resolutoria de sistema de nombres de dominio. Herramientas para verificar la operación n adecuada del servidor DNS (bind( bind-utils). El servidor DNS BD es ampliamente utilizado en la Internet (99% % de los servidores DNS) proporcionando una robusta y estable solución. TRODUCCION A DNS BD Introducción El Domain Name System (DNS) es una base de datos distribuida y jerárquica rquica que almacena información n asociada a nombres de dominio en redes como Internet.. Aunque como base de datos el DNS es capaz de asociar distintos tipos de información n a cada nombre, los usos más m s comunes son la asignación n de nombres de dominio a direcciones IP y la localización n de los servidores de correo electrónico de cada dominio. La asignación n de nombres a direcciones IP es ciertamente la función n más m s conocida de los protocolos DNS. Por ejemplo, si la dirección n IP del sitio WWW de ucbcba.edu.bo es 166.114.106.105,, la mayoría a de la gente llega a este equipo especificando www.ucbcba.edu.bo y no la dirección n IP. Además s de ser más m s fácil f de recordar, el nombre es más m s fiable. La dirección n numérica podría a cambiar por muchas razones, sin que tenga que cambiar el nombre. Inicialmente, el DNS nació de la necesidad de recordar fácilmente f los nombres de todos los servidores conectados a Internet. En un inicio, SRI (ahora SRI International) ) alojaba un archivo llamado HOSTS.TXT que contenía a todos los nombres de dominio conocidos (técnicamente, este archivo aún a n existe - la mayoría a de los sistemas operativos actuales todavía a pueden ser configurados para revisar su archivo hosts). 1
Cómo funciona el DNS El DNS organiza los nombres de máquina m (hostname( hostname) ) en una jerarquía a de dominios. Un dominio es una colección n de nodos relacionados de alguna forma porque estén n 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 Matemáticas ticas (maths( 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 también n se conoce por las siglas FQDN. En Figura vemos una parte del espacio de nombres. La raíz z del árbol, que se identifica con un punto sencillo, es lo que se denomina dominio raíz y es el origen de todos los dominios. Para indicar que un nombre es FQDN, a veces es se termina su escritura en un punto. Este punto significa que el último componente del nombre es el dominio raíz. 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 jerárquicos rquicos y descriptivos para localizar fácilmente f ordenadores (hosts( hosts) ) y otros recursos en dicha red, evitando de esta manera tener que q recordar la dirección n IP de cada ordenador al que se desea acceder. En esencia, DNS es una base de datos distribuida que contiene asociaciones de nombres simbólicos (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, nes, pero siempre de forma que los datos de cada segmento están n disponibles en toda la red, a través s 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 información n sobre algunos segmentos de la base de datos y los ponen a disposici osición n 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 jerárquica rquica del árbol es similar a la estructura del sistema de ficheros LUX. El árbol tiene una única raíz z en el nivel superior llamada raíz z (root( root). Cada nodo del árbol puede ramificarse en cualquier número n 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 ner hasta 63 caracteres, excepto el nodo raíz, 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 raíz, separando cada etiqueta de la siguiente mediante un punto. De esta forma, el nombre del nodo especifica de forma unívoca su localización n en la jerarquía. a. 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 raíz, el FQDN de cualquier nodo del árbol siempre acaba con un punto. La única restricción n que se impone en el árbol de nombres es que los nodos hijos del mismo padre tengan etiquetas diferentes. 2
Arbol jerarquico DNS Relacion DNS vs Linux/Unix Dependiendiendo de su localización n en la jerarquía, a, un dominio puede ser de primer nivel (top( top-level), segundo nivel o tercer nivel. Se pueden añadir a adir todos los niveles que queramos, pero no son habituales. Los que siguen son los dominios s de primer nivel que veremos con frecuencia: Inicialmente los cuatro primeros dominios de la lista anterior pertenecp ertenecían solo a los Estados Unidos, sin embargo, los cambios de política posteriores han hecho que estos dominios, llamados de dominios globales primer nivel (gtld( gtld) ) sean realmente globales. Además s se están n negociando nuevos dominios de primer nivel. Fuera de los Estados Unidos, cada país s suele tener su propio dominio de primer nivel codificado con las dos letras del país s definidas en la tabla ISO-3166. Finlandia, por ejemplo, usa el dominio fi; ; en España a se usa el dominio es; en México M se usa mx; ; en Bolivia, bo,, etc. Por debajo de cada dominio de primer nivel, cada país s 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 países, como España, a, ponen directamente como nombres de segundo nivel las instituciones o empresas e que los solicitan. Por ejemplo, tenemos hispalinux.es. Tipos de servidores de nombres Los servidores de nombres que mantienen oficialmente la información n de una zona se conocen como autorizados de la zona, y a veces se conocen como servidores principales o maestros.. Cualquier petición n de nodos de esa zona irá a parar a uno de estos servidores principales. Los servidores principales deben estar bien sincronizados. izados. Es decir, uno de ellos será llamado primario,, que carga su información n de un fichero, y hacer a los demás secundarios,, que obtienen su información n pidiéndosela periódicamente 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 acabarán n en los demás. Por supuesto, este esquema no nos protege de fallos del servidor que produzcan errores en todas las peticiones DNS, como podrían ser errores del software. También n podemos instalar un servidor de nombres que no es maestro de ninguna n zona. Esto es útil, para dar servicio de nombres a una red local aprovechando sus s características de ahorro de ancho de banda gracias a su caché.. Estos servidores se conocen como de sólo-caché. 3
La base de datos DNS Hemos visto que el DNS no sólo s sabe de direcciones IP de máquinas, m pero también almacena otras informaciones. Cada unidad de información n 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 dirección, como direcciones IP (la clase ), direcciones Hesiod (utilizadas por el sistema Kerberos del MIT) y algunas más. m El RR típico t es el registro A, que asocia un nombre completamente cualificado con una dirección n IP. Un nodo puede ser conocido por más m s 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 canónico nico.. La diferencia es que el canónico nico es el único registro A que debe existir apuntando a esa dirección n IP, mientras que el resto de los nombres deben ser alias (registros CNAME), que apuntan al nombre canónico. nico. Registros de Recursos (RR) Para resolver nombres, los servidores consultan sus zonas. Las zonas z contienen registros de recursos que constituyen la información n 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 símbolo s "" (que representa el nombre de la zona que se está describiendo) o una cadena vacía a (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. También n se puede expresar mediante letras indicando días d (d), horas (h), minutos (m) y segundos (s). Por ejemplo: "2h30m". Clase: define la familia de protocolos en uso. Suele ser siempre "", que representa Internet. Tipo: identifica el tipo de registro. RDATA: los datos del registro de recursos. 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 (sólo se incluyen los que poseen un significado específico para el tipo de registro): Propietario: nombre de dominio de la zona. Tipo: "SOA". Persona responsable: : contiene la dirección n de correo electrónico del responsable de la zona. En esta dirección n de correo, se utiliza un punto en el lugar del símbolo s "". Número de serie: : muestra el número n de versión n de la zona, es decir, un número n que sirve de referencia a los servidores secundarios de la zona para saber cuándo deben proceder a una actualización n de su base de datos de la zona (o transferencia de zona). Cuando el número n de serie del servidor secundario sea menor que el número n 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 número debe ser incrementado (manualmente) por el administrador de la zona cada vez que realiza un cambio en algún n registro de la zona (en el servidor maestro). Actualización: : muestra cada cuánto tiempo un servidor secundario debe ponerse en contacto con el maestro para comprobar si ha habido cambios en la zona. Registro de Recurso SOA Reintentos: : define el tiempo que el servidor secundario, después s 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, después s de la transferencia de zona anterior, responderá a las consultas de la zona antes de descartar la suya propia como no válida. v TTL mínimo nimo: : 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 sería a el siguiente: admon.com. pc0100.admon.com hostmaster.admon.com. ( 1 ; número n de serie 3600 ; actualización n 1 hora 600 ; reintentar 10 minutos 86400 ; caducar 1 día d 60 ; TTL 1 minuto ) 4
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 mínimo, m un registro NS. Por otra parte, estos registros también n se utilizan para indicar quiénes 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 serían los siguientes: admon.com. valencia.admon.com. NS pc0100.admon.com admon.com. NS pc0102.valencia.admon.com valencia.admon.com. Registro de Recurso A El tipo de registro de recursos A (Address( Address) ) asigna un nombre de dominio completamente cualificado (FQDN) a una dirección n IP, para que los clientes puedan solicitar la dirección IP de un nombre de host dado. Un ejemplo de registro A que asignaría a la dirección n IP 158.42.178.1 al nombre de dominio pc0101.valencia.admon.com valencia.admon.com.,., sería a el siguiente: pc0101.valencia.admon.com valencia.admon.com. A 158.42.178.1 Registro de Recurso El registro de recursos (PoinTeR( PoinTeR) ) o puntero, realiza la acción n contraria al registro de tipo A, es decir, asigna un nombre de dominio completamente cualificado a una dirección n IP. Este tipo de recursos se utilizan en la denominada resolución n inversa,, descrita en Servidores de nombres y zonas. Un ejemplo de registro que asignaría a el nombre pc0101.valencia.admon.com valencia.admon.com.. a la dirección n IP 158.42.178.1 sería a el siguiente: 1.178.42.158.in-addr.arpa addr.arpa. pc0101.admon.valencia.com admon.valencia.com. Registro de Recurso CNAME El registro de nombre canónico nico (CNAME, Canonical NAME) ) crea un alias (un sinónimo) nimo) para el nombre de dominio especificado. Un ejemplo de registro CNAME que asignaría a el alias controlador al nombre de dominio pc0102.valencia.admon.com valencia.admon.com,, sería a el siguiente: controlador.valencia.admon.com.. CNAME pc0101.valencia.admon.com 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 numérico 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 00 como el servidor de correo del dominio admon.com,, sería a el siguiente: admon.com. MX 0 pc0100.admon.com admon.com. Registro de Recurso HFO Este registro da información n sobre el hardware y el software de la máquina. m Su sintaxis es: [domain]] [ttl[ ttl] ] [class[ class] ] HFO 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 también n está normalizado. Por ejemplo, un registro HFO para describir un sistema Intel ejecutando e Linux podría a ser: tao 36500 HFO IBM-PC LUX2.2 y para el caso de que se tratara de un sistema basado en DELL: orion 36500 HFO DELL POWEREDGE2500 LUX CENTOS ENTERPRISE 4.2 5
Software Requerido. bind bind-chroot bind-utils caching-nameserver nameserver La instalación n puede hacerse a través s de yum para satisfacer todas las dependencias necesarias. yum -y y install bind bind-chroot bind-utils caching-nameserver nameserver 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 utilizarán n para efectos de redundancia. Éstos deben ser nombres que ya estén n 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( www,, mail, ftp, ns,, etc.) y las direcciones IP que estarán n 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 o que se pretende resolver. De igual modo, el servidor donde se implementará el servicio de DNS deberá contar con un nombre previa y plenamente resuelto. Preparativos. Como regla general se generará una zona de reenvío o por cada dominio sobre el cual se tenga autoridad plena y absoluta y se generará una zona de resolución n 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 resolución n inversa a fin de resolver inversamente las direcciones IP de dicha zona. Regularmente la resolucir esolución n inversa de las direcciones IP públicas p 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 e de zonas esclavas. Creación n de los ficheros de zona. Los siguientes corresponderían 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 reenvío o siempre se especifica al menos un Mail Exchanger (MX) y que se utilizan tabuladores (tecla TAB) en lugar de espacio. Solo o necesitará sustituir nombres y direcciones IP, y quizá añadir adir nuevas entradas para complementar su red local. 6
Zona de reenvío o red local /var/named/chroot/var/named named/mi-red-local.edu.bo.zone $TTL 86400 SOA intranet maquina2 maquina3 maquina4 www mail ftp dns mi-red red-local.edu.bo. jperez.mi-red red-local.edu.bo.. ( 8 ; serial 28800 ; refresh 7200 ; retry 604800 ; expire 86400 ; ttl ) NS dns MX 10 mail A 192.168.1.1 A 192.168.1.1 A 192.168.1.2 A 192.168.1.3 A 192.168.1.4 CNAME intranet A 192.168.1.1 CNAME intranet CNAME intranet Zona de resolución n inversa red local /var/named/chroot/var var/named/1.168.192.in-addr.arpa.zone $TTL 86400 SOA mi-red red-local.edu.bo. jperez.mi-red red-local.edu.bo.. ( 2005030401 ; serial 28800 ; refresh 7200 ; retry 604800 ; expire 86400 ; ttl ) NS dns.mi-red red-local.edu.bo. 1 intranet.mi-red red-local.edu.bo. 2 maquina2.mi-red red-local.edu.bo. 3 maquina3.mi-red red-local.edu.bo. 4 maquina4.mi-red red-local.edu.bo. Zona de reenvío o del dominio /var/named/chroot chroot/var/named/mi /mi-dominio.edu.bo.zone $TTL 86400 SOA nombre-plenamente plenamente-resuelto. jperez.cuenta.existente.. ( 8 ; serial 28800 ; refresh 7200 ; retry 604800 ; expire 86400 ; ttl ) NS dns MX 10 mail A 148.243.59.1 servidor A 148.243.59.1 www CNAME servidor mail A 148.243.59.1 ftp CNAME servidor dns CNAME servidor Zona de resolución n inversa del dominio /var/named/chroot/var var/named/1.243.148.in-addr.arpa.zone $TTL 86400 SOA nombre-plenamente plenamente-resuelto resuelto. jperez.cuenta.existente.. ( 2005030401 ; serial 28800 ; refresh 7200 ; retry 604800 ; expire 86400 ; ttl ) NS dns.mi-dominio.edu.bo dominio.edu.bo. 1 servidor.mi-dominio.edu.bo dominio.edu.bo. 2 maquina2.mi-dominio.edu.bo. 3 maquina3.mi-dominio.edu.bo. 4 maquina4.mi-dominio.edu.bo. Recuerde que cada vez que haga algún n cambio en algún n fichero de zona, deberá cambiar el número n de serie (serial) a fin de que tomen efecto los cambios de inmediato cuando se reinicie el daemon named,, ya que de otro modo tendría a que reiniciar el equipo, algo poco conveniente. 7
Fichero de Configuración n de Zonas de resolución /var/named/chroot/etc etc/named.conf options { directory "/var var/named/"; forwarders { 200.33.146.209; 200.33.146.217; forward first; zone "." { type hint; file "named.ca" named.ca"; zone "0.0.127.in-addr.arpa" { file "0.0.127.in-addr.arpa.zone"; allow-update { none; zone "localhost" localhost" " { file "localhost.zone" localhost.zone"; allow-update { none; Fichero de Configuración n de Zonas de resolución /var/named/chroot/etc etc/named.conf zone "mi-dominio.edu.bo dominio.edu.bo" " { file "mi-dominio.edu.bo.zone dominio.edu.bo.zone"; allow-update { none; zone "1.243.148.in-addr.arpa" { file "1.243.148.in-addr.arpa.zone"; allow-update { none; zone "mi-red red-local.edu.bo" " { file "mi-red red-local.edu.bo.zone"; allow-update { none; zone "1.168.192.in-addr.arpa" { file "1.168.192.in-addr.arpa.zone"; allow-update { none; 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 parámetro allow-query query,, el cual servirá para especificar que solo ciertas direcciones podrán realizar consultas al servidor de nombres de dominio. Se pueden especificar directamente direcciones IP, redes completas o listas de control de acceso que e deberán n definirse antes de cualquier otra cosa en /var/named/chroot/etc etc/named.conf: Seguridad adicional en DNS para uso exclusivo en red local. zone "1.168.192.in-addr.arpa addr.arpa" " { file "1.168.192.in-addr.arpa.zone addr.arpa.zone"; allow-update { none; ; acl "redlocal"" { 192.168.1.0/24; 192.168.2.0/24; 192.168.3.0/24; } options { directory "/var 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 red-local.edu.bo" " { file "mi-red red-local.edu.bo.zone"; allow-update { none; ; 8
SERVICIO NAMED Reinicialización y depuración n del servicio. Al terminar de editar todos los ficheros involucrados, solo bastar ará reiniciar el servidor de nombres de dominio. /sbin/serviceservice named restart También n 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 añadido a adido 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 depuración n y verifique que la zona haya cargado con número n de serie: tail -50 /var/ var/log/messages grep named SERVICIO NAMED Reinicialización y depuración n del servicio. Lo anterior, si está funcionando correctamente, debería a devolver algo parecido a lo mostrado a continuación: n: Aug 17 17:15:15 linux named[30618]: starting BD 9.2.2 -u u named Aug 17 17:15:15 linux named[30618]: using 1 CPU Aug 17 17:15:15 linux named: Iniciación de named succeeded Aug 17 17:15:15 linux named[30622]: loading configuration from '/etc/named.conf 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/: loaded serial 3 Aug 17 17:15:16 linux named[30622]: zone 1.168.192.in-addr.arpa/: loaded serial 2004022602 Aug 17 17:15:16 linux named[30622]: zone localhost/: loaded serial 1 Aug 17 17:15:16 linux named[30622]: zone mi-dominio.com.mx dominio.com.mx/: 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/: sending notifies (serial 2004022602) Aug 17 17:15:16 linux named[30622]: zone mi-dominio.com.mx dominio.com.mx/: sending notifies (serial 2004022602) Dig: : consultando la configuración dns Dig es una herramienta (linea( de comandos) disponible en prácticamente cualquier distribución linux (aunque también n hay alguna versión n para windows) ) que te permite hacer consultas a un servidor dns.. Tras su instalación, n, y antes de ejecutarlo, necesitarás editar resolv.conf y añadir a adir 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 válido v 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 e /etc/ etc/resolv.conf search yourdomain.com nameserver XX.XX.XX.XX Comprobación n de BD Comprueba la nueva instalación n de BD. Primero consulta la dirección n de la máquina m local con dig (sustituyendo XX por el numero IP de la maquina): dig -x x 127.0.0.1 dig -x XX.XX.XX.XX Ahora prueba la búsqueda b 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 dirección: dig servidor.midominio.edu.bo && dig servidor.midominio.edu.bo Verás s que el resultado es casi instantáneo neo cuando named consulta las direcciones almacenadas. Para saber todas las opciones de configuración n consulta el Manual de Referencia del Administrador de BD. 9
Opciones dig dig 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 NS ns2.nexen.net nexen.net. ignside.net.. 132119 NS ns1.nexen.net. El primer número n (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 loqueseatudominio.com.. Por ejemplo: ;; ANSWER SECTION: ignside.net.. 3600 MX 10 pouilly.nexen.net. ignside.net.. 3600 MX 20 champagne.nexen.net. Están n listados por orden de precedencia, los números n mas bajos (10, 20) primero. Opciones dig dig tu_dominio.com devuelve la IP del dominio dig midominio.com. dns1.nrc.ca nrc.ca consulta los datos dns en un servidor especifico. La mayoría a de los servidores DNS están n configurados para, si no conocen la respuesta al query,, encargarse ellos mismos de reformular la pregunta a otro servidor distinto. Esto se llama configuración n recurrente o amistosa (friendly( 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) (Hawk)-8.02 <<>> www.ignside.net ;; global options: printcmd ;; Got answer: ;; ->>HEADER<< >>HEADER<<- opcode: : QUERY, status: NOERROR, id: 1580 ;; flags: qr rd ra; ; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.ignside.net.. A ;; ANSWER SECTION: www.ignside.net.. 2886 CNAME irvnet.nexenservices.com. irvnet.nexenservices.com.. 6486 CNAME sauterne.nexen.net. sauterne.nexen.net.. 486 A 217.174.203.10 ;; Query time: 15 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Jul 28 22:33:36 2005 ;; MSG SIZE rcvd: : 116 Descifrando las respuestas 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 líneas, l dig se limita a informar de la versión n del programa en ejecución n y del dominio objeto de consulta. La línea l ;; global options: printcmd se refiere a las opciones generales usadas en la consulta. Puedes evitar e estas dos lineas utilizando la sintaxis de consulta dig +nocmd nombredominio.com La siguiente sección Got Answer nos ofrece detalles de la consulta recibida, entre ellos, el número n de respuestas recibidas, y si nos la ha dado o no una "autoridad" en dns. Las 'banderas' (flags( flags) ) nos dan detalles de la consulta y respuesta: QR (Query( 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. 10
Descifrando las respuestas La aceptación n de la petición n por el server es opcional. AA significaría a 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 tamaño o del permitido, AD (Authentic( Data) y CD (Checking( Disabled). La tercera sección n nos da detalles de la consulta; además s 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 dirección n de email.. indica que la búsqueda b 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 ea:202:a5ff: :202:a5ff:fecd:13a6 En el ejemplo que hemos puesto mas arriba, la respuesta tiene varias lineas.. La línea l www.ignside.net.. 2886 CNAME irvnet.nexenservices.com.. nos dice que el dominio por el que preguntamos es un alias (CNAME) de irvnet.nexenservices.com; ; La siguiente línea nos indica que irvnet.nexenservices.com es un alias de sauterne.nexen.net,, y la tercera línea l 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( nexen), obteniendo finalmente la Ip de este. El que ninguna de las respuestas que hemos obtenido sea AUTHORITY Y 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 sección n de respuestas adicionales, que típicamente nos informaría a de las IPS de los nameserves devueltos en la sección AUTHORITY, si los hubiera. La última sección n nos explica el tiempo que ha tardado en resolverse la consulta,, el número en bytes de la respuesta, la fecha y el servidor dns consultado. Acotando las respuestas: dig admite varias opciones que modalizan la cantidad de información n obtenida. Todas las secciones de la respuesta pueden ser eliminadas con las opciones +nocmd, +[no]comments no]comments,, +[no]question no]question,, +[no]answer no]answer,, +[no]authority no]authority,, +[no]additional y +[no]stats 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 opción n para limitar la información n 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 CNAME irvnet.nexenservices.com. TTL, o Time To Live,, es el tiempo máximo m durante el cual un server almacenará en su cache una respuesta obtenida de un server con "autoridad". Mientras dure el TTL, el server en cuestión n 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... 11
Acotando las respuestas: Zonas DNS Hemos venido hablando de respuestas autorizadas o no. El servidor r 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 información. n. Esta respuesta ya no es autorizada. Finalmente si el servidor está configurado para la búsqueda b recursiva, consultará -en nuestro nombre- a otro server dns. Por ello el concepto de autoridad, en dns,, es similar al de administración: n: la respuesta es autorizada si el dominio está en una zona administrada por ese server.. La respuesta también n 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. Acotando las respuestas: Pointer Record. Tambien llamado reverse record (registro inverso). Un registro asocia una dirección n 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 i sus cuatro grupos de números n y añadiendo a adiendo -ADDR.ARPA ADDR.ARPA. SOA record SOA son las iniciales de Start Of Authority.. Un Registro SOA identifica la mejor fuente de información n sobre un dominio dado, y solo puede haber un registro por dominio. La información n 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 google.com.... Mailbox.Domain.Name es (teóricamente) 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). Acotando las respuestas: serno se refiere el numero de serie, que identifica cuando ha habido una actualización n de la base de datos: por ejemplo numeros de serie válidos v serian 1, 2, 3 etc... Típicamente T se usa como serial number la fecha inversa de la ultima actualización n (año-mes 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 t de reconectar con el primario, en el momento de Refresh Expire es el numero de segundos durante los cuales el servidor secundario s 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 [roothades ~]# dig www.ucbcba.edu.bo; <<>> DiG 9.2.5 <<>> www.ucbcba.edu.bo ;; global options: printcmd ;; Got answer: ;; ->>HEADER<< >>HEADER<<- opcode: : QUERY, status: NOERROR, id: 15068 ;; flags: qr rd ra; ; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.ucbcba.edu.bo www.ucbcba.edu.bo.. A ;; ANSWER SECTION: www.ucbcba.edu.bo.. 86400 CNAME ucbsun2.ucbcba.edu.bo. ucbsun2.ucbcba.edu.bo. 79248 A 166.114.106.21 ;; AUTHORITY SECTION: ucbcba.edu.bo.. 17600 NS ucbns2.ucbcba.edu.bo. ucbcba.edu.bo.. 17600 NS ucbsun1.ucbcba.edu.bo. ;; Query time: 722 msec ;; SERVER: 192.168.3.100#53(192.168.3.100) ;; WHEN: Mon Mar 6 11:09:39 2006 ;; MSG SIZE rcvd: 116 12
Usando NSLOOKUP Se puede usar "nslookup" nslookup" " para verificar el funcionamiento del DNS. shell> nslookup Note: nslookup is deprecated and may be removed from future releases. Consider using the `dig&apos` dig' ; or `host&apos` host' ; programs instead. Run nslookup with the `-sil[ent]&apos` 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 pasándole la pregunta por la línea l de órdenes. En este último caso podemos invocar la orden así: shell> nslookup nombre-de de-host nslookup envía a sus peticiones al servidor citado en resolv.conf.. Si este fichero tiene más m de un servidor, nslookup eligirá uno al azar. El modo interactivo es mucho más m s interesante. No sólo s sirve para buscar la IP de un nodo, sino que también n podemos interrogar acerca de cualquier tipo de registro DNS y transferirnos toda la información n 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á sólo por registros A, es decir, obtención n de la IP asociada. Podemos elegir un tipo de registro diferente con la orden: set type=tipo tipo donde tipo es uno de los tipos de RR descritos antes, o ANY. Usando NSLOOKUP Veamos una posible sesión n 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í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 Server: tao.linux.org.au 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) 13
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 ncnoc.ncren.net internet address = 128.109.193.1 ns.unc.edu internet address = 152.2.21.1 De manera parecida, para preguntar por registros MX haremos: > set type=mx > unc.edu Server: tao.linux.org.au 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 ncnoc.ncren.net internet address = 192.101.21.1 ncnoc.ncren.net internet address = 128.109.193.1 Con el tipo ANY obtendremos todos los registros existentes asociados ados al nombre dado. Para ver el conjunto completo de comandos, podemos usar help dentro de nslookup. 14