DNS en IPv6 Implementacin de Registros A6 Experiencia en RETINA Autores: Guillermo H. Cicileo gcicileo@retina.ar Mariela C. Rocha mrocha@retina.

ar

Resmen

Para hacer corresponder un nombre de dominio con una direccin IPv6, se ha definido un innovador tipo de registro llamado A6, tratndose de una nueva alternativa para almacenar las direcciones IPv6. Dicha forma de almacenamiento tiene como caracterstica fundamental agilizar los procesos de Renumeracin en la red y el de Multi-proveedor (Multihomed). Aunque la relevancia de estas caractersticas se encuentran a la vista de todos los que estamos en el tema, es preciso manifestar que los registros A6 aun se situan en una fase de experimentacin y desarrollo. Este documento pretende compartir las experiencias de RETINA frente a la implementacin de los registros A6 en sus servicios de DNS, intentando de esta forma, colaborar con quienes deseen explorar en la misma direccin.

Introduccin:

El mtodo que tenemos, en general, para referirnos a un host, es a travs del uso de literales o nombres y con ello estamos haciendo mencin implcita a la direccin IP del mismo. Una de las formas, incluso una de las mas comunes, de llevar a cabo este mtodo automtico para el usuario final, es mediante la implementacin de un servicio conocido como DNS (Domain Name System). En primera instancia, el DNS fue definido para IPv4 mediante las especificaciones descriptas en los RFC1034 y RFC1035. Dichos documentos fueron actualizados con el RFC1886 para ampliar el servicio a la resolucin de direcciones con formato IPv6. El RFC1886 define un tipo de registro denominado AAAA, que logra cumplir con el objetivo de llevar a cabo bsquedas basadas en IPv6. No obstante, focalizando las metas en hacer mas fcil el mtodo de Renumeracin y Multi-proveedor, se ha

desarrollado un documento (RFC2874) que propone la introduccin de un nuevo tipo de registro: A6. Actualmente, en las redes de produccin IPv6, se implemeta el servicio de DNS a travs de los registros AAAA y sin mayores inconvenientes, por lo que la transicin a registros A6 se torna aun mas lenta de lo esperado. Como consecuencia de ello y colaborando tambin para que as sea, la documentacin disponible sobre A6 es escasa y adems, suele estar muy dispersa. Para nuestro trabajo en particular, esto ltimo nos oblig a incurrir en una primera y extensa etapa que consisti en la recopilacin y asimilacin de la informacin que resultaba til para nuestro objetivo, un trabajo de investigacin de carcter terico que nos permiti determinar los requrimientos necesarios para encausar nuestra problemtica. Luego, como una segunda etapa, construimos un laboratorio experimental que nos facilitara la investigacin en el orden prctico y en el cual bamos a volcar los resultados de la primer fase. En esta instancia, ya estbamos en condiciones de comenzar con nuestro trabajo, tal como detallamos a continuacin.

Definicin en un archivo de zonas Se denomina archivo de zonas del servidor de nombres a un archivo de base de datos que contiene los registros (cada una de las lneas del archivo) para resolver las distintas partes del dominio de la que es responsable. Es decir, es un archivo que contiene los datos para poder resolver las peticiones de nombres, asociadas a determinado dominio, en direcciones IP. Uno de los registros que se define en un archivo de zona es el denominado Registro de Direccin (Registros de tipo A, ver RFC1034). Un Registro de Direccin sirve para asociar nombres de host a direcciones IP dentro de una zona o dominio. stos son los registros que componen la mayor parte del archivo de zona. Estos registros tendrn un formato que ser diferente ya sea que se trate de una declaracin para resolver direcciones IPv6 o para resolver direcciones IPv4. Si se trata de IPv4, su formato es el siguiente: <nombrehost> IN A <direccinIPdehost> Ejemplos: machine1 IN A 157.55.201.143 nombreservidor2 IN A 157.55.200.2 Lo que significa, por ejemplo, que un cliente no va a necesitar acordarse de

