Servicios de Red e Internet Prá cticá Temá 2: DNS

Transcripción

1 Servicios de Red e Internet Prá cticá Temá 2: DNS En esta práctica, instalaremos servidores DNS en Windows Server y Linux, y comprobaremos su funcionamiento usando un cliente de DNS. Para esta práctica no vamos a necesitar que las VMs se encuentren aisladas de nuestra red del instituto ya que, a pesar de que DNS también es un servicio básico de red, en una red podemos tener tantos servidores DNS como nos apetezca sin que esto cree problemas en el funcionamiento normal de la red. Así que todo el mundo en modo Bridged. Ejercicio 1: DNS en Windows Server 2008 Empezamos arrancando la VM de Windows Server 2008 e instalando el rol de servidor DNS. Al igual que con DHCP, es conveniente para esta práctica que Active Directory no se encuentre instalado (que luego ya sabemos lo que pasa). Tras instalar el rol de servidor DNS, entrad en la configuración del DNS en las herramientas administrativas. Aquí, cread una zona de búsqueda directa (de nombre de dominio a IP) con el nombre de dominio prueba.net. Una vez creada la zona, agregad dentro de esa zona varios registros de prueba: - Un equipo router (realmente os saldrá como router.prueba.net) con IP Un servidor de correo correo con IP Un alias mail para el servidor de correo. - Otro alias smtp para el servidor de correo. - Cinco equipos pc1, pc2, etc., con direcciones hasta la Una vez configurado, toca comprobar si funciona bien. El método más simple es usando la herramienta nslookup de línea de comandos de Windows (la idea es usarla desde vuestro equipo, no la VM, aunque también podéis hacer click sobre la raíz de vuestro servidor DNS y ahí os sale la opción para realizar un nslookup). La sintaxis es muy sencillita: nslookup nombre-de-dominio Con esto os encontrará la IP del nombre de dominio especificado usando los DNS por defecto de Windows (podréis comprobar que el dominio prueba.net ya existe). Para que use vuestro DNS, escribid: nslookup nombre-de-domino dirección-ip-del-servidor-dns De todas formas, esta herramienta es bastante básica, así que os aconsejo usar algo mejor. Yo os he puesto para descargar una que se llama Sam Spade, o también podéis usar el comando

2 dig de Linux. Cualquiera de las dos nos permite acceder a todos los registros del DNS, y no sólo resolver la IP. Una vez comprobado que todos los registros funcionan adecuadamente, vamos a añadir una zona de búsqueda inversa. Aquí, asignamos una IP o conjunto de IPs a un nombre (justo al contrario que la búsqueda directa). Cread un registro inverso para cada uno de los registros que habíamos introducido en la zona de búsqueda directa y comprobad que funcionan (ahora tenéis que buscar por la IP y no por el nombre de dominio en la herramienta de comprobación que utilicéis). Lo siguiente es crear un subdominio dentro de nuestra prueba.net. Vamos a crear un subdominio oficina que dentro contendrá un servidor ( ), tres PCs ( ) y una impresora ( ). Además, habrá que configurar el DNS para que cualquier cuenta de correo de la oficina (p.ej.: pepe@oficina.prueba.net) use como servidor de correo nuestro equipo correo.prueba.net. Probadlo convenientemente. Además de los registros estándar (A, MX, CNAME, NS), podemos añadir cualquier otro de los campos que están definidos en el estándar. Por ejemplo, añadid un registro que se llame texto.prueba.net de tipo TXT en el que aparezca vuestro nombre. Probad a consultarlo con vuestro cliente DNS. Por último, vamos a configurar los reenviadores. Esto sirve para que si nuestro DNS no es capaz de contestar a la petición (porque le pidamos un registro que no se encuentra en nuestro servidor o directamente pertenece a otra zona) se reenvíe automáticamente la petición a otro servidor DNS. Por defecto, vienen configurados unos servidores en Sugerencias de raíz. Éstos son servidores por defecto que se usan si no ponemos nosotros uno manualmente. Si queremos que nuestro servidor no reenvíe peticiones hacia ningún otro servidor, deberemos borrar completamente esta lista. Comprobad que ahora no reenvía ninguna petición. Ahora añadid un reenviador (por ejemplo, el de Google) y comprobad que ahora si se reenvían las peticiones. Entrega: Capturas de pantalla de la configuración del servidor DNS (de las diferentes zonas). Captura de pantalla de nslookup o similares de consultas al DNS (al menos a un registro A, al MX, a un CNAME, a un PTR y a alguno del subdominio). Supuesto práctico Configurad una nueva zona que se llame asir2. Cread registros para cada uno de los equipos del aula que tengan IP fija, incluyendo la puerta de enlace y el del profesor, usando como nombre para el registro el nombre del alumno que lo utiliza (y profesor y router para los otros dos). Cread también la zona de búsqueda inversa correspondiente. Entrega: Capturas de pantalla de la configuración de la zona asir2.

