Los “Regional Internet Registries” (RIRs) son las organizaciones encargadas de administrar y delegar recursos de números IPs (IPv4 e IPv6) y Números Autónomos (ASN) en todo el mundo. Existen 5 en total, cada una a cargo de una región en particular. En el caso de Latinoamérica, el RIR es LACNIC, instalado en Montevideo, Uruguay; y es así como también tenemos APNIC en Asia Pacífico, AFRINIC en África, RIPE en Europa y ARIN en Norteamérica.
Dentro de las labores de cada RIR está el mantener el sub-árbol DNS de los reversos de las direcciones IP que son delegadas a un usuario final. Es así como si por ejemplo NIC Chile recibe el prefijo IPv4 200.7.7.0/24 desde LACNIC, se debe mantener sus nombres reversos bajo 7.7.200.in-addr.arpa, que es hijo de la zona padre 200.in-addr.arpa, administrado por LACNIC. Y así cada asignatario de un prefijo IP en LACNIC puede pedirle la delegación de su segmento.
Para ello, LACNIC dispone de un panel de control donde cada organización puede declarar sus servidores de nombre (NS), y así obtener la delegación en el DNS.
El problema con las transferencias inter-RIR
Hasta acá todo bien, pero ¿qué sucede cuando una organización en LACNIC sub-delega a su vez un trozo de su asignación a una organización que quiere registrarse en otro RIR? Eso es lo que se llama “transferencia inter-RIR”. Ocurre cuando por ejemplo una organización europea, que tiene escasez de direcciones IPv4, llega a un acuerdo con alguna organización latinoamericana que tuviera direcciones en desuso, y acuerdan traspasarse un segmento. En este caso, tanto la entidad que cede un segmento, como la destinataria, acuden a LACNIC y a RIPE para dejar registro de la transferencia, y que se actualicen datos de whois, geolocalización, y sobre todo de administración del reverso del segmento, que a partir de esta transferencia aparecerá en el panel de usuario en RIPE del organismo nuevo, y ya no aparecerá en el panel de usuario de LACNIC.
(Acceso libre, no requiere suscripción)
Sin embargo, un problema que se presenta es cómo justamente delegar correctamente el reverso del recurso en el DNS.
En un caso como en el del ejemplo, el nuevo asignatario definirá en RIPE los NS a los que quiere delegar el segmento, pero ese sub-árbol del DNS no pertenece a RIPE sino a LACNIC, por lo que es necesario algún tipo de coordinación para comunicar los datos.
Los zonelets
Sin embargo, un problema que se presenta es cómo justamente delegar correctamente el reverso del recurso en el DNS.
En un caso como en el del ejemplo, el nuevo asignatario definirá en RIPE los NS a los que quiere delegar el segmento, pero ese sub-árbol del DNS no pertenece a RIPE sino a LACNIC, por lo que es necesario algún tipo de coordinación para comunicar los datos.
Los zonelets
El mecanismo que se definió en estos casos entre todos los RIRs fue el uso de “zonelets”, que son trozos de configuración DNS que cada RIR comunica al RIR que corresponde a la delegación inversa del recurso, mediante un mecanismo automatizado que diariamente comparte esta información.
Volviendo al ejemplo, cuando esta organización defina en RIPE sus NSs, es RIPE el que arma un “zonelet” con estos datos, lo pone en un repositorio privado y compartido entre los distintos RIRs, y es LACNIC el que recoge este trozo de configuración y lo pone en el reverso correspondiente. De esta manera, la consulta DNS que parte en in-addr.arpa, luego se delega al prefijo bajo control de LACNIC, y bajando en el árbol llega un momento en que es delegado finalmente a los NS del cliente final.
El problema con los zonelets
Este mecanismo ha funcionado bien por años, pese a algunos problemas esporádicos que se han debido a mala mantención de sistemas y falta de comprobación, sistemas que han sido mejorados en el tiempo. Sin embargo, el sistema adolece de un problema más intrínseco a la solución, que es el tiempo que tarda un cambio en llevarse al DNS. Un mecanismo del estilo de los zonelets requiere de procesamiento en “batch” y chequeos que no necesariamente son lo suficientemente rápidos.
Por otro lado, en la realidad actual de agotamiento de IPv4 se espera que las transferencias inter-RIR sean cada vez más frecuentes, sometiendo al sistema a cargas mayores.
Es por esto que nuestra propuesta es modificar el mecanismo de re-delegación con una técnica relativamente nueva en el DNS que hace mucho más simple el proceso, quedando todo dentro del protocolo normal del DNS: el uso de DNAMEs.
Qué es DNAME
DNAME es una técnica de extensión del DNS definida originalmente el año 1999, pero actualizada en el RFC6672 del año 2012, que define un registro que permite delegar un sub-árbol completo a otro nodo del DNS. El nombre hace referencia al registro famoso CNAME (que quiere decir “canonical name”), que hace un alias pero para un “nodo final” del árbol DNS. DNAME lo hace por toda una rama.
Cómo utilizarlo para reversos
Es así como volviendo a nuestro caso, lo único que debiera hacer LACNIC al momento de ceder uno de sus recursos vía transferencia a otro RIR, es definir un registro DNAME apuntando a un “alias” en el RIR de destino, el que a su vez puede volver a definir NS para los nombres inferiores.
Este alias debiera ser un espacio bajo control del RIR de destino, que es acordado previamente. Usaremos como ejemplo in-addr.delegated.<ESPACIO DEL RIR>.
De esta manera, cualquier cambio de los NS del organismo controlador del prefijo lo hace directamente en RIPE, que a su vez lo modifica bajo el árbol in-addr.delegated.ripe.net directamente bajo su control, sin involucrar más al antiguo RIR LACNIC.
El cliente final debe tener cuidado también de cambiar el nombre de su zona final para respetar el nuevo subárbol bajo control de su RIR, y no directamente en in-addr.arpa como es lo normal.
Los cambios en el procedimiento serían:
un RIR que cede un recurso debe agregar un DNAME en el lugar del zone-cut, apuntando a un nuevo nombre que está bajo control del RIR obteniente;
el RIR obteniente pone en ese nuevo nombre los NS del cliente final,
el cliente final se hace autoritativo de ese nuevo nombre dentro del espacio del RIR obteniente.
En el caso de necesitar “anular” una transferencia, basta con quitar el DNAME y volver a la delegación normal original, con los NS del cliente original
En el caso de delegaciones “profundas” el procedimiento es el mismo. Si un padre delega directamente a un nieto, sin referirse al hijo (empty-non-terminal); es en este mismo punto que se reemplazan los NS por el DNAME al árbol externo.
Estudio de la solución
Se realizó un prototipo de esta solución en laboratorio, donde se validó su operación y se realizaron pruebas reales con distintas plataformas de medición y software de resolución de DNS.
Creemos que esta arquitectura puede ser coordinada entre los RIRs y reemplazar el esquema actual de zonelets. Las mejoras incluyen:
solución más simple como concepto, utilizando estándares de DNS;
dejar de depender en soluciones ad-hoc sujetos a otro tipo de fallas, y pasar a una solución dentro del DNS;
mayor control sobre el cliente final, que vuelve a tener control autoritativo de la zona utilizando el protocolo DNS;
cambios se propagan en forma instantánea, dentro de los rangos normales del DNS.
Por supuesto hay consideraciones que deben tomarse en cuenta, donde habrá cambios en la forma de coordinarse entre cada RIR, pero creemos que son menores a las que existen actualmente y por ende pueden ser llevadas a cabo con planificación y coordinación interna.
También debe considerarse el cambio en la configuración del cliente final, que ahora deberá agregar una etiqueta en el padre, a <rir>.in-addr.arpa.
Por último, es importante tomar en cuenta el TTL de los registros. El aumento en la cadena de resolución puede llevar a timeouts, por lo que es importante hacer uso óptimo del cache.
Sobre la solución misma, los experimentos muestran que podría esperarse un aumento de tasa de fallas del 1.1% utilizando la técnica descrita en este documento, producto de resolvers que no sean capaces de seguir el DNAME. Sin embargo podría aventurarse que estas fallas serían de resolvers muy antiguos, mal configurados, o dentro de redes que hacen filtrado excesivo. Esta tasa de falla podría considerarse que es lo esperable en un ambiente tan diverso como Internet, donde es prácticamente imposible esperar tasas de cero errores. De todas formas, también existe la posibilidad que los propios RIRs lleven a cabo pruebas más cercanas al mundo real, utilizando delegaciones “canario” dentro del árbol real, y utilizando otras métricas de éxito.
Con el presente proyecto, NIC Chile busca apoyar a la comunidad y poner a la disposición una técnica y su análisis, que mejore la experiencia de uso de todos los involucrados.
Las opiniones expresadas por los autores de este blog son propias y no necesariamente reflejan las opiniones de LACNIC.