tipear la direccin 157.55.201.143, sino que con tan solo escribir machine1, el servidor de DNS har la traduccin correspondiente basndose en el archivo de zona y en los Registros de Direcciones que all se alojan.

Ahora bien, cmo es el formato de la definicin de un Registro de Direcciones cuando lo que se trata de traducir es una direccin IPv6? En principio, y tal como mencionamos en la Introduccin a este documento, existen los denominados Registros de Direccin AAAA, los cuales describimos: Registros de Direccin AAAA Los Registros de Direccin AAAA, o simplemente Registros AAAA, son quienes reemplazan a los Registros A ya descriptos cuando la traduccin que se lleva a cabo es de nombre a direccin IPv6. Bajo estas conduiciones es muy fcil intuir cul ser su formato: <nombrehost> IN AAAA <direccinIPdehost> Ejemplos: machine2 IN AAAA 3FFE:8070:1019:E00:1234::33 nombreservidor3 IN AAAA 3FFE:8070:1019:E00:1234::4

Pero existe otra cuestin muy fcil de intuir, y ella tiene que ver con la siguiente pregunta: qu pasar cuando, por ejemplo, cambiamos de proveedor y nuestros prefijos por consiguiente cambian tambien? Bajo estas nuevas condiciones, la tarea de actualizar todos y cada uno de los registros se torna ms que tediosa, debido en gran parte, al formato de las direcciones IPv6 en general. Se busc entonces, una manera ms eficz de hacer las traducciones, que no haga necesario el cambio en todas las zonas del dominio, sino que sea un sistema dinmico de traduccin. Como resultado a lo planteado, nacieron los Registros de Direccin A6.

Registros de Direccin A6 El objetivo de los Registros A6, no fue meramente facilitar la escritura, sino tambin agilizar los procesos de Renumbering y Multi-proveedor. Este tipo de registro tiene la particularidad de permitir que una consulta se

haga en forma recursiva, es decir, que la respuesta a una peticin no la proporcione un solo servidor, sino que la consulta puede dividirse en subconsultas y as, recursivamente, ir solicitando las distintas respuestas a los servidores correspondientes. Para facilitar su comprensin, mostraremos el formato de la declaracin de un Registro A6: a.b.c A6 <NN> <address-suffix> <name> Donde: a.b.c es el nombre del dominio que se quiere resolver. NN es el largo del prefijo, o sea, 128 - <address-suffix> Address-suffix es la parte de la direccin que resuelve este registro. Name es el prximo registro que resuleve la otra parte de la direccin (siendo nulo si NN = 0). Veamos un ejemplo: Supongamos que queremos resolver la direccin: mariela.ipv6.retina.ar. En el archivo de zona ipv6.retina.ar, podemos encontrar por ejemplo la siguiente declaracin: mariela IN A6 56 ::22 prueba.subdom.ipv6.retina.ar.

Cmo leemos esta declaracin? Significa que este dominio resuelve solo 72 bits (128 56) bits, y esa resolucin se traduce a ::22, mientras que los 56 bits restantes sern resueltos en el registro prueba.subdom.ipv6.retina.ar. Veamos cmo debera ser la declaracin de prueba.subdom.ipv6.retina.ar, en el dominio subdom.ipv6.retina.ar: prueba.subdom.ipv6.retina.ar. IN A6 0 3ffe:8070:1019:200::

Lo que significa que los 56 bits que faltaban se traducen a: 3ffe:8070:1019:200:: y que ya no hay nada por resolver, tal como lo denota el 0 del campo NN. Lo que caracteriza a estas consultas es que ambas son hechas por el mismo cliente, solo que a servidores distintos, pudindose decir que se trata de una misma consulta dividida en dos subconsultas, y logrando as un carcter de recursiva. Como se puede apreciar, tenemos dos respuestas referidas a la misma