3 Ejercicio 2: DNS en Linux Ahora vamos a montar el mismo DNS en Linux, usando el servidor BIND. La configuración de este servidor es muchísimo más divertida que en Windows 2008, debido a la carencia total de asistentes y a los ininteligibles ficheros de configuración que BIND usa. El paquete que tenéis que instalar se llama bind9. Una vez instalado, el servidor BIND se configura modificando los archivos existentes en la carpeta /etc/bind. En el archivo named.conf.local es donde vamos a configurar las diferentes zonas, cada una de las cuales irá en un archivo distinto. Para empezar a configurar nuestra primera zona, vamos a fijarnos en cómo está configurada la zona localhost. La definición de la zona aparece en el fichero named.conf.default-zones en lugar de en named.conf.local ya que es una zona por defecto. Si os fijáis, es una zona de tipo master que se corresponde con un DNS primario. En la siguiente línea se especifica el fichero que contiene la configuración de la zona. Pues bien, fijándoos en esto, definid vuestra zona prueba.net para que sea un DNS primario y use el archivo db.prueba (recordad que va en el otro archivo). La configuración de la zona localhost se encuentra, como ya deberíais saber, en el fichero db.local. Haced una copia de este archivo en db.prueba y vamos a modificarlo para que funcione nuestra zona. En este archivo, en primer lugar se encuentra definido el registro SOA (Start Of Authority). La configuración de este registro no la vamos a tocar, pero si vamos a cambiar donde aparezca el nombre localhost por prueba.net. Atención con el punto que va detrás del nombre! Los nombres de dominio completos (Fully Qualified Domain Name) llevan un punto detrás para diferenciarlos de los nombres de dominio relativos a nuestra zona. En este caso estamos poniendo nombres de dominio completos, no relativos, así que tienen que llevar el punto. Debajo del registro SOA, vienen tres registros que se corresponden con la definición del servidor de nombres. El registro NS define el nombre de la máquina donde está el servidor de nombres, mientras que los registros A y AAAA definen su dirección IP en IPv4 y IPv6 respectivamente. En Windows no necesitamos darle nombre a la máquina que contenía el DNS, pero aquí si es necesario. Por ejemplo, la llamaremos dns.prueba.net y su IP será la (en la práctica debería ser la misma IP que la VM de Linux, pero en realidad no es necesario porque simplemente estamos configurando qué es lo que responde el servidor DNS, no donde está instalado) (y si le ponéis a la máquina la IP luego vais a tener más jaleo para poder comprobar el funcionamiento desde vuestro equipo). El registro de IPv6 lo vamos a borrar. Las líneas quedarían como IN NS dns.prueba.net dns IN A Sólo nos quedaría ahora ir rellenando el resto de registros del DNS. El formato, como podéis ver, es:

