{"id":16780,"date":"2022-04-05T16:26:06","date_gmt":"2022-04-05T16:26:06","guid":{"rendered":"https:\/\/prensa.lacnic.net\/news?p=16780"},"modified":"2022-05-16T15:08:32","modified_gmt":"2022-05-16T15:08:32","slug":"uso-do-dname-para-reversos-de-recursos-transferidos-intra-rirs","status":"publish","type":"post","link":"https:\/\/blog.lacnic.net\/pt-br\/uso-do-dname-para-reversos-de-recursos-transferidos-intra-rirs\/","title":{"rendered":"Uso do DNAME para reversos de recursos transferidos intra-RIRs"},"content":{"rendered":"\n

Escrito por Hugo Salgado<\/a><\/p>\n\n\n\n

Publica\u00e7\u00e3o original: NIC Chile<\/p>\n\n\n\n

Os “Regional Internet Registries” (RIRs) s\u00e3o as organiza\u00e7\u00f5es encarregadas de administrar e delegar recursos de n\u00fameros IPs (IPv4 e IPv6) e n\u00fameros aut\u00f4nomos (ASN) no mundo todo. H\u00e1 5 em total, cada uma respons\u00e1vel por uma regi\u00e3o em particular. No caso da Am\u00e9rica Latina, o RIR \u00e9 o LACNIC, instalado em Montevideu, Uruguai, da mesma forma temos APNIC na \u00c1sia Pac\u00edfico, AFRINIC na \u00c1frica, RIPS na Europa e ARIN na Am\u00e9rica do Norte.<\/p>\n\n\n\n

Dentro das fun\u00e7\u00f5es de cada RIR est\u00e1 a de manter a sub-\u00e1rvore DNS dos reversos dos endere\u00e7os IP que s\u00e3o delegados a um usu\u00e1rio 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 \u00e9 o filho da zona pai 200.in-addr.arpa, administrado pelo LACNIC. E \u00e9 assim que cada signat\u00e1rio de um prefixo IP no LACNIC pode pedir delega\u00e7\u00e3o de um segmento.<\/p>\n\n\n\n

Para isso, o LACNIC disp\u00f5e de um painel de controle onde cada organiza\u00e7\u00e3o pode declarar seus servidores de nome (NS), e obter assim a delega\u00e7\u00e3o no DNS.<\/p>\n\n\n\n

O problema com as transfer\u00eancias intra RIR<\/strong><\/p>\n\n\n\n

At\u00e9 aqui tudo bem, mas o que ocorre quando uma organiza\u00e7\u00e3o no LACNIC sub-delega tamb\u00e9m uma parte de sua aloca\u00e7\u00e3o a uma organiza\u00e7\u00e3o que quer se registrar em outro RIR? Isso \u00e9 o que se chama \u201ctransfer\u00eancia intra RIR. Ocorre, por exemplo, quando uma organiza\u00e7\u00e3o europeia, que possui escassez de endere\u00e7os IPv4, chega a um acordo com alguma organiza\u00e7\u00e3o latino-americana que tenha endere\u00e7os em desuso, e pactuam a transfer\u00eancia de um segmento. Neste caso, tanto a entidade que cede um segmento, quanto a destinat\u00e1ria, recorrem ao LACNIC e ao RIPE para deixar registro da transfer\u00eancia e para que os dados whois e os de geolocaliza\u00e7\u00e3o sejam atualizados, bem como os de administra\u00e7\u00e3o do reverso do segmento, que a partir desta transfer\u00eancia aparecer\u00e1 no painel do usu\u00e1rio no RIPE do organismo novo, e n\u00e3o aparecer\u00e1 no painel do usu\u00e1rio do LACNIC.<\/p>\n\n\n\n

Por\u00e9m, um problema que surgiu \u00e9 como delegar corretamente o reverso do recurso no DNS.<\/p>\n\n\n\n

No caso do exemplo acima, o novo signat\u00e1rio definir\u00e1 no RIPE os NS aos quais deseja delegar o segmento, mas essa sub-\u00e1rvore do DNS n\u00e3o pertencer\u00e1 ao RIPE, mas sim ao LACNIC, portanto ser\u00e1 necess\u00e1rio algum tipo de coordena\u00e7\u00e3o para comunicar os dados.<\/p>\n\n\n\n

Os zonelets<\/strong><\/p>\n\n\n\n

O mecanismo definido nestes casos, entre todos os RIRs, foi o uso de “zonelets”, que s\u00e3o peda\u00e7os de configura\u00e7\u00e3o DNS que cada RIR comunica ao RIR correspondente \u00e0 delega\u00e7\u00e3o inversa do recurso, mediante um mecanismo automatizado que diariamente compartilha informa\u00e7\u00e3o.<\/p>\n\n\n\n

Voltando ao referido exemplo, quando esta organiza\u00e7\u00e3o definir no RIPE seus NSs, \u00e9 o RIPE que montar\u00e1 um “zonelet” com estes dados, colocando-o num reposit\u00f3rio privado e compartilhado entre os diferentes RIRs, e \u00e9 o LACNIC que coleta esta parte da configura\u00e7\u00e3o e a coloca no reverso correspondente. Desta forma, a consulta DNS que parte em in-addr.arpa \u00e9 delegada ao prefixo sob controle do LACNIC, e, descendo pela \u00e1rvore, chega uma hora na qual este \u00e9 delegado finalmente aos NS do cliente final.<\/p>\n\n\n\n

O problema com os zonelets<\/strong><\/p>\n\n\n\n

Este mecanismo funcionou bem por muitos anos, pese a alguns problemas espor\u00e1dicos devido a uma manuten\u00e7\u00e3o ruim de sistemas e \u00e0 falta de comprova\u00e7\u00e3o, sistemas que foram aperfei\u00e7oados com o tempo. No entanto, o sistema carece de um problema mais intr\u00ednseco \u00e0 solu\u00e7\u00e3o, que \u00e9 o tempo que demora uma altera\u00e7\u00e3o em levar o DNS. Um mecanismo do estilo dos zonelets requer de processamento em \u201cbatch\u201d e checagens que n\u00e3o s\u00e3o suficientemente r\u00e1pidas.<\/p>\n\n\n\n

Por outro lado, na realidade atual de esgotamento de IPv4, espera-se que as transfer\u00eancias intra-RIR sejam cada vez mais frequentes, submetendo os sistemas a cargas maiores.<\/p>\n\n\n\n

\u00c9 por esse motivo que a nossa proposta \u00e9 modificar o mecanismo de re-delega\u00e7\u00e3o com uma t\u00e9cnica 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.<\/p>\n\n\n\n

O que \u00e9 DNAME<\/strong><\/p>\n\n\n\n

DNAME \u00e9 uma t\u00e9cnica de extens\u00e3o do DNS definida originalmente no ano 1999, atualizada no RFC6672 do ano 2012, que define um registro que permite delegar uma sub-\u00e1rvore completa a outro n\u00f3 do DNS.  O nome refere ao registro famoso CNAME (que quer dizer “canonical name”), o qual realiza um alias, mas para um \u201cn\u00f3 final\u201d da \u00e1rvore DNS. DNAME, o faz para o galho completo.<\/p>\n\n\n\n

Como utiliz\u00e1-lo para reversos<\/strong><\/p>\n\n\n\n

\u00c9 assim, voltando ao nosso caso, que o \u00fanico que o LACNIC deveria fazer na hora de ceder um de seus recursos via transfer\u00eancia a outro RIR, \u00e9 definir um registro DNAME, apontando a um \u201calias\u201d no RIR destino, que, por sua vez, pode voltar a definir NS para os nomes inferiores.<\/p>\n\n\n\n

Este alias deveria ser um espa\u00e7o sob controle do RIR de destino, acordado previamente.  Usaremos como exemplo in-addr.delegated.<ESPACIO DEL RIR>.<\/p>\n\n\n\n

Desta forma, qualquer altera\u00e7\u00e3o dos NS do organismo controlador do prefixo \u00e9 realizado diretamente no RIPE, que por sua vez \u00e9 modificado sob a \u00e1rvore in-addr.delegated.ripe.net, diretamente sob seu controle, sem ter que envolver o antigo RIR LACNIC.<\/p>\n\n\n\n

O cliente final deve ter cuidado tamb\u00e9m de alterar o nome de sua zona final para respeitar a nova sub-\u00e1rvore sob o controle de seu RIR, e n\u00e3o diretamente em in-addr.arpa como normalmente se faz.<\/p>\n\n\n\n

As altera\u00e7\u00f5es no procedimento ser\u00e3o:<\/p>\n\n\n\n

1. um RIR que cede um recurso deve adicionar um DNAME no lugar do zone-cut, apontando a um novo nome que est\u00e1 sob o controle do RIR possuidor;<\/p>\n\n\n\n