direccin solo que a partes diferentes de la misma. Le corresponder al cliente, entonces, reensamblar las respuestas para conseguir la traduccin correcta. Lograr dicha traduccin en forma completa depende del proceso de resolucin de nombres que se lleve a cabo. Para lograr comprender cmo es que se realiza este proceso, seria conveniente que veamos, en primera instancia, cmo es cuando se trata de IPv4 y luego describiremos lo concerniente a IPv6, o ms puntualmente, el tratamiento de Registros A6 y la resolucin de nombres en el cliente o aplicacin,. Resolucin de nombres La resolucin de nombres por parte de una aplicacin es decir, la traduccin de nombre a IP o viceversa- ha sido realizada tradicionalmente a travs de una interfaz llamada resolver. El resolver consiste bsicamente en una librera de funciones que implementan la tarea asociada con la conversin de nombre a nmero o de nmero a nombre, que puede ser hecha simplemente mirando la informacin en archivos fijos o a travs de algn servicio de directorios como LDAP, NIS , o, en el caso que nos concierne, el DNS. Dada la complejidad inherente al sistema de nombres de dominio, sera muy difcil implementar dicho protocolo a travs de una librera de funciones y por esta razn la solucin fue utilizar un conjunto muy simple de funciones stub resolver- cuya misin es consultar a un servidor de nombres, el que se encarga de toda la resolucin (este tipo de consulta es llamada recursiva, ya que el servidor de DNS consultado resuelve la consulta en nombre del cliente). De esta manera, una aplicacin solamente invoca una subrutina o una funcin de sistema a la cual le pasa como argumentos los parmetros necesarios y recibe como respuesta la informacin deseada (notar que no es necesario aqu implementar ningn protocolo particular). La subrutina en cuestin se encargar de preparar una consulta a un servidor DNS en la forma adecuada (entre otras cosas preparando la informacin para ser transmitida por la red) y esperar que sea este servidor quien le devuelva la respuesta, dejando por lo tanto todo el trabajo en manos del servidor consultado. La informacin que se obtiene de la consulta generalmente es mantenida en memoria compartida del sistema local (cached) para poder utilizarla en consultas subsiguientes sin necesidad de volver a recurrir al DNS (este cache puede ser compartido por mltiples procesos, usuarios, aplicaciones, etc).

Evidentemente, para que este esquema funcione, el resolver debe poder consultar a algn servidor de dominio y por lo tanto necesita saber a qu servidores consultar. Esta informacin generalmente se obtiene del archivo /etc/resolv.conf en el caso de los sistemas Unix/Linux.

DNS SERVER

Lightweight resolver para Ipv6 El protocolo Ipv6 introduce complejidades adicionales en el proceso de resolucin, tales como seguir cadenas de A6 o DNAME. Este tipo de tareas son virtualmente imposibles de realizar a travs del stub resolver tradicional. La solucin a este problema, en el caso de BIND9, ha sido hecha a travs de un conjunto de funciones llamado lightweight resolver library sumado a un proceso daemon que corre en el sistema local: lwresd. La comunicacin entre stos es hecha a travs de un protocolo basado en UDP llamado "lightweight resolver protocol", que es distinto y mucho ms simple que el protocolo DNS. El lwresd es esencialmente una versin reducida de un servidor de nombres, que responde consultasutilizandoelprotocolo"lightweightresolver envez

delprotocoloDNS.EstreprocesoescuchaconsultasenunportUDP(normalmente921) en la interfaz loopback 127.0.0.1 (es decir, slo responde consultas de procesos que correnenlapropiamquina).Reciberequerimientosenelformato"lightweightresolver , resuelveestosrequerimientosutilizandoelDNSycuandolaconsultasecompleta(al recibirrespuestadealgunservidordeDNS),vuelveatraducirestarespuestaalformato "lightweightresolver, parapasrselaalaaplicacinquehabahechoelrequerimiento inicial.

La librera lightweight resolver est implementada a travs de una API