4 1) Nombre (no el nombre completo, sino la parte que va delante del punto en el nombre del dominio; por ejemplo, para router.prueba.net hay que poner simplemente prueba). Si ponéis se usa el nombre base del dominio (en este caso prueba.net). 2) La clase de registro. En la práctica siempre va a ser IN, que significa Internet, pero antiguamente había otros tipos de clases (en el pleistoceno de la informática). 3) El tipo de registro. Los tipos de registros que vamos a utilizar son SOA, NS, A, MX, CNAME y PTR (para el DNS inverso). También están disponibles la mayoría de los tipos de registros que se podían crear en Windows Server. 4) Los datos que contiene el registro. Son de distintos tipos dependiendo del tipo de registro: - A: una dirección IP - CNAME: un nombre de dominio. Podemos escribir un nombre de dominio completo (FQDN) poniéndole un punto detrás o tan sólo la parte que va delante del nombre de la zona si es un equipo perteneciente a la misma (sin el punto esta vez). - NS y PTR: un nombre de dominio completo (con punto detrás). - MX: primero un número de prioridad (cuanto más pequeño, mayor prioridad; en Windows Server usábamos el 10) seguido del nombre de dominio del servidor de correo (con el mismo formato que CNAME). Como ejemplo, la línea correspondiente a nuestro router sería: router A IN El resto de las líneas son cosa vuestra (por ahora, sin el subdominio ni el DNS inverso). Para comprobar si nuestro archivo de zona está bien configurado, podemos usar la orden named-checkzone con dos parámetros: el primero será el nombre de la zona y el segundo el archivo donde se guarda. En nuestro caso, la orden completa sería: named-checkzone prueba.net db.prueba Con esto nos deberían salir los errores que tiene el fichero o un mensaje de OK si todo está bien. Después de eso, no se os olvide reiniciar el servidor DNS para que coja la nueva configuración (mandándole un restart a /etc/init.d/bind9). Para probarlo, hacedlo de la misma forma que para Windows 2008 (con nslookup, Sam Spade o dig). Sigamos con los subdominios. Una vez configurada nuestra zona, podemos añadir un subdominio (o subzona) a continuación con una línea $ORIGIN en la que definimos como se llama el subdominio y le indicamos al servidor que a partir de entonces todas las líneas pertenecen al subdominio y no al dominio original. En nuestro caso sería: $ORIGIN oficina.prueba.net. Y a partir de ahí, añadimos los equipos que se encontraban en el subdominio. Comprobad de nuevo que funciona antes de continuar. Configurar el DNS inverso tiene algo más de mandanga, sobre todo comparado con Windows 2008, que nos daba el nombre configurado y todo. Para empezar, tenemos que averiguar

5 cómo se llamará la zona correspondiente al DNS inverso. La sintaxis es siempre la misma: el dominio acaba en in-addr.arpa y delante lleva, en orden inverso, la IP de la red para la que queremos definir el DNS inverso (pero sólo la parte de red, es decir, sin los ceros). Por ejemplo, para una red /24, el dominio inverso sería: in-addr.arpa Por tanto, para nuestra zona, el dominio inverso será 10.in-addr.arpa (ya que se supone que es una /8) (esto sí lo sabíais, verdad?) ( verdad?!?). Una vez sabido esto, configuramos una nueva zona en el fichero named.conf.local. La zona se define exactamente igual que la directa, usando el nombre de zona que hemos averiguado. Como archivo, lo estándar es usar algo así como db.10 (porque nuestra zona es la ). Para modificarlo, esta vez vamos a hacer una copia del archivo de zona inversa de localhost, que se llama db.127 (por la ). En el registro SOA ponemos lo mismo que en el anterior, esto no cambia. Tampoco cambia la línea del NS. A partir de aquí empieza la diversión. Como esto es inverso, ahora donde poníamos el nombre ponemos la dirección y donde poníamos la dirección ponemos el nombre. Pero no acaba ahí! Como es inverso, la dirección la tenemos que poner al revés! Y además, la IP no tenemos que ponerla completa, sino sólo la parte que no es de red (en nuestro caso, todo menos el 10) mientras que el nombre de dominio esta vez sí va completo. Por último, recordad que para el DNS inverso usábamos un registro de tipo PTR. O sea, que las dos primeras líneas nos IN NS dns.prueba.net IN PTR dns.prueba.net. Y, por ejemplo, la del router sería: IN PTR router.prueba.net. Divertido, verdad? Pues ya sabéis, a meter todo el DNS inverso. Cada entrada A tendrá una PTR correspondiente. Las entradas CNAME tendrán una entrada PTR que resuelve la misma dirección pero con otro nombre de dominio. Las entradas MX no tienen inversa. Una vez terminado todo, comprobad la consistencia del fichero con named-checkzone y probad que funciona bien todo el DNS. Por último, vamos a configurar el servidor para que las consultas DNS que no pueda resolver las reenvíe a otro servidor DNS. Para ellos, sólo hay que añadir la opción forwarders en el fichero named.conf.options. Viene un ejemplo que podéis modificar. Probad que funcionan bien (si no funcionan bien, comprobad que los DNS de Linux están bien puestos en /etc/resolv.conf y reiniciad el interfaz de red; a mí me dio bastante por saquillo el asunto). Entrega: Los ficheros de configuración creados o modificados en este ejercicio y capturas de pantalla de las consultas (como en el ejercicio anterior).

