Os “Regional Internet Registries” (RIRs) são as organizações encarregadas de administrar e delegar recursos de números IPs (IPv4 e IPv6) e números autônomos (ASN) no mundo todo. Há 5 em total, cada uma responsável por uma região em particular. No caso da América Latina, o RIR é o LACNIC, instalado em Montevideu, Uruguai, da mesma forma temos APNIC na Ásia Pacífico, AFRINIC na África, RIPS na Europa e ARIN na América do Norte.
Dentro das funções de cada RIR está a de manter a sub-árvore DNS dos reversos dos endereços IP que são delegados a um usuário final. Por exemplo, se o NIC Chile recebe o prefixo IPv4 200.7.7.0/24 do LACNIC, deve manter seus nomes reversos sob 7.7.200.in-addr.arpa, que é o filho da zona pai 200.in-addr.arpa, administrado pelo LACNIC. E é assim que cada signatário de um prefixo IP no LACNIC pode pedir delegação de um segmento.
Para isso, o LACNIC dispõe de um painel de controle onde cada organização pode declarar seus servidores de nome (NS), e obter assim a delegação no DNS.
O problema com as transferências intra RIR
Até aqui tudo bem, mas o que ocorre quando uma organização no LACNIC sub-delega também uma parte de sua alocação a uma organização que quer se registrar em outro RIR? Isso é o que se chama “transferência intra RIR. Ocorre, por exemplo, quando uma organização europeia, que possui escassez de endereços IPv4, chega a um acordo com alguma organização latino-americana que tenha endereços em desuso, e pactuam a transferência de um segmento. Neste caso, tanto a entidade que cede um segmento, quanto a destinatária, recorrem ao LACNIC e ao RIPE para deixar registro da transferência e para que os dados whois e os de geolocalização sejam atualizados, bem como os de administração do reverso do segmento, que a partir desta transferência aparecerá no painel do usuário no RIPE do organismo novo, e não aparecerá no painel do usuário do LACNIC.
(Acesso livre, não requer assinatura)
Porém, um problema que surgiu é como delegar corretamente o reverso do recurso no DNS.
No caso do exemplo acima, o novo signatário definirá no RIPE os NS aos quais deseja delegar o segmento, mas essa sub-árvore do DNS não pertencerá ao RIPE, mas sim ao LACNIC, portanto será necessário algum tipo de coordenação para comunicar os dados.
Os zonelets
Porém, um problema que surgiu é como delegar corretamente o reverso do recurso no DNS.
No caso do exemplo acima, o novo signatário definirá no RIPE os NS aos quais deseja delegar o segmento, mas essa sub-árvore do DNS não pertencerá ao RIPE, mas sim ao LACNIC, portanto será necessário algum tipo de coordenação para comunicar os dados.
Os zonelets
O mecanismo definido nestes casos, entre todos os RIRs, foi o uso de “zonelets”, que são pedaços de configuração DNS que cada RIR comunica ao RIR correspondente à delegação inversa do recurso, mediante um mecanismo automatizado que diariamente compartilha informação.
Voltando ao referido exemplo, quando esta organização definir no RIPE seus NSs, é o RIPE que montará um “zonelet” com estes dados, colocando-o num repositório privado e compartilhado entre os diferentes RIRs, e é o LACNIC que coleta esta parte da configuração e a coloca no reverso correspondente. Desta forma, a consulta DNS que parte em in-addr.arpa é delegada ao prefixo sob controle do LACNIC, e, descendo pela árvore, chega uma hora na qual este é delegado finalmente aos NS do cliente final.
O problema com os zonelets
Este mecanismo funcionou bem por muitos anos, pese a alguns problemas esporádicos devido a uma manutenção ruim de sistemas e à falta de comprovação, sistemas que foram aperfeiçoados com o tempo. No entanto, o sistema carece de um problema mais intrínseco à solução, que é o tempo que demora uma alteração em levar o DNS. Um mecanismo do estilo dos zonelets requer de processamento em “batch” e checagens que não são suficientemente rápidas.
Por outro lado, na realidade atual de esgotamento de IPv4, espera-se que as transferências intra-RIR sejam cada vez mais frequentes, submetendo os sistemas a cargas maiores.
É por esse motivo que a nossa proposta é modificar o mecanismo de re-delegação com uma técnica relativamente nova no DNS, que faz com que o processo seja mais simples, ficando tudo dentro do protocolo normal do DNS: o uso de DNAMEs.
O que é DNAME
DNAME é uma técnica de extensão do DNS definida originalmente no ano 1999, atualizada no RFC6672 do ano 2012, que define um registro que permite delegar uma sub-árvore completa a outro nó do DNS. O nome refere ao registro famoso CNAME (que quer dizer “canonical name”), o qual realiza um alias, mas para um “nó final” da árvore DNS. DNAME, o faz para o galho completo.
Como utilizá-lo para reversos
É assim, voltando ao nosso caso, que o único que o LACNIC deveria fazer na hora de ceder um de seus recursos via transferência a outro RIR, é definir um registro DNAME, apontando a um “alias” no RIR destino, que, por sua vez, pode voltar a definir NS para os nomes inferiores.
Este alias deveria ser um espaço sob controle do RIR de destino, acordado previamente. Usaremos como exemplo in-addr.delegated.<ESPACIO DEL RIR>.
Desta forma, qualquer alteração dos NS do organismo controlador do prefixo é realizado diretamente no RIPE, que por sua vez é modificado sob a árvore in-addr.delegated.ripe.net, diretamente sob seu controle, sem ter que envolver o antigo RIR LACNIC.
O cliente final deve ter cuidado também de alterar o nome de sua zona final para respeitar a nova sub-árvore sob o controle de seu RIR, e não diretamente em in-addr.arpa como normalmente se faz.
As alterações no procedimento serão:
1. um RIR que cede um recurso deve adicionar um DNAME no lugar do zone-cut, apontando a um novo nome que está sob o controle do RIR possuidor;
o RIR possuidor coloca nesse novo nome aos NS do cliente final,
o cliente final se torna autoritativo desse novo nome dentro do espaço do RIR possuidor.
No caso de precisar “anular” uma transferência, é só tirar o DNAME e voltar à delegação normal original, com os NS do cliente original.
No caso de delegações “profundas” o procedimento é o mesmo. Se um pai delega diretamente um neto, sem se referir ao filho (empty-non-terminal); é neste mesmo ponto que são revezados os NS pelo DNAME para a árvore externa.
Estudo da solução
Foi realizado um protótipo desta solução no laboratório, onde foi validada a sua operação e realizados testes reais com diferentes plataformas de medição e software de resolução de DNS.
Acreditamos que esta arquitetura pode ser coordenada entre os RIRs e substituir o esquema atual de zonelets. As melhoras incluem:
solução mais simples como conceito, utilizando padrões de DNS;
não depender de soluções ad-hoc sujeitas a outro tipo de falhas e passar a uma solução dentro do DNS;
maior controle sobre o cliente final que volta a ter controle autoritativo da zona, utilizando o protocolo DNS;
as alterações são propagadas de forma instantânea, dentro das faixas normais do DNS.
Obviamente, há ponderações a serem levadas em conta, onde haverá alterações na coordenação entre cada RIR, porém acreditamos que são menores das que existem atualmente, portanto podem ser levadas adiante com planejamento e coordenação interna.
Também deve ser considerada a alteração na configuração do cliente final, que agora deverá colocar uma etiqueta no pai, a <rir>.in-addr.arpa.
Por último, é importante levar em conta o TTL dos registros. O aumento na cadeia de resolução pode levar a timeouts, por isso é fundamental fazer um bom uso do cache.
Sobre a solução propriamente dita, os especialistas mostram que poderia se esperar um aumento da taxa de falhas de 1.1%, utilizando a técnica descrita neste documento, produto de resolvers capazes de seguir o DNAME. No entanto, podemos pensar que estas falhas seriam de resolvers muito antigos, mal configurados, ou dentro de redes que realizam filtros excessivos. Esta taxa de falha poderia se considerar normal em um ambiente tão diverso como a Internet, onde é praticamente impossível obter taxas zero de erros. Mesmo assim, existe a possibilidade de que os próprios RIRs levem adiante testes que se aproximem mais ao mundo real, utilizando delegações “canário” dentro da árvore real e outras métricas de sucesso.
Com este projeto, o NIC Chile procura dar apoio à comunidade e pôr à disposição uma técnica e sua análise, a fim de melhorar a experiência de uso de todos os envolvidos.
As opiniões expressas pelos autores deste blog são próprias e não refletem necessariamente as opiniões de LACNIC.