que define las funciones tradicionales de resolucin de nombres: gethostbyname, gethostbyaddr, getaddrinfo, etc. Para permitir la coexistencia de esta librera con las funciones del sistema del mismo nombre, la librera lwres define estas funciones agregandoles el prefijo lwres_ (ej: lwres_getaddrinfo). Una aplicacin que quiera utilizar directamente esta librera en lugar de la tradicional, deber incluir el archivo <lwres/netdb.h> que es simplemente un conjunto de macros que mapean los nombres habituales de las funciones a los nombres con el prefijo lwres_ (por ejemplo: #define getaddrinfo lwres_getaddrinfo es una de las lneas que se pueden encontrar en ese archivo).

DNS SERVER

En sntesis, para poder utilizar resolucin de nombres utilizando registros A6, una aplicacin debera estar codificada utilizando esta librera lwres, ya sea a travs de llamadas explcitas a estas funciones (lwres_getaddrinfo) o, para evitar reescribir el cdigo completo, incluyendo el conjunto de macros del archivo lwres/netdb.h. Si pensamos esto seriamente, significa que ninguna aplicacin actual podra funcionar con registros A6! Habra que re-escribir el cdigo de cada programa para adaptarlo al uso de la librera lwres! Veremos a continuacin una forma alternativa para poder solucionar este problema sin necesidad de tener que lidiar con este tipo de problemas.

Nsswitch.conf Si recordamos lo que dijimos anteriormente, habamos mencionado que el resolver poda realizar la tarea de resolucin de nombres utilizando sistemas de directorios (NIS, LDAP, DNS) o simplemente mirando un archivo plano de texto. Cmo se indica entonces cul es el mtodo a utilizar en un sistema en particular? En los sistemas Unix/Linux modernos (por ejemplo Red Hat y Solaris) esto se realiza a travs del archivo de configuracin /etc/nsswitch.conf. All se especifica para cada base de datos del sistema operativo qu alternativas se debern considerar. Esto involucra desde las bases de datos de usuarios (passwd y shadow) hasta las bases de datos de nombres que es lo que nos concierne (hosts). De esta manera, una lnea en el nsswitch.conf del tipo: hosts: files dns Tratar de resolver nombres primero utilizando el archivo /etc/hosts y luego el DNS. Mientras que algo del tipo: hosts: nisplus ldap Intentar utilizar primero NIS+ y en caso de no hallar all la informacin buscada, utilizar LDAP. Cmo podemos aprovechar esto para nuestro fin? Simplemente agregando un mdulo ms al NSS (Name Service Switch) que implemente la resolucin de nombres mediante la librera lwres.

Mdulo nss_lwres Afortunadamente, esta tarea ya estaba hecha (ver nss_lwres-0.93). Este mdulo, creado por Mark Kettenis (kettenis@gnu.org), provee soporte para el lightweight resolver en sistemas que usan el nsswitch.conf. La idea detrs de esto es reemplazar el mdulo dns del NSS que usa el resolver tradicional por el mdulo lwres que utiliza la librera lwres. Para utilizar este mdulo, se deber incluir una lnea: hosts: files lwres en el nsswitch.conf, que indica que la resolucin de nombres de hosts se har en primer lugar utilizando el archivo /etc/hosts y luego con lwres (en vez de dns). Para que todo funcione, es necesario adems que el daemon lwresd (parte del BIND9) est corriendo en la mquina local, como ya vimos.

En sntesis:

Compilamos el mdulo nss_lwres (libnss_lwres.*) Configuramos hosts en nsswitch.conf para que utilice lwres Debe estar corriendo el lwresd que viene con el BIND9
Experiencia en RETINA - Prcticas realizadas Para realizar las prctica de lo estudiado, decidimos tener dos archivos de zona para dos dominios diferentes y realizar una misma consulta bajo dos situaciones distintas: con y sin la implementacin de lo descripto en los prrafos anteriores. Entonces: Mquina: ws2.retina.ar Dominio: ipv6.retina.ar Archivo de zona: ; ; BIND data file for ipv6.retina $TTL 3600 $ORIGIN ipv6.retina.ar. @ IN SOA ns1.ipv6.retina.ar. hostmaster.retina.ar. ( 2003062601 ; Serial ........ ........ NS NS NS AAAA IN NS ns1.ipv6.retina.ar. ws2-noc.retina.ar. ns1.retina.ar. 3ffe:8070:1019:0200::2 mariela.retina.ar.

; IN IN IN IN subdom ...... ...... wsdab ws3 mariela

IN IN IN IN IN

AAAA A6 A6 AAAA A6

0 0 56

3ffe:8070:1019:0200::20 3ffe:8070:1019:0200::20 3ffe:8070:1019:0200::21 3ffe:8070:1019:0200::21 ::22 prueba.subdom.ipv6.retina.ar.

Mquina: mariela.retina.ar Dominio: subdom.ipv6.retina.ar Archivos de Zona: ; ; Bind data file for ipv6.retina.ar ; $TTL 86400 ; $ORIGIN subdom.ipv6.retina.ar. @ IN SOA mariela.subdom.ipv6.retina.ar. mrocha.retina.ar. ( 2003062601 ; Serial 21600 ; Refresh 6 horas 1200 ; Retry 20 minutos 3600000 ; Expire 86400 ) ; minimun TTL - 24 horas NS NS mariela.retina.ar. ghc.retina.ar.

; IN IN

prueba.subdom.ipv6.retina.ar. IN A6 0 3ffe:8070:1019:200:: ; wsdab IN AAAA 3ffe:8070:1019:0200::20 ws3 IN AAAA 3ffe:8070:1019:0200::21 ghc IN AAAA 3ffe:8070:1019:0200::23 ...... ......

Bajo estas condiciones, en las que la nica foma de obtener una respuesta cuando se pregunta por mariela.ipv6.retina.ar es mediante los registros A6, decidimos en principio, ver cmo se comportaba el sistema cuando no tenamos lwresd corriendo: [root@mariela named]# ps -ef|grep lwresd root 24633 1 0 13:44 ? 00:00:00 /usr/local/sbin/lwresd root 25522 23074 0 15:18 pts/0 00:00:00 grep lwresd [root@mariela named]# kill 24633 [root@mariela named]# ps -ef|grep lwresd [root@mariela named]#

10

Ahora estamos seguros que lwresd no est ejecutndose en nuestra mquina. Luego, probamos utilizar el comando dig para realizar una consulta que nos devuelva la direccin IPv6 de mariela.ipv6.retina.ar:

[root@mariela named]# dig a6 mariela.ipv6.retina.ar ; <<>> DiG 9.2.1 <<>> a6 mariela.ipv6.retina.ar ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15707 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 4 ;; QUESTION SECTION: ;mariela.ipv6.retina.ar. ;; ANSWER SECTION: mariela.ipv6.retina.ar. 3600 ;; AUTHORITY SECTION: ipv6.retina.ar. 3600 IN ipv6.retina.ar. 3600 IN ipv6.retina.ar. 3600 IN

IN

A6

IN

A6

56 ::22 prueba.subdom.ipv6.retina.ar.

NS NS NS

ns1.ipv6.retina.ar. ns1.retina.ar. ws2-noc.retina.ar.

;; ADDITIONAL SECTION: prueba.subdom.ipv6.retina.ar. 86400 IN A6 0 3ffe:8070:1019:200:: ns1.ipv6.retina.ar. 3600 IN A 200.10.202.115 ns1.ipv6.retina.ar. 3600 IN A6 0 3ffe:8070:1019:200::10 ns1.ipv6.retina.ar. 3600 IN AAAA 3ffe:8070:1019:200::10 Vemos en la ejecucin del comando dig que el cliente cuenta con toda la informacin necesaria para poder construir la respuesta correcta basndose en los datos de ANSWER SECTION y ADDITIONAL SECTION. Sin embargo, al intentar utilizar la resolucin de nombres, por ejemplo mediante el comando ssh, obtenemos:

[root@mariela named]# ssh mariela.ipv6.retina.ar ssh: mariela.ipv6.retina.ar: Name or service not known [root@mariela named]# Observamos que aunque los datos estn disponibles, el cliente no puede determinar la direccin Ipv6 de mariela.ipv6.retina.ar. Es fcil deducir que quizs sea el reensamble de la respuesta el que no puede llevarse a cabo, ya que esa es la tarea del

11

deamon lwresd. Nos dispusimos entonces a ejecutar el deamon en cuestin, de la siguiente manera: [root@mariela named]# ps -ef|grep lwresd root 25540 1 0 15:20 ? 00:00:00 /usr/local/sbin/lwresd [root@mariela named]#

Y comprobamos que la respuesta del dig es la misma que en el caso anterior: [root@mariela named]# dig a6 mariela.ipv6.retina.ar ; <<>> DiG 9.2.1 <<>> a6 mariela.ipv6.retina.ar ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34726 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 6 ;; QUESTION SECTION: ;mariela.ipv6.retina.ar. ;; ANSWER SECTION: mariela.ipv6.retina.ar. 3127 ;; AUTHORITY SECTION: ipv6.retina.ar. 3127 IN ipv6.retina.ar. 3127 IN ipv6.retina.ar. 3127 IN

IN

A6

IN

A6

56 ::22 prueba.subdom.ipv6.retina.ar.

NS NS NS

ws2-noc.retina.ar. ns1.ipv6.retina.ar. ns1.retina.ar.

;; ADDITIONAL SECTION: prueba.subdom.ipv6.retina.ar. 86400 IN A6 0 3ffe:8070:1019:200:: ns1.ipv6.retina.ar. 3127 IN A 200.10.202.115 ns1.ipv6.retina.ar. 3127 IN A6 0 3ffe:8070:1019:200::10 ns1.ipv6.retina.ar. 3127 IN AAAA 3ffe:8070:1019:200::10 ns1.retina.ar. 86212 IN A 200.10.202.3 ws2-noc.retina.ar. 86212 IN A 200.10.202.115 Teniendo, al igual que en el caso anterior, todos los datos necesarios para obtener la respuesta correcta, solo que esta vez, lwresd est corriendo. Veamos qu sucede cuando ejecutamos un comando o aplicacin: [root@mariela named]# ssh mariela.ipv6.retina.ar

12

root@mariela.ipv6.retina.ar's password: Last login: Thu Jun 26 15:23:27 2003 from ::1 [root@mariela root]#

Llegado a este punto, queda a la vista de todos cul es el rol del deamon lwresd y su importancia para poder resolver cadenas de registros A6.

Conlusin:

Como se vio a lo largo de este documento, el uso de los nuevos registros A6 involucra actividades y conocimientos poco sencillos hasta lograr su implementacin. Se suma a esto la poca disponibilidad de documentacion adecuada que permita implementarlos con facilidad y el caracter experimental de este tipo de registros que contribuye a su poca divulgacion a gran escala. Por otra parte, el usuario final no advierte la diferencia entre un sistema de resolucin de nombres convencional (mediante registros A o AAAA) y el mecanismo utilizado por los registros A6, por lo que no existira una demanda que impulse el tema. An as, creemos que los beneficios aportados por estos registros sern importantes a la hora de enfrentarnos a una Renumeracin de la red o ante la existencia de una topologa Multi-proveedor, ya que, llegado este momento, no ser trivial un esquema de DNS dinmico, que asegure consistencia y fcil aplicacin.

REFERENCIAS: http://www.isc.org/products/BIND/bind9.html http://www.isc.org/ml-archives/bind9-users/2000/07/msg00025.html http://resin.csoft.net/cgi-bin/man.cgi?section=8&topic=lwresd http://www.arsys.es/soporte/productos/guia/dns.htm http://www.ietf.org/rfc/rfc1034.txt http://www.ietf.org/rfc/rfc1035.txt Agradecimientos: Ing. Santiago L. Aggio CRIBABB (Centro Regional de Investigaciones Bsicas Aplicadas de Baha Blanca) Ing. Carlos Barcenilla (Universidad Tecnolgica Nacional Facultad Regional La Plata) Daniel A. Bellomo RETINA (Red Teleinformtica Acadmica)

13