6 Supuesto práctico Configurad una nueva zona que se llame asir2. Leed el ejercicio anterior si ya se os ha olvidad como iba. Entrega: Ficheros de configuración creados o modificados para esta zona. Ejercicio 3: Configuración del servidor DNS en un router Si tan sólo necesitamos configurar unos cuantos nombres de hosts y disponemos de un router medianamente configurable, podemos activar en él un pequeño servidor DNS que nos permita resolver nombres de dominio. Esta vez no necesitáis cambiar el tipo de red ni la configuración con la que viene de inicio OpenWRT. Simplemente dejadle que coja una dirección dinámica para la conexión de red y entrad en la interfaz web. En la pestaña DHCP and DNS, tenéis que configurar las opciones básicas. Éstas son el nombre del dominio y los DNS forwardings. Después, en la pestaña Hostnames configuraremos las entradas del DNS. Sólo se pueden introducir registros A desde la interfaz web; el resto de entradas se pueden introducir, pero hay que tocar directamente los ficheros de configuración (en particular, el archivo /etc/config/dhcp, según estas instrucciones Configurad el router para que nos resuelva nombres de la red asir1 y probad que funciona con cualquier herramienta. Entrega: Capturas de pantalla de la configuración del DNS en el router (opciones generales y hostnames) y de al menos una prueba con un cliente DNS. Ejercicio 4: Configuración de log en BIND Los ficheros de log sirven para registrar todo lo que ocurre en un sistema operativo o en un programa. Bind se puede configurar para que cree ficheros de log con diferentes tipos de información. La configuración del logging en bind se puede escribir directamente en alguno de los ficheros named.conf.*, pero es preferible colocarla en un fichero aparte. Por ello, crearemos el fichero named.conf.log en el directorio /etc/bind y añadiremos una línea include en named.conf para que se lea también nuestro fichero de configuración de logs. Aunque no es estrictamente obligatorio que la configuración de los logs se lea justo al principio, es preferible puesto que hasta que no está definido el logging no se empieza a guardar ninguna información y es más difícil depurar los errores. Las directivas de configuración de logging podéis encontrarlas en esta página web:

7 Para no complicar mucho las cosas, diremos que el proceso de configuración de logging se divide en dos partes: la configuración de los ficheros de log (que se denominan canales) y la configuración de qué información va en cada fichero. Para cada canal, podemos definir lo siguiente: file: nos permite especificar el fichero donde se van a guardar los logs. Se suelen guardar en la carpeta /var/log. Además, permite especificar cuántas versiones de los archivos de log vamos a guardar y el tamaño máximo de cada fichero. Así: file /var/cache/bind/normal.log versions 3 size 2m; nos dice que guardaremos la información que nos llegue por este canal en el fichero especificado, que guardaremos tres versiones de los archivos de log (que se irán rotando) y que el tamaño máximo de cada uno será de 2 MB. Alternativamente, podemos especificar syslog, stderr o null en lugar de un fichero. severity: indica el nivel de detalle del log. Dependiendo del nivel, se guardará más o menos información. Por ejemplo, el nivel error sólo nos informará de errores (o cosas aún peores) mientras que le nivel info nos dará mucha más información (incluyendo los errores). print-time: si le ponemos yes nos escribe la fecha y la hora en cada línea del log. print-severity: si le ponemos yes nos escribe el nivel de serveridad de cada línea. print-category: si le ponemos yes nos indica a qué categoría pertenece la información (ver más abajo). Por ejemplo, si queremos configurar un canal que nos guarde toda la información posible (exceptuando niveles de debug), escribiríamos algo así: logging{ channel ejemplo { file "/var/cache/bind/normal.log" versions 3 size 2m; severity info; print-time yes; print-severity yes; print-category yes; Faltan por configurar las categorías. En la página web vienen especificadas todas las categorías posibles. Aunque hay muchas interesantes, sólo os voy a comentar dos de ellas: default: define una categoría que incluye todas las categorías que no estén definidas explícitamente. queries: registra todas las peticiones de los clientes DNS. Es la única categoría que no está incluida en default porque registra un volumen de información muy grande. Así, si queremos definir una categoría que use el canal que acabamos de crear para registrar la toda la información de errores, etc., que ocurran en nuestro servidor, escribiríamos:

8 logging{ channel ejemplo { //... category default{ ejemplo; Supuesto práctico Configurar nuestro servidor BIND para que registre la información pertinente. Deberemos tener un fichero /var/cache/bind/errores.log en el que se registren todos los errores que se produzcan y otro /var/cache/bind/consultas.log que registre las consultas DNS. Probar que funciona la configuración y realizar unas cuantas consultas para que se queden registradas en el log. Entrega: Los ficheros de configuración que se han creado o modificado y los ficheros de log que se han generado. Ejercicio 5: Configuración de DNS Maestro/Esclavo en BIND Para realizar este ejercicio necesitaréis o bien dos VMs con Linux o bien hacerlo por parejas. Vamos a aprender cómo se configura un DNS (esclavo) para que lea la información de otro servidor (maestro) y se sincronice automáticamente, de forma que ambos tengan siempre la misma información sobre los dominios y se puedan utilizar indistintamente para realizar consultas de DNS. La configuración de un servidor DNS esclavo es bastante simple. La principal diferencia es que a la hora de configurar las zonas, donde poníamos type master ahora ponemos type slave. Así, si queremos que nuestro servidor esclavo haga una copia de nuestra zona prueba.net, tendremos que crear en el fichero named.conf.local una nueva zona prueba.net de tipo slave. La opción file ahora es opcional, aunque recomendable, y especifica un fichero en el que se guardará temporalmente la configuración que nos mande el maestro. La nueva opción que tenemos que configurar es masters, que especifica cuál es el servidor maestro al que tenemos que pedirle la configuración. Un ejemplo para nuestra prueba.net sería: zone prueba.net { type slave; file db.prueba ; masters { ;

9 Esto ya debería funcionar. Y es que la seguridad que trae por defecto el servidor bind es bastante inexistente. Por si no os habéis dado cuenta, nuestro servidor maestro le da la configuración de cualquier zona a cualquier servidor esclavo que se la pida. Para arreglar este problema, vamos a cambiar algunas opciones de seguridad. Las siguientes opciones las podemos poner en el fichero named.conf.options, donde afectarán a todas las zonas de nuestro servidor (aquí deberíamos restringir casi todo), y también individualmente en cada zona que tengamos (aquí ya permitimos el acceso a quién nos interese). Las opciones las podéis encontrar aquí: La más importante que tenemos que configurar en el maestro es: allow-transfer: nos permite especificar qué servidores esclavos pueden copiar la información de las zonas desde nuestro servidor. Por defecto, se permite a cualquier servidor esclavo. Para aumentar la seguridad, en el fichero options escribiremos: allow-transfer { none ; Mientras que en cada zona, escribiremos una lista con los servidores a los que se les permite copiar la configuración: allow-transfer { ; En el esclavo, tenemos: allow-notify: permite especificar el servidor maestro del que podremos recibir notificaciones. Esto hace que cuando se produzca alguna modificación en las zonas del servidor maestro, éste nos mande automáticamente una notificación para que sincronicemos la información. Por defecto, se permite notificaciones de cualquier servidor, pero para aumentar la seguridad deberíamos restringirlo para aceptar sólo las de nuestro servidor maestro. Por defecto, nuestro servidor maestro notifica a todos los servidores que estén definidos dentro del dominio cono NS. Si queremos que notifique a alguno más (como, por ejemplo, en el caso de que estemos usando direcciones de mentira para los NS) (ejem, ejem), podremos especificarlo mediante la opción also-notify (bien en cada zona concreta o bien directamente en options). Comprobad que funciona el asunto (haciendo peticiones de DNS tanto al servidor maestro como al esclavo y viendo en el log cómo se produce la transferencia de información). Supuesto práctico Configurar un servidor esclavo para nuestra zona asir2 (y la correspondiente zona inversa). Entrega: Los ficheros de configuración pertinentes.

10 Ejercicio 6: Configuración de DNS Dinámico en BIND El DNS Dinámico es un tipo de DNS en el cuál los clientes pueden actualizar sus direcciones IP. Esto permite que cierto tipo de equipos (por ejemplo, externos a la red de la organización con una conexión de Internet que no permite IP fija) puedan actualizar el registro correspondiente a su nombre de dominio cuando cambie su IP. Un ejemplo de esto es el servicio DynDNS que nos permite tener una dirección de dns que corresponda con nuestra IP de casa y que se puede actualizar cada vez que cambie. Este proceso conlleva una cierta seguridad, que en el caso de BIND se denomina TSIG: Vamos a configurar nuestro servidor DNS para que reciba actualizaciones de un cliente de DNS dinámico. Para ello, necesitaremos dos VMs, así que, al igual que el ejercicio anterior, podéis hacerlo con dos VMs en vuestro propio ordenador o en parejas con algún compañero. Toda la información esta sacada de las páginas: Generando las claves Antes que todo, necesitamos generar unas claves que permitirán autenticar al cliente DNS dinámico en nuestro servidor. Esto se hace mediante el siguiente comando: dnssec-keygen -a HMAC-MD5 -b 512 -n USER <nombre_del_cliente> Donde el <nombre_del_cliente> es el identificador que le queremos poner a nuestro cliente DNS dinámico. Como normalmente se usa una dirección de correo (sin la arroba), vamos a usar de nombre de usuario el siguiente: usuario.prueba.net Los otros dos parámetros indican el algoritmo de generación de claves (ya lo veremos en el tema de Criptografía en la asignatura de Seguridad) y el tamaño en bits de la clave. Usamos HMAC-MD5 porque es el exigido para este tipo de transacciones. Cuando termine de generar las claves (puede tardar un buen rato, no desesperéis), tendremos dos ficheros que empiezan por K: uno con extensión.key y otro con extensión.private. Dentro del fichero.key nos aparecerá una sólo línea con varios campos separados por espacio, siendo el primero el nombre de usuario y el último (y más largo) la clave. Esta clave es la que tendremos que copiar al servidor para permitir el acceso de este usuario. Configurando el acceso en el servidor En el servidor DNS, tenemos que configurar un par de cosas. Primero deberemos insertar la clave que hemos generado en un fichero de configuración y después tendremos que decirle que el usuario con esa clave puede actualizar las zonas que le indiquemos.

11 Aunque la clave se puede insertar en cualquiera de los ficheros de configuración, se recomienda hacerlo en un fichero aparte, por ejemplo: named.conf.keys No se os olvide que para que BIND lea este fichero, deberemos añadir el correspondiente include en el fichero named.conf (poned el include antes del include de named.conf.local; esto es porque lo normal es definir la clave antes de usarla y la vamos a usar en la configuración de las zonas locales). La configuración de la clave será similar a la siguiente: key <usuario>. { algorithm HMAC-MD5; secret "<clave>"; Donde en <usuario> escribiremos el nombre de usuario que hayamos elegido y en <clave> copiaremos la clave pública que hemos generado anteriormente. Con esto ya tenemos listo el primer paso. Vamos con el segundo. En la configuración de nuestra zona prueba.net tenemos que añadir el siguiente parámetro: allow-update { key <usuario>.; Donde en <usuario> escribiremos el nombre de usuario que hayamos elegido. Esto permitirá al usuario realizar cualquier tipo de actualización sobre nuestra zona. Después veremos como restringirlo para que haga sólo cierto tipo de modificaciones. Realizando las actualizaciones De vuelta en el cliente, sólo nos queda crear un fichero con el script de actualización. En las páginas que os he puesto viene el siguiente ejemplo: server ns.bar44.com zone bar44.com update delete somehost.bar44.com. A update add somehost.bar44.com A show send En el campo server configuraremos la dirección del servidor. En nuestro caso, pondremos la IP del servidor DNS. En zone, especificamos la zona que queremos actualizar. El comando update es el que nos permite especificar la actualización. Como podéis ver, vienen dos ejemplos: en el primero se elimina el registro A del dominio somehost.bar44.com mientras que en el segundo se añadir el registro A del mismo dominio, indicando la IP y el tiempo de vida de la actualización (en este caso, 1 día). El comando show indica que se muestre toda la información de la transacción por la pantalla, lo cuál es muy útil a la hora de depurar errores. El último comando, send, indica que se realice la transacción.

12 En nuestro caso, vamos a decirle que añada un nuevo registro dinamico.prueba.net con dirección Una vez terminado el script, guardadlo con el nombre que queráis y ejecutad la orden nsupdate, que es la que realmente realiza el proceso. Necesita dos parámetros: nsupdate -k <fichero_clave_private> -v <fichero_script> El <fichero_clave_private> es el que hemos generado anteriormente y el <fichero_script> es el que acabamos de crear. Ejecutadlo y con una buena ración de suerte, funcionará todo bien. Comprobad con un cliente que nuestro servidor DNS nos traduce correctamente la dirección de dinamico.prueba.net. Posibles problemas (si habéis seguido los pasos correctamente; si no, los posibles problemas son infinitos): El primer divertido mensaje de error que me encontré fue: ; TSIG error with server: clocks are unsynchronized Update failed: NOTAUTH(BADTIME) Esto nos dice que los relojes del sistema del cliente DNS dinámico y el servidor DNS no están puestos con la misma hora. Esto es típico de Ubuntu en máquinas virtuales (je, je). Para solucionarlo, ponedlos los dos con la misma hora. El segundo fue aún más divertido: Update failed: SERVFAIL Ahá, así que algo falla en el servidor pero no nos dice qué es. Muy bonito. Cómo averiguamos qué está fallando? Pues nos vamos a los logs del servidor y vemos a ver qué le pasa. En mi caso, había un problema de permisos de escritura así que el servidor BIND no podía crear los archivos que necesitaba en la carpeta /etc/bind. La solución es cambiarle el propietario a esa carpeta para que sea bind o cambiarle los permisos de grupo para que el grupo bind pueda escribir en ella. En vuestro caso, puede ser cualquier otra cosa. Restringiendo las actualizaciones La política allow-update es demasiado poco restrictiva ya que permite al cliente especificado realizar cualquier tipo de cambio en la zona. Lo normal es permitir que el cliente sólo puede cambiar un registro o bien un subdominio. Para ello usamos la política update-policy: zone "bar44.com" { (...) update-policy { grant laptop.bar44.com. name laptop.bar44.com. A TXT; grant foo22.bar44.com. subdomain bar44.com. ANY;

13 En el ejemplo vemos dos ejemplos de política de actualizaciones: La primera línea grant (que significa conceder permisos) nos dice que el usuario laptop.bar44.com puede modificar los registros A y TXT del nombre de dominio laptop.bar44.com. El segundo grant nos dice que el usuario foo22.bar44.com puede modificar cualquier registro (ANY) del subdominio bar44.com. Con esta información probad a cambiar la política allow-update por una update-policy que sólo permita al usuario que hemos creado modificar el registro A del nombre de dominio dinamico2.prueba.net. Comprobad que una vez reiniciado el servidor ya no podemos actualizar el nombre de dominio dinamico.prueba.net pero sí el dinamico2.prueba.net que acabamos de permitir. Supuesto práctico Configurar el servidor DNS para que nuestra zona asir2 pueda ser actualizada dinámicamente. En concreto, la idea es que la gente que tiene portátiles pueda actualizar su nombre de dominio con la dirección dinámica que cogen por DHCP. Así, cread una pareja de claves para el usuario portatil1.asir2 y configurad el acceso para que ese portátil pueda actualizar correctamente su nombre de dominio portatil1.asir2 con la IP que se le indique. Entrega: Los ficheros de configuración del servidor que hayáis modificado o creado, así como el fichero de script y los dos ficheros generados para las claves.