jpsalviano

DNS, delegação e o IP que não era meu

Com meu Aspire headless e debloated como um servidor, queria me aprofundar mais em como poderia expor o que estivesse rodando ali para usuários externos, de forma segura. Isso exigia noções mais concretas de DNS e redes, e o primeiro passo foi adquirir o domínio jpsalviano.com.br. É o handler que uso a vida toda no Twitter, Instagram e Facebook, agora reaproveitado como identidade profissional de engenheiro de software. No momento, porém, o domínio representava só uma intenção, pois faltava o essencial: um IP alcançável para onde ele pudesse resolver.

Um domínio por si só não significa nada enquanto não o apontarmos para um endereço físico na internet. Para entender esse processo, é preciso adentrar numa questão administrativa importante. Globalmente, o Domain Name System (DNS) é coordenado pelo ICANN (Internet Corporation for Assigned Names and Numbers), que garante a unicidade dos nomes. Essa instituição delega, ao redor do mundo, o gerenciamento de Top Level Domains (TLDs) a instituições Registry, que por sua vez mantêm um banco de dados mestre de seu(s) TLD(s). No caso brasileiro, o NIC.br fica responsável pelo TLD .br. Outras instituições conhecidas como Registrar têm o papel de comercializar, via arrendamento (leasing), domínios dentro do TLD à escolha dos clientes, ou Registrants. No Brasil, temos o Registro.br, braço do NIC.br que atua como registrar, onde eu mesmo, no papel de registrant, fiz a aquisição do jpsalviano.com.br. Além da comercialização, o Registro.br se encarrega de registrar no WHOIS, sistema público de consulta de dados de domínios, a minha identidade como registrant e os nameservers atribuídos ao meu domínio. Por isso, adquirir um domínio é um ato puramente administrativo. A hierarquia global do DNS ainda não possui nenhuma instrução técnica sobre para onde mandar o tráfego.

O DNS é um sistema hierárquico e distribuído de resolução em camadas. A camada global, root, é mantida pelo ICANN; as camadas de TLD são mantidas pelos respectivos registries; e a camada de domínio fica a cargo dos nameservers autoritativos. Até eles, nenhuma camada sabe a resposta para a pergunta principal: para qual endereço este domínio deve resolver? O DNS Resolver é quem fundamentalmente responde a essa pergunta. Trata-se de um software que sabe como percorrer essa hierarquia recursivamente, questionando do seu ponto mais alto ao mais baixo, camada por camada. Existem vários DNS Resolvers públicos na internet, todos seguindo o mesmo protocolo de resolução. O mais conhecido é o do Google, no endereço 8.8.8.8. Quando requisitamos jpsalviano.com.br ao resolver, ele consulta:

Esse caminho não é percorrido a cada requisição. Existe um sistema de cache redundante: no cliente, tanto no browser quanto no sistema operacional (stub resolver), e no próprio DNS Resolver. Caso não exista registro em cache, ou ele já tenha expirado (pelo TTL, time to live), aí sim o resolver percorre a hierarquia em busca do IP final, e grava o resultado nos caches para reaproveitamento posterior. Resta uma pergunta: quem responde, hoje, como autoritativo pelo jpsalviano.com.br? Foi exatamente isso que configurei ao trocar os nameservers do domínio.

Ao registrar um domínio .br, os nameservers autoritativos default são do Registro.br. Isto é, na última camada da hierarquia do DNS, os servidores que apontam o IP de resolução para o domínio são definidos no próprio registrar. Decidi fazer uma delegação de DNS, alterando a autoridade técnica sobre o jpsalviano.com.br do Registro.br para a Cloudflare, que oferece um plano de DNS gratuito. Por enquanto, basta compreender que, ao adicionar o domínio na Cloudflare, recebo a atribuição de dois nameservers da infraestrutura dela: aryanna.ns.cloudflare.com e pranab.ns.cloudflare.com. Repare que esses nameservers são nomes, não endereços IP. Isso geraria um problema circular: para resolver aryanna.ns.cloudflare.com, o resolver precisaria consultar um nameserver, que também é um nome. A hierarquia quebra esse ciclo com o glue record, o IP do nameserver é entregue junto ao referral, permitindo a conexão direta. Então, para que o servidor TLD na cadeia de DNS possa entender que esses serão os nameservers autoritativos do domínio, concretizamos a delegação no registrar, substituindo os nameservers default por esses atribuídos pela Cloudflare. Dessa maneira, o servidor na camada TLD da hierarquia DNS passa a indicar os nameservers da Cloudflare, e a zona de DNS inserida ali passa a ser a fonte da verdade sobre como resolver o domínio. Vale notar que o domínio continua registrado no Registro.br. O que mudou foi apenas quem responde como autoridade técnica: o registro administrativo e a autoridade de DNS são responsabilidades separadas, e podem ficar em provedores diferentes.

O arquivo de zona (zone file) reside nos nameservers e contém o mapeamento final da resolução DNS: registros que associam nomes aos endereços IP onde estão hospedados os recursos acessados pelos visitantes. Cada registro tem um tipo; alguns comuns são CNAME e MX. O A record, que mapeia um nome a um endereço IPv4 (seu equivalente para IPv6 é o AAAA), foi o que inseri para apontar jpsalviano.com.br ao meu IP público, definindo o caminho até o conteúdo servido pelo meu Aspire. Ou pelo menos, era esse o plano.

Vamos percorrer o fluxo de toda resolução DNS para qualquer domínio devidamente apontado a um IP público:

  1. O usuário digita o domínio no seu browser. Antes de qualquer consulta à hierarquia, três caches são checados em ordem: no browser, no stub resolver do sistema operacional, e no próprio resolver recursivo. A maioria das requisições para aqui.

  2. Quando não existe consulta em cache, ou quando expirada pelo TTL, o resolver recursivo percorre a hierarquia do DNS, coletando referrals. Primeiro, requisita ao root sobre o TLD (.br); em seguida, requisita ao NIC.br sobre o autoritativo; finalmente requisita aos nameservers da Cloudflare, que consultam o A record do arquivo de zona e devolvem o IP ao resolver. O resolver então retorna esse endereço ao browser do usuário.

  3. Com o IP em mãos, o browser abre uma conexão TCP na porta 443, faz o handshake TLS para abrir uma sessão criptografada, e executa uma requisição GET HTTP, pedindo o recurso ao servidor endereçado, que responderá ao usuário.

E aqui vem o choque de realidade. Quando fui descobrir qual IP público colocar no A record, esbarrei em dois problemas com o IPv4 público atribuído à interface de rede da máquina. Primeiro, ele é dinâmico, podendo ser alterado pelo provedor sem aviso prévio, o que quebraria o mapeamento no A record. E pior: esse IP público não pertence à minha máquina, e sim a um equipamento do provedor que o compartilha entre vários clientes, num sistema chamado CGNAT. Não há como, de fora da rede, endereçar um pacote especificamente ao meu Aspire. Mais detalhes sobre esses obstáculos, e como os superei com a ajuda de outros serviços gratuitos da Cloudflare, são os temas do próximo post. Continuem acompanhando ;)