DNS COMO <author> Nicolai Langfeldt <tt/janl(en)langfeldt.net/ ) ,Jamie Norrish y otros. Traducción: Pedro Pablo Fábrega <tt>pfabrega(en)arrakis.es"</tt> </author> <date>Versión 9.0, 2001-12-20 <abstract> COMO convertirse en todo un administrador DNS en poco tiempo </abstract> <toc> <sect>Preámbulo <p>Keywords: DNS, BIND, BIND 4, BIND 8, named, dialup, PPP, slip,ISDN, Internet, domain, name, resolution, hosts, caching, resolución,cacheo. <p> Este documento es parte del Linux Documentation Project (Proyecto de Documentación Linux). <sect1>Cuestiones legales <p>(C)opyright 1995-2001 Nicolai Langfeldt, Jamie Norrish & Co. No modificar sin mantener o mejorar el copyright, se puede distribuir libremente pero manteniendo este mensaje de copyright. <sect1>Créditos y solicitud de ayuda. <p>Quiero agradecer a toda la gente que se ha aburrido con la lectura de este documento (tú sabes quien eres) quienes han sufrido los borradores de este trabajo y han proporcionado muchas y muy útiles aportaciones. También quiero agradecer a las numerosas personas que me han enviado sugerencias y notas por correo electrónico. <p> Esto nunca será un documento acabado, por favor mandadme correo con vuestros problemas y éxitos; de esta forma me ayudarás a mejorar este COMO. Así que por favor, manda dinero, comentarios y/o preguntas a <tt>janl(en)langsfeld.net</tt>. O compra mi libro sobre DNS(se titula "The Concise Guide to DNS and BIND, en la bibliografía tienes el ISBNs). Si envías un E-mail, y quieres respuesta, por favor <em/asegúrate/ de que tu dirección de remitente es correcta, recibo un montón de E-mail. Asimismo, por favor lee la sección de las PUF (<ref id="PUF" name="PUFs">) antes de enviarme un mail. Otra cosa, sólo entiendo Noruego e Inglés. <footnote>N.T. Como consecuencia se ruega no hacer preguntas que el autor no se entere de lo que se le está preguntando. El traductor sí entiende el castellano, pero no sabe tanto, ni mucho menos, como el autor.</footnote> <p>Esto es un COMO. Lo he mantenido como parte del LDP desde 1995. Durante el año 2000 he escrito un libro con los mismos fines. Quiero decir que, aunque este COMO es en muchos aspectos como el libro, <em>no</em> es una versión limitada destinada a promocionar el libro. Sin embargo encontrará el libro en la bibliografía, al final de este COMO. Los lectores de este COMO me han ayudado a comprender cuales son las dificultades para comprender el DNS. Eso me ha ayudado con libro, pero el libro también me ha ayudado a pensar qué es lo que este COMO necesita. El COMO precedió al libro, el libro precedió la la versión 3 de este COMO. Muchas gracias a los editores del libro, <em/Que/, que me dieron una oportunidad. :-) <!-- Esto es un comentario para los traductores: Si eres un traductor puedes incluir información para localizar alguien que hable el idioma al que se traduce, y que pueda ayudar con los problemas con el DNS, como tú mismo, aquí. (en otro caso recibiré correos en chino y español solicitando ayuda sobre DNS). Si quieres traducir este COMO, por favor notifícamelo para que yo pueda mantener la pista de las lenguas en las que he sido publicado y pueda notificar cuando se actualiza. Por favor, tampoco sustituyas el "(en)" de la dirección de correo por el "@". Espero que esto reduzca la cantidad de spam que recibo, o al menos no aumentarlo. --> <sect1>Dedicatoria <p>Este COMO está dedicado a Anne Line Norheim. Aunque ella probablemente nunca lo leerá porque no es de esa clase de chicas. <sect1>Versiones Actualizadas <p>Deberías poder encontrar versiones actualizadas de este COMO en <url url="http://langfeldt.net/DNS-HOWTO/"> y en en <url url="http://www.linuxdoc.org/">. Pásate por allí si este documento tiene más de 9 meses. <sect>Introducción.<label id="intro"> <p><bf/Qué es y qué no es./ <p>DNS es el Domain Name System (Sistema de nombres de dominio). DNS convierte nombres de máquina a las direcciones IP que tienen todas las máquinas de la red. DNS traduce o relaciona nombres con direcciones y de direcciones con nombres, y alguna que otra cosa más. Este COMO documenta como se definen tales asociaciones usando sistemas Unix, con algunos pequeños detalles específicos de Linux. <p>Una relación es simplemente una asociación entre dos cosas, en estecaso un nombre de máquina, como <tt>ftp.linux.org</tt>, y el número IP de la máquina (o dirección) <tt/199.249.150.4/. DNS también contiene relaciones en el sentido contrario, del número IP al nombre de la máquina; esto se denomina "asociación inversa". <p>El DNS es, para los no iniciados (tú. <tt/;-)/, una de las áreas más opacas de la administración de una red. Afortunadamente el DNS no es realmente difícil. Este COMO tratará de aclarar algunas cosas. Describe cómo configurar un servidor de nombres DNS simple, comenzando con un servidor de sólo cacheo (<it>caching only server</it>)<footnote>Servidor que se limita a guardar en una caché las IP de los nombres de máquina más solicitados, obteniéndolas de servidores externos.</footnote>, y continuaremos con la configuración de un servidor DNS primario para un dominio. Para configuraciones más complejas puedes consultar la sección de PUF (<ref id="PUF">) de este documento. Si lo que buscas no está descrito allí, necesitarás <em/leer/ la <it/Documentación Real/. Volveré a lo que es la <it/Documentación Real/ en el <ref id="grande" name="último capítulo">. <bf>Antes de empezar</bf>, debes configurar tu sistema convenientemente, de forma que pueda hacer <tt/telnet/ desde y hacia tu máquina, efectuando satisfactoriamente toda clase de conexiones de red, especialmente <tt>telnet 127.0.0.1</tt> entrando en tu propia máquina (compruébalo ahora). También necesitas que los archivos <tt>/etc/host.conf</tt> (o <tt>/etc/nsswitch.conf</tt>), <tt>/etc/resolv.conf</tt> y <tt>/etc/hosts</tt> sean correctos como punto de partida, ya que no explicaré sus funciones aquí. Si NO tienes aun esta configuración y no funciona en red, el <it>Networking-HOWTO</it> y <it>Networking-Overview-HOWTO</it> explican como hacerlo. Léelos.<footnote> N.T.: Mira los documentos en castellano en <htmlurl url="www.insflug.org" name="www.insflug.org"> </footnote> Cuando digo <it>``tu máquina''</it> quiero decir la máquina en la que estás intentando configurar DNS. No cualquier otra máquina que puedas tener en tu red. Supongo que <bf>no estás detrás de cualquier clase de cortafuegos</bf> (<it/firewall/) que bloquee peticiones de nombres. Si necesitas una configuración especial, mira la sección <ref id="PUF" name="PUF">. El servicio de nombres en Unix se lleva a cabo por un programa, llamado <tt>named</tt>. Éste programa forma parte del paquete <tt/bind/, que es coordinado por el <it/The Internet Software Consortium/. <tt>named</tt> está incluido en la mayoría de las distribuciones de Linux y generalmente se instala como <tt>/usr/sbin/named</tt>, normalmente de un paquete llamado <tt/BIND/, en mayúsculas o minúsculas, depende quien lo confeccione. <p>Si tienes el fichero <tt>named</tt> probablemente puedas usarlo; si no lo tienes, puedes obtener el binario en un ftp de Linux, o conseguir los últimos y más voluminosos fuentes en <tt><htmlurl url="ftp://ftp.isc.org/isc/bind/src/" name="ftp://ftp.isc.org/isc/bind/src/"></tt>, bien de los subdirectorios de versión actual, o de prueba, lo que mejor se adapte a tu estilo de vida. Este COMO trata la versión 9 de BIND. Las anteriores versiones del COMO tratan de las versiones 4 y 8, todavía disponibles en <url url="http://langfeldt.net/DNS-HOWTO/"> en caso de que uses BIND 4 u 8 (tambien encontrarás este COMO). Si la página de manual de named habla sobre (al final del todo, en la sección FILES)<tt/named.conf/ tiene BIND 8; si habla de <tt/named.boot/ tienes BIND 4. Si tienes la 4 y te preocupa la seguridad realmente deberías actualizarte a la última versión de BIND 8. Ahora. <p> <bf>DNS es una base de datos cuyo ámbito es la Red</bf>. Ten cuidado con lo que pones en ella. Si pones incongruencias, tú y los demás obtendrán incongruencias de ella. Mantén tu DNS limpia y consistente y conseguirás un buen servicio de ella. Aprende a usarla, administrarla, depurarla y serás otro buen administrador, salvando a la red de caerse de rodillas sobrecargada por falta de mantenimiento. <descrip> <tag /Aviso:/ Haz una copia de seguridad de todos los archivos que te indico que cambie si ya los tienes, y así si después, si no funciona podrás volver al principio.</descrip> <sect1>Otras implementaciones de servidores de nombres. <p>Esta seccion la ha escrito Joost van Baal. <p> Existen varios paquetes para disponer de servidores e nombres en tu máquina. Esta el paquete BIND (<url url="http://www.isc.org/products/BIND/">); sobre el que trata este COMO. Es el servidor de nombres más popular que hay y se usa en una amplia mayoría de los servidores de Internet desde que apareció sobre 1980. Está disponible bajo licencia BSD. Como es el paquete más popular hay muchísima documentación y conocimientos sobre su comportamiento. Sin embargo han habido problemas de seguridad con BIND. <p>Tambien está djbdns (<url url="http://djbdns.org/">)un paquete relativamente nuevo escrito por Daniel J. Bernstein que tembien escribió qmail. Es una suite modular: varios pequeños programas llevan a cabo las diferentes tareas que se supone que tiene que realizar un servidor de nombres. Está diseñado teniendo la seguridad en mente. Usa un formato de fichero de zona más simple y generalmente es más fácil de configurar. Sin embargo, al ser menos conocido, tu gurú local podría no poder ayudarte. Por desgracia, este software no es <tt>Open Source</tt>. El anuncio del autor está en <url url="http://cr.yp.to/djbdns/ad.html">. <p>Si el software DJBs es una mejora sobre las viejas alternativas es motivo de un amplio debate. Una discusion (¿o es un <tt>flame-war</tt>?) sobre BIND vs djbdns a la que se adhirió la gente de ISC la puedes ver en <url url="http://www.isc.org/ml-archives/bind-users/2000/08/msg01075.html"> <sect>Servidor de nombres de ``sólo cacheo''.<label id="caching"> <p><bf/Una primera nota para la configuración de DNS, muy útil para usuarios de módem, cable-módem, ADSL y similares./ <p>En Red Hat y distribuciones derivadas puedes conseguir los resultados prácticos de esta primera sección del COMO instalando los paquetes <tt/bind/, <tt/bind-utils/ y caching-nameserver. Si usa Debian simplemente instala <tt/bind/ (o <tt/bind9/, al escibir esto, BIND 9 no está soportado por Debian Stable (potato))y <tt/bind-doc/. Desde luego, que sólo instalando estos paquetes no aprenderás más que leyendo este COMO. Así pues, instala los paquetes, lee y verifica los ficheros instalados. <p>Un servidor de "sólo cache" encontrará las respuestas a las consultas de nombres y las recordará para la próxima vez que las necesites. Esto acorta el tiempo de espera significativamente para la próxima vez, especialmente si dispones de una conexión lenta. <p>Lo primero que necesitas es un fichero llamado <tt>/etc/named.conf</tt> (Debian: <tt>/etc/bind/named.conf</tt>). Este fichero se lee cuando arranca named. Por ahora simplemente contendrá: <code> // Fichero de configuración para servidor de sólo cacheo // La version que lea de este COMO puede contener espacios // iniciales (espacios previos a los caracteres de estas // líneas) en este u otros ficheros. Debe eliminarlos para // que las cosas funcionen. // // Observe que los nombres de ficheros y directorio pueden // ser distintos, aunque los ultimos contenidos deben // ser muy parecidos. options { directory "/var/named"; // Descomentar esto podría ayudar si tiene que salir a través // de un cortafuegos y las cosas no funcionan fuera. Sin embargo, de todas // formas necesitarás hablar con el administrador del cortafuegos. // query-source port 53; }; controls { inet 127.0.0.1 allow { localhost; } keys { rndc_key; }; }; key "rndc_key" { algorithm hmac-md5; secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K"; }; zone "." { type hint; file "root.hints"; }; zone "0.0.127.in-addr.arpa" { type master; file "pz/127.0.0"; }; </code> <p>Los paquetes de las distribuciones Linux pueden usar diferentes nombres para cada uno de los ficheros mencionados aquí; el contenido sigue siendo el mismo. <p>La línea `<tt/directory/' le indica a named donde buscar los ficheros. Todos los ficheros mencionados están relativos a esta ruta. Así <tt>pz</tt> es un directorio bajo <tt>/var/named</tt>, i.e., <tt>/var/named/pz</tt>. <tt>/var/named</tt> es el directorio correcto de acuerdo con la distribución estándar de directorios en Linux (<em/Linux File system Standard/). <p>Aquí describimos el fichero <tt>/var/named/root.hints</tt>. <tt>/var/named/root.hints</tt> debería contener lo siguiente: (<em/si cortas y pegas este fichero de una versión electrónica del documento, ten en cuenta que <bf/no/ deberían haber espacios en blanco iniciales en este fichero, i.e. todas las líneas deberían comenzar con un carácter que no sea espacio. Algún software de procesamiento de documentos inserta espacios al comienzo de las líneas y causan confusión. En este caso, elimina los espacios iniciales/). <code> ; ; Puede haber comentarios aquí si ya tenías el fichero. ; Si no no te preocupes. ; . 6D IN NS A.ROOT-SERVERS.NET. . 6D IN NS B.ROOT-SERVERS.NET. . 6D IN NS C.ROOT-SERVERS.NET. . 6D IN NS D.ROOT-SERVERS.NET. . 6D IN NS E.ROOT-SERVERS.NET. . 6D IN NS F.ROOT-SERVERS.NET. . 6D IN NS G.ROOT-SERVERS.NET. . 6D IN NS H.ROOT-SERVERS.NET. . 6D IN NS I.ROOT-SERVERS.NET. . 6D IN NS J.ROOT-SERVERS.NET. . 6D IN NS K.ROOT-SERVERS.NET. . 6D IN NS L.ROOT-SERVERS.NET. . 6D IN NS M.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 6D IN A 198.41.0.4 B.ROOT-SERVERS.NET. 6D IN A 128.9.0.107 C.ROOT-SERVERS.NET. 6D IN A 192.33.4.12 D.ROOT-SERVERS.NET. 6D IN A 128.8.10.90 E.ROOT-SERVERS.NET. 6D IN A 192.203.230.10 F.ROOT-SERVERS.NET. 6D IN A 192.5.5.241 G.ROOT-SERVERS.NET. 6D IN A 192.112.36.4 H.ROOT-SERVERS.NET. 6D IN A 128.63.2.53 I.ROOT-SERVERS.NET. 6D IN A 192.36.148.17 J.ROOT-SERVERS.NET. 6D IN A 198.41.0.10 K.ROOT-SERVERS.NET. 6D IN A 193.0.14.129 L.ROOT-SERVERS.NET. 6D IN A 198.32.64.12 M.ROOT-SERVERS.NET. 6D IN A 202.12.27.33 </code> <p> Este archivo describe los servidores de nombres raíz en el mundo. Este archivo cambiará a lo largo del tiempo y tiene que ser mantenido y actualizado con una cierta regularidad. Vea la sección de (<ref id="mantenimiento" name="mantenimiento">) para saber cómo mantenerlo actualizado. La siguiente sección de <tt>named.conf</tt> es la última <tt>zone</tt>. Explicaré su uso en un capítulo posterior: Por ahora, crea un archivo llamado <tt>127.0.0</tt> en el subdirectorio <tt/pz/:(<em/De nuevo, por favor borra los espacios iniciales si cortas y pegas esto/). <code> $TTL 3D @ IN SOA ns.linux.bogus. hostmaster.linux.bogus. ( 1 ; Serial 8H ; Refresh 2H ; Retry 4W ; Expire 1D) ; Minimum TTL NS ns.linux.bogus. 1 PTR localhost. </code> <p>Las secciones llamadas <tt/key/ y <tt/controls/ juntas especifican que tu named se puede controlar remotamente mediante un programa llamado <tt/rndc/ si se conecta desde el host local y se identifica con la llave secreta codificada. Esta llave es como una contraseña. Para que rndc funcione necesita que <tt>/etc/rndc.conf</tt> cumpla esto: <code> key rndc_key { algorithm "hmac-md5"; secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K"; }; options { default-server localhost; default-key rndc_key; }; </code> <p>Como puedes ver la clave es idéntica. Si quieres usar <tt/rndc/ desde otras máquinas sus tiempos tiene que estar dentro de un margen de 5 minutos la una de la otra. Recomiendo usar el software the ntp (<tt/xntpd/ y <tt/ntpdate/) para hacer esto. <p>A continuación, necesitas un <tt>/etc/resolv.conf</tt> parecido a este:(<em/De nuevo: ¡borrar espacios!/) <code> search subdomain.your-domain.edu your-domain.edu nameserver 127.0.0.1 </code> <p>La línea `<tt/search/' especifica en qué dominios buscar para cualquier nombre de máquina al que te quieras conectar. La línea `<tt/nameserver/' especifica la dirección de tu servidor de nombres, en este caso tu misma máquina ya que es donde se ejecuta named (127.0.0.1 está bien, no importa si la máquina tiene otra dirección también). Si quieres incluir varias máquinas como servidores de nombres basta añadir líneas `<tt/nameserver/' para cada uno.(Nota: Named nunca lee este fichero, lo lee la aplicación que busca un servidor de nombres. Nota 2: En algunos ficheros resolv.conf puedes encontrar una línea "domain". Es correcto, pero no uses a la vez "search" y "domain", sólo una de ellas funcionará). Para ilustrar lo que hace este archivo: &nl; Si un cliente intenta buscar a <tt>fulano</tt>, primero se probará <tt>fulano.subdominio.su-dominio.edu</tt>, a continuación <tt>fulano.su-dominio.edu</tt>, y finalmente <tt>fulano</tt>. Si un cliente intenta buscar <tt>sunsite.unc.edu</tt>, <tt>sunsite.unc.edu.subdominio.su-dominio.edu</tt> se prueba primero (sí, es tonto, pero es así como tiene que ser), después <tt>sunsite.unc.edu.su-dominio.edu</tt>, y finalmente <tt>sunsite.unc.edu</tt>. Puede que no quieras poner demasiados dominios en la línea <tt/search/, lleva su tiempo el efectuar las búsquedas. <p>El ejemplo supone que pertenece al dominio <tt>subdominio.su-dominio.edu</tt>, tu máquina probablemente se llame <tt>su-máquina.subdominio.su-dominio.edu</tt>. La línea <tt/search/ no debería contener tu <it>TLD</it> (<it/Top Level Domain/ o <it/Dominio de Nivel Superior/, `<tt/edu/' en este caso). Si necesitas conectar frecuentemente con máquinas de otro dominio, puedes añadir ese dominio a la línea <tt/search/ como sigue:(<em/Recuerda eliminar los espacios iniciales, si los hay/) <code> search subdominio.su-dominio.edu su-dominio.edu otro-dominio.com </code> y así. Obviamente necesitas poner un dominio real en su lugar. Esto es importante; por favor observa la ausencia de puntos al final de los nombres de dominio. <sect1>Iniciando named<label id="iniciando"> <p>Tras haber terminado todo lo anterior es el momento de lanzar named. Si usas un conexión por módem, conéctate primero. Ejecuta el guion de arranque <tt>/etc/init.d/named start</tt> o named directamente: <tt>/usr/sbin/named</tt>. Si has usado versiones previas de BIND probablementa hayas usado `<tt/ndc start/'. BIND9 lo ha sustituido por `<tt>rndc start</tt>', que puede controlar tu named remotamente, pero que ya no puede iniciar named. Si falla mira la sección <ref id="PUF" name="PUF">. Si observas los mensajes del fichero de syslog (normalmente llamado <tt>/var/adm/messages</tt>, Debian lo llama <tt>/var/log/daemon</tt> o también en el directorio, <tt>/var/log</tt>) mientras inicias named (ejecuta <tt>tail -f /var/log/messages</tt>) deberías ver algo como: <p>(las líneas terminadas en \ continúan en la siguiente línea) <tscreen><verb> Dec 23 02:21:12 lookfar named[11031]: starting BIND 9.1.3 Dec 23 02:21:12 lookfar named[11031]: using 1 CPU Dec 23 02:21:12 lookfar named[11034]: loading configuration from \ '/etc/named.conf' Dec 23 02:21:12 lookfar named[11034]: the default for the \ 'auth-nxdomain' option is now 'no' Dec 23 02:21:12 lookfar named[11034]: no IPv6 interfaces found Dec 23 02:21:12 lookfar named[11034]: listening on IPv4 interface lo,\ 127.0.0.1#53 Dec 23 02:21:12 lookfar named[11034]: listening on IPv4 interface eth0, \ 10.0.0.129#53 Dec 23 02:21:12 lookfar named[11034]: command channel listening on \ 127.0.0.1#953 Dec 23 02:21:13 lookfar named[11034]: running </verb></tscreen> <p>Si hay algún mensaje sobre errores debe haber algún fallo. Named indicará el fichero en el que está el fallo. Vuelve y compruébalo. Reinicia named (<tt/"/etc/init.d/named restart"/ ) cuando lo hayas corregido. <p>Ahora puedes comprobar la configuración. Tradicionalmente hay un programa llamado <tt/nslookup/ que nos servirá para estos fines. Actualmente se recomienda <tt/dig/: <tscreen><verb> $ dig -x 127.0.0.1 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26669 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;1.0.0.127.in-addr.arpa. IN PTR ;; ANSWER SECTION: 1.0.0.127.in-addr.arpa. 259200 IN PTR localhost. ;; AUTHORITY SECTION: 0.0.127.in-addr.arpa. 259200 IN NS ns.linux.bogus. ;; Query time: 3 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Dec 23 02:26:17 2001 ;; MSG SIZE rcvd: 91 </verb></tscreen> <p>Si es esto lo que obtienes, está funcionando. Espero. Ante cualquier otra cosa, vuelve y verifica todo otra vez. Cada vez que modifiques un fichero necesitas reiniciar named usando la orden <tt/rndc reload/. <p>Ahora puedes introducir una consulta. Intenta buscar alguna máquina cercana. <tt/pat.uio.no/ está cerca de mi, en la Universidad de Oslo: <tscreen><verb> $ dig pat.uio.no ; <<>> DiG 9.1.3 <<>> pat.uio.no ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15574 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 0 ;; QUESTION SECTION: ;pat.uio.no. IN A ;; ANSWER SECTION: pat.uio.no. 86400 IN A 129.240.130.16 ;; AUTHORITY SECTION: uio.no. 86400 IN NS nissen.uio.no. uio.no. 86400 IN NS nn.uninett.no. uio.no. 86400 IN NS ifi.uio.no. ;; Query time: 651 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Dec 23 02:28:35 2001 ;; MSG SIZE rcvd: 108 </verb></tscreen> <p>Esta vez <tt/dig/ ha preguntado a tu named para buscar la máquina <tt/pat.uio.no/. Contacta con una de las máquinas servidoras de nombres indicadas en tu fichero <tt>root.hints</tt>, y busca su camino desde ahí. Puede demorar un poquito antes de obtener los resultados si tiene que buscar todos los dominios que hay en <tt>/etc/resolv.conf</tt>. <!-- Hum, esta version de dig no parece mostrar este indicador aa. Mal. Y nslookup siempre dice "non-authoritative". Un cambio de comportamiento aquí, es necesario comprobar si es permantente o no. Observa que los indicadores "aa" en la línea "flag:". Significa que la respuesta es autorizada (authoritative), esto es, que es directa de un servidor autorizado. Más tarde explicaré que significa autorizada ("authoritative"). --> <p>Si de nuevo preguntas lo mismo, obtendrás: <tscreen><verb> $ dig pat.uio.no ; <<>> DiG 8.2 <<>> pat.uio.no ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3 ;; QUERY SECTION: ;; pat.uio.no, type = A, class = IN ;; ANSWER SECTION: pat.uio.no. 23h59m58s IN A 129.240.130.16 ;; AUTHORITY SECTION: UIO.NO. 23h59m58s IN NS nissen.UIO.NO. UIO.NO. 23h59m58s IN NS ifi.UIO.NO. UIO.NO. 23h59m58s IN NS nn.uninett.NO. ;; ADDITIONAL SECTION: nissen.UIO.NO. 23h59m58s IN A 129.240.2.3 ifi.UIO.NO. 1d23h59m58s IN A 129.240.64.2 nn.uninett.NO. 1d23h59m58s IN A 158.38.0.181 ;; Total query time: 4 msec ;; FROM: lookfar to SERVER: default -- 127.0.0.1 ;; WHEN: Sat Dec 16 00:23:09 2000 ;; MSG SIZE sent: 28 rcvd: 162 </verb></tscreen> <!-- <p>Observa la ausencia del indicador "aa" (authoritative answer) en esta respuesta. Esto significa que named no ha salido a la red esta vez, ya que la información ahora está en el caché<footnote>Las respuestas marcadas como "aa" o "Authoritative Answer" quiere decir que es una respuesta obtenida directamente del servidor autorizadode ese dominio. Si no se indica "aa" quiere decir que es una "Non Authoritative Answer" y significa que la respuesta se ha obtenido de un cache. Esto no quiere decir que no sea una respuesta valida, simplemente indica su origen<footnote>.Pero la información del cache <em/podría/ estar obsoleta. Por eso se te informa de esta (remota) posibilidad con la ausencia de "aa". Pero sabes que tu cache está funcionando. --> <sect1>Resolutores (Resolvers) <p>Todos los sistemas operativos que incorporan la API estándar de C disponen de las llamadas gethostbyname y gethostbyaddr. Estas llamadas pueden obtener información de diferentes orígenes. El origen viene determinado por la configuración indicada en <tt>/etc/nsswitch.conf</tt> en Linux (y otros Unix). Es un fichero grande que especifica de qué base de datos se obtienen los diferentes tipos de datos. Normalmente contiene comentarios útiles al principio, que deberías leer. Tras encontrar que empieza con `<tt/hosts:/'; se debería leer: <code> hosts: files dns </code> (<em/¿Recuerdas lo de los espacios en blanco? Ya no lo voy a mencionar de nuevo./) <p>Si no hay una línea que comience por `<tt/hosts:/', pon una como la anterior. Eso le dice a los programas que primero deben buscar en el fichero <tt>/etc/hosts</tt>, y después comprobar DNS de acuerdo con <tt/resolv.conf/. <sect1>Felicitaciones <p>Ahora ya sabes como configurar un servidor de nombres de sólo cacheo. Tómate una cerveza, leche, o lo que más te guste, para celebrarlo. <sect>Reenvío (Forwarding) <p>En redes grandes y bien organizadas, académicas o ISP (Internet ServiceProvider, Proveedores de servicios de internet) algunas veces verás que la gente ha configurado una jerarquía de reenvío de servidores DNS que ayuda a aligerar la carga de la red interna y también de los servidores externos. No es fácil saber si estás dentro de una red así o no. Sin embargo no es importante, y al usar los servidores DNS de tu proveedor de red como un ``forwarder'' puedes obtener respuestas más rápidas a las consultas y una menor carga de la red. Si usas un módem esto puede ser una ventaja. Para este ejemplo, supondremos que tu proveedor de red tiene dos servidores de nombres que permiten que uses, con direcciones IP <tt/10.0.0.1/ y <tt/10.1.0.1/. Entonces, en tu fichero <tt/named.conf/ , en la sección llamada ``options'', inserta estas líneas: <code> forward first; forwarders { 10.0.0.1; 10.1.0.1; }; </code> <p>Hay un bonito truco para máquinas con conexión por módem usando forwarders, se describe en la sección <ref id="PUF" name="PUF">. <p>Reinicia tu servidor de nombres y comprueba con <tt/dig/. Todavía debería funcionar bien. <sect>Un dominio <em/simple/.<label id="simple"> <p><bf>Cómo configurar tu propio dominio.</bf> <sect1>Pero primero algo de teoría a secas <p>Antes de nada: ¿Has leído todo lo anterior? Tienes que hacerlo. <p>Antes de comenzar <em/realmente/ con esta sección, voy a dar un poco de teoría sobre cómo funciona DNS. Y lo deberías de leer porque es mejor para ti. Si no quieres, al menos deberías echar un vistazo rápido. Deja el repaso cuando sepas lo que debes incluir en tu fichero <tt>named.conf</tt>. El DNS es un sistema jerárquico, un sistema con estructura de árbol. La raíz se escribe como `<tt/./' y se denomina <it>`root'</it> como es habitual para estructuras en árbol. Debajo hay cierto número de Dominios de Nivel Superior (<it/Top Level Domains/, <it/TLD/s), los más conocidos son <tt/ORG, COM, EDU/ y <tt/NET/, pero hay muchos más. Como en un árbol, tiene raíz y ramas. Si tienes una base de informática puedes reconocer DNS como un árbol de búsqueda, y podrás buscar nodos. Los puntos son nodos, en los extremos están los nombres. <p>Cuando se busca una máquina, la pregunta procede recursivamente en la jerarquía comenzando desde la raíz. Si quieres localizar la dirección de <tt>prep.ai.mit.edu</tt>, tu servidor de nombres tiene que empezar preguntando en algún sitio. Comienza mirando e el cache. Si sabe la respuesta, por tenerla en el cache de antes, responderá de la misma forma que vimos en la última sección. Si lo desconoce mirará la respuesta más cercana que verifique el nombre pedido y utilizará el cache. En el peor de los casos que no se encuentre nada salvo la '.' (raíz) del nombre, se consultarán los servidores raíz. Eliminará partes del nombre comenzando por la izquierda, comprobando si sabe algo de <tt/ai.mit.edu./, después <tt/mit.edu./, después <tt/edu./ y si no, lo que conoce de <tt/./ es lo que tiene el fichero "hints". Entonces preguntará al servidor <tt/./ sobre <tt/prep.ai.mit.edu/. Este servidor <tt/./ desconoce la respuesta, pero ayudará a tu servidor a encontrar el camino dando la referencia sobre donde buscar. Estas referencias, le dirigen al servidor de nombres que conoce la respuesta. Ilustramos eso ahora. <tt/+norec/ significa que dig está preguntando consultas no recursivas para que la obtengamos nosotros mismos. La otras opciones son para reducir lo que dig genera para no obtener muchas páginas: <tscreen><verb> $ dig +norec +noH +noques +nostats +nocmd prep.ai.mit.edu. ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 980 ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0 ;; AUTHORITY SECTION: . 518400 IN NS J.ROOT-SERVERS.NET. . 518400 IN NS K.ROOT-SERVERS.NET. . 518400 IN NS L.ROOT-SERVERS.NET. . 518400 IN NS M.ROOT-SERVERS.NET. . 518400 IN NS A.ROOT-SERVERS.NET. . 518400 IN NS B.ROOT-SERVERS.NET. . 518400 IN NS C.ROOT-SERVERS.NET. . 518400 IN NS D.ROOT-SERVERS.NET. . 518400 IN NS E.ROOT-SERVERS.NET. . 518400 IN NS F.ROOT-SERVERS.NET. . 518400 IN NS G.ROOT-SERVERS.NET. . 518400 IN NS H.ROOT-SERVERS.NET. . 518400 IN NS I.ROOT-SERVERS.NET. </verb></tscreen> <p>Esto es una referencia. Nos devuelve una "Authority section" sólo, no "Answer section". Nuestro propio servidor de nombres nos envía a un servidor de nombres. Toma uno al azar. <tscreen><verb> $ dig +norec +noques +nostats +nocmd prep.ai.mit.edu. @D.ROOT-SERVERS.NET. ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58260 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3 ;; AUTHORITY SECTION: mit.edu. 172800 IN NS BITSY.mit.edu. mit.edu. 172800 IN NS STRAWB.mit.edu. mit.edu. 172800 IN NS W20NS.mit.edu. ;; ADDITIONAL SECTION: BITSY.mit.edu. 172800 IN A 18.72.0.3 STRAWB.mit.edu. 172800 IN A 18.71.0.151 W20NS.mit.edu. 172800 IN A 18.70.0.160 </verb></tscreen> Esto nos envía a los servidores de MIT.EDU de una vez. De nuevo toma uno al azar. <tscreen><verb> $ dig +norec +noques +nostats +nocmd prep.ai.mit.edu. @BITSY.mit.edu. ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29227 ;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4 ;; ANSWER SECTION: prep.ai.mit.edu. 10562 IN A 198.186.203.77 ;; AUTHORITY SECTION: ai.mit.edu. 21600 IN NS FEDEX.ai.mit.edu. ai.mit.edu. 21600 IN NS LIFE.ai.mit.edu. ai.mit.edu. 21600 IN NS ALPHA-BITS.ai.mit.edu. ai.mit.edu. 21600 IN NS BEET-CHEX.ai.mit.edu. ;; ADDITIONAL SECTION: FEDEX.ai.mit.edu. 21600 IN A 192.148.252.43 LIFE.ai.mit.edu. 21600 IN A 128.52.32.80 ALPHA-BITS.ai.mit.edu. 21600 IN A 128.52.32.5 BEET-CHEX.ai.mit.edu. 21600 IN A 128.52.32.22 </verb></tscreen> <p>Esta vez obtenemos una "ANSWER SECTION", y una respuesta para nuestra pregunta. La "AUTHORITY SECTION" contiene información sobre a qué servidores hacer las preguntas sobre <tt/ai.mit.edu/ la próxima vez. Así les puede preguntar directamente la próxima vez que necesite algo de sobre los nombres de <tt/ai.mit.edu/, es decir, cuando preguntamos por <tt/w.ww.mit.edu/ estaremos mucho mas cerca de obtener la respuesta. <p>Así, empezando en <tt/./ encontramos los sucesivos servidores de nombres para cada nivel por referencia. Si has usado tu propio servidor DNS en lugar de usar todos esos servidores, tu named, por supuesto, guardará en el cache toda la información que encuentre mientras consulta para ti, y no tendrá que preguntar de nuevo durante cierto tiempo. <p>En la analogía con el árbol, cada ``<tt/./'' del mismo nombre es un punto de rama. Y cada parte entre ``<tt/./'' son los nombres de ramas individuales del árbol. Uno sube por el árbol tomando el nombre que queremos (<tt/prep.ai.mit.edu/) preguntando a la raíz (<tt/./) o a cualquier servidor más arriba de la raíz hacia prep.ai.mit.edu cuya información tuviéramos en el cache. Una vez que llegamos a los límites del caché las resolución recursiva continúa preguntando a servidores, obteniendo referencias más lejanas del nombre. <p>Aunque se hable mucho menos, un dominio tan importante es <tt/in-addr.arpa/. También se anida como los dominios `normales'. <tt/in-addr.arpa/ nos permite obtener el nombre de host cuando tenemos su dirección. Una cosa importante que tenemos que observar es que las direcciones IP se escriben en orden inverso en el dominio <tt/in-addr.arpa/. Si tiene la dirección de una máquina: <tt/192.186.203.77/ named procede igual que para el ejemplo de <tt/prep.ai.mit.edu/: encuentra servidores <tt/arpa./. Busca servidores <tt/in-addr.arpa./, busca servidores <tt/192.in-addr.arpa./, busca servidores <tt/186.192.in-addr.arpa./, busca servidores<tt/203.186.192.in-addr.arpa./. Busca los registros que necesitamos para <tt/77.203.186.192.in-addr.arpa./ como haría para <tt/prep.ai.mit.edu/. Ejemplo: Al no encontrar una entrada en el cache adecuada salvo `.', pregunta al servidor raíz, <tt/m.root-servers.net/ que te envía a otro servidor raíz. <tt/b.root-servers.net/ nos envia directamente a <tt//bitsy.mit.edu/. Se debería poder tomar ya desde allí. <sect1>Nuestro propio dominio <p>Ahora vamos a definir nuestro propio dominio. Vamos a crear el dominio <tt/linux.bogus/ y definir máquinas en él. Uso un nombre de dominio totalmente falso para estar seguro de que no molestamos a nadie de fuera. <p>Una cosa más antes de empezar: No se permiten todos los caracteres en nombres de máquina. Estamos restringidos a los caracteres del alfabeto inglés: a-z, números 0-9 y el carácter '-' (guión). Manténte en estos caracteres. Las mayúsculas y minúsculas son indistintas para el DNS, así <tt/pat.uio.no/ es idéntico a <tt/Pat.UiO.No/. <p>Ya hemos comenzado esta parte con la siguiente línea en <tt/named.conf/: <code> zone "0.0.127.in-addr.arpa" { type master; file "pz/127.0.0"; }; </code> <p>Por favor, observa la ausencia de `<tt/./' al final de los nombres de dominio en este fichero. Esto dice que ahora vamos a definir la zona <tt/0.0.127.in-addr.arpa/, de la que somos servidor principal ("master") y que está definida en un fichero llamado <tt>pz/127.0.0</tt>. Ya hemos configurado este fichero, en el que podemos leer: <code> $TTL 3D @ IN SOA ns.linux.bogus. hostmaster.linux.bogus. ( 1 ; Serie 8H ; Refresco 2H ; Reintento 4W ; Expira 1D) ; Minimo TTL NS ns.linux.bogus. 1 PTR localhost. </code> <p>Por favor observa los `<tt/./' al final de los nombres de dominio completo en contraste con el archivo <tt>named.conf</tt> anterior. A algunas personas les gusta iniciar cada zona del archivo con una directiva <tt/$ORIGIN/, pero esto es superfluo. El origen (lugar de la jerarquía DNS a donde pertenece) de un fichero de zona se especifica en la seccion <tt>zona</tt> del archivo <tt>named.conf</tt>; en este caso es <tt>0.0.127.in-addr.arpa.</tt> <p>Este ``fichero de zona'' contiene tres <it>registros de recursos</it> (RRs): Un <tt>RR SOA</tt>, Un <tt>RR NS</tt> y un <tt>RR PTR</tt>. <tt>SOA</tt> es una abreviatura de <it>Start Of Authority</it>. La `<tt/@/' es una notación especial que simboliza el origen, y como la columna <tt>dominio</tt> para este archivo indica <tt/0.0.127.in-addr.arpa/. La primera línea realmente significa: <tscreen><verb> 0.0.127.in-addr.arpa. IN SOA ... </verb></tscreen> <p><tt>NS</tt> es el <tt>RR Name Server</tt> (Servidor de Nombres). No hay '@' al comienzo de esta línea; es implícita ya que la línea previa comenzaba con '@'. Eso ahorra algo de tecleo. Así la línea NS se podría haber escrito también como: <tscreen><verb> 0.0.127.in-addr.arpa. IN NS ns.linux.bogus </verb></tscreen> <p>Esto le indica a DNS qué máquina es el servidor de nombres del dominio <tt/0.0.127.in-addr.arpa/ este es <tt/ns.linux.bogus/. 'ns' es un nombre habitual para servidores de nombres, pero como con los servidores web que habitualmente se llaman <tt/www./<em/loquesea/ el nombre puede ser cualquiera. <p>Y finalmente el registro <tt>PTR</tt> (Domain Name Pointer, Puntero de nombre de dominio) le dice que el host con dirección <tt/1/ (igual a <tt/1.0.0.127.IN-ADDR.ARPA/, esto es, <tt/127.0.0.1/) es el llamado <tt/localhost/. El registro <tt>SOA</tt> es el preámbulo de <em/todos/ los archivos de zona y debe haber uno exactamente en cada archivo de zona,(pero tras la directiva <tt/$TTL/ ). El registro <tt>SOA</tt> describe la zona, de dónde proviene (una máquina llamada <tt>linux.bogus</tt>), quién es el responsable de su contenido (<tt>hostmaster@linux. bogus</tt>, deberías poner su dirección de correo aquí, qué versión del archivo de zona es (<tt/Número de Serie/, <tt/1/), y otras cosas que tienen que ver con el caché y los servidores secundarios DNS. Para el resto de los campos (<tt>Tasa de Refresco</tt>, <tt>Tasa de Reintento</tt>, <tt>Caducidad para secundario</tt> y <tt>Tiempo de Validez para Clientes</tt>) usa los valores que aparecen aquí para mayor seguridad. Antes de SOA viene una línea obligatoria, la línea <tt/$TTL 3D/ Ponla en todos tus ficheros de zona. Ahora reinicia tu named (la orden es <tt/rndc stop/ o <tt>/etc/init.d/named restart</tt>) y usa dig para examinar tu trabajo. <tt/-x/ pregunta por resolución inversa: <tscreen><verb> $ dig -x 127.0.0.1 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30944 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;1.0.0.127.in-addr.arpa. IN PTR ;; ANSWER SECTION: 1.0.0.127.in-addr.arpa. 259200 IN PTR localhost. ;; AUTHORITY SECTION: 0.0.127.in-addr.arpa. 259200 IN NS ns.linux.bogus. ;; Query time: 3 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Dec 23 03:02:39 2001 ;; MSG SIZE rcvd: 91 </verb></tscreen> <p>Así gestiona para obtener <tt/localhost/ de 127.0.0.1, bien. Ahora para nuestro tarea principal, el dominio <tt/linux.bogus/,inserta una nueva sección 'zone' en <tt/named.conf/: <code> zone "linux.bogus" { notify no; type master; file "pz/linux.bogus"; }; </code> <p>Observa de nuevo la ausencia de `<tt/./' final en el nombre de dominio en el fichero <tt/named.conf/. <p>En el fichero de zona <tt/linux.bogus/ pondremos datos totalmente ficticios <footnote>N del T &nl; Por si no lo has notado todavía, <it/bogus/ en inglés significa precisamente <it/falso/.</footnote>: <code> ; ; Fichero de zona para linux.bogus ; ; El fichero de zona completo ; $TTL 3D @ IN SOA ns.linux.bogus. hostmaster.linux.bogus. ( 199802151 ; serie, fecha de hoy + serie de hoy # 8H ; refresco, segundos 2H ; reintento, segundos 4W ; expira, segundos 1D ) ; mínimo, segundos ; NS ns ; Dirección Inet del servidor de nombres MX 10 mail.linux.bogus ; Relay de correo primario MX 20 mail.friend.bogus. ; Relay de correo secundario ; localhost A 127.0.0.1 ns A 192.168.196.2 mail A 192.168.196.4 </code> <p>Deben de observarse dos cosas sobre los registros <tt>SOA</tt>. <tt>ns.linux.bogus</tt> <em/debe/ ser una máquina actual con un registro <tt>A</tt>. No es legal tener un registro <tt/CNAME/ para la máquina mencionada en el registro <tt>SOA</tt>. Su nombre no necesita ser <tt>ns</tt>, podría ser cualquier nombre legal de máquina. A continuación, en <tt>hostmaster.linux.bogus</tt> deberá aparecer algo como <tt>hostmaster@linux.bogus</tt>; esto sería un alias de email, o una cuenta de correo, donde la(s) persona(s) que realizan el mantenimiento de DNS deberían leer con frecuencia el correo. Cualquier email respecto del dominio será mandado a la dirección aquí indicada. El nombre no tiene por que ser <tt>hostmaster</tt>, puede ser cualquier dirección email legal, pero la dirección email <tt>hostmaster</tt> funcionará también. <p>Hay un nuevo tipo de <tt>RR</tt> en este archivo, el <tt>MX</tt>, o <it>Mail eXchanger</it>. Este indica el sistema de correo a donde mandar el correo dirigido a <tt>alguien@linux.bogus</tt>, pudiendo ser también <tt>mail.linux.bogus</tt> o <tt>mail.friend.bogus</tt>. El número que precede a cada nombre de máquina es la prioridad del <tt>RR MX</tt>. El <tt/RR/ con el número más bajo (<tt/10/) es aquel al que el correo será enviado primero. Si este falla, puede ser mandado a otro con un número más alto, que será gestor secundario de correo, como <tt>mail.friend.bogus</tt> que tiene una prioridad <tt/20/ aquí. <p>Reinicia <tt>named</tt> ejecutando <tt>rndc reload</tt>. Examina los resultados con <tt>dig</tt>: <tscreen><verb> $ dig any linux.bogus ; <<>> DiG 9.1.3 <<>> any linux.bogus ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55239 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;linux.bogus. IN ANY ;; ANSWER SECTION: linux.bogus. 259200 IN SOA ns.linux.bogus. \ hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400 linux.bogus. 259200 IN NS ns.linux.bogus. linux.bogus. 259200 IN MX 20 mail.friend.bogus. linux.bogus. 259200 IN MX 10 mail.linux.bogus.linux.bogus. ;; AUTHORITY SECTION: linux.bogus. 259200 IN NS ns.linux.bogus. ;; ADDITIONAL SECTION: ns.linux.bogus. 259200 IN A 192.168.196.2 ;; Query time: 4 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Dec 23 03:06:45 2001 ;; MSG SIZE rcvd: 184 $ dig any linux.bogus ; <<>> DiG 9.1.3 <<>> any linux.bogus ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55239 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;linux.bogus. IN ANY ;; ANSWER SECTION: linux.bogus. 259200 IN SOA ns.linux.bogus. \ hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400 linux.bogus. 259200 IN NS ns.linux.bogus. linux.bogus. 259200 IN MX 20 mail.friend.bogus. linux.bogus. 259200 IN MX 10 mail.linux.bogus.linux.bogus. ;; AUTHORITY SECTION: linux.bogus. 259200 IN NS ns.linux.bogus. ;; ADDITIONAL SECTION: ns.linux.bogus. 259200 IN A 192.168.196.2 ;; Query time: 4 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Dec 23 03:06:45 2001 ;; MSG SIZE rcvd: 184$ dig any linux.bogus ; <<>> DiG 9.1.3 <<>> any linux.bogus ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55239 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;linux.bogus. IN ANY ;; ANSWER SECTION: linux.bogus. 259200 IN SOA ns.linux.bogus. \ hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400 linux.bogus. 259200 IN NS ns.linux.bogus. linux.bogus. 259200 IN MX 20 mail.friend.bogus. linux.bogus. 259200 IN MX 10 mail.linux.bogus.linux.bogus. ;; AUTHORITY SECTION: linux.bogus. 259200 IN NS ns.linux.bogus. ;; ADDITIONAL SECTION: ns.linux.bogus. 259200 IN A 192.168.196.2 ;; Query time: 4 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Dec 23 03:06:45 2001 ;; MSG SIZE rcvd: 184 $ dig any linux.bogus ; <<>> DiG 9.1.3 <<>> any linux.bogus ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55239 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;linux.bogus. IN ANY ;; ANSWER SECTION: linux.bogus. 259200 IN SOA ns.linux.bogus. \ hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400 linux.bogus. 259200 IN NS ns.linux.bogus. linux.bogus. 259200 IN MX 20 mail.friend.bogus. linux.bogus. 259200 IN MX 10 mail.linux.bogus.linux.bogus. ;; AUTHORITY SECTION: linux.bogus. 259200 IN NS ns.linux.bogus. ;; ADDITIONAL SECTION: ns.linux.bogus. 259200 IN A 192.168.196.2 ;; Query time: 4 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Dec 23 03:06:45 2001 ;; MSG SIZE rcvd: 184 </verb></tscreen> <p>Con un examen cuidadoso puede descubrir fallos. La línea <tscreen><verb> linux.bogus. 3D IN MX 10 mail.linux.bogus.linux.bogus. </verb></tscreen> <p>está completamente equivocada. Debería ser <tscreen><verb> linux.bogus. 3D IN MX 10 mail.linux.bogus. </verb></tscreen> <p>Deliberadamente cometí un error para que pudieras aprender de él. :-) Mirando en el fichero de zona encontramos la línea: <tscreen><verb> MX 10 mail.linux.bogus ; Relay de correo primario </verb></tscreen> <p>Falta un punto. O tiene demasiados 'linux.bogus'. Si una nombre de máquina no termina en punto, en un fichero de zona, se le añade el origen al final ocasionado el doble <tt/linux.bogus.linux.bogus/. Entonces, o bien <code> MX 10 mail.linux.bogus. ; Relay de correo primario </code> o <code> MX 10 mail ; Relay de correo primario </code> es correcto. Prefiero la última forma, hay que teclear menos. Hay algunos expertos den BIND que no están de acuerdo con esto y otros que sí. En un fichero de zona el dominio debería de escribirse bien finalizado con un `<tt/./' o no debería incluirse, en cuyo caso toma como valor predeterminado el origen. <p>Tengo que insistir que en el fichero named.conf <em/no/ se tiene que poner `<tt/./'s tras los nombres de dominio. No tienes ni idea de cuantas veces un `<tt/./' por ponerlo o por no ponerlo ha estropeado todo y ha vuelto loca a la gente. <p>Y habiendo incluido mi punto,aquí está el nuevo fichero de zona, con alguna información extra también: <code> ; ; Fichero de zona para linux.bogus ; ; Fichero de zona completo ; $TTL 3D @ IN SOA ns.linux.bogus. hostmaster.linux.bogus. ( 199802151 ; seriel, fecho de hoy + serie de hoy # 8H ; refresco, segundos 2H ; reintento, segundos 4W ; expira, segundos 1D ) ; mínimo, segundos ; TXT "Linux.Bogus, sus consutas DNS" NS ns ; Inet Address of name server NS ns.friend.bogus. MX 10 mail ; Relay primario de correo MX 20 mail.friend.bogus. ; Relay secundario de correo localhost A 127.0.0.1 gw A 192.168.196.1 TXT "El router" ns A 192.168.196.2 MX 10 mail MX 20 mail.friend.bogus. www CNAME ns donald A 192.168.196.3 MX 10 mail MX 20 mail.friend.bogus. HINFO "i486" "Linux 2.0" TXT "DEK" mail A 192.168.196.4 MX 10 mail MX 20 mail.friend.bogus. ftp A 192.168.196.5 MX 10 mail MX 20 mail.friend.bogus. </code> <p>El registro <tt>TXT</tt> es un texto en formato libre que puede usar para cualquier cosa que le interese. <tt>CNAME</tt> (<it>Canonical NAME</it>) es una forma de dar a cada máquina varios nombres. Por tanto <tt>www</tt> es un alias para <tt>ns</tt>. <p> El uso de registros CNAME es controvertido. Pero es más seguro seguir la norma de que los registros <tt>MX</tt>, <tt>CNAME</tt> y <tt>SOA</tt> <bf>nunca deben hacer referencia a un registro</bf> <tt/CNAME/, sólo deben referirse a registros <tt>A</tt>, en consecuencia es desaconsejable tener <code> foobar CNAME www ; NO! </code> lo correcto sería tener <code> foobar CNAME ns ; Si! </code> <p>También es mejor suponer que un <tt>CNAME</tt> no es un nombre de máquina legal para direcciones de correo: <tt>webmaster@www.linux.bogus</tt> es una dirección email ilegaldada en la configuración anterior. Encontrarás muy pocos administradores de correo de Ahí Afuera que recomienden esta regla, incluso si te funciona. La forma de evitar esto es usar un registro <tt>A</tt> (y quizá algunos otros también, como un registro <tt>MX</tt>) en su lugar: <code> www A 192.168.196.2 </code> <p>Algunos gurús de <tt>named</tt> recomiendan no usar CNAME. Por tanto considera el no utilizarlo seriamente. Pero la discusión de por qué o no está más allá de los objetivos de este documento. <p>Pero como puede ver, en este COMO y en muchos sitios no siguen esta regla. Cargue la nueva base de datos ejecutando <tt>rndc reload</tt>, esto provoca la lectura de sus archivos de nuevo. <tscreen><verb> $ dig linux.bogus axfr ; <<>> DiG 9.1.3 <<>> linux.bogus axfr ;; global options: printcmd linux.bogus. 259200 IN SOA ns.linux.bogus. hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400 linux.bogus. 259200 IN NS ns.linux.bogus. linux.bogus. 259200 IN MX 10 mail.linux.bogus. linux.bogus. 259200 IN MX 20 mail.friend.bogus. donald.linux.bogus. 259200 IN A 192.168.196.3 donald.linux.bogus. 259200 IN MX 10 mail.linux.bogus. donald.linux.bogus. 259200 IN MX 20 mail.friend.bogus. donald.linux.bogus. 259200 IN TXT "DEK" ftp.linux.bogus. 259200 IN A 192.168.196.5 ftp.linux.bogus. 259200 IN MX 10 mail.linux.bogus. ftp.linux.bogus. 259200 IN MX 20 mail.friend.bogus. gw.linux.bogus. 259200 IN A 192.168.196.1 gw.linux.bogus. 259200 IN TXT "The router" localhost.linux.bogus. 259200 IN A 127.0.0.1 mail.linux.bogus. 259200 IN A 192.168.196.4 mail.linux.bogus. 259200 IN MX 10 mail.linux.bogus. mail.linux.bogus. 259200 IN MX 20 mail.friend.bogus. ns.linux.bogus. 259200 IN MX 10 mail.linux.bogus. ns.linux.bogus. 259200 IN MX 20 mail.friend.bogus. ns.linux.bogus. 259200 IN A 192.168.196.2 www.linux.bogus. 259200 IN CNAME ns.linux.bogus. linux.bogus. 259200 IN SOA ns.linux.bogus. hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400 ;; Query time: 41 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Dec 23 03:12:31 2001 ;; XFR size: 23 records </verb></tscreen> <p>Está bien. Como ves, se parece bastante al propio ficheros de zona. Comprobamos que dice para <tt/www/ solo: <tscreen><verb> $ dig www.linux.bogus ; <<>> DiG 9.1.3 <<>> www.linux.bogus ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16633 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.linux.bogus. IN A ;; ANSWER SECTION: www.linux.bogus. 259200 IN CNAME ns.linux.bogus. ns.linux.bogus. 259200 IN A 192.168.196.2 ;; AUTHORITY SECTION: linux.bogus. 259200 IN NS ns.linux.bogus. ;; Query time: 5 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Dec 23 03:14:14 2001 ;; MSG SIZE rcvd: 80 </verb></tscreen> <p>En otras palabras, el nombre real de <tt/www.linux.bogus/ es <tt/ns.linux.bogus/, y te da parte de la información que tiene de ns también, suficiente si fueras un programa. <p>Ahora estamos a mitad de camino. <sect1>La zona inversa <p>Ahora los programas pueden convertir los nombres de linux.bogus a direcciones a las que poder conectarse. Pero también se necesita una zona inversa, una para hacer que DNS sea capaz de convertir de direcciones a nombres. Ese nombre lo utilizan distintos tipos de servidores (FTP, IRC, WWW y otros) para decidir si quieren o no hablar contigo, y en caso afirmativo, qué prioridad se le debería dar. Para un acceso completo a los servicios de internet se necesita una zona inversa. <p>Pon esto en <tt/named.conf/: <code> zone "196.168.192.in-addr.arpa" { notify no; type master; file "pz/192.168.196"; }; </code> <p>Esto es exactamente como en <tt/0.0.127.in-addr.arpa/, y los contenidos son similares: <code> $TTL 3D @ IN SOA ns.linux.bogus. hostmaster.linux.bogus. ( 199802151 ; Serial, todays date + todays serial 8H ; Refresco 2H ; Reintento 4W ; Expira 1D) ; Minimo TTL NS ns.linux.bogus. 1 PTR gw.linux.bogus. 2 PTR ns.linux.bogus. 3 PTR donald.linux.bogus. 4 PTR mail.linux.bogus. 5 PTR ftp.linux.bogus. </code> <p>Ahora reinicia tu named (<tt/rndc reload/) y examina el trabajo con dig de nuevo: <code> $ dig -x 192.168.196.4 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58451 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;4.196.168.192.in-addr.arpa. IN PTR ;; ANSWER SECTION: 4.196.168.192.in-addr.arpa. 259200 IN PTR mail.linux.bogus. ;; AUTHORITY SECTION: 196.168.192.in-addr.arpa. 259200 IN NS ns.linux.bogus. ;; ADDITIONAL SECTION: ns.linux.bogus. 259200 IN A 192.168.196.2 ;; Query time: 4 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Dec 23 03:16:05 2001 ;; MSG SIZE rcvd: 107 </code> <p>y parece correcto, vuelca todo y examínalo también: <code> $ dig 196.168.192.in-addr.arpa. AXFR ; <<>> DiG 9.1.3 <<>> 196.168.192.in-addr.arpa. AXFR ;; global options: printcmd 196.168.192.in-addr.arpa. 259200 IN SOA ns.linux.bogus. \ hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400 196.168.192.in-addr.arpa. 259200 IN NS ns.linux.bogus. 1.196.168.192.in-addr.arpa. 259200 IN PTR gw.linux.bogus. 2.196.168.192.in-addr.arpa. 259200 IN PTR ns.linux.bogus. 3.196.168.192.in-addr.arpa. 259200 IN PTR donald.linux.bogus. 4.196.168.192.in-addr.arpa. 259200 IN PTR mail.linux.bogus. 5.196.168.192.in-addr.arpa. 259200 IN PTR ftp.linux.bogus. 196.168.192.in-addr.arpa. 259200 IN SOA ns.linux.bogus. \ hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400 ;; Query time: 6 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Dec 23 03:16:58 2001 ;; XFR size: 9 records </code> <p>¡Parece bien! Si tu salida no se parece, busca algún mensaje de error en tu syslog, explico como hacerlo en la primera sección en la cabecera <ref id="iniciando" name="Starting named"> <sect1>Palabras de precaución <p>Hay algunas cosas que añadiría aquí. Las direcciones IP utilizadas en los ejemplos se han tomado del rango de 'redes privadas',i.e., no se permite usarlas públicamente en internet. Esto es más seguro para usar en un ejemplo en el COMO. Las segunda cosa es la línea <tt/notify no;/. Esta le dice a named que no notifique a sus servidores secundarios (eslave, esclavos) cuando haya realizado una actualización de uno de sus ficheros de zona. En BIND-8 y posteriores named puede notificar al resto de servidores listados en registros NS de la zona cuando se actualiza una zona. Es bueno para el uso ordinario. Pero para experimentos privados con zonas, se debería deshabilitar esta característica. No queremos que los experimentos contaminen internet ¿no?. <p>Y por supuesto, este dominio es ficticio y en consecuencia, todas las direcciones que hay en él. Para tener un ejemplo de dominio de la vida real mira la sección correspondiente. <sect1>Por qué no funciona la resolución inversa <p>Hay una serie de pegas que normalmente se evitan con búsquedas de nombres que se ven con frecuencia cuando se configuran las zonas inversas. Ante de proseguir, necesitas que funcionen las búsquedas inversas en tu propio servidor de nombres. Si aun no funciona vuelve atrás y corrígelo antes de continuar. <p>Discutiré dos fallos de las búsquedas inversas tal y como se ven desde fuera de tu red: <sect2>La zona inversa no está delegada. <p>Cuando le solicita a un proveedor de servicios un rango de red y un nombre de dominio, el nombre de dominio normalmente se delega. Una delegación es el registro NS que te ayuda a obtener de un servidor de nombres otro servidor de nombres, como se explicaba en la anterior sección "Un poco de teoría a secas". ¿La has leído? Si tu zona inversa no funciona, vuelve y léela. Ahora. <p>La zona inversa también necesita ser delegada. Si tienes la red <tt/192.168.196/ con el dominio <tt/linux.bogus/ de tu proveedor, ellos tienen que poner registros <tt/NS/ para tu zona inversa también como para tus zonas de reenvío. Si sigues la cadena desde <tt/in-addr.arpa/ hasta llegar a tu red, probablemente encontrarás una ruptura en la cadena, los más probable en tu proveedor de servicios. Cuando hayas encontrado la ruptura de la cadena, contacta con tu proveedor de servicios y pídeles que corrijan el error. <sect2>Tienes una subred sin clases <p>Esta es una cuestión avanzada, pero las subredes sin clase son muy comunes hay día, y probablemente tendrás una si tienes una pequeña empresa. <p>Las subredes sin clase es lo que mantiene internet en funcionamiento hoy día. Hace algunos años. Hace no mucho tiempo había mucha dificultad para acortar las direcciones IP. La gente inteligente del IETF (Internet Engineering Task Force, ellos mantienen internet en funcionamiento) se devanaron juntos los sesos y resolvieron el problema. A un precio. El precio es que obtienes menos que una subred de clase ``C'' y ciertas cosas pueden no funcionar. Por favor mira <url name="Preguntar a Mr. DNS (Ask Mr. DNS at)" url="http://www.acmebw.com/askmrdns/00007.htm"> para tener una buena explicación sobre todo esto y como gestionarlo. <p>¿Lo has leído? No lo voy a explicar, por favor léelo. <p>La primera parte del problema es que tu ISP tiene que entender la técnica descrita por Mr. DNS. No todos los pequeños proveedores comprenden esto de forma práctica. Si es así, tendrías que explicárselo tú y ser insistente. Pero primero asegúrate de entenderlo tú :-). Así ellos configurarán un bonita zona inversa en sus servidores que tú puedes examinar con dig para posibles correcciones. <p>La segunda y última parte del problema es que tienes que entender la técnica. Si no estás seguro, vuelve y lee todos esto de nuevo. Ahora puedes configurar tu propia zona inversa sin clases como lo describe Mr. DNS. <p>Hay otra trampa escondida aquí. Los resolutores (muy) viejos <em/no/ podrán seguir el truco <tt/CNAME/ en la cadena de resolución y fallarán en la resolución inversa de tu máquina. Esto puede ocasionar en el servicio la asignación de una clase de acceso incorrecta, denegación de acceso o algo similar. Si tropiezas con este servicio la única solución (que yo sepa) es que tu ISP inserte tu registro PTR directamente en su fichero de zona sin clase en lugar del truco del registro CNAME. <p>Algunos ISP te pueden ofrecer otras formas de gestionar esto, como formularios Web para que introduzca las relaciones inversas u otros sistema automágicos. <sect1>Servidores esclavos <p>Una vez que hayas configurado tus zonas correctamente en el servidor principal, necesitas configurar al menos un servidor esclavo. Los servidores esclavos son necesarios por motivos de robustez. Si cae el servidor principal, la gente de la red todavía podrá obtener información sobre tu dominio a partir del esclavo. Tu servidor esclavo debería estar tan alejado de ti como sea posible. El principal y el esclavo deberían compartir los menos posibles de entre estos aspectos: Suministro eléctrico, red local, ISP, ciudad país. Si todas estas cosas son diferentes para sus servidores principal y esclavo, ha encontrado realmente un buen esclavo. <p>Un esclavo es simplemente un servidor de nombres que copia los ficheros de zona de un principal. Lo puedes poner como: <code> zone "linux.bogus" { type slave; file "sz/linux.bogus"; masters { 192.168.196.2; }; }; </code> <p>Para copiar los datos se usa un mecanismo llamado transferencias de zona. La transferencia de zona esta controlada por su registro SOA: <code> @ IN SOA ns.linux.bogus. hostmaster.linux.bogus. ( 199802151 ; serie, fecha de hoy + serie de hoy # 8H ; refresco, segundos 2H ; reintento, segundos 4W ; expira, segundos 1D ) ; minimo, segundos </code> <p>Una zona solo se transfiere si el numero de serie del principal es mayor que el del esclavo. En cada intervalo de refresco el esclavo comprueba si el principal se ha actualizado. Si la comprobación falla (porque el principal no esté disponible) intentará comprobarlo cada intervalo de reintento. Si el fallo continúa hasta el intervalo de expiración el esclavo eliminará la zona de su sistema de ficheros y ya no volverá a estar disponible. <sect>Opciones de seguridad básicas <label id="seguridad"> <p><em/Por Jamie Norrish/ <p><bf/Opciones de configuración para reducir los problemas de seguridad./ <p>Hay algunos pasos simples que puede llevara cabo para asegurar su servidor y reducir su carga. El material incluido aquí no es más que un punto de partida; si te preocupan los temas de seguridad (y deberían preocuparte), por favor, consulta otros recursos en la red (mira el <ref id="grande" name="último capítulo">). <p>Las siguientes directivas de configuración se incluyen en el fichero <tt/named.conf/. Si la directiva aparece en la sección <tt/options/ del fichero, entonces se aplica a todas las zonas incluidas en ese fichero. Si aparecen en una entrada <tt/zone/, entonces se aplican sólo a esa zona. Los valores de <tt/zone/ se anteponen a los especificados en <tt/options/. <Sect1>Restringir transferencias de zona <p>Para que sus servidores esclavos puedan responder consultas sobre tu dominio tienen que poder transferir la información de la zona de tu servidor primario. Del resto, muy pocas máquinas deberían hacerlo. Por tanto, restringe las transferencias de zona usando la opción <tt/allow-transfer/, suponiendo que 192.168.1.4 es la dirección IP de ns.friend.bogus y añádete a ti mismo por motivos de depuración: <code> zone "linux.bogus" { allow-transfer { 192.168.1.4; localhost; }; }; </code> <p>Al restringir las transferencias de zona te aseguras que la información pública disponible es la que la gente consulte directamente, nadie puede preguntar detalles sobre la configuración del servidor. <Sect1>Protegerse contra falsificaciones <p>Primero, desactiva cualquier consulta para dominios que no sean de tu propiedad, salvo para consultas internas y la máquina local. Esto no sólo ayuda a prevenir el uso malicioso de tu servidor DNS, sino que reduce el uso innecesario de tu servidor. <code> options { allow-query { 192.168.196.0/24; localhost; }; }; zone "linux.bogus" { allow-query { any; }; }; zone "196.168.192.in-addr.arpa" { allow-query { any; }; }; </code> <p>Más aun, desactiva las consultas recursivas salvo para orígenes internos/locales. Esto reduce el riesgo de "ataques de envenenamiento" (que alimentan tu servidor con datos falsos). <code> options { allow-recursion { 192.168.196.0/24; localhost; }; }; </code> <Sect1>Ejecutar named no como root <p>Es buena idea ejecutar named como un usuario distinto de root, de forma que los privilegios obtenidos por un cracker estén tan limitados como sea posible. Primero tenemos que crear unos usuario y grupo para ejecutar named, y después modificar los guiones de inicio necesarios que uses para lanzar named. Pasa el usuario y el grupo a named usando las opciones -u y -g. <p>Por ejemplo, en Debian GNU/Linux 2.2 podría modificar su guion <tt>/etc/init.d/bind</tt> para tener la siguiente línea (donde el usuario y el grupo ya se han creado): <code> start-stop-daemon --start --quiet --exec /usr/sbin/named -- -u named -g named </code> <p>Lo mismo se puede hacer con Red Hat y otras distribuciones. Dave Lugo ha descrito una configuración dual chroot segura <url url="http://www.etherboy.com/d ns/chrootdns.html"> que te puede resultar interesante leer. <sect>Un ejemplo de dominio real<label id="real-example"> <p><bf/Donde incluimos algunos ficheros de zona <em/reales/./ <p>Algunos usuarios han sugerido que incluya un ejemplo real de un dominio en funcionamiento además del ejemplo del tutorial. <p>Yo uso este ejemplo con permiso de David Bullock de LAND-5. Estos archivos eran los usados el 24 de Septiembre de 1996, se han editado para adaptarse a las restricciones de BIND 8 y uso mis extensiones. Así lo que ve podría diferir de los que encuentres si preguntas ahora al servidor de nombres LAND-5. <sect1>/etc/named.conf (o /var/named/named.conf) <p>Aquí encontramos las secciones de zonas principales para las dos zonas de resolución inversa necesarias: tanto la red 127.0.0 como la subred <tt/206.6.177/ de LAND-5, y una línea primaria para la zona de reenvío de land-5, <tt/land-5.com/. También observa que en lugar de almacenar los ficheros en un directorio llamado <tt/pz/, como hace en este COMO, él los pone en un directorio llamado <tt/zone/. <code> // Boot file for LAND-5 name server options { directory "/var/named"; }; controls { inet 127.0.0.1 allow { localhost; } keys { rndc_key; }; }; key "rndc_key" { algorithm hmac-md5; secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K"; }; zone "." { type hint; file "root.hints"; }; zone "0.0.127.in-addr.arpa" { type master; file "zone/127.0.0"; }; zone "land-5.com" { type master; file "zone/land-5.com"; }; zone "177.6.206.in-addr.arpa" { type master; file "zone/206.6.177"; }; </code> <p>Si pones esto en tu fichero named.conf para probar <bf/POR FAVOR/ pon ``<tt/notify no;/'' en la sección de zona para las dos zonas <tt/land-5/ para evitar accidentes. <sect1>/var/named/root.hints <p>Tenga en cuenta que este fichero es dinámico, y el listado aquí es viejo. Lo mejor es usar uno creado ahora, con dig, como se explicaba antes. <code> ; <<>> DiG 8.1 <<>> @A.ROOT-SERVERS.NET. ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13 ;; QUERY SECTION: ;; ., type = NS, class = IN ;; ANSWER SECTION: . 6D IN NS G.ROOT-SERVERS.NET. . 6D IN NS J.ROOT-SERVERS.NET. . 6D IN NS K.ROOT-SERVERS.NET. . 6D IN NS L.ROOT-SERVERS.NET. . 6D IN NS M.ROOT-SERVERS.NET. . 6D IN NS A.ROOT-SERVERS.NET. . 6D IN NS H.ROOT-SERVERS.NET. . 6D IN NS B.ROOT-SERVERS.NET. . 6D IN NS C.ROOT-SERVERS.NET. . 6D IN NS D.ROOT-SERVERS.NET. . 6D IN NS E.ROOT-SERVERS.NET. . 6D IN NS I.ROOT-SERVERS.NET. . 6D IN NS F.ROOT-SERVERS.NET. ;; ADDITIONAL SECTION: G.ROOT-SERVERS.NET. 5w6d16h IN A 192.112.36.4 J.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.10 K.ROOT-SERVERS.NET. 5w6d16h IN A 193.0.14.129 L.ROOT-SERVERS.NET. 5w6d16h IN A 198.32.64.12 M.ROOT-SERVERS.NET. 5w6d16h IN A 202.12.27.33 A.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.4 H.ROOT-SERVERS.NET. 5w6d16h IN A 128.63.2.53 B.ROOT-SERVERS.NET. 5w6d16h IN A 128.9.0.107 C.ROOT-SERVERS.NET. 5w6d16h IN A 192.33.4.12 D.ROOT-SERVERS.NET. 5w6d16h IN A 128.8.10.90 E.ROOT-SERVERS.NET. 5w6d16h IN A 192.203.230.10 I.ROOT-SERVERS.NET. 5w6d16h IN A 192.36.148.17 F.ROOT-SERVERS.NET. 5w6d16h IN A 192.5.5.241 ;; Total query time: 215 msec ;; FROM: roke.uio.no to SERVER: A.ROOT-SERVERS.NET. 198.41.0.4 ;; WHEN: Sun Feb 15 01:22:51 1998 ;; MSG SIZE sent: 17 rcvd: 436 </code> <sect1>/var/named/zone/127.0.0 <p>Sólo lo básico, el registro SOA y el registro que asocia 127.0.0.1 con <tt/localhost/. Ambos son necesarios. No es necesario nada más en este fichero. Probablemente nunca tendrá que actualizarse, salvo que cambien las direcciones del servidor de nombres o del hostmaster. <code> @ IN SOA land-5.com. root.land-5.com. ( 199609203 ; Serial 28800 ; Refresh 7200 ; Retry 604800 ; Expire 86400) ; Minimum TTL NS land-5.com. 1 PTR localhost. </code> <p>Si miras una instalación de BIND al azar, probablemente encontrarás que falta una línea <tt/$TTL/ como aquí. Esto no se usaba antes, y sólo la versión 8.2 de BIND ha comenzado a avisarnos de su ausencia. BIND 9 <em/requiere/ el <tt/$TTL/. <footnote>N.T. Mira de nuevo los datos de syslog para detectar la ausencia de un TTL predeterminado.</footnote> <sect1>/var/named/zone/land-5.com <p>Aquí vemos el registro <tt>SOA</tt> obligatorio y los registros <tt>NS</tt> necesarios. Podemos observar que dispone de un servidor de nombres secundario <tt>ns2.psi.net</tt>. Esto es como debe ser, ten <em/siempre/ un servidor secundario de seguridad. También podemos ver que tiene una máquina principal llamada <tt/land-5/ que se encarga de todos los diferentes servicios de internet, y que se ha hecho usando <tt>CNAME</tt> (una alternativa al uso de los registros <tt/A/). <p>Como puedes ver en el registro <tt>SOA</tt>, el origen del archivo de zona es <tt/land-5.com/, la persona de contacto es <tt>root@land-5.com.</tt> <tt/hostmaster/ es otro uso frecuente para la persona de contacto. El número de serie en el formato habitual <it/yyyymmdd/ con el número de serie de hoy añadido; esta es probablemente la sexta versión del archivo de zona del 20 de Septiembre de 1996. Recuerde que el número de serie debe incrementarse monótonamente, aquí hay sólo <em/un/ dígito para las series de hoy, así que después de 9 ediciones tendrás que esperar hasta mañana antes de poder editar el el archivo de nuevo. Considera el uso de dos dígitos. <code> $TTL 3D @ IN SOA land-5.com. root.land-5.com. ( 199609206 ; serial, todays date + todays serial # 8H ; refresh, seconds 2H ; retry, seconds 4W ; expire, seconds 1D ) ; minimum, seconds NS land-5.com. NS ns2.psi.net. MX 10 land-5.com. ; Primary Mail Exchanger TXT "LAND-5 Corporation" localhost A 127.0.0.1 router A 206.6.177.1 land-5.com. A 206.6.177.2 ns A 206.6.177.3 www A 207.159.141.192 ftp CNAME land-5.com. mail CNAME land-5.com. news CNAME land-5.com. funn A 206.6.177.2 ; ; Workstations ; ws-177200 A 206.6.177.200 MX 10 land-5.com. ; Primary Mail Host ws-177201 A 206.6.177.201 MX 10 land-5.com. ; Primary Mail Host ws-177202 A 206.6.177.202 MX 10 land-5.com. ; Primary Mail Host ws-177203 A 206.6.177.203 MX 10 land-5.com. ; Primary Mail Host ws-177204 A 206.6.177.204 MX 10 land-5.com. ; Primary Mail Host ws-177205 A 206.6.177.205 MX 10 land-5.com. ; Primary Mail Host ; {Many repetitive definitions deleted - SNIP} ws-177250 A 206.6.177.250 MX 10 land-5.com. ; Primary Mail Host ws-177251 A 206.6.177.251 MX 10 land-5.com. ; Primary Mail Host ws-177252 A 206.6.177.252 MX 10 land-5.com. ; Primary Mail Host ws-177253 A 206.6.177.253 MX 10 land-5.com. ; Primary Mail Host ws-177254 A 206.6.177.254 MX 10 land-5.com. ; Primary Mail Host </code> <p>Si examinas el servidor de nombres de land-5 verás que los nombres de host son de la forma <tt/ws_/<em/number/. Como desde las versiones de BIND 4 named fuerza la restricción sobre qué caracteres se pueden usar en los nombres de máquina. Por eso no funcionará del todo con BIND-8 y he sustituido '-' (guiones) por los '_' (subrayados) para usarlo en este COMO. Pero como se mencianaba anteriormente BIND9 ya no fuerza esta restricción. <p>Otra cosa a tener en cuenta es que las estaciones de trabajo no tienen nombres propios, sino un prefijo seguido por las dos últimas porciones de los números IP. Usar tal convención puede simplificar el mantenimiento significativamente, pero puede resultar un poquito impersonal, y de hecho, ser una fuente de irritación de los clientes. <p>También vemos que <tt/funn.land-5.com/ es un alias de <tt/land-5.com/, pero usando un registro A, no un registro CNAME. Esto es una buena política como observamos anteriormente. <sect1>/var/named/zone/206.6.177 <p>Ya comentaré este fichero más abajo. <code> $TTL 3D @ IN SOA land-5.com. root.land-5.com. ( 199609206 ; Serial 28800 ; Refresh 7200 ; Retry 604800 ; Expire 86400) ; Minimum TTL NS land-5.com. NS ns2.psi.net. ; ; Servers ; 1 PTR router.land-5.com. 2 PTR land-5.com. 2 PTR funn.land-5.com. ; ; Workstations ; 200 PTR ws-177200.land-5.com. 201 PTR ws-177201.land-5.com. 202 PTR ws-177202.land-5.com. 203 PTR ws-177203.land-5.com. 204 PTR ws-177204.land-5.com. 205 PTR ws-177205.land-5.com. ; {Many repetitive definitions deleted - SNIP} 250 PTR ws-177250.land-5.com. 251 PTR ws-177251.land-5.com. 252 PTR ws-177252.land-5.com. 253 PTR ws-177253.land-5.com. 254 PTR ws-177254.land-5.com. </code> <p>La <bf>zona de resolución inversa</bf> es la parte de la configuración que parece crear más dolores de cabeza. <bf>Se usa para encontrar el nombre de la máquina a partir de su dirección IP</bf>. Ejemplo: supon que estás en un servidor FTP y acepta conexiones de clientes <tt/ftp/. El servidor <tt/ftp/ es noruego y quiere aceptar mas conexiones de clientes de Noruega y otros países escandinavos y menos del resto del mundo. Cuando se produce una conexión de un cliente, la librería <it/C/ es capaz de indicar el número IP de la máquina conectada porque el número IP del cliente está contenido en todos los paquetes que se pasan a través de la red. Ahora puede llamar a una función llamada <tt>gethostbyaddr</tt> que busca el nombre de la máquina dada su dirección IP. <tt>gethostbyaddr</tt> interrogará a un servidor DNS el cual efectuará una búsqueda DNS para la máquina. Suponiendo que la conexión cliente viene de <tt/ws_177200.land-5.com/, la dirección IP que la librería <it/C/ proporciona al servidor irc será <tt/206.6.177.200/. Para encontrar el nombre de la máquina necesitamos encontrar <tt/200.177.6.206.in-addr.arpa/. El servidor DNS primero encuentra los servidores <tt/arpa./, después los servidores <tt/in-addr.arpa./, a continuación sigue por <tt/206/, <tt/6/ y al final busca el servidor para la zona <tt/177.6.206.in-addr.arpa/ en <tt/land-5/. Aquí obtendrá finalmente que para <tt/200.177.6.206.in-addr.arpa/ tenemos un registro `<tt>PTR ws_177200.land-5.com</tt>', que significa que el nombre que va con <tt/206.6.177.200/ es <tt/ws_177200.land-5.com/. Como con la explicación de cómo buscar <tt/prep.ai.mit.edu/, esto es ligeramente ficticio. Volviendo al ejemplo del servidor FTP. El servidor FTP prioriza las conexiones de los países escandinavos, osea, <tt/*.no/, <tt/*.se/, y <tt/*.dk/; el nombre <tt/ws_177200.land-5.com/ claramente no se ajusta a ninguno de ellos, y el servidor pondrá la conexión en la clase de conexiones con menor ancho de banda y menor número de clientes. Si no hubiese habido resolución inversa de <tt/206.2.177.200/ mediante la zona <tt/in-addr.arpa/ el servidor habría sido incapaz de de encontrar el nombre y habría tenido que comparar <tt/206.2.177.200/ con <tt/*.no/, <tt/*.se/ y <tt/*.dk/, es decir, cifras con nombres, ninguna de las cuales concordaría, e incluso podría haber denegado la conexión por falta de clasificación. <p>Algunas personas te dirán que la resolución inversa sólo es importante para los servidores, o que no tienen importancia. No es así; muchos servidores de ftp, news, irc e incluso algunos servidores http (WWW) <em/NO/ aceptarán conexiones de máquinas de las cuales no son capaces de resolver el nombre. Por tanto la asociacion inversa de máquinas es de hecho <em/obligatoria/. <sect>Mantenimiento<label id="mantenimiento"> <p><bf/Manteniéndolo en funcionamiento./ <p>Hay una tarea de mantenimiento que tienes que realizar con <tt>named</tt>, además de mantenerlo en funcionamiento. Esta tarea es mantener el archivo <tt>root.hints</tt> actualizado. La forma más fácil es usar <tt>dig</tt>, primero ejecuta <tt>dig</tt> sin argumentos, conseguirás <tt>root.hints</tt> de acuerdo con tu propio servidor. Entonces pregunta a alguno de los servidores raíz listados con <tt/dig @rootserver/. Podrás observar que la salida se parece terriblemente al archivo <tt>root.cache</tt> excepto por un par de números extras. Esos números no ocasionan problemas. Guárdalo en un archivo (<tt/dig @e.root-servers.net . ns >root.hints.nuevo/) y sustituye el antiguo <tt/root.hints/ con él. <p>Recuerda reiniciar <tt>named</tt> después de sustituir el archivo caché. <p>Al Longyear me envió este script que puede ser ejecutado automáticamente para actualizar <tt>root.cache</tt>, instala una entrada en el <tt>crontab</tt> para ejecutarlo una vez al mes y olvídate. El script supone que trabajas con correo y que el alias de mail <tt/hostmaster/ está definido. Debes editarlo para ajustarlo a tu configuración. <code> #!/bin/sh # # Actualizacion del cache del servidor de nombres una vez al mes. # Esto es ejecutado automaticamente mediante una entrada de cron # # Original de Al Longyear# Actualizado para BIND 8 por Nicolai Langfeldt # Varias condiciones de error notificadas por David A. Ranch # Test ping test sugerido por Martin Foster # named activo sugerido por Erik Bryer. # ( echo "To: hostmaster <hostmaster>" echo "From: system <root>" # ¿Está named activo? Verifica el estado de named. case `ndc status 2>&1` in *'refused'*) echo "named está inactivo. root.hints NO actualizado" echo exit 0 ;; esac PATH=/sbin:/usr/sbin:/bin:/usr/bin: export PATH # NOTA: /var/named tiene que tener permiso de escritura sólo para los usuarios válidos del guion # podrá ocasionar oportunidades de comprometer el sistema o ataques DOS. cd /var/named 2>/dev/null || { echo "Subject: No puedo ir a /var/named, error $?" echo echo "El motivo lo dice todo" exit 1 } # ¿Estamos en red? Hace ping a un servidor del tu ISP case `ping -qnc 1 some.machine.net 2>&1` in *'100% packet loss'*) echo "Subject: root.hints NO actualizado. La red no está activa." echo echo "El motivo lo dice todo" exit 1 ;; esac dig @e.root-servers.net . ns >root.hints.new 2> errors case `cat root.hints.new` in *NOERROR*) # funciona :;; *) echo "Subject: la actualización de root.hints ha FALLADO." echo echo "La actualización de root.hints ha fallado" echo "Este es el informe de errores de dig:" echo cat root.hints.new errors exit 1 ;; esac echo "Subject: El fichero root.hints se ha actualizado" echo echo "El fichero root.hints se ha actualizado y contiene la siguiente información:" echo cat root.hints.new chown root.root root.hints.new chmod 444 root.hints.new rm -f root.hints.old errors mv root.hints root.hints.old mv root.hints.new root.hints rndc reload echo echo "El servidor de nombres se ha reiiniciado para asegurarnos que la actualización es completa." echo "El anterior fichero root.hints file ahora se llama/var/named/root.hints.old." ) 2>&1 | /usr/lib/sendmail -t exit 0 </code> <p>Alguno de vosotros puede haber observado que el archivo <tt>root.hints</tt> está también disponible mediante ftp en <it>Internic</it>. Por favor NO utilice ftp para actualizar <tt/root.cache/, el método anterior es mucho más amistoso con la red. <sect>Cambiando a BIND9<label id="bind9"> <p>La distribucion de BIND 9 y las versiones empaquetadas también continen un documento llamado <tt/migration/ que contienen notas sobre como cambiar de BIND 8 a BIND 9. El documento es bastante directo. Si ha instalado los paquetes binarios es probable que se guarde en <tt>/usr/share/doc/bind*</tt> o <tt>/usr/doc/bind*</tt> <p>Si esta usando BIND 4, puede encontrar un documento llamado <tt/migration-4to9/ en el mismo lugar. <sect>Preguntas y respuestas<label id="PUF"> <p>Por favor, lee esta sección antes de enviar correos con preguntas. <enum> <item>Mi named quiere un fichero named.boot <p>Estás leyendo el COMO equivocado. Por favor mira versiones anteriores de este COMO, que tratan de BIND 4, en <url url="http://langfeldt.net/DNS-HOWTO/"> o <url url="http://www.insflug.org/">. <item>¿Cómo uso DNS desde dentro de un cortafuegos (<it>firewall</it>)? <p>Una pista: `<tt/forwad only/'. También puede necesitar <code> query-source port 53; </code> dentro de ``options'', parte del fichero <tt/named.conf/, como se sugería en el ejemplo de la sección <ref id="caching" name="caching">. <item>¿Cómo hago que DNS rote las direcciones disponibles para un servicio, digamos <tt/www.busy.site/ para obtener un efecto de balanceo de carga o similar? <p>Haz varios registros <bf/A/ para <tt/www.busy.site/ y use BIND 4.9.3 o posterior. Entonces BIND hará un "round-robin" de las respuestas. Esto <em/no/ funcionará con versiones anteriores de BIND. <item>Quiero configurar DNS en una intranet (cerrada). ¿Qué hago? <p>Elimina el fichero <tt/root.hints/ y define los ficheros de zona. Esto también significa que no tienes por qué obtener nuevos ficheros de caché. <item>¿Cómo configuro un servidor de nombres secundario(esclavo)? <p>Si el servidor primario/master tiene dirección 127.0.0.1 pon una linea como la siguiente en el fichero named.conf de tu secundario: <code> zone "linux.bogus" { type slave; file "sz/linux.bogus"; masters { 127.0.0.1; }; }; </code> Puedes listar varios servidores principales alternativos la zona se puede copiar desde la lista de <tt/masters/, separadas por ';' (punto y coma). <item>Quiro que bind funcione cuando me desconecto de la red. <p>Hay que considerar cuatro puntos: <itemize> <item>Específico para BIND 8/9, Adam L Rice me ha enviado este correo, sobre como ejecutar DNS sin miedo en una máquina con módem: <tscreen><verb> He descubierto que con las nuevas versiones de BIND esto ya no es necesario. Hay una directiva "forward" además de la directiva "forwarders" directiva que controla como se usan. El valor predeterminado es "forward first", que primero pregunta a cada uno de los forwarders, y luego intenta el mecanismo normal, si esto falla. Esto da el comportamiento familiar de gethostbyname() de llevarse mucho tiempo cuando la conexión no está abierta. Pero si se activa "forward only", entonces BIND vuelve cuando no obtiene una respuesta de los forwarders, y gethostbyname() termina inmediatamente. Por tanto no es necesario realizar retoques de los ficheros y reiniciar el servidor named. En mi caso, he añadido las líneas forward only; forwarders { 193.133.58.5; }; a la sección options { } de mi fichero named.conf. Funciona muy bien. La única desventaja de esto es que reduce una pieza de software DNS increíblemente sofisticado al estado de un volcado de cache. Extendiéndonos un poco, me gustaría ejecutar un volcado de caché en su lugar, pero no parece haber tal pieza de software disponible para Linux. </verb></tscreen> <item>He recibido este correo de Ian Clark <ic@deakin.edu.au> donde explica su forma de hacer esto: <tscreen><verb> Ejecuto named en mi máquina con 'Masquerading'. Tengo dos ficheros root.hints, uno llamado root.hints.real que contiene los nombres de los servidores reales y otro llamado root.hints.fake que contiene... ---- ; root.hints.fake ; este fichero no contiene información ---- Cuando me desconecto, copia el root.hints.fake a root.hints y reinicio named. Cuando me conecto copio root.hints.real en root.hints y reinicio named. Esto se hace desde ip-down e ip-up respectivamente. La primera vez que hago una consulta desconectado sobre un dominio, named no tiene detalles para ella y pone una entrada como la siguiente en messages... Jan 28 20:10:11 hazchem named[10147]: No root nameserver for class IN con la que puedo sobrevivir. Esto ciertamente me funciona. Puedo usar los servidores de nombres para máquinas locales mientras estoy desconectado sin los retrasos del temporizador para dominios externos y cuando estoy en la red, las consultas para dominios externos funcionan normalmente. </verb></tscreen> <p>Peter Denison pensó que Ian no fue suficientemente lejos. Escribió: <tscreen><verb> Cuando estoy conectado) sirve todas las entradas cacheadas (y red local) inmediatamente para las entradas no cacheadas, se dirige la servidor de nombres de mi ISP Cuando estoy desconectado) sirve las consultas locales inmediatamente falla en otras consultas **inmediatamente** La combinación de cambiar el fichero root cache y consultas forwarding no funciona. Así, he configurado (con algunas discusiones sobre esto en el LUG local) dos named de la siguiente forma: named-online: forwards a servidores del ISP master para zona localnet master para zona inversa localnet(1.168.192.in-addr.arpa) master para 0.0.127.in-addr.arpa escucha en el puerto 60053 named-offline: sin forwarding "fake" (falso) fichero root.cache esclavo para 3 zonas locales (master es 127.0.0.1:60053) escucha en el puerto 61053 Y combinando esto con reenvío de puertos, para enviar el puerto 53 al 61053 cuando estoy desconectado y al puerto 60053 cuando estoy conectado. (Uso el nuevo paquete netfilter bajo 2.3.18, pero el mecanismo anterior (ipchains) debería funcionar). Observe que esto no funcionará fuera de la máquina, ya que hay un ligero bug en BIND 8.2, que he hablado con los desarrolladores, que previene para tener un esclavo en la misma dirección IP que el principal (incluso sobre diferentes puertos). Es un parche trivial que podría salir pronto, espero. </verb></tscreen> <item>También he recibido información sobre como BIND interactúa con NFS y el portmapper en gran parte de la máquina desconectada de Karl-Max Wanger: <tscreen><verb> Suelo ejecutar mi propio named en todas mis máquinas que sólo se conectan ocasionalmente a internet por módem. El servidor de nombres sólo actúa como cache, no tiene área de autoridad y consulta todo de los servidores de nombres del fichero root.cache. Como es normal en Slackware, se inicia antes que nfs y mountd. Con una de mis máquinas (un Libretto 30 notebook) he tenido el problema que algunas veces podía montarlo de otro sistema conectado a mi red local, pero la mayoría de las veces no funcionaba. Obtuve el mismo efecto independientemente del uso de PLIP, una tarjeta PCMCIA ethernet o PPP sobre un interfaz serie. Tras preguntarme y experimentar durante cierto tiempo, encontré que named aparentemente interfería el proceso de registro que nfsd y mountd tienen que realizar con el portmapper en el arranque (inicio estos demonios en el arranque, como es habitual). Al comenzar tras nfsd y mountd elimina este problema completamente. Como no supone ninguna desventaja la modificación de la secuencia de arranque, os advierto a todos que lo hagáis para prevenir potenciales problemas. </verb></tscreen> <item>Finalmente, hay información sobre esto en <url name="Ask Mr. DNS at" url="http://www.acmebw.com/askmrdns/#linux-dialup">. Es sobre BIND 4 aunque, tendrá que adaptarlo a lo que hemos dicho de BIND 8. </itemize> <item>¿Donde guarda el servidor de cacheo su cache? ¿Hay forma de controlar el tamaño del cache? <p>El cache se almacena en memoria completamente. <em/No/ se escribe en disco en ningún momento. Cada vez que matas a <tt/named/ se pierde el caché. El caché no es controlable de ninguna forma, <tt/named/ lo maneja de acuerdo con unas reglas simples. No puedes controlar ni el caché ni su tamaño de ninguna forma ni por ningún motivo. Si quieres, puedes cambiar esto tocando los fuentes de <tt/named/, lo cual no es recomendable. <item> ¿Salva <tt>named</tt> el caché entre reinicios? ¿Puedo guardarlo? <p>No, <tt/named/ no salva el caché cuando muere. Esto significa que el cache se debes reconstruir de nuevo cada vez que mates y reinicies <tt/named/. <em/No/ hay forma de hacer que <tt/named/ salve el caché en un archivo. Si quieres, puedes cambiar esto tocando los fuentes de <tt/named/, lo cual no es recomendable. <item>¿Cómo puedo obtener un dominio? Quiero configurar mi propio dominio llamado (por ejemplo) <tt/linux-rules.net/. ¿Cómo puedo obtener el dominio que quiero que se me asigne? <p>Por favor, contacta con tu proveedor de servicios de internet. Ellos podrán ayudarte con esto. Ten en cuenta que en la mayor parte del mundo tienes que pagar para obtener un dominio. <item>¿Como puedo asegurar mi servidor DNS? ¿Como divido DNS? <p>Ambas son características avanzadas. Ambos temas se tratan en <url url="http://www.etherboy.com/dns/chrootdns.html">. No explicaré estos temas más allá de esto. </enum> <sect>Cómo convertirse en un gran <it>admin</it> DNS.<label id="grande"> <p><bf>Documentación y herramientas.</bf> <p>Existe documentación real. En línea e impresa. La lectura de varios de estos documentos es necesaria para dar los pasos de un gran admin DNS en poco tiempo. Impreso, he escrito <em/The Concise Guide to DNS and BIND/ (por Nicolai Langfeldt), publicado por Que (ISBN 0-7897-2273-9). El libro es parecido a este COMO. Más detalles, y un poco más de todo. Ha sido traducido al polaco y publicado como <em/DNS i BIND/ por Helion (<url url="http://helion.pl/ksiazki/dnsbin.htm">, ISBN 83-7197-446-9).Pero el libro estándar es en u cuarta edicion <em/DNS and BIND/ por C. Liu and P. Albitz from O'Reilly & Associates (ISBN 0-937175-82-X). Es excelente también. Consigue la 3ª edición, cubre BIND 8 y también BIND 4. También hay una sección sobre DNS en <em>TCP/IP Network Administration</em>, por Craig Hunt de O'Reilly (ISBN 0-937175-82-X). Otro para buena administración DNS (o cualquier cosa buena para ese asunto) es <em/Zen and the Art of Motorcycle Maintenance/ por Robert M. Pirsig :-) Disponible como ISBN 0688052304 y otros. <p>En la red podrás encontrar mi libro con toneladas de otros libros, disponibles electronicamente como suscripcion en <url url="http://safari.informit.com/">. Hay material en <url url="http://www.dns.net/dnsrd/">(DNS Resources Directory), <url url="http://www.isc.org/bind.html">; Una FAQ, un manual de referencia (BOG; BIND Operations Guide) también como papeles y definición de protocolos y trucos DNS (estos, y la mayoría, si no todos,los RFCs mencionados abajo, también contenidos en la distribución de BIND). No he leído la mayoría de estos, pero no soy un admin DNS a tiempo completo. Arnt Gulbrandsen por otro lado ha leído BOG y quedó extasiado :-). El grupo de noticias <url url="news:comp.protocols.tcp- ip.domains"> es sobre DNS. Además hay un número de RFCs sobre DNS, los más importantes son probablemente los listados aquí. Los que tienen números BCP (Best Current Practice) son <em/altamente recomendables/. <descrip> <tag/RFC 2671/ P. Vixie, <em/Extension Mechanisms for DNS (EDNS0)/ August 1999. <tag/RFC 2317/, BCP 20, H. Eidnes et. al. <em/Classless IN-ADDR.ARPA delegation/, March 1998. This is about CIDR, or classless subnet reverse lookups. <tag/RFC 2308/, M. Andrews, <em/Negative Caching of DNS Queries/, March 1998. About negative caching and the $TTL zone file directive. <tag/RFC 2219/, BCP 17, M. Hamilton and R. Wright, <em/Use of DNS Aliases for Network Services/, October 1997. About CNAME usage. <tag/RFC 2182/, BCP 16, R. Elz et. al., <em/Selection and Operation of Secondary DNS Servers/, July 1997. <tag/RFC 2052/ A. Gulbrandsen, P. Vixie, <em/A DNS RR for specifying the location of services (DNS SRV)/, October 1996 <tag/RFC 1918/ Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de Groot, E. Lear, <em/Address Allocation for Private Internets/, 02/29/1996. <tag/RFC 1912/ D. Barr, <em/Common DNS Operational and Configuration Errors/, 02/28/1996. <tag/RFC 1912 Errors/ B. Barr <em/Errors in RFC 1912/, this is available at <url url="http://www.cis.ohio-state.edu/~barr/rfc1912-errors.html"> <tag/RFC 1713/ A. Romao, <em/Tools for DNS debugging/, 11/03/1994. <tag/RFC 1712/ C. Farrell, M. Schulze, S. Pleitner, D. Baldoni, <em/DNS Encoding of Geographical Location/, 11/01/1994. <tag/RFC 1183/ R. Ullmann, P. Mockapetris, L. Mamakos, C. Everhart, <em/New DNS RR Definitions/, 10/08/1990. <tag/RFC 1035/ P. Mockapetris, <em/Domain names - implementation and specification/, 11/01/1987. <tag/RFC 1034/ P. Mockapetris, <em/Domain names - concepts and facilities/, 11/01/1987. <tag/RFC 1033/ M. Lottor, <em/Domain administrators operations guide/, 11/01/1987. <tag/RFC 1032/ M. Stahl, <em/Domain administrators guide/, 11/01/1987. <tag/RFC 974/ C. Partridge, <em/Mail routing and the domain system/, 01/01/1986. </descrip> <sect>Traducción <p> Este documento ha sido traducido por Pedro Pablo Fábrega Martínez, <tt><htmlurl url="mailto:pfabrega(en)arrakis.es s" name="pfabrega(en)arrakis.es"></tt> Si encontráis mejoras, añadidos o fallos, de cualquier tipo, indicádmelo para mejorar el documento. <p> Nota: El autor del documento, como ya ha dicho él anteriormente, sól0 entiende noruego e inglés; por favor no le hagáis consultas en otros idiomas. En caso de duda os podéis dirigir al traductor, y aunque no pueda resolveros vuestra duda sí que os puede indicar algún foro donde os podrían ayudar. <p> Por otro lado me he permitido usar el tuteo en este texto, saltándome algunas normas de estilo. No creo que nadie se sienta molesto. Bastante serio es el DNS de por sí. <sect>Anexo: El INSFLUG <label id="Grupos"> <p> El <em/INSFLUG/ forma parte del grupo internacional <it/Linux Documentation Project/, encargándose de las traducciones al castellano de los Howtos (Comos), así como la producción de documentos originales en aquellos casos en los que no existe análogo en inglés. En el <bf/INSFLUG/ se orienta preferentemente a la traducción de documentos breves, como los <em/COMOs/ y <em/PUFs/ (<bf/P/reguntas de <bf/U/so <bf/F/recuente, las <it/FAQs/. <tt/:)/ ), etc. Diríjase a la sede del INSFLUG para más información al respecto. En la sede del INSFLUG encontrará siempre las <bf/últimas/ versiones de las traducciones: <tt><htmlurl url="http://www.insflug.org" name="www.insflug.org"></tt>. Asegúrese de comprobar cuál es la última versión disponible en el Insflug antes de bajar un documento de un servidor réplica. Se proporciona también una lista de los servidores réplica (<it/mirror/) del Insflug más cercanos a Vd., e información relativa a otros recursos en castellano. Francisco José Montilla, <tt><htmlurl url="mailto:pacopepe@insflug.org" name="pacopepe@insflug.org"></tt>. </article>