| Guía de Administración de Redes con Linux | ||
|---|---|---|
| Anterior | Capítulo 6. El servicio de nombres y su configuración | Siguiente |
named (pronúnciese n'eim-di:) es el servidor DNS en casi todas las máquinas Unix. Es un programa desarrollado originalmente para BSD. La versión 4 se ha usado mucho tiempo y venía con cualquier distribución GNU/Linux. La nueva edición, la versión 8, se ha introducido después y supone grandes cambios desde la anterior.[1] Tiene muchas características nuevas, como el soporte de actualización dinámica del DNS, notificaciones de cambios, mejoras importantes de rendimiento y una nueva sintaxis de fichero de configuración. Para más detalle debemos comprobar la documentación que viene con el código fuente.
Esta sección requiere ideas acerca de cómo funciona el Sistema de Nombres y Dominios (DNS). Si lo que sigue a continuación le suena a chino, puede releer el capítulo Sección 6.2, que le dará información acerca de cómo funciona básicamente el DNS.
named suele iniciarse al arrancar la máquina, y ejecutarse hasta que se apaga. Las versiones anteriores de BIND hasta la 8 obtienen la información que necesitan de un fichero llamado /etc/named.boot. Las nuevas versiones usan el fichero /etc/named.conf. Además, hay que configurar los ficheros de zona.
Para ejecutar named, sólo tiene que teclear:
# /usr/sbin/named |
El programa named se iniciará y leerá el fichero named.boot y los ficheros de zona que se especifiquen en él. Su número de proceso será anotado en ASCII en el fichero /var/run/named.pid, recibirá ficheros de zona de los servidores principales si es necesario y comenzará a escuchar las peticiones de DNS por el puerto 53.
El fichero de configuración para los BIND anteriores a la 8 tenían una estructura muy simple. En la versión 8 el fichero se llama /etc/named.conf y es totalmente distinto. Nos pararemos en ambas versiones y veremos las diferencias, y cómo convertir del formato antiguo al nuevo.
El fichero named.boot suele ser muy pequeño y contiene punteros a ficheros con información de zonas y a otros servidores de nombres. Los comentarios en este fichero comienzan con un punto y coma y se extienden hasta el siguiente fin de línea. Antes de que veamos con más detalle el formato de este fichero, observaremos el ejemplo para la máquina vlager dado en Ejemplo 6-8.
Ejemplo 6-8. Fichero named.boot para vlager
;
; Fichero /etc/named.boot para vlager.vbrew.com
;
directory /var/named
;
; domain file
;-----------------
caché . named.ca
primary vbrew.com named.hosts
primary 0.0.127.in-addr.arpa named.local
primary 16.172.in-addr.arpa named.rev |
Veamos cómo es el fichero. La palabra directory indica a named el directorio donde están los demás ficheros de configuración (los ficheros de zona).
Los comandos caché y primary sirven para cargar información en \prog{named}. Esta información se obtiene de los ficheros espeficados en el segundo argumento. Contienen representaciones textuales de los registros DNS, que veremos a continuación.
En este ejemplo, se configura named como el servidor de nombres principal para tres dominios: los que se indican con la orden primary. La primera línea dice que named actúe como servidor principal para vbrew.com, tomando la información de zona del fichero named.hosts.
La entrada iniciada con la palabra caché es muy especial y debe estar presente en casi todas las máquinas que ejecuten un servidor de nombres. Su función es doble: indica a named que active su caché, y también que cargue la información de los servidores raíz del fichero indicado (en este caso, named.ca). Regresaremos a este concepto más tarde.
A continuación se presenta una lista de las opciones más importantes que podemos poner en el fichero named.boot :
Especifica un directorio donde estén los ficheros de zona. Pueden ponerse varios directorios repitiendo el comando directory. De acuerdo con el estándar de sistema de ficheros para Linux, el directorio debería ser /var/named.
Los argumentos que lleva son un nombre de dominio y un nombre de fichero, declarando el servidor local primario para el dominio de named. Como servidor primario, named carga la información de zona del fichero dado.
Normalmente, siempre habrá por lo menos una orden primary en cada fichero named.boot, para traducción inversa del IP 127.0.0.1, que es el interfaz de bucle o «loopback», como ya sabemos.
Esta sentencia tiene como parámetros un nombre de dominio, una lista de direcciones y un nombre de fichero. Declara el servidor local como servidor maestro secundario para el dominio indicado.
Un servidor secundario mantiene también información «autorizada» como el primario, pero en lugar de obtenerla de un fichero, la intenta obtener de un servidor primario. Debe proporcionarse al menos una dirección IP de servidor primario en la lista de direcciones. El servidor local irá contactando con cada uno de ellos hasta que transfiera con éxito la base datos de zona, que será almacenada en el fichero de respaldo -copia de seguridad o backup- dado en el tercer argumento del comando. Si ninguno de los servidores primarios responde, se obtendrá la información de zona del fichero de respaldo.
named intentará entonces refrescar los datos almacenados regularmente. Esto se explica después cuando se vean las entradas SOA de los ficheros.
Tiene como argumentos un dominio y un nombre de fichero. Contiene la lista de servidores de nombres raíz. Sólo se reconocerán registros NS y A. El argumento domain es normalmente el nombre del dominio raíz (.).
Esta información es fundamental: si la orden caché no existiera, named no haría una caché local. Esto degradaría de forma importante el rendimiento e incrementaría la carga de la red si los nombres que se buscan no están en la red local. Además, named tampoco será capaz de contactar con cualquier servidor de nombres raíz, y por ello, no podrá resolver ninguna dirección excepto aquellas para las que esté autorizado. Una excepción a esta regla, ocurre cuando se usan servidores redirigidos (con la opción forwarders explicada a continuación).
Esta opción lleva una lista de direcciones como argumento. Las direcciones IP en la lista especifican servidores de nombres a los que named puede preguntar si falla una traducción de un nombre mediante su caché local. Se intenta preguntar a todos en orden hasta que uno de ellos responda.
Esta opción hace que el servidor sea esclavo. Esto significa que nunca realizará consultas recursivas, sino que las redirigirá a los servidores especificados con forwarders.
Hay dos opciones adicionales que no vamos a describir: sortlist y domain. Además, hay dos directivas que pueden aparecer en los ficheros de zona. Son $INCLUDE y $ORIGIN, que tampoco vamos a describir, ya que raramente se utilizan.
En la versión 8 de BIND se han incluido nuevas características, lo cual ha requerido una nueva sintaxis del fichero de configuración principal. El fichero named.boot ha sido reemplazado por otro, de nombre named.conf, que tiene una sintaxis similar a la del programa gated y recuerda a la del lenguaje C.
La nueva sintaxis es más compleja, pero por suerte disponemos de una utilidad para convertir automáticamente los ficheros named.boot de sintaxis antigua. Esta utilidad es un script de PERL llamado named-bootconf.pl, que encontraremos en el código fuente de BIND 8; y lee un fichero en sintaxis antigua, devolviendo por su salida estándar el fichero en sintaxis nueva. Naturalmente, para utilizarlo es necesario tener correctamente instalado el intérprete de lenguaje PERL.
Al script lo invocaremos, por ejemplo, así:
# cd /etc
# named-bootconf.pl <named.boot >named.conf |
Ejemplo 6-9. Fichero named.conf para usar BIND 8 con vlager
//
// /etc/named.boot para vlager.vbrew.com
options {
directory "/var/named";
};
zone "." {
type hint;
file "named.ca";
};
zone "vbrew.com" {
type master;
file "named.hosts";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "named.local";
};
zone "16.172.in-addr.arpa" {
type master;
file "named.rev";
}; |
Si observamos el ejemplo, veremos que cada línea de named.boot ha sido convertida a un bloque en estilo C, encerrado entre llaves (signos { y } ).
Los comentarios del fichero se escriben ahora en notación similar a C++, es decir, dos barras (signo // ).
La sentencia directory va ahora dentro del bloque options, junto a otras posibles opciones globales de configuración.
Las sentencias caché y primary se convierten en bloques de zona, con sentencias type específicas, de valor hint y master, respectivamente.
Los ficheros de zona no necesitan modificarse, ya que su sintaxis sigue siendo la de antes.
La nueva sintaxis de configuración se ha pensado para poder incluir muchas más opciones de configuración, en las que no vamos a detenernos. Si deseamos conocerlas, la mejor fuente de información es la que viene con el paquete de fuentes de BIND 8.
Los ficheros incluidos con named, como named.hosts, siempre tienen un dominio asociado a ellos llamado origen. Este es el nombre de dominio especificado con los comandos caché y primary. En un fichero maestro, se pueden especificar nombres de máquinas y dominios relativos a este dominio. Un nombre dado en un fichero de configuración se considera absoluto si termina con un punto. En caso contrario se considera relativo al origen. Al origen en sí mismo nos podemos referir con «@».
Todos los datos en un fichero principal se dividen en registros de recursos o RRs. Son la unidad de información del DNS. Cada RR tiene un tipo. Los registros de tipo A, por ejemplo, asocian un nombre a una dirección IP. Los registros de tipo CNAME asocian un alias de una máquina con su nombre oficial. Como ejemplo, obsérvese Ejemplo 6-11, que muestra el fichero named.hosts para nuestro sistema.
La representación de los RRs en los ficheros utiliza el siguiente formato:
[domain] [ttl] [class] type rdata |
Los campos se separan por espacios o tabulaciones. Una entrada puede continuarse en varias líneas si se abre un paréntesis antes del primer fin de línea y el último campo es seguido de un cierre de paréntesis. Cualquier cosa entre un punto y coma y el siguiente salto de línea será un comentario.
Aquí va el nombre del dominio que se aplica al RR actual. Si no se da nombre de dominio, se asume el mismo que se puso para el RR anterior.
Con el fin de forzar al sistema DNS a descartar información después de cierto tiempo, cada RR lleva asociado un tiempo de vida o ttl[2]. El campo ttl especifica, en segundos, el tiempo de validez de la información desde que se obtiene del servidor. Es un número decimal de hasta ocho dígitos.
Si no se especifica ningún valor, tomará uno por defecto del campo minimum del registro SOA precedente.
Aquí se indica la clase de dirección: IN para direcciones IP, HS para objetos de la clase Hesiod. Trabajando con redes TCP/IP debe usarse siempre la clase IN.
Si no se especifica ningún valor, se toma el valor del RR anterior.
Describe el tipo de RR. Los tipos habituales son A, SOA, PTR y NS. En las siguientes secciones comentaremos estos tipos de RRs.
Contiene los datos asociados al RR. El formato depende del tipo, y se describirán más adelante.
A continuación se presenta una lista incompleta de RRs que se utilizan en los ficheros de DNS. Hay algunos más que no vamos a comentar. Son experimentales, y de escaso uso.
Describe una zona de autoridad (SOA significa «Start of Authority», es decir, «Comienzo de Autoridad»). Señala que los registros siguientes contienen información «autorizada» para el dominio. Cada fichero incluido en la opción primary debe tener un registro SOA para esta zona. Los datos asociados contienen los siguientes campos:
Nombre canónico del servidor de nombres primario para este dominio. Se suele dar como nombre absoluto.
Dirección de correo electrónico de la persona responsable de mantener el dominio, reemplazando el carácter «@» por un punto. Por ejemplo, si el responsable de nuestra red fuese janet, este campo contendrá: janet.vbrew.com.
Este es el número de versión del fichero de zona, expresado con un número decimal. Cuando se cambien datos del fichero, deberá incrementarse este número. Se suele expresar como número de versión en el día actual, es decir, en el formato AAAAMMDDnn siendo AAAA el año, MM el mes, DD el día y nn el número de revisión de ese día (01 si no hay más de una). Por ejemplo, 2001072201 para el 22 de julio de 2001.
El número de versión es utilizado por los servidores secundarios para saber cuándo la información de una zona ha cambiado. Para mantenerse actualizados, los servidores secundarios piden cada cierto tiempo el registro SOA del primario, y comparan el número de versión con el que tienen en la caché. Si ha cambiado, el servidor secundario pedirá de nuevo la información de zona al primario.
Especifica el intervalo, en segundos, que esperan los servidores secundarios entre peticiones de registros SOA a los primarios. De nuevo, se trata de un número decimal de hasta ocho dígitos.
Normalmente, la topología de la red no cambia mucho, con lo que este número será como poco de un día para grandes redes, y de mucho más tiempo para redes pequeñas.
Este número determina los intervalos de tiempo entre reintentos de comunicación con servidores primarios cuando una petición de una zona falla. No debe ser pequeño ya que un fallo temporal del servidor primario hará que el secundario cargue inútilmente la red. Buenas elecciones son una hora o como poco media hora.
Especifica el tiempo, en segundos, que tardará el servidor en descartar los datos de zona si no ha podido contactar con el servidor primario. Normalmente se pondrá un valor grande, de por lo menos una semana (604800 segundos), aunque si se incrementa a un mes o más será incluso más razonable.
Valor predeterminado para el valor del ttl en los registros de recursos que no lo especifiquen. Sirve para indicar a otros servidores de nombres que descarten el RR tras cierto tiempo. No tiene efecto, sin embargo, sobre el tiempo en el que un servidor secundario intenta actualizar la información de zona.
El valor de minimum debe ser grande, en especial para redes locales con topologías poco cambiantes. Una buena elección puede ser de una semana o un mes. En el caso de que haya registros RR que cambien con frecuencia, siempre podrá asignarle valores particulares de ttl.
Asocia direcciones IP con nombres. El campo de datos contiene la dirección separando los octetos por puntos, como es habitual.
Para cada máquina sólo puede haber un registro A, que se considera nombre oficial o canónico. Cualquier otro nombre será un alias y debe ser incluido con registros CNAME.
Apunta a un servidor de nombres maestro de una zona subordinada. El campo de datos contiene el nombre del servidor. Para traducir ese nombre debe proporcionarse un registro A adicional, que se conoce como glue, al proporcionar la dirección IP del servidor.
Hay que incluir registros NS en dos casos: primero, cuando delegamos la autoridad a una zona subordinada. Segundo, en la base de datos del servidor principal de cualquier zona. Los servidores NS especificados en el fichero de zona deben coincidir exactamente con los que especifica la zona padre que delega.
El registro NS especifica el nombre del servidor de nombres primario y los secundarios para una zona. Estos nombres deben poderse resolver para poderse usar. A veces los servidores pertenecen al mismo dominio que sirven, lo que ocasiona un problema de el huevo o la gallina: no podemos obtener el servidor de nombres hasta que accedamos al dominio, pero para acceder el dominio hay que conocer la IP del servidor de nombres... Para resolver este problema se crean registros A directamente en la zona padre, para resolver esas direcciones. Estos son los que ya comentamos antes, los registros glue (podríamos traducirlos como registros-pegamento), puesto que unen o pegan la zona hija a la zona padre.
Asocia un alias con su nombre canónico. El nombre canónico se determina con un registro A. Los alias son indicados mediante registros CNAME.
Se usa para asociar nombres del dominio in-addr.arpa con sus nombres normales. Se usa para obtener nombres a partir de direcciones IP (traducción inversa). El nombre de la máquina debe ser el canónico.
Especifica el servidor de correo para un dominio. En la sección Sección 17.4.1 se explica por qué son necesarios estos servidores. La sintaxis del registro MX es:
[domain] [ttl] [class] MX preference host |
host nombra el servidor de correo para el dominio domain. Cada servidor tiene asociado un valor de preference (preferencia). Cuando un agente de transferencia de mensajes quiere entregar correo al dominio, intentará conectarse a esos servidores hasta conseguir entregar el mensaje; empezando por el que tenga menor valor de preferencia.
Este registro da información sobre el hardware y el software de la máquina. 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 también está normalizado.
Por ejemplo, un registro HINFO para describir un sistema Intel ejecutando Linux podría ser:
tao 36500 IN HINFO IBM-PC LINUX2.2 |
cevad 36500 IN HINFO ATARI-104ST LINUX2.0
jedd 36500 IN HINFO AMIGA-3000 LINUX2.0 |
Hay una clase especial de configuración de named, que nos servirá para introducirnos en su funcionamiento. Se llama sólo-caché. No sirve ningún dominio propio, pero actúa como repetidor de otros DNS para nuestra red local. Cuando se repitan peticiones a un mismo nodo, el servidor responderá con la información que ya tiene, evitando peticiones repetidas que ocupen ancho de banda en Internet. Esto es especialmente útil cuando contamos con una conexión de banda estrecha, como las que veremos en Capítulo 7 y Capítulo 8.
El fichero named.boot para un servidor sólo de caché, es similar a éste:
; named.boot para servidor de sólo caché
directory /var/named
primary 0.0.127.in-addr.arpa named.local ; red local
caché . named.ca ; servidores raiz |
Además de este fichero, hay que tener el correspondiente named.ca, con una lista válida de servidores raíz. Debemos copiar y usar Ejemplo 6-10 para esto. No se requieren otros ficheros para una configuración de sólo caché.
Ejemplo 6-10, Ejemplo 6-11, Ejemplo 6-12, y Ejemplo 6-13 muestran ficheros de ejemplo para un servidor de nombres de la Cervecera Virtual, localizada en vlager. Debido a la naturaleza de la red propuesta (una simple LAN), el ejemplo es muy simple también.
El fichero de caché named.ca mostrado en Ejemplo 6-10 contiene ejemplos de registros de servidores raíz. Un fichero típico de caché contiene como una docena de servidores de esta clase. Se puede obtener una lista de los servidores raíz usando la utilidad The named.ca caché file shown in nslookup mostrada en la siguiente sección. [3]
Ejemplo 6-10. El fichero named.ca
;
; /var/named/named.ca Fichero de caché para la cervecera.
; Al no estar en Internet no necesitamos servidores
; raiz. Si no fuera asi, descomentense.
;
;. 3600000 IN NS A.ROOT-SERVERS.NET.
;A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
;. 3600000 NS B.ROOT-SERVERS.NET.
;B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107
;. 3600000 NS C.ROOT-SERVERS.NET.
;C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12
;. 3600000 NS D.ROOT-SERVERS.NET.
;D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90
;. 3600000 NS E.ROOT-SERVERS.NET.
;E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10
;. 3600000 NS F.ROOT-SERVERS.NET.
;F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241
;. 3600000 NS G.ROOT-SERVERS.NET.
;G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4
;. 3600000 NS H.ROOT-SERVERS.NET.
;H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53
;. 3600000 NS I.ROOT-SERVERS.NET.
;I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17
;. 3600000 NS J.ROOT-SERVERS.NET.
;J.ROOT-SERVERS.NET. 3600000 A 198.41.0.10
;. 3600000 NS K.ROOT-SERVERS.NET.
;K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129
;. 3600000 NS L.ROOT-SERVERS.NET.
;L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12
;. 3600000 NS M.ROOT-SERVERS.NET.
;M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33
; |
Ejemplo 6-11. El Fichero named.hosts
;
; /var/named/named.hosts Nodos de la cervecera
; El origen es vbrew.com
;
@ IN SOA vlager.vbrew.com. janet.vbrew.com. (
2000012601 ; serie
86400 ; refresco: uno al dia
3600 ; reintento: una hora
3600000 ; caducidad: 42 dias
604800 ; minimo: 1 semana
)
IN NS vlager.vbrew.com.
;
; Correo local se entrega a vlager
IN MX 10 vlager
;
; direccion `loopback'
localhost. IN A 127.0.0.1
;
; La ethernet de la cervecera virtual
vlager IN A 172.16.1.1
vlager-if1 IN CNAME vlager
; vlager es tambien servidor de noticias
news IN CNAME vlager
vstout IN A 172.16.1.2
vale IN A 172.16.1.3
;
; Ethernet de la vinatera virtual
vlager-if2 IN A 172.16.2.1
vbardolino IN A 172.16.2.2
vchianti IN A 172.16.2.3
vbeaujolais IN A 172.16.2.4
;
; Ethernet (subsidiaria) de los Espiritus Virtuales
vbourbon IN A 172.16.3.1
vbourbon-if1 IN CNAME vbourbon |
Ejemplo 6-12. Fichero named.local
;
; /var/named/named.local Resolucion inversa de 127.0.0
; El origen es 0.0.127.in-addr.arpa.
;
@ IN SOA vlager.vbrew.com. joe.vbrew.com. (
1 ; serie
360000 ; refresco: 100 horas
3600 ; reintento: una hora
3600000 ; caducidad: 42 dias
360000 ; minimo: 100 horas
)
IN NS vlager.vbrew.com.
1 IN PTR localhost. |
Ejemplo 6-13. Fichero named.rev
;
; /var/named/named.rev Resolucion inversa de nuestras IPs
; El origen es 16.172.in-addr.arpa.
;
@ IN SOA vlager.vbrew.com. joe.vbrew.com. (
16 ; serie
86400 ; refresco: una vez diaria
3600 ; reintento: una hora
3600000 ; caducidad: 42 dias
604800 ; minimo: 1 semana
)
IN NS vlager.vbrew.com.
; cervecera
1.1 IN PTR vlager.vbrew.com.
2.1 IN PTR vstout.vbrew.com.
3.1 IN PTR vale.vbrew.com.
; vinatera
1.2 IN PTR vlager-if2.vbrew.com.
2.2 IN PTR vbardolino.vbrew.com.
3.2 IN PTR vchianti.vbrew.com.
4.2 IN PTR vbeaujolais.vbrew.com. |
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 de órdenes. En este último caso podemos invocar la orden así:
$ nslookup
nombre-de-host |
nslookup envía sus peticiones al servidor citado en resolv.conf. Si este fichero tiene más de un servidor, nslookup eligirá uno al azar.
El modo interactivo es mucho más interesante. No sólo sirve para buscar la IP de un nodo, sino que también podemos interrogar acerca de cualquier tipo de registro DNS y transferirnos toda la informació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 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.
Veamos una posible sesión de nslookup:
$ 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
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)
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 al nombre dado.
Una aplicación práctica de nslookup, para depurar un servidor, es obtener la lista de servidores raíz. Para ello no hay más que pedir los NS del registro raíz (.):
> set type=NS
> .
Server: tao.linux.org.au
Address: 203.41.101.121
Non-authoritative answer:
(root) name server = A.ROOT-SERVERS.NET
(root) name server = H.ROOT-SERVERS.NET
(root) name server = B.ROOT-SERVERS.NET
(root) name server = C.ROOT-SERVERS.NET
(root) name server = D.ROOT-SERVERS.NET
(root) name server = E.ROOT-SERVERS.NET
(root) name server = I.ROOT-SERVERS.NET
(root) name server = F.ROOT-SERVERS.NET
(root) name server = G.ROOT-SERVERS.NET
(root) name server = J.ROOT-SERVERS.NET
(root) name server = K.ROOT-SERVERS.NET
(root) name server = L.ROOT-SERVERS.NET
(root) name server = M.ROOT-SERVERS.NET
Authoritative answers can be found from:
A.ROOT-SERVERS.NET internet address = 198.41.0.4
H.ROOT-SERVERS.NET internet address = 128.63.2.53
B.ROOT-SERVERS.NET internet address = 128.9.0.107
C.ROOT-SERVERS.NET internet address = 192.33.4.12
D.ROOT-SERVERS.NET internet address = 128.8.10.90
E.ROOT-SERVERS.NET internet address = 192.203.230.10
I.ROOT-SERVERS.NET internet address = 192.36.148.17
F.ROOT-SERVERS.NET internet address = 192.5.5.241
G.ROOT-SERVERS.NET internet address = 192.112.36.4
J.ROOT-SERVERS.NET internet address = 198.41.0.10
K.ROOT-SERVERS.NET internet address = 193.0.14.129
L.ROOT-SERVERS.NET internet address = 198.32.64.12
M.ROOT-SERVERS.NET internet address = 202.12.27.33 |
Para ver el conjunto completo de comandos, podemos usar help dentro de nslookup.
Hay algunas utilidades que pueden ayudarnos en nuestro trabajo como administradores de BIND. Vamos va ver algunas de ellas. Para cualquier detalle adicional se recomienda consultar la documentación específica de dichas utilidades.
hostcvt le ayuda con la configuración inicial de BIND convirtiendo su fichero /etc/hosts en ficheros maestros para named. Genera tanto las entradas del mapeado directo (A) como el mapeado inverso (PTR), y toma en cuenta los alias. Por supuesto, no hará todo el trabajo por usted, así que todavía tendrá que ajustar los palores de temporización el el registro SOA, por ejemplo, a añadir registros MX. También, le puede ayudar a ahorrarse algunas aspirinas. hostcvt es parte de las fuentes BIND, pero puede encontrase como un paquete individual en unos pocos servidores FTP.
Tras la puesta en marcha del servidor, normalmente habrá que probarla. Algunas utilidades facilitan la vida para esto. Una de ellas es dnswalk, que está basada en Perl. La segunda es nslint. Ambas recorren la base de datos DNS buscando errores habituales y verificando que la información que encuentran es consistente. Otras dos utilidades interesantes son host y dig, que vienen con el paquete BIND y pueden usarse para una inspección manual del las bases de datos.
Estas utilidades suelen venir empaquetadas. dnswalk y nslint están disponibles en fuentes en http://www.visi.com/~barr/dnswalk/ y ftp://ftp.ee.lbl.gov/nslint.tar.Z. En cuanto a host y dig, el código fuente se encuentra en ftp://ftp.nikhef.nl/pub/network/ y ftp://ftp.is.co.za/networking/ip/dns/dig/.
| [1] | BIND 4.9 fue desarrollado por Paul Vixie, paul@vix.com, aunque actualmente lo mantiene el Consorcio de Software para Internet, en bind-bugs@isc.org. |
| [2] | N. del T.: Time to Live |
| [3] | Nótese que no podemos preguntar esto a nuestro servidor de nombres si no tenemos entradas de servidores raíz instaladas. Para evitar esto, podemos usar nslookup para interrogar a un servidor de nombres externo, o usar como fichero de caché el mostrado en Ejemplo 6-10 y de ahí obtener una lista completa. |