Conceitos de DNS Parte 1

Essa documentação sobre DNS vai ser um pouco maçante no começo, vou tentar abordar toda a teoria nesse começo e deixar a parte prática para o final, tendo o objetivo de abordar o uso de DNS com BIND e NSD, pretendo reservar um espaço para Unbound e DnsMasq.

DNS - Domain Name System

O DNS (Domain Name System) ou em Português Brasileiro Sistema de Nomes de Domínio, desempenha um papel crucial na infraestrutura da Internet, sendo fundamental para a forma como navegamos e comunicamos hoje em dia. Desde sua criação até os dias atuais, o DNS tem sido uma peça essencial que possibilitou e ainda possibilita o crescimento e a escalabilidade da Internet.

O DNS é responsável por traduzir um nome de domínio em um ou mais endereços IP. Ele funciona como uma lista telefônica, permitindo que você encontre o endereço de um site usando o nome do site. Traduzir um nome de domínio em um ou mais endereços IP é essencial para que possamos acessar sites facilmente sem ter que memorizar múltiplos endereços IP.

Um endereço IP é um número exclusivo atribuído a cada dispositivo conectado a uma rede de computadores, cada dispositivo possui um endereço IP para que possam se comunicar na rede. Esse número identifica de forma única um dispositivo na rede, permitindo que qualquer outro dispositivo na rede possa localizar e se comunicar uns com os outros.

Por padrão, os clientes DNS fazem consultas na porta 53 usando o User Datagram Protocol (UDP). No entanto, é possível fazer consultas usando o Transmission Control Protocol (TCP), especificando no cliente DNS que a consulta deve ser realizada usando TCP. As conexões na porta 53 usando TCP só ocorrem por padrão em transferências de zona, mas podemos fazer consultas normais usando elas também, só que isso não é um comportamento normal.

Um pouco de história

A história do DNS data de muitas décadas atrás. Em 1958 o Governo dos Estados Unidos da America criou ARPA (Advanced Research Projects Agency, hoje é conhecida como DARPA - Defense Advanced Research Projects Agency) em resposta ao lançamento do Sputnik pela União Soviética em 1957, esse fato marcou o início da corrida espacial durante a Guerra Fria.

O Sputnik foi primeiro satélite artificial colocado órbita pela humanidade.

Por causa da Guerra Fria, havia uma grande preocupação com a vulnerabilidade das comunicações militares serem interceptadas pelos inimigos dos Estados Unidos da America. Com isso, entre 1968 e 1969 Lawrence Roberts e a ARPA criaram a ARPAnet (Advanced Research Projects Agency Network). A ARPAnet foi a primeira rede de computadores criada para transmitir dados militares sigilosos e interligar os departamentos de pesquisa por todo os Estados Unidos, facilitando assim o compartilhamento de informações e recursos computacionais.

Inicialmente, o processo de atribuição de endereços para computadores na rede era mantido pelo Stanford Research Institute Network Information Center (SRI NIC) e todo o processo de cadastrar um novo computador (Nome e endereço) era manual. O registro de computadores, com seus respectivos nomes de host e endereços IP, era feito manualmente e adicionado a um arquivo chamado HOSTS.TXT. Esse arquivo era mantido e distribuído centralmente por um único host, conhecido como SRI-NIC.

Os administradores da ARPAnet enviavam as alterações e/ou adições por e-mail para a SRI NIC. A SRI NIC compilava manualmente as alterações recebidas por e-mail em um novo arquivo hosts.txt, isso ocorria uma ou duas vezes por semana. O novo arquivo hosts.txt era disponibilizado para download via FTP (File Transfer Protocol). Os administradores da ARPANET precisavam então se conectar ao servidor FTP da SRI-NIC, baixar o arquivo e substituir o arquivo antigo pelo novo em seus computadores.

À medida que a ARPANET crescia e se tornava mais complexa, surgia a necessidade de um sistema que permitisse aos usuários encontrar informações sobre recursos específicos e os contatos associados a esses recursos. Foi nesse contexto que Jon Postel e Elizabeth Feinler, da SRI International (anteriormente Stanford Research Institute), desenvolveram e implementaram o sistema WHOIS.

O WHOIS foi criado como um diretório central, hospedado em um servidor do SRI-NIC, para facilitar a busca e obtenção de informações sobre hosts, servidores e outros recursos conectados à ARPANET.

Nessa etapa, o crescente número de sites fez com que o arquivo hosts.txt fosse ficando cada vez maior e havia uma grande necessidade de um modelo descentralizado, fácil de implantar e que fosse escalável. Um grupo foi criado para lidar com esse problema, entre eles estavam: Jon Postel, Paul Mockapetris e Craig Partrige, eles ficaram responsáveis de criar um sistema onde as pessoas não precisassem lembrar o endereço IP de cada computador e que também não ficassem dependentes do nosso já conhecido hosts.txt.

Em novembro de 1983 foram publicadas duas RFCs propondo a arquitetura do DNS, que são: RFC 882 e RFC 883. Ambas RFC foram um marco importante no desenvolvimento do DNS, nessa nova arquitetura, o DNS era um sistema distribuído em mais de um servidor.

De 1983 para 1984 Paul Mockapetris escreveu a primeira implementação de DNS, o codinome era Jeeves, esse DNS foi escrito para ser executado nas máquinas DEC Tops-20 localizadas no Instituto de Ciências da Informação da Universidade do Sul da Califórnia (USC-ISI) e no Centro de Informações de Rede da SRI International (SRI-NIC). O intuito do Jeeves era resolver o problemas de escalabilidade na rede ARPANET, era um protótipo de servidor DNS utilizado para testar e validar os conceitos que Mockapetris estava desenvolvendo. Este protótipo ajudou a demonstrar a viabilidade do DNS como um sistema distribuído e hierárquico para resolver nomes de domínio em endereços IP. Apesar de sua importância como prova de conceito, o Jeeves não foi o sistema DNS final implementado em larga escala.

Em outubro de 1984 Jon Postel e Joyce Reynolds publicaram a RFC 920 que estabeleceu alguns domínios gTLD que seriam adicionados ao DNS quando ele fosse finalmente implantado em grande escala. Os gTLD eram: .com, .org, .edu, .gov, .mil e .arpa para fornecer espaço de domínio para empresas, organizações sem fins lucrativos, escolas, redes, escritórios do governo dos EUA e militares dos EUA.

O documento também planejou a criação de domínios de nível superior (TLDs) relacionados ao país usando os códigos de duas letras da Organização Internacional de Padronização (ISO).

No começo de 1985 o BIND (Berkeley Internet Name Domain) versão 4 foi lançado pela Universidade da Califórnia, Berkeley como o DNS em operação, e não como um protótipo assim como Jeeves. Ainda em 1985, a DARPA fez um esforço para incentivar a adoção do DNS, que apesar de estar caminhando, muitos administradores ainda usavam o hosts.txt. Isso incluiu políticas e recomendações firmes para que os usuários e administradores de rede migrassem para o novo sistema, garantindo que o DNS fosse amplamente implementado e utilizado.

Em 1987 as RFCs 882 e 883 foram posteriormente substituídas pelas RFC 1034 e RFC 1035, modificando os documentos originais para inserir melhorias. As duas novas RFC se tornaram os padrões sobre os quais todas as implementações de DNS são construídas hoje.

Em 1995, a Network Solutions que na época era a única entidade autorizada a registrar domínios nos gTLDs (.com, .net, .org), começou a cobrar pelo registro de domínios. Inicialmente foram US$ 100 dólares por dois anos de registro de domínio, o custo era de US$ 50 por ano, mas o pagamento mínimo era de dois anos adiantados. Depois mudou para US$ 70 por dois anos de registro de domínio.

Essa cobrança gerou receitas substanciais para a Network Solutions, que acumulou grandes lucros e acabou criando um monopólio no registro de domínios. A falta de concorrência e o controle exclusivo da empresa sobre os registros gerou preocupações sobre a centralização do poder na internet.

Em 1997 uma nova versão do Bind foi lançada, sendo a versão 8. Ainda em 1997, também foi lançado o primeiro conjunto de especificações do DNSSEC (Domain Name System Security Extensions). O interesse em melhorar a segurança do DNS foi impulsionado por incidentes de segurança, como o cache poisoning. Embora não tenha sido o primeiro ataque desse tipo, em 1997 houve um ataque notável de DNS cache poisoning que expôs a vulnerabilidade dos servidores de nomes em aceitar respostas DNS maliciosas.

Esse tipo de ataque ocorre quando um servidor de DNS é enganado para armazenar informações incorretas em seu cache, redirecionando o tráfego para endereços maliciosos.

Como resposta ao cenário criado em 1995 com a cobrança pelo registro de domínios, foi então criada a ICANN (Internet Corporation for Assigned Names and Numbers) em 1998, com o objetivo de descentralizar o processo de registro de domínios e promover mais competição e transparência na gestão dos recursos da internet. A ICANN assumiu a responsabilidade de supervisionar o DNS e garantir que a administração dos domínios fosse distribuída entre várias entidades.

A ICANN foi criada como uma organização sem fins lucrativos, sediada nos Estados Unidos, com a missão de substituir o papel do governo dos EUA na gestão da infraestrutura técnica da Internet. Até então, essa responsabilidade estava sob o controle do Departamento de Comércio dos EUA, com a Network Solutions desempenhando um papel central no registro de domínios.

O modelo registry/registrar foi uma das maiores inovações da ICANN, separando a função de registro de domínios em duas partes:

Registry (Registro)
Um Registry é a organização que gerencia um gTLD como: .com, .net. O registro mantém a base de dados central com todos os nomes de domínio registrados sob esse TLD e define as políticas globais para o domínio.
Registrar (Registrador)
São empresas que vendem os domínios diretamente ao público e atuam como intermediários entre o usuário final e o Registry. Os registrars competem entre si, oferecendo preços e serviços variados, o que aumentou significativamente a escolha e a competitividade no mercado de domínios.

Em 1999, a versão revisada do DNSSEC foi publicada na RFC 2535. Essa revisão tratou de várias questões que surgiram após a primeira especificação do DNSSEC, publicada em 1997 (RFC 2065). O BIND 9 foi lançado no ano de 2000 como uma grande reformulação do software BIND, o servidor DNS mais utilizado no mundo até então. Diferente das versões anteriores, o BIND 9 foi reescrito do zero, com foco em maior segurança, estabilidade e novos recursos, incluindo suporte a DNSSEC, IPv6, e melhorias na escalabilidade.

Softwares de DNS

À medida que a tecnologia evolui, novos softwares DNS são desenvolvidos, cada um com recursos específicos e mais adequados para diferentes necessidades e ambientes. Alguns dos softwares DNS mais conhecidos são:

Berkeley Internet Name Domain (BIND)
É um dos softwares DNS mais antigos e amplamente usados. Ele pode funcionar como um servidor DNS autoritativo, recursivo, Forward e ainda ter funcionalidades de cache. O BIND também é capaz de configurar servidores primários e secundários.
PowerDNS
É um software DNS de código aberto que oferece suporte a uma ampla gama de recursos e funcionalidades. Seu foco principal é fornecer flexibilidade e escalabilidade, permitindo diferentes modos de operação como Autoritativo, Recursivo, Cache ou ambos combinados. O PowerDNS também é capaz de configurar servidores primários e secundários. Atualmente compete com o BIND.
Dnsmasq
É uma ferramenta de software projetada para fornecer funcionalidades de servidor de sistema de nomes de domínio e Dynamic Host Configuration Protocol (DHCP) em um único pacote compacto. Amplamente utilizado em ambientes de redes domésticas, pequenas empresas e redes locais, o Dnsmasq oferece uma solução leve e facilmente configurável para resolver nomes de domínio e atribuir endereços IP dinamicamente a dispositivos na rede.
NSD
O NSD é um servidor de Sistema de Nomes de Domínio de código aberto. O foco principal do NSD é fornecer funcionalidade de servidor DNS autoritativo altamente eficiente e escalável. Ele foi desenvolvido pelo NLnet Labs de Amsterdã em cooperação com o RIPE NCC, ele foi desenvolvido do zero como um servidor de nomes oficial e hoje é outro que compete fortemente com o BIND.

O NSD também é capaz de configurar tanto servidores primários quanto secundários. O NSD não implementa recursão e com isso, também não possui funcionalidades de cache.
Unbound
É um software de servidor DNS inicialmente desenvolvido apenas para atuar como Recursivo e Resolver de consultas, é desenvolvido pela NLnet Labs assim como o NSD. É um servidor rápido e seguro que suporta DNSSEC. Muita atenção, O Unbound também pode ser configurado para ser usado como servidor autoritativo. No entanto, essa funcionalidade de servidor autoritativo do Unbound é mais limitada em comparação com servidores DNS autoritativos dedicados, como o BIND e NSD.

A principal ênfase do Unbound é ser um resolvedor DNS rápido, seguro e eficiente. Ele é projetado para resolver consultas DNS recursivas de forma eficaz, com um foco na segurança e na implementação de padrões modernos, como DNS-over-TLS e DNS-over-HTTPS, para aumentar a privacidade e a segurança das comunicações DNS.

O Namespace

O DNS possui uma estrutura hierárquica para organizar os nomes de domínio de forma semelhante a uma árvore invertida, com várias camadas ou níveis. Essa estrutura hierárquica permite que os nomes de domínio sejam organizados de maneira lógica e eficiente, facilitando a localização e o acesso a recursos na Internet.

Essa estrutura é conhecida como Namespace (ou Domain Namespace) e identifica a estrutura de domínios que se combinam para formar um nome de domínio completo; em outras palavras, é uma estrutura que tem partes combinadas para formar o nome de domínio completo.

Sua estrutura se assemelha a uma árvore invertida, com o nó raiz no topo (onde estão os Servidores Raiz) representado por um ponto (.). Cada nó da árvore possui um rótulo que o identifica; a imagem abaixo representa esta estrutura mencionada.

Os servidores raiz são parte crucial da infraestrutura do DNS, atualmente existem 13 conjuntos de servidores Raiz, que são mantidos por diferentes organizações em todo o mundo. Esses servidores são autoritativos para a zona raiz (.) e armazenam os dados da hierarquia do DNS.

Os servidores raiz têm como principal função responder a consultas de DNS realizadas por DNS recursivos, fornecendo informações sobre os servidores de DNS autoritativos responsáveis pelos domínios de topo (TLDs) e pelos domínios de código de país (ccTLDs) do qual o servidor DNS recursivo está perguntando.

DNS Namespace

A figura cima demonstra o namespace partindo da Raiz até o subdomínio.
Fonte: Elaborado por mim para o programa de aprendizado da lpi.org em 2024.

Por exemplo, no nome de domínio learning.lpi.org; .org é o domínio de topo (gTLD), lpi identifica o nome de domínio secundário (geralmente um site hospedado por uma organização e/ou empresa), e learning identifica um subdomínio. A estrutura completa de domínio DNS é referida como o namespace. O nome atribuído a um domínio ou computador está relacionado à sua posição no namespace.

A estrutura do domínio é separada em dois tipos de nomenclatura. Um Nome de Domínio Completo (FQDN) é o nome completo do domínio, incluindo o subdomínio. Por exemplo, o domínio www.lpi.org é um FQDN, assim como learning.lpi.org.

Um Nome de Domínio Parcial (PQDN), também conhecido como Nome de Domínio Relativo ou Hostname, refere-se apenas ao nome do servidor. Neste caso, seria learning ou www do domínio lpi.org.

Top Level Domain - TLD

Já introduzi os domínios de primeiro nível quando contei a um pouco da História do DNS, mas queria deixar uma seção reservada para mostrar qual é o propósito de cada um dos TLDs, pelo menos os mais famosos. Recapitulando, os Top-Level Domains (TLDs) são os domínios localizados no topo da hierarquia, logo abaixo do . no Namespace. Os TLD são categorizados em diferentes tipos, cada um servindo a um propósito específico. Alguns exemplos incluem:

mil
Reservado para organizações militares, como o Exército dos Estados Unidos (army.mil) e a Marinha (navy.mil).
org
Designado para organizações não comerciais, como o Linux Professional Institute (lpi.org). Restrições sobre o uso de .org foram removidas em 1996, similar ao .net.
gov
Reservado para organizações governamentais, como a NASA (nasa.gov) e a National Science Foundation (nsf.gov).
edu
Designado para instituições educacionais, como a Universidade da Califórnia, Berkeley (berkeley.edu) e a Universidade Purdue (purdue.edu).
com
Designado para organizações comerciais, como Hewlett-Packard (hp.com), Sun Microsystems (sun.com) e IBM (ibm.com).

Ao longo dos anos, novos domínios de nível superior foram criados para representar países individuais e foram chamados de country-code Top-Level Domains (ccTLDs). Consequentemente, os TLDs anteriormente conhecidos passaram a ser reconhecidos como generic Top-Level Domains (gTLD). O termo "genérico" contrasta com os domínios de alto nível de código de país, que são específicos para um país particular. Essa distinção foi necessária, já que os ccTLDs estão no mesmo nível hierárquico que os gTLDs.

Com essa mudança, foram estabelecidas organizações nacionais e regionais, e por meio da delegação de autoridade, cada país gerencia seu próprio ccTLD. A partir de agora o que era conhecido como TLD passará a ser chamado de gTLD para domínio de topo (.com, .org, .gov).

Estrutura de DNS no Mundo

Vamos explorar agora como essa estrutura é organizada, começando pelas entidades centrais, como a ICANN e a IANA, até as organizações regionais e locais, que lidam com a distribuição de recursos na internet, como endereços IP e domínios.

A infraestrutura do DNS é complexa, com diversas entidades responsáveis pela sua manutenção e administração em diferentes níveis, desde a ICANN e a IANA no topo, até as RIRs, NIRs, LIRs e as organizações que cuidam dos ccTLDs em nível local. A colaboração entre essas organizações garante que o sistema de DNS funcione de forma eficiente e estável, permitindo que a Internet continue a se expandir e a evoluir globalmente.

A imagem abaixo mostra a relação entre a ICANN, IANA, RIRs e Regional ccTLD organizations:

IANA, ICANN, RIRs and Regional ccTLD organizations

ICANN - Internet Corporation for Assigned Names and Numbers

A ICANN é uma organização sem fins lucrativos responsável pela coordenação e gestão dos nomes de domínio e endereços IP da internet, essencial para garantir a estabilidade e funcionamento da rede. Criada em 1998, a ICANN surgiu de um contrato com o Departamento de Comércio dos Estados Unidos, assumindo o papel de coordenar o sistema de endereçamento global da internet, incluindo a administração dos servidores raiz do DNS, a atribuição de domínios genéricos (gTLDs) e de códigos de países (ccTLDs).

A missão central da ICANN é manter a segurança, estabilidade e interoperabilidade da internet. Isso envolve a gestão de gTLDs e a delegação de ccTLDs. Embora a ICANN tenha foco na regulação de nomes de domínio, ela não interfere diretamente em outras questões da internet, como a resolução de problemas relacionados a spam ou interconexões entre redes físicas.

A organização também supervisiona processos para a criação de novos gTLDs, o que exige um plano de negócios detalhado e taxas elevadas, tornando essa iniciativa viável apenas para grandes corporações. A ICANN, portanto, equilibra o papel de gestora técnica e facilitadora de negócios, gerando debates sobre sua influência e atuação no cenário da governança da internet.

A ICANN organiza diversos eventos ao longo do ano com o objetivo de promover o diálogo, a colaboração e a transparência em relação à governança da internet. Esses eventos são focados em reunir diferentes partes interessadas, incluindo governos, empresas, organizações sem fins lucrativos, especialistas técnicos e o público em geral.

No geral alguns do eventos são:

Reuniões Públicas da ICANN
Workshops e Sessões de Treinamento
Fóruns Regionais
Sessões de Engajamento Multissetorial

KSK Rollover

A ICANN é a responsável por coordenar o KSK rollover, que é o processo de troca da chave de assinatura principal (KSK) usada no DNSSEC. A KSK protege a integridade do sistema de nomes de domínio (DNS), garantindo que os dados do DNS sejam autênticos.

O KSK rollover é a substituição da chave criptográfica principal que assina a ZSK (Zone Signing Key), responsável pela segurança da zona raiz do DNS. Para garantir total transparência, o KSK rollover envolve cerimônias públicas onde a nova chave é gerada e assinada. Essas cerimônias exigem a presença de três pessoas chamadas de "gerentes de confiança" (ou Key Ceremony Participants), que têm funções específicas durante o processo. Sem essas três pessoas, a cerimônia não pode acontecer.

Após a cerimônia, a nova chave KSK é distribuída globalmente para os validadores de DNSSEC, garantindo que todas as redes possam autenticar a nova chave de forma segura. A nova chave KSK pode ser adicionada manualmente pelos operadores de validadores de DNSSEC, mas esse processo é opcional. A ICANN projeta o KSK rollover para que, em condições normais, a nova chave seja automaticamente distribuída e reconhecida pelos validadores, sem a necessidade de intervenção manual. No entanto, se por algum motivo o validador não atualizar automaticamente, é possível que os operadores adicionem a nova chave manualmente.

A primeira troca de chaves ocorreu em 2018, marcando um evento histórico na segurança da internet, sendo a primeira vez que a chave foi trocada desde a implementação do DNSSEC. Em 11 de janeiro de 2025 será possível baixar a nova chave DS (Delegation Signer) dos servidores DNS root.

Em 11 de outubro de 2026 o KSK rollover ocorrerá definitivamente, onde a nova chave começará a ser usada para assinar a zona raiz. Em Abril de 2027 uma nova chave KSK será gerada para o próximo ciclo de rollover.

Em 11 de outubro de 2029 (data estimada) uma nova troca de chaves acontecerá, e pode incluir a adoção de um novo algoritmo criptográfico, substituindo o RSA/SHA-256 por um algoritmo mais seguro e eficiente, como ECDSA.

Mais detalhes de como isso ocorre vou deixar na seção sobre DNSSEC.

IANA - Internet Assigned Numbers Authority

A IANA foi criada em 1988, naquela época o cenário da internet era bem diferente do que conhecemos hoje, mas já havia uma necessidade crescente de coordenação global para gerenciar recursos essenciais de rede, como Endereços IP, DNS, Números de portas e Protocolos.

Naquela época, a internet ainda estava em seus estágios iniciais de expansão, mas estava se tornando cada vez mais evidente que o crescimento futuro exigiria uma entidade central para gerenciar a atribuição de números IP, números de sistemas autônomos (ASNs) e nomes de domínio. Embora a internet não tivesse o tamanho e a complexidade atuais, os problemas de organização e padronização já eram relevantes. As redes interconectadas começavam a crescer além dos ambientes acadêmicos e militares, e era necessário garantir que houvesse uma estrutura para evitar conflitos na alocação desses recursos.

A IANA, portanto, foi criada como parte dessa necessidade de centralização e coordenação. Naquela época, o gerenciamento ainda era simples em comparação com os dias de hoje, mas foi um passo essencial para garantir que o crescimento da internet fosse estruturado e coordenado. A formalização da IANA ajudou a estabelecer as bases para a expansão massiva que a internet experimentaria nas décadas seguintes.

Delegation Record

Todo ccTLD (country code Top-Level Domain) possui um Delegation Record na IANA, que é essencial para que o domínio de topo de código de país fique disponível em todos os servidores DNS da internet.

O Delegation Record é o registro que mantém informações importantes sobre o ccTLD, incluindo:

Servidores de nomes (DNS) responsáveis pela resolução do domínio.
Informações técnicas e administrativas sobre o ccTLD, como a entidade responsável pela sua gestão.

Para que o ccTLD esteja disponível em todos os servidores DNS do mundo, os servidores raiz da internet precisam saber onde direcionar as consultas para esse domínio. O Delegation Record fornece essas informações.

A IANA mantém e atualiza esses registros, garantindo que qualquer mudança técnica ou administrativa no ccTLD (como troca de servidores DNS) seja refletida globalmente e de forma precisa.

Exemplo de registro mantido na IANA: https://www.iana.org/domains/root/db/br.html

Relação entre ICANN e IANA

A ICANN tem um papel administrativo e regulador, enquanto a IANA é a entidade técnica que executa essas decisões. A IANA faz parte da estrutura operacional da ICANN e, por meio dela, são feitas as alocações e gestões técnicas de DNS, blocos IP, e outras funções críticas.

RIR - Regional Internet Registry

O RIR é uma organização que é responsável por gerenciar a distribuição e alocação de recursos de endereçamento de Internet em uma determinada região geográfica. Os RIRs são responsáveis por distribuir endereços IP (Internet Protocol versão 4 e 6) e números de sistemas autônomos (AS) para provedores de serviços de Internet, organizações e indivíduos em sua região.

A IANA delega recursos da Internet para os RIRs, que acabam seguindo políticas regionais de delegação de recursos para seus clientes, que incluem provedores de Internet e Sistemas Autônomos. Como dito, cada RIR é responsável por um continente ou mais, como é o caso do APNIC. Existem atualmente cinco RIRs que são responsáveis por diferentes regiões do mundo:

RIR	Regional ccTLD Organizations	Descrição
AFRINIC	AFTLD	Região da Africa.
APNIC	APTLD	Região da Ásia e Pacífico (engloba a Oceania).
ARIN	CIRA, Registry Services	Região do Canada, USA, e algumas ilhas do Caribe.
LACNIC	LACTLD	Região da América Latina e algumas ilhas do Caribe.
RIPE NCC	CENTR	Região da Europa, Oriente Médio e Asia central.

Nem todas as regiões têm uma organização regional de ccTLDs que corresponde a um RIR, para que coordenem os registros de ccTLDs. Na América do Norte (coberta pelo ARIN), não existe uma organização regional de ccTLDs. Cada país (como Canadá e Estados Unidos) tem uma entidade separada que gerencia seu próprio ccTLD, mas elas não são coordenadas por uma organização regional de ccTLDs unificada, como acontece em outras partes do mundo.

A imagem abaixo (Retirada de secbitrez.files.wordpress.com) mostra a relação entre a IANA e os RIRs:

IANA and RIRs

LACNIC - Latin American and Caribbean Internet Addresses Registry

O LACNIC é o Registro Regional da Internet (RIR) responsável pela gestão e alocação de recursos de internet, como endereços IP (IPv4 e IPv6) e números de sistemas autônomos (ASN), para a região da América Latina e Caribe. Criado em 2002, o LACNIC desempenha um papel essencial na promoção do desenvolvimento da internet e da infraestrutura de rede na região, além de fomentar a adoção de novas tecnologias e boas práticas de segurança.

O LACNIC cobre toda a América Latina e Caribe, servindo mais de 30 países da região, incluindo Brasil, Argentina, Chile, Colômbia, México, além de várias ilhas caribenhas.

RIPE NCC - Réseaux IP Européens Network Coordination Centre

O RIPE NCC é o Registro Regional da Internet (RIR) responsável pela alocação e gestão de endereços IP (IPv4 e IPv6), números de sistemas autônomos (ASN) e outros recursos de rede na região da Europa, Oriente Médio e Ásia Central. Fundado em 1992, o RIPE NCC é um dos cinco RIRs globais e desempenha um papel essencial no gerenciamento de recursos de internet, além de promover a cooperação e o desenvolvimento técnico na região.

ARIN - American Registry for Internet Numbers

O ARIN é o Registro Regional da Internet (RIR) responsável pela alocação de endereços IP (IPv4 e IPv6), números de sistemas autônomos (ASN) e outros recursos de internet para a região da América do Norte. O ARIN foi fundado em 1997 e atende os Estados Unidos, Canadá, e várias ilhas do Caribe e Atlântico Norte.

APNIC - Asia-Pacific Network Information Centre

O APNIC é o Registro Regional da Internet (RIR) responsável pela alocação e gestão de recursos de internet, como endereços IP (IPv4 e IPv6) e números de sistemas autônomos (ASN), para a região da Ásia-Pacífico. Fundado em 1993, o APNIC atende a um vasto território que inclui países como China, Japão, Austrália, Índia e muitos outros da região.

AFRINIC - African Network Information Centre

O AFRINIC é o Registro Regional da Internet (RIR) responsável pela alocação e gestão de endereços IP (IPv4 e IPv6), números de sistemas autônomos (ASN) e outros recursos de internet para o continente africano. O AFRINIC atende toda a região africana, incluindo países como África do Sul, Nigéria, Quênia, Egito, e muitos outros. Sua sede está localizada em Ebene, Maurício.

NIR - National Internet Registry

Os NIRs são organizações que estão sob um determinado RIR, foram criadas para ajudar os RIRs a gerenciar a alocação e gestão dos recursos de numeração IP em um país e/ou continente, por exemplo, o NIC.br é o NIR responsável pelo Brasil, o JPNIC é o NIR responsável pelo Japão. É importante ressaltar que alguns países podem ter o seu próprio NIR, ou compartilhar um NIR com outros países vizinhos, seguindo a política e a estrutura organizacional adotada em cada país.

Os NIRs são uma forma de descentralização da gestão dos recursos de numeração IP, permitindo que cada país ou região possa ter uma entidade responsável por gerenciar e alocar seus próprios recursos de numeração IP, seguindo as políticas estabelecidas pelos RIRs. Isso permite uma maior eficiência e agilidade na gestão dos recursos, além de permitir que cada país ou região tenha um maior controle sobre seus próprios recursos de numeração IP.

Segue alguns dos NIRs existente:

NIR	Descrição
NIC.br	Responsável pela gestão dos recursos de numeração IP no Brasil.
NIC Chile	Responsável pela gestão dos recursos de numeração IP no Chile.
NIC Argentina	Responsável pela gestão dos recursos de numeração IP na Argentina.
NIC Colombia	Responsável pela gestão dos recursos de numeração IP na Colômbia.
NIC Mexico	Responsável pela gestão dos recursos de numeração IP no México.
CIRA	Responsável pela gestão dos recursos de numeração IP no Canadá.
KRNIC	Responsável pela gestão dos recursos de numeração IP na Coreia do Sul.
JPNIC	Responsável pela gestão dos recursos de numeração IP no Japão.
TWNIC	Responsável pela gestão dos recursos de numeração IP em Taiwan.
HKIRC	Responsável pela gestão dos recursos de numeração IP em Hong Kong.
CNNIC	Responsável pela gestão dos recursos de numeração IP na China.

LIR - Local Internet Registry

Um LIR é uma organização que recebeu um bloco de endereços IP por meio de um National Internet Registry (NIR) e que atribui a maior parte desse bloco a seus próprios clientes. Ele atribui principalmente espaço de endereço aos usuários dos serviços de rede que fornece. Os LIRs são geralmente Provedores de Serviços de Internet (ISPs), cujos clientes são principalmente usuários finais e possivelmente outros ISPs. É necessário ser membro de um RIR para se tornar um LIR.

Um provedor de serviços de Internet (ISP) é uma organização que fornece acesso à Internet. Os provedores de serviços de Internet podem ser de propriedade da comunidade e sem fins lucrativos ou de propriedade privada e com fins lucrativos.

Os LIRs podem obter seus blocos de IP diretamente do RIR de sua região caso não possuam um NIR.

Registry ccTLDs

O Registry ccTLDs ou Registries ccTLDs (Para quando estamos falando de mais de um) é uma organização responsável pelo gerenciamento de um ccTLD específico em nível global. Cada ccTLD é gerenciado por uma organização nacional ou territorial, mas a ICANN supervisiona e coordena a delegação dos ccTLDs e mantém um registro global desses domínios.

Existe também um Registry gTLD, que possui a mesma função de um Registry ccTLD mas para gTLDs.

O Registry ccTLDs é responsável por manter o registro global dos nomes de domínio para o ccTLD que gerencia, além de garantir que o domínio seja operado de acordo com os padrões globais do DNS. Isso inclui a manutenção dos servidores de nomes, o gerenciamento de solicitações de registro de domínio e a implementação de políticas de registro para garantir a segurança e a estabilidade do domínio.

O Registry ccTLDs também é responsável por manter o contato com os outros operadores de ccTLDs e com a ICANN para garantir que o registro global de ccTLDs seja consistente e seguro. Cada Registry ccTLDs é uma entidade separada e é responsável por seus próprios custos operacionais, que geralmente são financiados pelos custos de registro e renovação de nomes de domínio.

Em alguns casos um NIR e o Registry podem ser a mesma organização. Isso ocorre porque alguns países ou territórios podem optar por ter uma única organização responsável tanto pelo registro de endereços IP quanto pelo registro de nomes de domínio ccTLDs. Nesses casos, a organização pode desempenhar as funções de um NIR, como a alocação e o registro de blocos de endereços IP e ASN, bem como as funções de um Registry ccTLD, como o registro e a manutenção de nomes de domínio ccTLDs. Um exemplo disso é o caso do NIC.br, que é responsável pelo registro e manutenção dos nomes de domínio .br (ccTLD brasileiro) e também é o NIR responsável pela alocação e registro de blocos de endereços IP para o Brasil.

Segue abaixo um exemplo de empresas que são Registry para gTLD:

Verisign Registry do .com e .net.
Public Interest Registry Registry do .org.
Donuts Inc Registry de vários novos gTLDs, como .guru, .photography, .email, entre outros.

Segue abaixo um exemplo de empresas que são Registry para ccTLD:

NIC.br Registry do .br (Brasil).
Afilias Registry de vários ccTLDs, incluindo .io (Ilhas Britânicas no Oceano Índico) e .in (Índia).
CIRA Registry do .ca (Canadá).
Nominet Registry do .uk (Reino Unido).
DENIC Registry do .de (Alemanha).

Curiosidade

Como uma curiosidade existe uma ISO que define códigos de países e subdivisões administrativas, como estados e províncias. Esses códigos são amplamente utilizados em sistemas de informação, comunicação e comércio para identificar países e suas subdivisões em formatos padronizados. A norma é mantida pela Organização Internacional para Padronização (ISO) e é atualizada regularmente para refletir mudanças políticas e administrativas em todo o mundo.

Os códigos de país da ISO 3166 são usados em muitos contextos, incluindo identificação de domínios de topo de nível de país (ccTLDs), códigos de aeroportos, códigos de moeda, entre outros. A norma também define códigos para regiões geográficas e territórios especiais que não são países independentes.

Registrars

Os Registrars (Registradores) são empresas que são responsáveis por fornecer serviços de registro e gerenciamento de domínios na Internet, ou seja, são as organizações que os usuários finais (pessoas físicas ou jurídicas) podem contatar quando desejam registrar nomes de domínio.

Os Registrars geralmente têm acordos com Registry, que são os responsáveis por gerenciar as extensões de nomes de domínio, seja ele gTLD ou ccTLD. Esses acordos estipulam os termos e condições para o registro de nomes de domínio, incluindo a definição de preços, prazos, requisitos para renovação de domínios, etc.

Segue abaixo um exemplo de empresas que são Registrar:

Registro BR (faz parte do NIC.BR)
GoDaddy
Namecheap
Google Domains
Tucows
Network Solutions

Curiosidade

Os Registrars enviam as informações sobre novos domínios para os Registries usando o Extended Provisioning Protocol (EPP) definido pela RFC 5730, é uma forma segura de troca de informação sobre domínios.

O EPP é utilizado para gerenciar registros de nomes de domínio, como criação, atualização, transferência e exclusão. Ele foi criado para padronizar a comunicação entre registrars e registry, garantindo que ambos utilizem a mesma linguagem, evitando assim erros. Baseado em XML e sendo extensível, o EPP pode ser adaptado para outras necessidades além do registro de domínios, como a gestão de endereços IP ou outras informações. Além disso, oferece segurança através do TCP e pode ser combinado com TLS para criptografar as comunicações entre as partes.

Como vimos o NIC.br é um Registry ccTLD e um NIR. Ele também é um Registrars (o registro.br faz parte do NIC.br), além disso, outras empresas também operam em território Brasileiro como Registrars, como: Godaddy, Locaweb e HostGator.

Regional ccTLD organizations

Existem organizações regionais que representam e coordenam os registros de ccTLDs (country code Top-Level Domains) em várias partes do mundo. Essas associações desempenham papéis importantes ao promover o desenvolvimento, a cooperação técnica e o compartilhamento de boas práticas entre os registros de domínios, que são responsáveis pela gestão dos domínios de código de país.

Os operadores de registro de domínio de nível superior de código de país (ccTLD) são responsáveis por gerenciar ou administrar um domínio de nível superior específico de um país. Eles são como um banco de dados para todos os domínios em seu TLD. Entre suas principais responsabilidades, os operadores de registro fornecem serviços de resolução de nomes (conectando nomes de domínio com seus endereços IP associados) e mantêm a infraestrutura crítica necessária para concluir consultas DNS.

Os operadores de ccTLDs são os responsáveis por enviar solicitações para a IANA e ICANN quando desejam que um novo ccTLD seja delegado (atribuído) ou quando há necessidade de mudanças na sua gestão. A ICANN, por meio da IANA, é responsável por revisar essas solicitações e realizar a delegação ou reatribuição do ccTLD de acordo com os padrões globais.

Além de coordenar e representar os interesses dos ccTLDs, as organizações regionais também desempenham um papel crucial ao oferecer suporte técnico, o que inclui a manutenção de servidores DNS para ccTLDs que, por questões financeiras ou técnicas, não conseguem manter sua própria infraestrutura de DNS. Isso é comum em NIRs ou em operadores de ccTLDs em regiões com menos recursos.

As organizações regionais podem fornecer soluções de DNS anycast (técnica que distribui consultas DNS para servidores em diferentes locais geográficos), aumentando a resiliência e a estabilidade do ccTLD.

Atualmente, no ecossistema global de governança da Internet, existem quatro Organizações Regionais (RO) que agrupam e representam os interesses dos administradores de ccTLDs:

CENTR, que agrupa os ccTLDs da Europa;
APTLD, para aqueles na Ásia-Pacífico;
AfTLD, para os da África,
LACTLD, para os da América Latina e Caribe.

LACTLD - Latin American and Caribbean Top Level Domains Organization

O LACTLD é uma organização sem fins lucrativos que agrupa e representa os interesses dos administradores de domínios de primeiro nível com código de país (ccTLD) na América Latina e no Caribe.

O LACTLD foi fundado em 20 de agosto de 1998 em Buenos Aires - Argentina, por representantes de 7 ccTLDs (.AR, .BO, .BR, .CL, .MX, .PE e .UY) no âmbito das reuniões do International Forum on the White Paper. Atualmente, a Associação reúne e representa 31 administradores de ccTLDs da América Latina e do Caribe com o objetivo de coordenar políticas conjuntas, promover a cooperação e a troca de experiências e promover uma Internet que contribua para o desenvolvimento econômico e social através do uso de nomes de domínio.

A LACTLD tem sua base operacional em Montevidéu, na Casa da Internet da América Latina e do Caribe (CILAC), principal hub de entidades de Internet da região, onde convive com organizações do setor como ALAI, ASIET, eCom LAC, ICANN , Internet Society, LAC-IX, LACNIC, LACNOG e RedClara. A principal missão do LACTLD é promover nomes de domínio e Internet na América Latina e no Caribe, contribuindo para o desenvolvimento econômico e social da região.

O LACTLD tem dois projetos principais que contribuem para o fortalecimento da infraestrutura de ccTLDs na América Latina e Caribe.

Buscador LACTLD

O Buscador LACTLD é uma ferramenta desenvolvida pelo LACTLD que permite consultar a disponibilidade de nomes de domínio em diversos ccTLDs da América Latina e Caribe. Com ele, os usuários podem verificar de forma centralizada se um determinado nome de domínio está disponível para registro em múltiplos ccTLDs da região, como .br (Brasil), .mx (México), .ar (Argentina), entre outros.

Com essa ferramenta, potenciais registrantes podem explorar a disponibilidade de um nome desejado em vários domínios de código de país sem precisar visitar sites individuais de cada registro.

LACTLD Anycast Cloud

O projeto LACTLD Anycast Cloud é uma iniciativa para fornecer uma infraestrutura de DNS anycast regional robusta, especificamente voltada para os operadores de ccTLDs da América Latina e Caribe. O anycast permite que múltiplos servidores DNS em diferentes locais respondam a consultas de forma mais rápida e eficiente, melhorando a resiliência, disponibilidade, e segurança dos ccTLDs na região. Este projeto é especialmente útil para países que podem não ter os recursos técnicos ou financeiros para implementar uma infraestrutura anycast própria.

Graças ao projeto Anycast Cloud, falhas em regiões específicas não comprometem totalmente os ccTLDs, que continuam operando normalmente. As consultas DNS são direcionadas ao servidor mais próximo geograficamente, o que melhora a velocidade e eficiência na resolução de domínios.

O que é Anycast?

Anycast é uma tecnologia de endereçamento que permite o uso otimizado e eficiente das redes. Em uma Anycast Cloud, vários nós (servidores) armazenam cópias da mesma "base de dados", que pode incluir, por exemplo, zonas de clientes da Cloud, como os domínios gerenciados (.sv, .do, .gt). Esses nós estão localizados em diferentes partes do mundo e compartilham o mesmo endereço IP. Quando uma consulta chega a essa base de dados, os sistemas de roteamento determinam qual dos nós disponíveis está mais próximo do ponto de origem da consulta e direcionam a solicitação para esse nó geograficamente mais próximo, acelerando a resposta.

Exemplo: Se nossa rede tiver nós em Santiago do Chile, São Paulo e San José da Costa Rica, e receber uma consulta de Santo Domingo, o sistema de roteamento identificará que o nó da Costa Rica é o mais próximo e direcionará o tráfego para lá.

Devido à sua natureza distribuída, a rede ativa dinamicamente as respostas às consultas dos usuários de acordo com a disponibilidade de cada nó. Além disso, promove a diversidade geográfica e topológica, facilitando o intercâmbio de tráfego local. Ao gerenciar as consultas de maneira eficiente, a Anycast Cloud pode reduzir significativamente o tempo de resposta. Isso garante maior disponibilidade para responder às solicitações dos usuários e melhora a velocidade operacional dos nós, reduzindo a dependência de redes externas.

Se um dos nós falhar ou parar de funcionar, ele é automaticamente removido das opções de roteamento, e o tráfego futuro é redirecionado para os outros nós da Cloud. Graças a esse mecanismo, os clientes (que têm cópias de suas zonas em todos os nós da rede) se recuperam instantaneamente em caso de falha ou ataque. O Anycast Cloud do LACTLD permite o uso eficiente da infraestrutura dos participantes, otimizando os recursos disponíveis e aumentando a confiabilidade dos serviços de DNS.

CENTR - Council of European National Top-Level Domain Registries

O CENTR (Council of European National Top-Level Domain Registries) é uma associação sem fins lucrativos que representa e coordena os gestores de domínios de nível superior de código de país (ccTLDs) da Europa, como .de (Alemanha), .uk (Reino Unido), .fr (França) e muitos outros. Fundado em 1998, o CENTR facilita a colaboração entre os registradores de ccTLDs europeus, promove a troca de conhecimento e experiência, e atua como uma voz unificada para questões relacionadas ao Sistema de Nomes de Domínio (DNS) no continente.

O principal objetivo do CENTR é representar os interesses de seus membros (gestores de ccTLDs europeus) e promover a cooperação entre eles. A missão da organização é melhorar a operação e a segurança dos ccTLDs, além de garantir que os registradores europeus sejam bem representados nas discussões globais sobre o DNS.

APTLD - Asia Pacific Top Level Domain Association

A APTLD é a organização que reúne e representa os gestores de domínios de código de país (ccTLDs) na região da Ásia-Pacífico. Fundada em 1998, a APTLD tem como objetivo promover a colaboração, troca de conhecimento e desenvolvimento técnico entre os operadores de ccTLDs na região, ajudando-os a enfrentar os desafios únicos relacionados à administração de domínios de topo.

A APTLD visa fortalecer a infraestrutura de DNS e a capacidade técnica dos ccTLDs na região da Ásia-Pacífico, promovendo práticas recomendadas e fornecendo um fórum para a cooperação entre seus membros. Seu foco é garantir que os ccTLDs sejam geridos de maneira eficaz e segura.

A APTLD trabalha em parceria com outras organizações regionais de ccTLDs, como a CENTR (Europa), AFTLD (África) e LACTLD (América Latina e Caribe), além de colaborar com entidades globais como a ICANN e a ISOC (Internet Society). Essa cooperação ajuda a garantir que os interesses da região Ásia-Pacífico sejam representados em discussões globais sobre o DNS.

AFTLD - Africa Top Level Domains Organization

A AFTLD é uma organização sem fins lucrativos que representa os registros de domínios de nível superior (ccTLDs) da África. Seu principal objetivo é promover o desenvolvimento e a gestão de domínios de internet na África, fortalecendo a presença digital do continente.

A AFTLD promove o compartilhamento de conhecimento e a colaboração entre os gestores africanos de ccTLDs. Ela busca fortalecer as capacidades técnicas e administrativas desses gestores e garantir que a África tenha uma voz representativa nas discussões globais sobre DNS.

A AFTLD colabora com outras organizações regionais de ccTLDs, como a APTLD (Asia Pacific Top Level Domain Association), CENTR (Council of European National Top-Level Domain Registries) e LACTLD (Latin American and Caribbean Top Level Domains Organization). Também trabalha em parceria com organizações como a ISOC (Internet Society) e o NSRC (Network Startup Resource Center).

CIRA - Canadian Internet Registration Authority

O CIRA é a organização sem fins lucrativos responsável por gerenciar o domínio de nível superior de código de país (ccTLD) .ca, que é o domínio para o Canadá. Além de administrar o registro de domínios .ca, o CIRA trabalha para melhorar a internet no Canadá por meio de iniciativas de segurança, inovação digital e apoio a projetos comunitários. O registro de um domínio .ca é restrito a pessoas e organizações que atendem aos requisitos de presença no Canadá.

O CIRA promove a segurança da infraestrutura de DNS no Canadá. A organização oferece serviços como o DNS Firewall, que ajuda a proteger redes contra ataques cibernéticos, e trabalha na implementação de tecnologias de segurança, como o DNSSEC.

Registry Services, LLC

O domínio de nível superior de código de país dos Estados Unidos, o .us, agora é administrado pela Registry Services - LLC, uma subsidiária da GoDaddy (anteriormente operado pela Neustar). Atualmente, o .us é operado sob uma política de registro específica chamada .US Registration Policy, que define as regras e requisitos para o registro de domínios .us. Essa política abrange critérios de elegibilidade, uso aceitável e diretrizes técnicas para quem deseja registrar um domínio .us.

ccNSO - Country Code Names Supporting Organization

A ccNSO é uma das organizações de apoio dentro da estrutura da ICANN, focada especificamente em questões relacionadas aos domínios de código de país (ccTLDs). A ccNSO é responsável por desenvolver e recomendar políticas para a gestão dos ccTLDs. Ela atua promovendo a colaboração entre os gestores de ccTLDs, criando um espaço para o compartilhamento de boas práticas, discutindo questões de políticas globais e ajudando na coordenação de aspectos técnicos e administrativos desses domínios.

A ccNSO faz parte da governança multissetorial da ICANN e trabalha para garantir que as necessidades e preocupações dos gestores de ccTLDs sejam ouvidas no processo de formulação de políticas da ICANN. Ela também colabora com outras organizações de apoio e comitês dentro da ICANN para garantir que as políticas globais sejam apropriadas para os domínios de código de país.

É composta pelos gestores dos ccTLDs, que são organizações responsáveis pela administração de domínios de países (por exemplo, o CGI.br no caso do .br). A adesão à ccNSO é voluntária, o que significa que nem todos os ccTLDs são membros, embora muitos participem ativamente.

Outras Organizações

Além das organizações mencionadas anteriormente, também há a participação de outras entidades que desempenham um papel fundamental na melhoria da internet e do sistema de DNS.

DNS-OARC - DNS Operations, Analysis, and Research Center

O DNS-OARC é uma organização sem fins lucrativos que se dedica a melhorar a segurança, a estabilidade e o desempenho do Sistema de Nomes de Domínio (DNS) globalmente. Fundada em 2004, a DNS-OARC promove a cooperação entre operadores de DNS, pesquisadores e especialistas em segurança, visando melhorar as práticas operacionais, aumentar a resiliência do DNS e prevenir falhas ou ataques que possam comprometer o funcionamento da internet.

A missão da DNS-OARC é ser um ponto de encontro para a colaboração e a troca de informações entre operadores de DNS, pesquisadores e outras partes interessadas. O foco está em fornecer dados, ferramentas e análises para garantir que o DNS funcione de maneira confiável e segura. A organização realiza regularmente reuniões e workshops que reúnem especialistas da comunidade de DNS para discutir novos desafios, compartilhar pesquisas e promover boas práticas operacionais. Esses eventos são uma parte essencial da missão da DNS-OARC, ajudando a fomentar a inovação e a colaboração.

A DNS-OARC coleta dados operacionais sobre o tráfego e o desempenho do DNS, oferecendo à comunidade uma visão abrangente de como o sistema está funcionando globalmente. Esses dados são usados por pesquisadores e operadores para identificar padrões de comportamento, detectar ataques e melhorar a operação dos servidores DNS.

A organização desempenha um papel fundamental na identificação e mitigação de ameaças à segurança do DNS. Isso inclui a prevenção de ataques de negação de serviço (DDoS) e a proteção contra a manipulação de dados DNS, como o cache poisoning. O DNS-OARC desenvolve e distribui ferramentas para ajudar os operadores de DNS a monitorar e melhorar o desempenho de suas infraestruturas. A organização também publica pesquisas baseadas nos dados que coleta, oferecendo insights sobre tendências de segurança e operação do DNS.

ISOC - Internet Society

A ISOC é uma organização global sem fins lucrativos que se dedica a garantir o desenvolvimento, a evolução e o uso aberto da internet em benefício de todas as pessoas. Criada em 1992, a ISOC desempenha um papel fundamental na promoção de padrões técnicos, políticas públicas e ações para manter a internet acessível, segura e inclusiva.

A ISOC tem como missão promover uma internet aberta e acessível a todos, incentivando políticas públicas que garantam a segurança, a privacidade e a conectividade global. A organização busca garantir que a internet continue sendo uma plataforma para a inovação, o desenvolvimento social e econômico e a liberdade de expressão.

A ISOC atua em questões políticas globais relacionadas à internet, promovendo a inclusão digital, a proteção da privacidade, a neutralidade da rede, e defendendo uma governança aberta e multissetorial da internet. A organização trabalha com governos, empresas, ONGs e outras partes interessadas para moldar políticas que protejam a liberdade e os direitos dos usuários online.

PIR - Public Interest Registry

O PIR é uma organização sem fins lucrativos responsável pela administração e operação do domínio de nível superior genérico (gTLD) .org, um dos domínios mais utilizados globalmente. O PIR foi criado em 2002 pela Internet Society (ISOC) com o objetivo de gerir o domínio .org de maneira alinhada ao interesse público, focando em oferecer uma alternativa de domínio para organizações sem fins lucrativos, projetos comunitários, fundações e outros grupos voltados para causas sociais.

O PIR é mais conhecido por administrar o .org, que é amplamente utilizado por organizações não governamentais (ONGs), fundações, iniciativas de caridade e outras entidades sem fins lucrativos. A gestão do .org segue princípios de transparência e responsabilidade, sendo uma escolha popular para entidades que priorizam o interesse público e comunitário.

Além de administrar o .org, o PIR também gerencia outros gTLDs voltados para o interesse público, como o .ngo e .ong, que são domínios específicos para organizações não governamentais. Esses domínios adicionais reforçam o compromisso do PIR em fornecer plataformas seguras e respeitáveis para organizações que trabalham em prol de causas sociais.

Introdução ao DNS

O DNS é um sistema de nomenclatura hierárquica que é usado para traduzir nomes de domínio em endereços IP numéricos que são usados para localizar recursos na Internet. A estrutura hierárquica de nomes de domínio é conhecida como Domain Namespace, que é dividida em áreas gerenciáveis chamadas Domain Namespace Zones.

Para traduzir nomes de domínio em endereços IP, o DNS usa servidores DNS, que são responsáveis por armazenar informações de registro de recursos para os nomes de domínio dentro de cada zona do Domain Namespace. Os servidores DNS são organizados em hierarquias, onde os servidores DNS de nível superior (root servers) estão no topo da hierarquia e os servidores DNS autoritativos de zonas específicas estão mais abaixo na hierarquia.

Os clientes DNS usam um software chamado DNS Resolver para fazer consultas aos servidores DNS e obter as informações de registro de recursos para os nomes de domínio solicitados. O DNS Resolver envia a consulta a um servidor DNS recursivo, que consulta outros servidores DNS até que a informação de registro de recursos seja encontrada e devolvida ao DNS Resolver.

Para ficar mais claro, veremos a mais a fundo cada parte importante sobre o DNS separadamente.

O Protocolo DNS

Operações DNS são realizadas na porta 53 usando o protocolo UDP para as requisições para assim obter maior performance, devido à sua natureza de comunicação não orientada a conexão. Essas consultas usando UDP possuem um limite de tamanho de bloco (block-size) de 512 Bytes. O TCP permite a negociação de um tamanho de bloco maior entre o cliente DNS e o servidor DNS, permitindo consultas DNS mais longas e respostas maiores, porém, implica em maior overhead na Rede.

O IPv6 e o DNSSEC estão aumentando o volume de dados nas transações DNS. O Extended DNS 0 (EDNS0) é usado para evitar usar o TCP quando a transação DNS excede o tamanho de bloco de 512 Bytes. EDNS0 negocia um tamanho de bloco UDP Estendido, O BIND 9 negocia um tamanho de bloco para 4096 Bytes (4K) por padrão, mas pode ser configurado para outro valor.

Domain Namespace Zones

Um Domain Namespace Zone é uma parte do espaço de nomes de um domínio. Cada zona de namespace é responsável por armazenar informações sobre os registros DNS de um conjunto específico de nomes de domínio dentro do domínio raiz.

Por exemplo, considere o domínio example.com. Esse domínio pode ter diversas zonas de namespace, cada uma responsável por um conjunto específico de nomes de domínio, como vendas.exemplo.com ou suporte.exemplo.com. Cada uma dessas zonas de namespace pode ter seus próprios registros DNS, como endereços IP para servidores ou registros de correio eletrônico (MX).

As zonas de namespace são utilizadas para permitir uma gestão mais granular dos registros DNS de um domínio, além de permitir a delegação de subdomínios a outros servidores DNS, o que é comum em grandes organizações.

Root Servers

Os servidores de nomes autorizados (authoritative) que atendem à zona raiz do DNS, são conhecidos como servidores raiz ou Root Servers em inglês, eles são uma rede de centenas de servidores em muitos países ao redor do mundo. Eles são configurados na zona raiz do DNS como 13 autoridades nomeadas.

Cada root server tem um operador responsável (ou Operator em Inglês) por sua manutenção e operação. O operador do root server é uma organização ou entidade que é responsável por garantir que o servidor esteja disponível e funcione corretamente, respondendo a consultas de DNS para o domínio raiz.

A função do operador do root server é manter o servidor funcionando 24 horas por dia, 7 dias por semana, garantindo que ele esteja sempre acessível e capaz de responder a consultas de DNS. Isso envolve a instalação e configuração do hardware e software do servidor, bem como a manutenção contínua, atualizações e reparos.

Os Root Servers são responsabilidade da ICANN, mas eles são operados por um Acordo denominado "Cooperative Research and Development of Commerce. Este contrato abrange os métodos e processos pelos quais as atualizações nos sistemas de nomes raiz são realizadas. A ICANN também criou o "Root Server System Advisory Committee (RSSAC)" para fornecer conselhos e guias quanto à operação e desenvolvimento desse recurso crítico.

The IETF was requested by the RSSAC to develop the engineering stan- dards for operation of the root-servers. This request resulted in the publication of RFC 2870.

There are currently 13 root-servers. They occupy a reserved domain name, root-servers.net. Each root-server typically comprises more than one physical server but shares a common IP address. Root-servers are named from a.root-servers.net through m.root-servers.net as shown in Table 1-1.

A tabela abaixo foi retirada do site da iana.org:

Hostname	IP Addresses	Operator
a.root-servers.net	198.41.0.4, 2001:503:ba3e::2:30	Verisign, Inc.
b.root-servers.net	199.9.14.201, 2001:500:200::b	University of Southern California, Information Sciences Institute
c.root-servers.net	192.33.4.12, 2001:500:2::c	Cogent Communications
d.root-servers.net	199.7.91.13, 2001:500:2d::d	University of Maryland
e.root-servers.net	192.203.230.10, 2001:500:a8::e	NASA (Ames Research Center)
f.root-servers.net	192.5.5.241, 2001:500:2f::f	Internet Systems Consortium, Inc.
g.root-servers.net	192.112.36.4, 2001:500:12::d0d	US Department of Defense (NIC)
h.root-servers.net	198.97.190.53, 2001:500:1::53	US Army (Research Lab)
i.root-servers.net	192.36.148.17, 2001:7fe::53	Netnod
j.root-servers.net	192.58.128.30, 2001:503:c27::2:30	Verisign, Inc.
k.root-servers.net	193.0.14.129, 2001:7fd::1	RIPE NCC
l.root-servers.net	199.7.83.42, 2001:500:9f::42	ICANN
m.root-servers.net	202.12.27.33, 2001:dc3::35	WIDE Project

Name Servers (NS)

O NameServer nesse contexto é diferente do tipo de registro chamado ns que também faz parte do DNS. Aqui é um programa que roda no servidor de nomes (servidor DNS) responsável por informar o endereço IP de um Host, além disso, temos alguns tipos de Name Servers, são eles: Primário (antigamente denominado como Master), Secundário (antigamente denominado com Slave), Cache e Forward.

Todos os servidores delegados (servidores DNS autoritativos) devem responder consultas em UDP e TCP na porta 53, isso é considerado uma boa prática.

DNS Recursivo

Um servidor DNS Recursivo (também conhecido como resolvedor de Cache) obtém informações específicas fazendo consultas em servidores DNS Autoritativos (Master e Slave) sobre um domínio para responder uma consulta de um Cliente DNS e armazena em cache os dados localmente que foram obtidos por um determinado tempo. O armazenamento em Cache é uma configuração padrão no caso do BIND, mas não é obrigatória.

Os RR (Resource Record ou Registro de Recurso) são descartados após os RR terem atingido seus respectivos TTL. Esse tipo de servidor não tem autoridade sobre o domínio (ou zona). Enquanto um servidor Master ou Slave sempre responde com autoridade às solicitações de informações sobre sua zona, um DNS de Cache só responderá autoritativamente com os dados da zona na primeira vez que obtiver os dados (diretamente do Master ou Slave da zona). A partir da segunda resposta ele obterá as informações de seu Cache, nesse caso os dados não são marcados mais como autoritativos e a resposta será não autoritativa.

O BIND já vem configurado para ser um servidor de Cache e responder a consultas recursivamente na instalação.

Ter um mecanismo de cache no servidor DNS, é importante para melhorar o desempenho e reduzir a carga do servidor. Os usos mais comuns das configurações de cache DNS são os seguintes:

Ter um servidor DNS atuando como Master ou Slave para uma ou mais zonas (com o recurso de Cache desativado) e um outro servidor de Cache para todas as outras consultas (que não seja autoritativo).

No caso de um servidor DNS de Cache estiver sendo atingido milhares de vezes por segundo para dar suporte a um site de alto volume, o desempenho se torna um fator crítico. Nesse cenário, é possível considerar a desativação do cache no servidor DNS por algumas razões:

Tempo de resposta em tempo real
Desabilitar o cache significa que todas as consultas serão direcionadas diretamente aos servidores autoritativos. Embora o cache seja projetado para melhorar o desempenho, ele também introduz um pequeno atraso, pois o servidor precisa verificar se a resposta está armazenada em cache antes de consultar um servidor externo. Com o cache desativado, as respostas serão fornecidas em tempo real, sem a verificação do cache.
Consultas personalizadas e dinâmicas
Se o site de alto volume requer consultas DNS personalizadas ou dinâmicas que não podem ser armazenadas em cache devido à natureza do conteúdo ou requisitos específicos, desabilitar o cache pode ser necessário para garantir que as consultas sejam sempre respondidas corretamente.
Alívio de carga do servidor
Em alguns casos, desativar o cache pode aliviar a carga nos servidores DNS autoritativos. Ao direcionar todas as consultas diretamente para esses servidores, o servidor DNS de uso geral atua apenas como um intermediário, não armazenando respostas em cache. Isso pode ajudar a reduzir a carga nos servidores autoritativos, especialmente em momentos de pico de tráfego.

Além disso, há muitos administradores de DNS que, devido aos perigos relacionados ao cache, nunca permitirão o comportamento de cache em um servidor de nomes que tenha zonas master ou slave. O BIND 9 fornece apenas controles limitados para desabilitar o comportamento de cache, principalmente ao incluir a instrução recursion no; no arquivo de configuração, mas muitas sobrecargas de cache permanecem.

DNS Master

Possui autoridade sobre o domínio (ou zona), é conhecido como Authoritative e lê as informações da zona ou domínio a partir do Sistema de Arquivo local. Mais de um servidor DNS Autoritativo é necessário para aumentar a confiabilidade e performance da zona, mesmo sendo possível ter apenas um único servidor, o que não é recomendado, já que se o servidor ficar fora, a zona que ele serve também ficará fora e o domínio ficará inacessível. É importante manter todos os servidores autoritativos em diferentes locais geográficos e o mais seguro é que todos sejam Master.

Um servidor DNS Master pode enviar (usando mensagens do tipo NOTIFY) um aviso de que houve uma mudanças de zona para servidores DNS Slave. Isso certifica que as alterações de zona sejam rapidamente propagadas para os Slaves, sendo assim os servidores Slave não precisam esperar o tempo configurado em REFRESH para pesquisar se existem alterações no SOA RR. O padrão BIND é notificar (usando NOTIFY) automaticamente todos os servidores DNS definidos nos registros NS para a zona.

Quando um servidor DNS que é Master para uma ou mais zonas recebe uma consulta para uma zona da qual não é Master ou Slave, seu comportamento sera seguido conforme a configuração. No BIND, esse comportamento é definido no arquivo de configuração principal denominado named.conf.

Se as consultas de Cache e Recursivas forem permitidas, o servidor responderá completamente à solicitação ou retornará um erro.
Se apenas consultas iterativas (não recursivas) e Cache for permitido, o servidor poderá responder com a resposta completa se já estiver no cache devido a outra solicitação, uma referência ou retornar um erro.
Se Cache não for permitido (um servidor DNS somente autoritativo), o servidor retornará uma referência ou um erro.

Se a recursão for desativada no servidor Master ele poderá ser reconhecido como Authoritative-Only (ou Somente Autoritativo), já que ele não servirá como servidor recursivo.

DNS Slave

O servidor DNS Slave é o segundo servidor a ter autoridade (também é um Authoritative) sobre domínio ou zona, ele recebe essa autoridade do servidor Master; no processo de transferência de zona. O ato de transferir a zona pode ser visto como tendo autoridade delegada para a zona ao Slave pelo período de tempo definido no valor de expiração do registro SOA e, assim, permite que o Slave responda com autoridade às consultas.

DNS de Forward

Um servidor DNS Forward encaminha todas as consultas que recebe para outro servidor DNS e armazena em cache os resultados. O uso de servidores DNS forward também pode ser usado para aliviar o peso da administração local. O encaminhamento também pode ser usado como parte de uma configuração de servidor stealth (ou split) para defesa de perímetro.

DNS Hidden Master

Também conhecido como servidor DNS Stealth, é definido como um servidor DNS que não aparece em nenhum NS RR publicamente visível para o domínio. Os servidores furtivos são usados em configurações às vezes chamadas de zonas desmilitarizadas (DMZs) ou servidores split. Tanto Hidden Master quanto Stealth não é um tipo de servidor DNS, mas sim um conceito, é usado para descrever uma configuração que é usada para descrever uma configuração DNS especial que protege o servidor DNS Master contra ataques.

O que leva a adotar uma configuração dessas pode ser diversas, mas uma delas é precisar expor o DNS para acesso público mas ao mesmo tempo não querer que o mundo veja qualquer host interno ou principalmente, no caso do servidor DNS ser comprometido, a configuração não ficará no File System local. Uma configuração ideal para um Hidden Master seria um servidor DNS cuja função é limitada apenas às transferências de zona necessárias, mas que nunca responde a consultas de fontes internas ou externas, essas transferências acontecem apenas para servidores Slaves visíveis na Internet.

Existem várias configurações possíveis para um DNS Hidden Master, mas a ideia básica é que ele fica na rede interna de uma organização, protegido por um firewall ou outras medidas de segurança. Ele não é configurado como um servidor DNS recursivo, ou seja, não realiza consultas de resolução de DNS para clientes externos, mas pode realizar para clientes internos. O DNS Hidden Master é responsável por armazenar e atualizar as informações de zona de DNS.

Com os dados da zona atualizados no DNS Hidden Master, ele transfere essas informações atualizadas para servidores DNS secundários que são acessíveis pelos clientes externos, mas ninguém em momento algum possui conhecimento desse servidor. A transferência de zona do DNS Hidden Master para o servidor público geralmente é realizada usando o protocolo de transferência de zona (AXFR) ou o protocolo de notificação de alteração de zona (IXFR). Essa transferência permite que o servidor público tenha uma cópia atualizada da zona de DNS e possa responder a consultas de resolução de DNS dos clientes externos.

Dica

O BIND fornece uma cláusula view que pode ser usada para fornecer funcionalidade semelhante usando um único servidor, mas isso não resolve o problema do sistema host do servidor de nomes sendo comprometido, revelando assim dados adicionais sobre a organização.

DNS Resolver

É um software ou biblioteca que faz a consulta em servidores DNS, é usado no sistema local (DNS cliente) e também é parte do DNS server. Normalmente ele também guarda em cache as consultas que faz.

Tomando um navegador web como exemplo, o processo de resolução de um nome de domínio para acessar um website envolve as seguintes etapas, assumindo que não temos em nenhum momento o endereço em cache e estamos usando um resolver local:

O usuário digita "www.google.com.br" na barra de endereços do navegador e pressiona Enter. O navegador envia uma consulta de resolução para o resolver DNS do sistema operacional do usuário. O resolver DNS verifica seu cache local em busca do registro de resolução de nomes (ou seja, uma tabela que contém informações de resolução de nomes que foram recentemente resolvidas) para o nome "www.google.com.br".
- Se o registro estiver disponível, o resolver retornará o endereço IP armazenado em cache para o navegador e o processo de resolução será concluído.
- Se o registro não estiver disponível no cache do resolver DNS, ele enviará uma consulta de resolução para um servidor DNS recursivo que esteja configurado na máquina ou na rede do usuário.
O servidor DNS recursivo consulta sua própria tabela de cache local em busca de um registro de resolução de nomes para "www.google.com.br".
- Se o registro estiver disponível, o servidor retornará o endereço IP armazenado em cache para o resolver DNS.
- Se o registro não estiver disponível no cache do servidor DNS recursivo, ele enviará uma consulta de resolução para um dos treze servidores raiz da Internet.
O servidor raiz responde com uma referência ao servidor de nomes autoritativo para o TLD ".br".
O servidor DNS recursivo consulta o servidor de nomes autoritativo para o TLD ".br", solicitando o endereço do servidor de nomes autoritativo para o domínio "google.com.br".
O servidor de nomes autoritativo para o TLD ".br" responde com uma referência ao servidor de nomes autoritativo para o domínio "google.com.br".
O servidor DNS recursivo consulta o servidor de nomes autoritativo para o domínio "google.com.br", solicitando o endereço IP do servidor web que hospeda o site "www.google.com.br".
O servidor de nomes autoritativo para o domínio "google.com.br" responde com o endereço IP do servidor web que hospeda o site "www.google.com.br".
O servidor DNS recursivo armazena o endereço IP retornado em cache para acelerar consultas futuras e retorna o endereço IP para para o resolver, que também armazena em Cache.
O navegador usa o endereço IP retornado para estabelecer uma conexão com o servidor web e solicita o conteúdo do site www.google.com.br.
O servidor web responde com o conteúdo do site, que é exibido no navegador do usuário.

Delegação de subdomínios

Uma das principais vantagens do Sistema de Nomes de Domínio é sua capacidade de descentralizar a administração de nomes de domínio. Isso significa que é possível delegar a responsabilidade de gerenciamento de um domínio para outro servidor de nomes. Essa delegação pode ocorrer em diferentes níveis hierárquicos, incluindo a delegação de subdomínios.

Um domínio pode ter vários subdomínios delegados, isso significa que um domínio pode ser dividido em vários subdomínios, e a responsabilidade por cada subdomínios pode ser transferida a diferentes organizações. Tomando como exemplo domínios do Governo Brasileiro, o domínio gov.br possui um subdomínio que é o sp.gov.br e esse mesmo subdomínio pode ser dividido em mais subdomínios e ter a responsabilidade transferida.

Veja alguns exemplos: prefeitura.sp.gov.br, saopaulo.sp.gov.br e educacao.sp.gov.br, além de muitos outros.

Na delegação de um domínio, você precisa configurar os registros NS (Name Server) para indicar quais servidores DNS são autoritativos para o domínio. No entanto, a resolução de nomes desses servidores pode exigir registros adicionais, como A (IPv4) e AAAA (IPv6), dependendo da situação. Se o nome do servidor DNS não for responsivo via outros DNS, será preciso colocar A e AAAA. Vejamos o primeiro exemplo:

# Delegando autoridade sobre o subdomínio 'vagas.sp.gov.br':
deld        IN NS ns1.wlf.eti.br.
            IN NS ns2.wlf.eti.br.

Embora não seja necessário, ainda é uma prática comum incluir os registros A e AAAA para os servidores DNS autoritativos, mesmo quando seus nomes são responsivos.

Nesse caso não é preciso colocar o endereço do IPv4 nem do IPv6 por que o nome dos NS é responsivo, veja só:

$ host ns1.wlf.eti.br
ns1.wlf.eti.br has address 94.72.123.149
ns1.wlf.eti.br has IPv6 address 2605:a141:2167:7657::1

$ host ns2.wlf.eti.br
ns2.wlf.eti.br has address 75.119.143.187
ns2.wlf.eti.br has IPv6 address 2a02:c206:2120:1140::1

Agora, se o nome dos NS não for responsivo, teremos que colocar o endereço IP dos mesmos. Isso acontece muito quando o sub-domínio que será delegado não será gerenciado por um ou mais servidores DNS conhecidos globalmente, nesses casos teremos que adicionar os registro A e AAAA para os servidores DNS.

Antes faça um teste para verificar se o servidores DNS que vão receber o domínio deld.hermodr.com.br é responsivo:

$ host ns1.deld.hermodr.com.br
Host ns1.deld.hermodr.com.br not found: 3(NXDOMAIN)

$ host ns2.deld.hermodr.com.br
Host ns2.deld.hermodr.com.br not found: 3(NXDOMAIN)

Como eles não são, teremos que adicionar os registro de IPv4 e IPv6:

deld        IN NS ns1.deld.hermodr.com.br.
            IN NS ns2.deld.hermodr.com.br.
ns1.deld    IN A 94.72.123.149
            IN AAAA 2605:a141:2167:7657::1
ns2.deld    IN A 94.72.123.150
            IN AAAA 2605:a141:2167:7657::2

Introdução aos Tipos de TLDs

Os TLDs (Top-Level Domains), são a parte final de um nome de domínio na estrutura hierárquica do DNS. Eles desempenham um papel crucial na organização da internet, categorizando domínios com base em diferentes critérios, como localização geográfica, propósito ou tipo de organização. Existem vários tipos de TLDs, cada um com suas próprias características e finalidades específicas.

A seguir, exploraremos os principais tipos de TLDs, incluindo gTLDs (generic Top-Level Domains), ccTLDs (country code Top-Level Domains) e sTLDs (sponsored Top-Level Domains), explicando suas características e exemplos de uso.

generic Top-Level Domains - gTLDs

Já falamos sobre ele, mas vamos reforçar. Os generic Top-Level Domains são os domínios localizados no topo da hierarquia, logo abaixo do . no Namespace. Dentre esses gTLDs incluem .com, .org, .net, .edu, .gov, .mil, .info, .biz e outros. Esses gTLDs são gerenciados por organizações como a Verisign, a PIR (Public Interest Registry) e outras.

Existem mais dois domínios gTLD que são bastante famosos nos dias de hoje. O .onion e o .bit são gTLDs alternativos que funcionam de maneira diferente dos gTLDs tradicionais.

O .onion é um gTLD usado exclusivamente na rede Tor, que é uma rede anônima usada para acessar conteúdo na internet de forma privada. Os endereços .onion não são acessíveis pela internet normal e não podem ser registrados ou gerenciados pelos Registrars de domínios tradicionais. Em vez disso, eles são gerados automaticamente pela rede Tor, usando um processo de criptografia para criar um endereço único para cada serviço ou site .onion.

Já o .bit é um gTLD alternativo que funciona como parte da Namecoin, uma criptomoeda baseada em blockchain. Ele usa a tecnologia blockchain para armazenar e gerenciar registros de nome de domínio e é descentralizado, o que significa que não depende de um único servidor centralizado. Como resultado, os domínios .bit são resistentes à censura e à interferência de governos ou outras autoridades centrais.

Os usuários podem registrar nomes de domínio .bit usando uma carteira de criptomoeda que suporta Namecoin. Isso permite que os proprietários de domínio tenham controle total sobre seus nomes de domínio, sem depender de intermediários ou terceiros.

country code Top Level Domain - ccTLD

Assim como o tema acima, já falamos sobre ele, mas vamos reforçar. Os Country Code Top-Level Domains são domínios de nível superior designados para países, territórios ou regiões específicas. Cada ccTLD é composto por duas letras baseadas no código de país da ISO 3166-1, como .br para o Brasil, .uk para o Reino Unido e .jp para o Japão. Esses domínios são usados para identificar websites e recursos online que estão diretamente associados a uma nação ou região específica.

Cada ccTLD é gerenciado por uma organização ou autoridade local, conhecida como Registry, responsável pelas políticas e pela administração do domínio dentro de seu país ou território. No Brasil, por exemplo, o .br é administrado pelo NIC.br. Exemplos de ccTLDs:

ccTLD	País/Território
.br	Brasil
.us	Estados Unidos
.uk	Reino Unido
.de	Alemanha
.jp	Japão
.cn	China
.fr	França
.au	Austrália
.ca	Canadá
.ru	Rússia
.in	Índia
.za	África do Sul
.mx	México
.ar	Argentina
.it	Itália
.kr	Coreia do Sul
.ch	Suíça
.es	Espanha
.co	Colômbia

Second-Level Domains - SLDs

Os Second-Level Domains são a parte de um nome de domínio que fica imediatamente à esquerda do Top-Level Domain. Em outras palavras, o SLD é o nome principal do domínio, enquanto o TLD (como .com ou .br) define a categoria ou a localização geográfica. No exemplo de domínio example.com, example é o SLD, enquanto .com é o TLD.

Domínios de Terceiro Nível e abaixo

Esses domínios são subdomínios dos SLDs e permitem que as organizações criem nomes de domínio personalizados para suas redes internas e serviços, como www, ftp e mail são comuns e podem ser usados para diferentes propósitos dentro de uma mesma estrutura de domínio. Um exemplo seria www.example.com, onde www é o subdomínio, example é o SLD, e .com é o TLD.

Consulta recursiva e iterativa

A consulta Recursiva e Iterativa acontece durante o processo de resolução de nomes.

Recursiva
A consulta recursiva é o processo que um servidor DNS realiza para obter um endereço de host quando o servidor DNS consultado não é o autoritativo da zona DNS. Nesse processo, o servidor DNS consultado busca informações em outros servidores DNS até encontrar a resposta solicitada. Esse método é usado por padrão pelo cliente DNS do sistema operacional e é o mais comum em consultas DNS.
Iterativa
A consulta iterativa é um método em que o servidor DNS retorna informações que podem ajudar o cliente a encontrar a resposta solicitada. Se o servidor DNS não tiver a resposta em seu próprio cache ou autoridade, ele pode fornecer referências a servidores de nomes adicionais que possam ter as informações desejadas. No entanto, o servidor DNS não fará solicitações adicionais a esses servidores em nome do cliente. Em vez disso, o cliente DNS recebe as referências dos servidores DNS iterativos e, em seguida, pode enviar consultas adicionais diretamente aos servidores de nomes mencionados nessas referências. Essas consultas subsequentes são feitas pelo cliente DNS de forma independente para cada servidor mencionado, até que a resposta final seja obtida.

A consulta Iterativa é mais simples e não exige tanto trabalho por parte do servidor de nomes que foi consultado. Antes de entendermos o processo é importante entender quando acontece uma consulta Iterativa. O termo consulta Iterativa pode ser usado também como Resolução Iterativa. A consulta Iterativa acontece quando o cliente solicita uma consulta no servidor DNS mas o servidor está desabilitado para fazer uma consulta recursiva ou quando o cliente explicitamente solicita uma consulta Iterativa.

Como foi dito, um servidor de nomes simplesmente fornece a melhor resposta que já conhece ao cliente durante a consulta Iterativa. O servidor de nomes consultado vai consultar seus dados locais (incluindo seu cache) procurando os dados solicitados. Se não encontrar a resposta, ele encontrará os nomes e endereços dos DNS que estão mais próximos ao nome de domínio que o cliente quer consultar e então retornará esses dados como referência para ajudar o cliente a continuar o processo de resolução sozinho, sem a ajuda do servidor DNS inicial.

FQDN

O FQDN (Fully Qualified Domain Name, ou em Português, Nome de Domínio Completamente Qualificado), algumas vezes denominado nome de domínio absoluto, é um nome de domínio que especifica sua localização exata na árvore hierárquica do Domain Name System (DNS). Ele especifica todos os níveis de domínio, incluindo, pelo menos, um domínio de segundo nível e um domínio de nível superior. Um FQDN é distinguido pela sua falta de ambiguidade: ele pode ser interpretado apenas de uma maneira. Exemplo:

Nome do Computador: "foo"
Nome do domínio: "bar.com"

O FQDN será: "foo.bar.com."

Outros exemplos de FQDN:

"espec.ppgia.pucpr.br.", "www.uol.com.br.", "www.mit.edu.", "edas.info.".

PDQN

Um PQDN (Partially Qualified Domain Name) não inclui subdivisões até a raiz do DNS. Tais nomes são também conhecidos como Relative Domain Name ou Hostname, são apenas os nomes das máquinas pertencentes aos domínios.

Tipos de zonas

Os tipos de zonas DNS servem para definir a relação de autoridade entre os servidores DNS. Cada tipo de zona define um conjunto de servidores DNS que são autoritativos para os registros de DNS de um determinado domínio ou subdomínio. Abaixo seguem os tipos de zonas e a descrição e cada um.

Zonas	Descrição
MASTER	Zona de autoridade sobre o domínio. Os dados da "zona" serão criados, publicados e administrados a partir deste ponto.
SLAVE	É basicamente uma "cópia" da zona original (master), nenhuma criação ou alteração respectiva a essa "zona" será feita diretamente neste DNS.
STUB	Enquanto as zonas Slave contêm uma cópia completa dos registros de uma zona DNS, o STUB contém apenas algumas informações importantes sobre a zona, como os registros NS (Name Server) que indicam quais servidores DNS são responsáveis pela zona. O STUB pode ser usado para reduzir a carga de trabalho dos servidores DNS recursivos e melhorar o desempenho das consultas DNS, uma vez que o servidor DNS recursivo só precisa consultar o servidor DNS remoto especificado no STUB para obter informações sobre a zona DNS. Esse tipo de zona não é implementado em todos os software de DNS (É possível usar o no BIND e no NSD).
HINT	Essa zona é uma lista de servidores DNS raiz. Quando um servidor DNS autoritativo é iniciado, ele precisa saber onde começar a pesquisa pelo nome de um domínio. É aqui que a lista de servidores DNS raiz se torna importante. A lista de servidores raiz está presente em um arquivo de configuração chamado `named.root`, que é usado pelo BIND e outros servidores DNS autoritativos para determinar os servidores DNS raiz atuais. O BIND usa a zona HINT para carregar essa lista de servidores raiz do arquivo `named.root` e usá-los para começar a pesquisa DNS.
FORWARD	Serve para orientar o "BIND", e encaminhar a consulta sobre uma determinada "zona" para outro servidor em especial.
DELEGATION-ONLY	Uma zona especial no DNS que contém apenas informações de delegação para subdomínios, mas não contém registros de recursos para o próprio domínio. Em outras palavras, uma zona de delegação apenas não tem registros de recursos de host para consultas de resolução DNS, mas apenas aponta para outras zonas que contêm essas informações. Essas zonas são usadas principalmente para delegar a autoridade sobre subdomínios para outros servidores DNS, sem fornecer informações de resolução DNS para o domínio principal. Eles são úteis em ambientes de grande escala, onde a administração e a distribuição de dados do DNS são gerenciadas por diferentes equipes ou organizações.

Replicação de Zona

Nesse tópico veremos como é realizado a transferência de zona entre um servidor Master e um servidor Slave após o processo de configuração, ou seja, veremos como o servidor Slave sempre mantém a configuração mais atualizada em comparação com o Master.

Em geral AXFRs e IXFRs usam TCP na porta 53, isso ocorre porque o TCP é um protocolo orientado a conexão que fornece garantia de entrega e controle de fluxo, tornando-o mais adequado para transferir grandes quantidades de dados, como as zonas DNS. Em resumo, ao usar o TCP, é possível garantir que a zona seja transferida com sucesso e que não haja perda de dados no caminho.

Protocolo AXFR

O AXFR é um protocolo para transferências total de zona, usado para a replicação de dados de DNS de um servidor DNS autoritativo para um ou mais servidores Slaves. A transferência da zona é feita em formato de arquivo, permitindo que o servidor secundário mantenha uma cópia atualizada da zona de DNS.

O processo de AXFR ocorre da seguinte maneira:

O servidor secundário (slave) fica consultando o servidor Master de tempos em tempos para verificar se houve alguma atualização na zona ou domínio, esse tempo é configurado pela opção Refresh no SOA. Se o valor de SN (Serial Number) no SOA RR do Master for maior do que o atualmente armazenado pelo servidor Slave, uma operação de transferência de zona é iniciada.
O servidor secundário (Slave) envia uma solicitação AXFR ao servidor primário (Master) indicando o nome da zona que deseja transferir.
O servidor primário (Master) responde à solicitação AXFR com uma série de registros DNS contendo as informações completas da zona, incluindo registros de recursos (A, MX, CNAME, etc.), registros de autoridade (SOA) e registros de servidores de nomes (NS).
O servidor secundário (Slave) recebe a resposta AXFR e armazena os registros em sua própria cópia da zona DNS, atualizando-a para refletir as informações mais recentes. Dessa forma o servidor Slave consegue fornecer as informações mais atualizadas para os clientes DNS de forma autoritativa.

Devemos ter muito cuidado com as configurações padrões de aplicações DNS. As solicitações AXFR revelam muitas informações de um subdomínio, já que o servidor Master por padrão efetua transferências de zona para qualquer um que a solicitar. Com isso um atacante poderia obter informações como: nomes de subdomínio, endereços IP, CNAMES, PTR, servidores DNS, MX e muito mais.

Está certo que boa parte dessas consultas podem ser obtidas publicamente, mas o atacante precisa possui alguma informação, como saber o endereço do site para consultar e por ai vai. O problema é que com AXFR aberto assim, você não precisa possuir nenhuma informação, e pior, a consulta lhe ta um mapa de Rede completo, o que é um prato cheio para qualquer atacante.

# Podemos fazer uma solicitação AXFR usando o DIG:
$ dig @SERVIDOR AXFR DOMINIO

Um método para impedir que isso aconteça é implantar TSIG para transferência de zonas e só liberar as transferências de zona para servidores Slaves de conhecimento nosso, ou seja, só permitir as transferências para servidores previamente autorizados.

Protocolo IXFR

O IXFR é um protocolo para transferências incrementais de zona. Ele foi desenvolvido porque a transferência de arquivos de zona muito grandes pode levar muito tempo e desperdiçar largura de banda e outros recursos, especialmente quando a mudança na zona tem acontecido em apenas um único registro; nesse caso transferir toda uma zona sendo que apenas um registro foi modificado seria um desperdício de recursos.

A RFC 1995 de 1996 introduziu esse novo protocolo que permite que o servidor DNS Slave e o servidor DNS Master transfiram apenas os registros que foram alterados. O funcionamento é similar ao AXFR.

O processo de IXFR ocorre da seguinte maneira:

O servidor secundário (slave) fica consultando o servidor Master de tempos em tempos para verificar se houve alguma atualização na zona ou domínio, esse tempo é configurado pela opção Refresh no SOA. Se o valor de SN (Serial Number) no SOA RR do Master for maior do que o atualmente armazenado pelo servidor Slave, uma operação de transferência de zona é iniciada.
O servidor secundário (Slave) solicita uma transferência de zona e indica se é capaz ou não de aceitar um IXFR. Se os servidores de nomes Master e Slave suportarem o recurso, ocorrerá um IXFR; caso contrário, ocorre um AXFR.
O servidor primário (Master) responde à solicitação IXFR apenas com as informações que foram modificadas.
O servidor secundário (Slave) recebe a resposta IXFR e armazena os registros em sua própria cópia da zona DNS, atualizando-a para refletir as informações mais recentes. Dessa forma o servidor Slave consegue fornecer as informações mais atualizadas para os clientes DNS de forma autoritativa.

O modo padrão do BIND ao atuar como um servidor DNS Slave é solicitar IXFR, a menos que tenha sido configurado para não usar a instrução request-ixfr no servidor. Já o padrão para o BIND quando é um Master é usar IXFR somente quando a zona é Dinâmica.
O uso de IXFR é controlado por meio da instrução provide-ixfr no servidor. Os IXFRs afetam apenas o volume de dados transferidos.

NOTIFY

O NOTIFY é um mecanismo que permite que servidores primários (Masters) notifiquem seus servidores secundários (Slaves) sobre mudanças nos dados de uma zona, ou seja, sempre que uma zona for carregada ou atualizada, o servidor Master enviará uma notificação para os servidores Slaves daquela zona informando que houve uma mudança de estado na zona. Em resposta a uma mensagem NOTIFY de um servidor primário, o secundário verifica se sua versão da zona é a versão atual e, se não for, inicia uma transferência de zona.

A RFC 1996 introduziu um esquema pelo qual um servidor de nome de zona autoritativo (Master ou Slave) enviará uma mensagem NOTIFY para os servidores DNS de zona (definidos pelos NS RRs) sempre que a zona for carregada ou atualizada. Essa mensagem indica que pode ter ocorrido uma alteração nos registros do domínio. O servidor DNS ao receber a mensagem NOTIFY solicitará o SOA RR do Master da zona, se o SN for maior que o armazenado atualmente, tentará uma transferência de zona usando um AXFR) ou um IXFR.

Como uma zona secundária também pode ser primária para outras secundárias, o BIND por padrão envia mensagens NOTIFY para cada zona que carrega. O comportamento de NOTIFY no BIND é controlado por instruções notify, also-notify e notify-source no arquivo de zona ou nas cláusulas de opções do arquivo named.conf.

Dynamic Update

Particularmente não queria escrever sobre esse recurso, já que ele demanda muito esforço em tornar a administração segura e sem brechas (o que não será 100% seguro), mas achei interessante falar sobre mesmo não gostando desse recurso (pelo menos como um administrador, mas como um cliente que uso em minha residência, é um recurso incrível).

O método normal de atualizar registros de zona é editando manualmente o arquivo de zona, em seguida parando e iniciando o processo da aplicação que fornece serviço de DNS para reler os arquivos de zona e propagar as alterações. Quando o volume de alterações atinge um certo nível, isso pode se tornar muito complicado e propenso a erros, especialmente considerando organizações que lidam com um grande número de arquivos de zona, nesse cenário o BIND pode demorar muito para reiniciar porque inicializa um grande número de arquivos de zona.

Dynamic Update é um recurso do DNS que permite a modificação em tempo real dos registros DNS em uma zona. Clientes autorizados podem fazer alterações automáticas nos registros DNS, sem a necessidade de intervenção manual. A principal limitação nesta especificação é que um novo domínio ou zona não pode ser adicionado ou excluído dinamicamente. Todos os registros dentro de uma zona existente podem ser adicionados, alterados ou excluídos apenas. Ao atualizar os RRs de zona dinamicamente, é essencial atualizar apenas um servidor, embora possa haver vários servidores Masters para a zona.

Para resolver este problema, um servidor chefe deve ser selecionado. O servidor chefe não tem nenhuma característica especial além de ser definido como o servidor DNS no SOA RR e pode aparecer em uma instrução allow-update do arquivo de configuração do BIND para controlar o processo de atualização dinâmica. O DDNS é sempre descrito com os recursos de Secure DNS, como o TSIG e TKEY. Além disso, devemos sempre configurar a instrução allow-update do BIND, mas isso fornece proteção limitada.

A configuração allow-update em um servidor DNS é usada para definir quais clientes têm permissão para enviar solicitações de atualização e modificar os registros DNS na zona. O comportamento DDNS padrão do BIND é negar a todos os hosts.

Alternativas de DDNS

O BIND-DLZ também conhecido como Dynamic Loadable Zones, é uma extensão para o BIND que permite a integração de back-ends de armazenamento de dados externos para zonas DNS. Essa extensão permite que o BIND obtenha informações de zona de uma fonte de dados diferentes do formato de arquivo de zona tradicional. O BIND-DLZ oferece suporte aos principais bancos de dados de código aberto, incluindo MySQL, PostgreSQL, BDB e LDAP. Todas as consultas de DNS recebidas são primeiro direcionadas para as rotinas de acesso ao banco de dados para que os dados de zona novos, modificados ou excluídos sejam imediatamente refletidos nas respostas do servidor de nomes. Dependendo do banco de dados selecionado e da configuração, o desempenho pode cair muito.

DNS Reverso

O DNS reverso é o oposto da resolução de nomes comum. Em vez de traduzir nomes de domínio em endereços IP, ele traduz endereços IP em nomes de domínio. É muito usado para autenticar servidores de e-mail, prevenir spam, identificar atividades maliciosas e facilitar a identificação de um endereço IP por um administrador de Rede.

Se tratando de servidores de e-mail, o DNS reverso permite que determinem se um endereço IP está associado a um nome de domínio legítimo antes de aceitar e-mails desse endereço.

Para configurar o DNS reverso, é criado um registro PTR (Pointer) no servidor DNS, associando um endereço IP a um nome de domínio. A zona reversa, também chamada de zona de resolução reversa, é usada para realizar essa resolução reversa de endereços IP em nomes de domínio. Enquanto na resolução DNS normal um nome de domínio é convertido em um endereço IP, na resolução reversa um endereço IP é convertido em um nome de domínio.

Ao realizar a resolução reversa de DNS, um endereço IP pode ser convertido em um nome de domínio que termina com .arpa. Esse domínio de nível superior, chamado .arpa, é exclusivamente usado para a infraestrutura de DNS reversa e é gerenciado pela Internet Assigned Numbers Authority (IANA). Na resolução reversa de DNS, o nome de domínio completo segue um formato específico. O endereço IP é dividido em quatro octetos, invertido e separados por pontos (no caso do IPv4). Em seguida, a string in-addr.arpa é adicionada ao final do endereço IP invertido para formar o nome de domínio completo. Por exemplo, se o endereço IP for 192.0.2.1, o nome de domínio completo resultante seria 1.2.0.192.in-addr.arpa.

Para a resolução reversa de endereços IPv6 em nomes de domínio, o domínio reverso padrão é o ip6.arpa. Assim como na resolução reversa de DNS do IPv4, o endereço IPv6 também é dividido, mas no IPv6 a divisão é feita em blocos de 16 bits e invertido. Em seguida, cada bloco é convertido em um número hexadecimal e separado por um ponto. Por fim, o nome de domínio ip6.arpa é adicionado ao final do endereço IPv6 invertido e formatado para criar o nome de domínio completo.

Por exemplo, se o endereço IPv6 for 2001:0db8:85a3:0000:0000:8a2e:0370:7334, o nome de domínio reverso correspondente seria 4.3.3.7.0.3.e.2.a.8.8.0.0.0.0.3.5.a.5.8.b.d.0.1.0.0.2.ip6.arpa.

$ host 35.185.44.232
232.44.185.35.in-addr.arpa domain name pointer 232.44.185.35.bc.googleusercontent.com.

$ host 2620:0:2830:201::1:71
1.7.0.0.1.0.0.0.0.0.0.0.0.0.0.0.1.0.2.0.0.3.8.2.0.0.0.0.0.2.6.2.ip6.arpa domain name pointer pechora5.icann.org.

No caso do Brasil o órgão responsável pela distribuição dos blocos de endereçamento IPv4 e IPv6 é a Numeração, além de distribuir os blocos de endereço IP, também distribuem os ASN (Autonomous System Number). Sendo assim, quando você paga por um ASN e recebe um bloco de endereçamento IP, é possível cadastrar o seu servidor DNS para que o registro.br possa delegar a autoridade sobre o reverso do bloco de endereçamento que você recebeu para o seu servidor DNS.

Delegação de DNS Reverso

A resolução de DNS reverso segue a mesma hierarquia dos domínios, tornando fácil encontrar o reverso de um endereço IP usando o DNS; isso funciona porque como já foi mostrado, o endereço IP é convertido em um nome de domínio específico (.arpa). No início dessa hierarquia está o domínio .arpa, que é gerenciado pela IANA. Quando a IANA delega um bloco de endereços para os RIRs (Regional Internet Registries), também deve delegar o mapeamento reverso para esses blocos aos RIRs. Cada RIR recebe um bloco de endereços e a autorização para criar o mapeamento reverso correspondente. A partir desse ponto, as coisas podem se tornar mais complexas, pois cada RIR pode ter políticas diferentes para delegar o mapeamento reverso para os endereços distribuídos.

Geralmente, cada RIR entrega e delega o mapeamento reverso dos endereços recebidos para seus respectivos NIRs (National Internet Registries), que são responsáveis por distribuir os endereços em um país ou continente específico, assim como delegar o mapeamento reverso dentro da área de responsabilidade do RIR. Nos locais onde existem LIRs (Local Internet Registries), o NIR delega blocos de endereços e também o mapeamento reverso desses blocos para o LIR.

Problemas na Delegação de Blocos CIDR Subdivididos

Por padrão, e para manter uma configuração adequada no sistema de DNS reverso, os blocos de endereços IP devem ser delegados em tamanhos específicos, como /8, /16 e /24. Isso ocorre porque o formato in-addr.arpa utilizado no DNS reverso foi projetado para funcionar eficientemente com essas divisões. Esses tamanhos de blocos são os mais comuns para delegação porque correspondem a divisões naturais dentro da estrutura de endereços IP, que facilita a administração e roteamento no DNS reverso.

Delegar blocos menores ou maiores que /8, /16 e /24 pode causar complicações, já que o DNS reverso não reconhece facilmente esses intervalos e requer configurações manuais e complexas para funcionar corretamente. Ao delegar DNS reverso para um bloco de endereços IPv4 maior que /24, como um /19, é necessário subdividir o bloco em múltiplos /24 para cobrir todo o intervalo de endereços. Para um bloco /19, como 192.0.0.0/19, que cobre os endereços de 192.0.0.0 a 192.0.31.255, você precisará dividir esse bloco em 8 sub-blocos /24. Cada /24 terá sua própria zona DNS reversa, que será configurada individualmente.

O bloco 192.0.0.0/19 pode ser dividido em:

192.0.0.0/24
192.0.1.0/24
192.0.2.0/24
.
.
192.0.31.0/24

Cada sub-bloco terá uma zona DNS reversa separada:

; Reverse mapping of 192.0.0/24
0.0.192.in-addr.arpa  IN NS ns1.example.com.

; Reverse mapping of 192.1.0/24
1.0.192.in-addr.arpa  IN NS ns1.example.com.

; Reverse mapping of 192.2.0/24
2.0.192.in-addr.arpa  IN NS ns1.example.com.
.
.
; Reverse mapping of 192.31.0/24
31.0.192.in-addr.arpa IN NS ns1.example.com.

O exemplo acima tenta simular que cada endereço está em um arquivo de zona separado, onde os registros PTR apontam para os endereços IP específicos do sub-bloco /24, como 192.0.0.0/24, 192.0.1.0/24, e assim por diante. Cada arquivo será configurado no servidor DNS que delegará a responsabilidade para outro servidor DNS, que será responsável por responder às consultas de DNS reverso desses blocos.

A única exceção seria a delegação de blocos menores que /24, como /25 ou /26, conforme especificado na RFC 2317. No entanto, essa regra não se aplica a blocos maiores, como /24, /23, e assim por diante. Portanto, o método correto para delegar um bloco maior que /24, como um /19, é subdividi-lo em blocos /24 e delegar cada um separadamente.

Essa hierarquia e delegação no DNS reverso são essenciais para o seu correto funcionamento. Vamos considerar um exemplo prático de resolução reversa para o endereço IP 200.160.4.6, associado ao domínio nic.br.

$ dig +trace -4x 200.160.4.6

; <<>> DiG 9.18.12-0ubuntu0.22.04.1-Ubuntu <<>> +trace -4x 200.160.4.6
;; global options: +cmd
.           2793    IN  NS  c.root-servers.net.
.           2793    IN  NS  l.root-servers.net.
.           2793    IN  NS  h.root-servers.net.
.           2793    IN  NS  k.root-servers.net.
.           2793    IN  NS  i.root-servers.net.
.           2793    IN  NS  f.root-servers.net.
.           2793    IN  NS  b.root-servers.net.
.           2793    IN  NS  j.root-servers.net.
.           2793    IN  NS  e.root-servers.net.
.           2793    IN  NS  a.root-servers.net.
.           2793    IN  NS  g.root-servers.net.
.           2793    IN  NS  m.root-servers.net.
.           2793    IN  NS  d.root-servers.net.
;; Received 239 bytes from 127.0.0.53#53(127.0.0.53) in 0 ms

in-addr.arpa.       172800  IN  NS  a.in-addr-servers.arpa.
in-addr.arpa.       172800  IN  NS  b.in-addr-servers.arpa.
in-addr.arpa.       172800  IN  NS  c.in-addr-servers.arpa.
in-addr.arpa.       172800  IN  NS  d.in-addr-servers.arpa.
in-addr.arpa.       172800  IN  NS  e.in-addr-servers.arpa.
in-addr.arpa.       172800  IN  NS  f.in-addr-servers.arpa.
in-addr.arpa.       86400   IN  DS  47054 8 2 5CAFCCEC201D1933B4C9F6A9C8F51E51F3B39979058AC21B8DF1B1F2 81CBC6F2
in-addr.arpa.       86400   IN  DS  53696 8 2 13E5501C56B20394DA921B51412D48B7089C5EB6957A7C58553C4D4D 424F04DF
in-addr.arpa.       86400   IN  DS  63982 8 2 AAF4FB5D213EF25AE44679032EBE3514C487D7ABD99D7F5FEC3383D0 30733C73
in-addr.arpa.       86400   IN  RRSIG   DS 8 2 86400 20230625060000 20230612050000 19456 arpa. HRXaxoCZzwXeRgaXXWEjKhiAvpo8/0zXtHSiIeS7YrBCJNqFLSQnuFLt ZZh2b+DGgqzLtr8UvM49dWyDgAdDAm/BM0qHgROi9QjGXtHv9P5UeGiy veBfnR06cXDXoDP1mafrTE7J+PuUuGnCGK80ZVhg7kHQRtCGMe8DVN8H XUbftNFB3+GLrI4LsZ8N/VC8xzPrjEx1EGyoqLEbxIeU1l2D/iXriBEi h2b/hRpfWE99JJsIEYUz8HLmWWjuJd2ofGQaoqNEEgJBBbDBwUn0yV4r g+0Gdq6YR8++5iai1v0COXyauz8tAqQrAi6KxNFEQtg2ZM0ZIvWewfDz DpGJFg==
;; Received 865 bytes from 192.58.128.30#53(j.root-servers.net) in 68 ms

200.in-addr.arpa.   86400   IN  NS  lacnic.authdns.ripe.net.
200.in-addr.arpa.   86400   IN  NS  a.arpa.dns.br.
200.in-addr.arpa.   86400   IN  NS  a.lactld.org.
200.in-addr.arpa.   86400   IN  NS  ns3.afrinic.net.
200.in-addr.arpa.   86400   IN  NS  ns.lacnic.net.
200.in-addr.arpa.   86400   IN  NS  ns2.lacnic.net.
200.in-addr.arpa.   86400   IN  NS  ns4.apnic.net.
200.in-addr.arpa.   86400   IN  NS  rirns.arin.net.
200.in-addr.arpa.   86400   IN  DS  16591 8 2 99BF764655E51E2341F9E320F6E2D03CAF216E3DE611615B8F2F20EA 93AF4C78
200.in-addr.arpa.   86400   IN  RRSIG   DS 8 3 86400 20230625044041 20230603213001 48561 in-addr.arpa. EkiRoZ6UDNRhu5P7J6UbGjb0H/z1Chbiy2JHfrlWbz8opACOz9ONSanv GzmJIeJv0/IKlANZ7aR6TUD0VxbavH2vw38XD3Erh3rLU5jxMl+PBHVh bb3UXDsDd1ClORqxOpFDpUtJLsKTlD0vYIxUSpFZvToH8ymrTciw1AL/ tA8=
;; Received 536 bytes from 200.10.60.53#53(d.in-addr-servers.arpa) in 12 ms

4.160.200.in-addr.arpa. 86400   IN  NS  B.DNS.BR.
4.160.200.in-addr.arpa. 86400   IN  NS  D.DNS.BR.
4.160.200.in-addr.arpa. 86400   IN  NS  C.DNS.BR.
4.160.200.in-addr.arpa. 86400   IN  NS  A.DNS.BR.
4.160.200.in-addr.arpa. 86400   IN  NS  E.DNS.BR.
4.160.200.in-addr.arpa. 86400   IN  DS  18509 13 2 6603EBCDD03A75F1C2A1FFFBA364F3BCD5B74F818CAC1F5D9DD8F1DA 8C490BB6
4.160.200.in-addr.arpa. 86400   IN  RRSIG   DS 8 5 86400 20230701200947 20230601200820 17484 200.in-addr.arpa. yBrE9y0J1HnlDqdhcXyK30m6XjfxY2H9KHzuM//MJIY8yd8g/n7mu5fz 4RhvIoNKguCRcTyCvIBaUJmfnNzd/GjFImklC9MUo4/mbi6aMTtARS27 GGWAoP5IWnxJiHlx68+Fryy6KOZF1Rr6u3bhifoHXg5HlQ7lSIIKqHR/ DIUjW08pKs7jEtB9921cHAbOwi1Gx7lkO02SzAsiBwg5AFL8kQIXd/YN XVBd/83hrKCRNBX/1ObXYuWs2n+H2kfWrZF0ubJI7XKnhev0T17TIJkd SKiAKRv+NsDQm2TKKuGtZsS2tb1GyYDsH+Qbx7dvRL9S1O7iaaP633/3 8kl14g==
;; Received 519 bytes from 199.253.249.53#53(rirns.arin.net) in 180 ms

6.4.160.200.in-addr.arpa. 86400 IN  PTR nic.br.
6.4.160.200.in-addr.arpa. 86400 IN  RRSIG   PTR 13 6 86400 20230709143441 20230430135616 18509 4.160.200.in-addr.arpa. uZVXvQ1Qv8JjNWLJSbbS7oWzpWF/F6thFKg0ElYDTQ6OBuLx//OgvTod KeqUO/UyZfX+GCW4fmGbzEIAccjF1A==
;; Received 219 bytes from 200.219.148.10#53(A.DNS.BR) in 8 ms

No primeiro bloco podemos ver que é retornado os Root Servers que respondem pelo . (raiz). Os Root Servers são responsáveis por fornecer informações sobre os servidores de autoridade dos domínios de nível superior:

; <<>> DiG 9.18.12-0ubuntu0.22.04.1-Ubuntu <<>> +trace -4x 200.160.4.6
;; global options: +cmd
.           2793    IN  NS  c.root-servers.net.
.           2793    IN  NS  l.root-servers.net.
.           2793    IN  NS  h.root-servers.net.
.           2793    IN  NS  k.root-servers.net.
.           2793    IN  NS  i.root-servers.net.
.           2793    IN  NS  f.root-servers.net.
.           2793    IN  NS  b.root-servers.net.
.           2793    IN  NS  j.root-servers.net.
.           2793    IN  NS  e.root-servers.net.
.           2793    IN  NS  a.root-servers.net.
.           2793    IN  NS  g.root-servers.net.
.           2793    IN  NS  m.root-servers.net.
.           2793    IN  NS  d.root-servers.net.
;; Received 239 bytes from 127.0.0.53#53(127.0.0.53) in 0 ms

No segundo bloco podemos ver quem são os servidores responsáveis pelo domínio in-addr.arpa., essa resposta nos foi dada por um dos Root Servers. Também recebemos os registros DS e RRSIG para validação do DNSSEC.

in-addr.arpa.       172800  IN  NS  a.in-addr-servers.arpa.
in-addr.arpa.       172800  IN  NS  b.in-addr-servers.arpa.
in-addr.arpa.       172800  IN  NS  c.in-addr-servers.arpa.
in-addr.arpa.       172800  IN  NS  d.in-addr-servers.arpa.
in-addr.arpa.       172800  IN  NS  e.in-addr-servers.arpa.
in-addr.arpa.       172800  IN  NS  f.in-addr-servers.arpa.
in-addr.arpa.       86400   IN  DS  47054 8 2 5CAFCCEC201D1933B4C9F6A9C8F51E51F3B39979058AC21B8DF1B1F2 81CBC6F2
in-addr.arpa.       86400   IN  DS  53696 8 2 13E5501C56B20394DA921B51412D48B7089C5EB6957A7C58553C4D4D 424F04DF
in-addr.arpa.       86400   IN  DS  63982 8 2 AAF4FB5D213EF25AE44679032EBE3514C487D7ABD99D7F5FEC3383D0 30733C73
in-addr.arpa.       86400   IN  RRSIG   DS 8 2 86400 20230625060000 20230612050000 19456 arpa. HRXaxoCZzwXeRgaXXWEjKhiAvpo8/0zXtHSiIeS7YrBCJNqFLSQnuFLt ZZh2b+DGgqzLtr8UvM49dWyDgAdDAm/BM0qHgROi9QjGXtHv9P5UeGiy veBfnR06cXDXoDP1mafrTE7J+PuUuGnCGK80ZVhg7kHQRtCGMe8DVN8H XUbftNFB3+GLrI4LsZ8N/VC8xzPrjEx1EGyoqLEbxIeU1l2D/iXriBEi h2b/hRpfWE99JJsIEYUz8HLmWWjuJd2ofGQaoqNEEgJBBbDBwUn0yV4r g+0Gdq6YR8++5iai1v0COXyauz8tAqQrAi6KxNFEQtg2ZM0ZIvWewfDz DpGJFg==
;; Received 865 bytes from 192.58.128.30#53(j.root-servers.net) in 68 ms

Na última linha conseguimos saber quem nos deu essa resposta: ;; Received 865 bytes from 192.58.128.30#53(j.root-servers.net) in 68 ms.

No terceiro bloco podemos ver quem são os servidores que respondem pelo domínio 200.in-addr.arpa., essa resposta nos foi dada por um dos servidores responsáveis pelo domínio in-addr.arpa.. Também temos os registros DS e RRSIG para validação do DNSSEC.

in-addr.arpa.   86400   IN  NS  lacnic.authdns.ripe.net.
in-addr.arpa.   86400   IN  NS  a.arpa.dns.br.
in-addr.arpa.   86400   IN  NS  a.lactld.org.
in-addr.arpa.   86400   IN  NS  ns3.afrinic.net.
in-addr.arpa.   86400   IN  NS  ns.lacnic.net.
in-addr.arpa.   86400   IN  NS  ns2.lacnic.net.
in-addr.arpa.   86400   IN  NS  ns4.apnic.net.
in-addr.arpa.   86400   IN  NS  rirns.arin.net.
in-addr.arpa.   86400   IN  DS  16591 8 2 99BF764655E51E2341F9E320F6E2D03CAF216E3DE611615B8F2F20EA 93AF4C78
in-addr.arpa.   86400   IN  RRSIG   DS 8 3 86400 20230625044041 20230603213001 48561 in-addr.arpa. EkiRoZ6UDNRhu5P7J6UbGjb0H/z1Chbiy2JHfrlWbz8opACOz9ONSanv GzmJIeJv0/IKlANZ7aR6TUD0VxbavH2vw38XD3Erh3rLU5jxMl+PBHVh bb3UXDsDd1ClORqxOpFDpUtJLsKTlD0vYIxUSpFZvToH8ymrTciw1AL/ tA8=
;; Received 536 bytes from 200.10.60.53#53(d.in-addr-servers.arpa) in 12 ms

Na última linha conseguimos saber quem nos deu essa resposta: ;; Received 536 bytes from 200.10.60.53#53(d.in-addr-servers.arpa) in 12 ms.

No quarto bloco podemos ver quem são os servidores que respondem pelo domínio 4.160.200.in-addr.arpa., essa resposta nos foi dada por um dos servidores responsáveis pelo domínio 200.in-addr.arpa.. Também temos os registros DS e RRSIG para validação do DNSSEC.

160.200.in-addr.arpa. 86400   IN  NS  B.DNS.BR.
160.200.in-addr.arpa. 86400   IN  NS  D.DNS.BR.
160.200.in-addr.arpa. 86400   IN  NS  C.DNS.BR.
160.200.in-addr.arpa. 86400   IN  NS  A.DNS.BR.
160.200.in-addr.arpa. 86400   IN  NS  E.DNS.BR.
160.200.in-addr.arpa. 86400   IN  DS  18509 13 2 6603EBCDD03A75F1C2A1FFFBA364F3BCD5B74F818CAC1F5D9DD8F1DA 8C490BB6
160.200.in-addr.arpa. 86400   IN  RRSIG   DS 8 5 86400 20230701200947 20230601200820 17484 200.in-addr.arpa. yBrE9y0J1HnlDqdhcXyK30m6XjfxY2H9KHzuM//MJIY8yd8g/n7mu5fz 4RhvIoNKguCRcTyCvIBaUJmfnNzd/GjFImklC9MUo4/mbi6aMTtARS27 GGWAoP5IWnxJiHlx68+Fryy6KOZF1Rr6u3bhifoHXg5HlQ7lSIIKqHR/ DIUjW08pKs7jEtB9921cHAbOwi1Gx7lkO02SzAsiBwg5AFL8kQIXd/YN XVBd/83hrKCRNBX/1ObXYuWs2n+H2kfWrZF0ubJI7XKnhev0T17TIJkd SKiAKRv+NsDQm2TKKuGtZsS2tb1GyYDsH+Qbx7dvRL9S1O7iaaP633/3 8kl14g==
;; Received 519 bytes from 199.253.249.53#53(rirns.arin.net) in 180 ms

Na última linha conseguimos saber quem nos deu essa resposta: ;; Received 519 bytes from 199.253.249.53#53(rirns.arin.net) in 180 ms.

No qui to e último bloco podemos descobrir o RR PTR para o endereço IP consultado, nessa etapa já temos o nome de domínio completo que compõe o endereço reverso 4.160.200.in-addr.arpa., também temos o registro RRSIG para validação do DNSSEC.

6.4.160.200.in-addr.arpa. 86400 IN  PTR nic.br.
6.4.160.200.in-addr.arpa. 86400 IN  RRSIG   PTR 13 6 86400 20230709143441 20230430135616 18509 4.160.200.in-addr.arpa. uZVXvQ1Qv8JjNWLJSbbS7oWzpWF/F6thFKg0ElYDTQ6OBuLx//OgvTod KeqUO/UyZfX+GCW4fmGbzEIAccjF1A==
;; Received 219 bytes from 200.219.148.10#53(A.DNS.BR) in 8 ms

Na última linha conseguimos saber quem nos deu essa resposta: ;; Received 219 bytes from 200.219.148.10#53(A.DNS.BR) in 8 ms.

RFC 2317 e RFC 4189

A principal diferença entre a RFC 2317 e a RFC 4183 está na forma como tratam a delegação de DNS reverso para blocos menores de endereços IP (como /25, /26 e etc).

RFC 2317
Especifica a delegação IN-ADDR.ARPA sem classes, uma série de registros PTR enumerando as sub-redes de uma determinada rede na notação CIDR devem ser usados na delegação. Além do CIDR, deve-se usar registros CNAME para redirecionar a resolução para outra zona. Isso mantém o formato de nome de domínio tradicional. Exemplo:
```
# Delegando DNS Reverso para 192.0.2.0/25:
$ORIGIN 2.0.192.in-addr.arpa.
0/25            NS      ns.A.domain.
;
1               CNAME   1.0/25.2.0.192.in-addr.arpa.
2               CNAME   2.0/25.2.0.192.in-addr.arpa.
3               CNAME   3.0/25.2.0.192.in-addr.arpa.

$ORIGIN 0/25.2.0.192.in-addr.arpa.
@       IN      SOA     ns.A.domain. hostmaster.A.domain. (...)
@               NS      ns.A.domain.
@               NS      some.other.name.server.
```
Para cada bloco delegado há a necessidade de se criar registros CNAME na zona pai. Esses registros CNAME é quem vão realmente redirecionar a consulta para o servidor DNS que irá responder por essa zona. Além disso, como criamos um CNAME que não existe, temos que criar uma delegação para ele, para que possa ser resolvido corretamente.
RFC 4183
A RFC 1101 foi uma tentativa inicial de abordar o problema de representar e delegar sub-redes IP em zonas DNS. Um dos problemas apresentados é o fato de não suportar máscaras de sub-rede de comprimento variável, que são comumente implantadas na Internet. A RFC 4183 propõe uma abordagem alternativa baseada em DNS para lidar com sub-redes e máscaras de sub-rede de comprimento variável, o que pode ser visto como uma solução para algumas das limitações práticas da RFC 2317.

Além de propor um método alternativo ao da RFC 2317 para lidar com sub-redes no DNS, especialmente em relação a máscaras de sub-rede de comprimento variável. A principal diferença é o uso de um hífen (-) em vez de uma barra (/) para delimitar o intervalo de endereços de uma sub-rede.

A delegação proposta nesta RFC é bastante complexa, por isso, recomendo a leitura completa para uma melhor compreensão dos detalhes e implicações.

RTT - Round-Trip Time

O RTT é o tempo necessário para que uma consulta DNS seja enviada a um servidor de DNS e a resposta seja recebida de volta. O BIND e outros servidores de DNS podem levar em consideração o RTT para otimizar o desempenho e a eficiência das consultas DNS. O RTT é usado pelo BIND em casos onde vários servidores DNS estão disponíveis, como os Root-Servers ou gTLDs.

O BIND usa o RTT como uma métrica de algoritmo para distribuir a carga de forma equilibrada e garantir o resultado mais rápido possível. Ele registra o tempo de resposta às consultas de cada servidor de nomes e utiliza essas informações para tomar decisões sobre o redirecionamento de consultas e melhorar o desempenho do sistema de nomes de domínio.

Quando uma lista de servidores de nomes é fornecida inicialmente em uma referência (Após uma consulta), cada servidor de nomes tem um RTT (tempo de ida e volta) de zero, ou seja, ainda não há informações sobre o tempo de resposta. Nesse caso, o BIND acessará cada servidor DNS em uma ordem circular (round-robin), no fim um valor de RTT estará disponível para cada servidor de nomes.

Após essa etapa inicial, o BIND selecionará o servidor de nomes com o menor RTT e continuará utilizando-o até que seu RTT ultrapasse o RTT de um dos outros servidores de nomes. Nesse momento, o servidor de nomes com o menor RTT se tornará a escolha preferencial.

Load Balancing

O load balancing ou balanceamento de carga, é um conceito utilizado em sistemas de computação para distribuir de forma equilibrada o trabalho entre vários recursos disponíveis. Esses recursos podem ser servidores, computadores, dispositivos de rede ou até mesmo processos em um único computador. Imagine que você tem um site popular que recebe milhares de solicitações de usuários simultaneamente. Para lidar com essa demanda, você pode ter vários servidores que hospedam o site. O load balancing entra em cena para garantir que todas as solicitações sejam distribuídas de maneira uniforme entre esses servidores.

Existem diferentes algoritmos de balanceamento de carga que determinam como as solicitações são distribuídas. Alguns algoritmos podem levar em consideração a capacidade de processamento de cada servidor, enquanto outros podem usar informações sobre a carga atual de cada servidor. O objetivo principal é garantir que cada recurso seja utilizado de maneira equilibrada, evitando gargalos e mantendo a disponibilidade e a capacidade de resposta do sistema. Também é possível ter esse mesmo efeito usando o DNS.

Como já você verá mais para frente (veja aqui) é possível fazer Load Balance com servidores de e-mail caso apliquemos o mesmo valor no campo preference para todos os RR MX no servidor DNS, caso o valor de preference seja diferente, o comportamento será um servidor primário (ativo) e outro secundário (backup).

Também é possível ter esse mesmo efeito em qualquer RR do tipo A, mesmo não possuindo o campo preference. O servidor DNS entregará os A RRs na ordem definida pela instrução rrset-order e cujo padrão é a ordem round-robin ou cíclica.

O balanceamento de carga do DNS não pode contabilizar o carregamento do serviço, por exemplo, certas transações podem gerar cargas muito altas de CPU e/ou recursos. Para este tipo de controle é necessário um balanceador de carga especializado que meça os tempos de resposta das transações de cada servidor e que possa contabilizar o nível de consumo de recursos.

Balanceando Serviços

O registro SRV fornece balanceamento de carga usando um campo de prioridade e um campo de peso para controle, além de fornecer capacidade de failover. O SRV RR ainda não é amplamente usado mas já é suportado por alguns serviços, mas não todos. Os serviços que mais suportam o SRV RR são: Lightweight Directory Access Protocol (LDAP) e o Protocolo de Iniciação de Sessão (SIP) usado em VoIP. Para mais detalhes sobre o registro SRV cosulte aqui.

RRset Order

Versões posteriores do BIND 9.4 introduziram uma funcionalidade chamada rrset-order, que permite controlar a ordem de retorno de conjuntos de registros (RRsets) de qualquer tipo. Um RRset (conjunto de registros de recursos) consiste em vários registros de recursos relacionados a um domínio específico no sistema de nomes de domínio. Por exemplo, quando você digita "exemplo.com.br" em seu navegador, o DNS consulta o RRset associado a esse domínio, o que resulta em um conjunto de registros sendo retornados, e não apenas um único registro. Os tipos de registros que podem ser retornados mas não se limite apenas a esses incluem: registros A, registros AAAA, registros MX, registros CNAME, entre outros, todos dentro de uma única resposta do servidor DNS.

A instrução rrset-order aceita vários argumentos:

cíclico
Segue a ordem definida no arquivo de zona e usa o esquema round-robin para cada consulta subsequente (esse é o comportamento padrão).
aleatório
Ordena aleatoriamente as respostas para cada consulta.

É importante ressaltar que a instrução rrset-order só pode ser utilizada na cláusula de opções globais do BIND, mas também pode receber argumentos adicionais para torná-la aplicável a uma ou mais zonas.

Cliente DNS

A principal configuração para o cliente DNS fica no arquivo /etc/resolv.conf, dentro desse arquivo ficam as definições de quem serão os servidores DNS que o cliente vai usar. Por padrão qualquer aplicação que necessite consultar um servidor DNS, vai obter os servidores a partir desse arquivo, não importando se o sistema é um desktop ou servidor. Existe certas aplicações que mudam o comportamento padrão desse arquivo, estou falando de usar um resolver DNS que faz a intermediação das consultas DNS para as aplicações locais, principalmente ao usar o daemon Systemd-resolved.

Os testes foram realizados usando Ubuntu 20.04 LTS.

Systemd-Resolved

O systemd-resolved é um daemon que fornece um Serviço de Resolução de Nomes (DNS) para aplicações locais, com ele podemos ter cache DNS, DNSSEC e muitas outras vantagens. Esse daemon também é conhecido como resolver porque quando o usamos, não é a aplicação solicitante que vai até o servidor DNS realizar a consulta, é esse daemon que vai até o servidor DNS, então ele faz a consulta e retorna o resultado para a aplicação solicitante, veja o esquema abaixo para facilitar a compreensão.

dns

A foto na esquerda representa um sistema com o systemd-resolved instalado e configurado para usar ele, já a foto que está na direita representa um sistema que não usa nenhum sistema para intermediar a comunicação com os servidores DNS, nesse caso o próprio Firefox é o resolver.

Os servidores DNS que serão usados para consulta são determinados a partir das configurações globais em /etc/systemd/resolved.conf, além desse arquivo existem outros que também são consultados, o uso de cada arquivo varia de acordo com o daemon usado para fazer a configuração de Rede, normalmente o systemd-resolved funciona com a maioria dos daemons de Rede para conseguir fornecer um serviço de DNS, mas aqui vou mencionar dois que são os mais comuns de usos em Desktops e Servidores, são eles: SystemD-NetworkD e NetworkManager.

Além do arquivo mencionado acima, é consultado o arquivo /etc/resolv.conf para descobrir mais servidores DNS, mas somente se esse arquivo não for um link simbólico para /run/systemd/resolve/stub-resolv.conf, /usr/lib/systemd/resolv.conf ou /run/systemd/resolve/resolv.conf, caso ele seja, o arquivo /etc/resolv.conf será ignorado quanto ao obter servidores DNS que estiverem dentro dele.

Esse processo acontece porque se /etc/resolv.conf for um link simbólico para /run/systemd/resolve/stub-resolv.conf ou para /usr/lib/systemd/resolv.conf isso configura o sistema para usar o resolver systemd-resolved na porta 53 do IP 127.0.0.53 e se ele apontar para /run/systemd/resolve/resolv.conf, ele vai ignorar o uso do resolver systemd-resolved como um serviço intermediário e passa a fazer as consultas DNS diretamente com os servidores DNS.

resolv.conf e stub-resolv.conf

Como é um pouco confuso, resolvi deixar mais explicito a diferença entre os arquivo /run/systemd/resolve/stub-resolv.conf e /run/systemd/resolve/resolv.conf. Lembrando que ambos são usados para manter a compatibilidade com programas Linux tradicionais e um deles sempre será um link simbólico para /etc/resolv.conf.

/run/systemd/resolve/stub-resolv.conf
Esse arquivo contém uma configuração que informa para o sistema que o servidor DNS é o 127.0.0.53, isso automaticamente faz com que qualquer aplicação que vá usar o DNS use o serviço do systemd-resolved, basicamente é isso que esse arquivo faz. As consultas são sempre recursivas.
/run/systemd/resolve/resolv.conf
Nesse arquivo contém informações sobre todos os servidores DNS conhecidos, com isso quero dizer, nesse arquivo ficam todos os servidores DNS que foram obtidos de alguma forma, seja via DHCP ou via configuração estática em algum arquivo. Com isso passamos a ignorar o systemd-resolved já que as aplicações conversam diretamente com os servidores DNS e por isso cria-se uma limitação ao usar esse arquivo.
Essa limitação acontece porque ao usar servidores DNS diretamente, as interfaces não conhecem o conceito de servidores DNS por interface e, portanto, contém apenas definições de servidor DNS em todo o sistema, ou seja, todas as interfaces vão usar o mesmo servidor DNS, para sistemas de servidores isso é até um requisito em 99% dos casos, mas para sistemas de Desktop isso pode impactar quanto ao uso de aplicações via VPN.

Para ver qual resolver está usando (se é que está) podemos usar o comando abaixo:

$ sudo lsof -i :53 -S
COMMAND   PID            USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
systemd-r 512 systemd-resolve   12u  IPv4  21648      0t0  UDP localhost:domain 
systemd-r 512 systemd-resolve   13u  IPv4  21651      0t0  TCP localhost:domain (LISTEN)

# Outra forma:
$ sudo ss -lp -i sport 53
Netid   State    Recv-Q    Send-Q       Local Address:Port         Peer Address:Port   Process                                      
udp     UNCONN   0         0            127.0.0.53%lo:domain            0.0.0.0:*       users:(("systemd-resolve",pid=512,fd=12))   
tcp     LISTEN   0         4096         127.0.0.53%lo:domain            0.0.0.0:*       users:(("systemd-resolve",pid=512,fd=13))
     cubic cwnd:10

Caso não apareça nada, provavelmente você não possui um resolver e está fazendo as consultas diretamente nos servidores DNS.

Systemd-networkd

O Systemd-networkd é um serviço do Sistema Operacional Linux usado para gerenciar Redes, ele detecta e configura dispositivos de Rede quando eles aparecem para ele. Normalmente esse serviço é instalado em ambientes que usem SystemD e em sistemas servidores, ou seja, não notei o uso desse serviço em Sistemas de Desktops (para uso de clientes finais), esse serviço é encontrado quando aplicamos pacotes de Desktop num ambiente Servidor, fazendo a conversão do sistema Servidor para Desktop.

Lembrando que usei o Ubuntu Server e Desktop para os testes.
Como curiosidade o principal daemon do NetworkD é systemd-networkd.service.

Os arquivos contendo a configuração de Rede, incluindo os servidores DNS podem ficar em: /run/systemd/network/* e /etc/systemd/network/*, dando maior prioridade para primeiro diretório. Esses mesmos diretórios são usados pelo daemon do systemd-resolved para obter os servidores DNS, criando-se assim uma compatibilidade direta entre esses daemons (já que todos são pertencentes ao SystemD).

Por padrão o Ubuntu Server vem com o Systemd-resolved e o Systemd-networkd instalados e configurados, na maioria dos casos acho bom remover o Systemd-resolved e usar somente o NetworkD já que com o Systemd-resolved ele acaba fazendo cache das consultas DNS e muitas vezes por ser um servidor precisamos da resultado mais recente possível para uma determinada consulta. Outro detalhe que vale a pena mencionar é que o NetworkD não sobrescreve o que está em /etc/resolv.conf caso você remova o link simbólico e crie um arquivo estático.

Network-Manager

O Network-Manager é um serviço do Sistema Operacional Linux usado para gerenciar Redes assim como o Systemd-networkd, diferente do NetworkD o Network-Manager possui funções e utilitários que fazem muito mais, seu arquivo de configuração principal fica em /etc/NetworkManager/NetworkManager.conf e as informações de Rede, principalmente sobre conexões Wifi ficam em /etc/NetworkManager/system-connections/, já as informações sobre interfaces virtuais e rede cabeada ficam em /run/NetworkManager/system-connections/.

Além dos arquivos mencionados acima ainda temos alguns arquivos para armazenar informações de DNS como o /run/NetworkManager/no-stub-resolv.conf (esse arquivo se assemelha ao /run/systemd/resolve/resolv.conf) e outro arquivo é o /run/NetworkManager/resolv.conf (esse arquivo se assemelha ao /run/systemd/resolve/stub-resolv.conf).

Por padrão no Ubuntu Desktop o Network Manager funciona em conjunto com o Systemd-Resolved, mesmo que não tenha conseguido visualizar explicitamente essa configuração nos arquivos, mas esse comportamento pode ser mudado. A documentação do network manager informa que existem 3 modos de processos para trabalhar com DNS, são eles:

dns=default
O NetworkManager sempre vai atualizar o arquivo /etc/resolv.conf, mesmo quando ele for um arquivo estático, e nesse modo de operação, servidores DNS de todas as conexões são adicionadas ao /etc/resolv.conf e os search domains também são.
dns=systemd-resolved e dns=dnsmasq
O NetworkManager sempre vai atualizar o arquivo /etc/resolv.conf, mesmo quando ele for um arquivo estático, remover o link simbólico que aponta para os arquivos do Systemd-Resolved não surte efeito como acontece com o NetworkD, o Network Manager vai sobrescrever o conteúdo do /etc/resolv.conf fazendo com que a configuração de DNS aponte para o IP 127.0.0.53 (é exatamente o mesmo conteúdo de /run/systemd/resolve/stub-resolv.conf), isso acontece porque ele está configurado para usar dnsmasq ou systemd-resolved.

Ambas as configurações usam servidores de DNS divididos, isso quer dizer que, o uso de servidores DNS será fornecido pela conexão somente quando o domínio consultado combinar com o domínio associado a conexão. Veja a imagem abaixo para entender melhor o fluxo.
A imagem mostra que sempre será usado o DNS da interface que combina com o domínio associado a interface, mas e quando o domínio não estiver presente em nenhuma interface? Nesses casos é usado a conexão que tem o search domain igual a ~, por exemplo:
```
# No caso do systemd-resolved:
$ resolvectl -i enxa44cc8f1a2d9
Link 2 (enxa44cc8f1a2d9)
      Current Scopes: DNS        
DefaultRoute setting: yes        
       LLMNR setting: yes        
MulticastDNS setting: no         
  DNSOverTLS setting: no         
      DNSSEC setting: no         
    DNSSEC supported: no         
  Current DNS Server: 192.168.1.1
         DNS Servers: 192.168.1.1
          DNS Domain: ~.         
                      lan

$ resolvectl -i enxa44cc8f1a2d9 domain
Link 2 (enxa44cc8f1a2d9): ~. lan
```
Para desligar esse efeito do Network Manager sobrescrever o arquivo /etc/resolv.conf independente do modo de operação, faça a configuração abaixo:
```
$ sudo vim /etc/NetworkManager/NetworkManager.conf

## Adicione as opções abaixo dentro da sessão [main]:
dns=none
rc-manager=unmanaged
```
none = NetworkManager não vai modificar /etc/resolv.conf. Isto implica em rc-manager = unmanaged.

A opção rc-manager configura o modo de gerenciamento do /etc/resolv.conf, já o modo unmanaged informa para não mexer no arquivo /etc/resolv.conf.

Vejamos um exemplo de cada arquivo, começando com o resolv.conf

$ cat /etc/resolv.conf 
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad

Debian 11

Fiz um teste com Debian 11, ele não possui Network Manager e nem NetworkD, nesse sistema temos o IfUpDown e apesar da configuração de DNS informar que existe System-resolved eu não o achei instalado por padrão, vale ressaltar que usei uma máquina com uso do Vagrant e pode ter sido alterada.

# Verificando se tenho systemd-resolved:
vagrant@debian11:~$ sudo systemctl is-active systemd-resolved
inactive

# Verificando se tenho systemd-networkd:
vagrant@debian11:~$ sudo systemctl is-active systemd-networkd
inactive

# Verificando se tenho natwork manager:
vagrant@debian11:~$ sudo systemctl is-active NetworkManager
inactive

# Verificando se tenho o IfUpDown:
vagrant@debian11:~$ sudo systemctl is-active networking
active

vagrant@debian11:~$ dpkg -l ifupdown
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version      Architecture Description
+++-==============-============-============-================================================
ii  ifupdown       0.8.36       amd64        high level tools to configure network interfaces


# Ao consultar o resolv.conf é informado que existe systemd-resolved:
vagrant@debian11:~$ cat /etc/resolv.conf 
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "resolvectl status" to see details about the actual nameservers.

nameserver 8.8.8.8
nameserver 192.168.121.1

Novamente, esse sistema pode ter sido alterado antes de ter sido disponibilizado para o Vagrant Cloud.

Resolv.conf

Agora, tendo o conhecimento de toda essa estrutura que pode e vai mudar o funcionamento do /etc/resolv.conf, vamos ver como funciona esse arquivo num ambiente onde ele não seja influenciado por mais nada além de alguém que vá editar ele (sem resolver intermediário e sem conceito de DNS por interface).

Segue uma tabela com as opções que podemos usar:

Opção	Descrição
domain (domínio)	Fornece um domínio.
search (domain1) (domain2)	Fornece os domínios para associar a interface e usar aquele DNS para uma consulta DNS para um daqueles domínios. Além de não precisa ficar colocando sempre o domínio no nome do Host, será testado todos os domínios até achar o correto. Ex: search eng.br Agora pingue: `ping www.sysnetbr`

Veja um exemplo desse arquivo:

$ cat /etc/resolv.conf 

nameserver 8.8.8.8
search eng.br

/etc/hosts

Era um arquivo usado antes do protocolo DNS, ele fornece resolução de nomes para as aplicações locais, normalmente ele é consultado primeiro e depois é consultado o DNS, mas isso pode mudar de acordo com a configuração do /etc/nsswitch.conf.

Veja um exemplo desse arquivo:

$ cat /etc/hosts
127.0.0.1   localhost

192.168.1.28    keygen.ddns.net
192.168.121.186 www.empresa.com.br
2000:0db8:0:::dddd foo.bar.com

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

/etc/network

Esse arquivo é usado para dar nome as redes.

$ cat /etc/networks
# symbolic names for networks, see networks(5) for more information
link-local 169.254.0.0

Fontes

https://nlnetlabs.nl/projects/nsd/about/

https://nlnetlabs.nl/projects/unbound/about/

https://regional.forum.ix.br/files/apresentacao/arquivo/313/ICANN%20IX%20Forum%20SC.pdf

https://www.cloudflare.com/pt-br/learning/dns/glossary/what-is-a-domain-name-registrar/

https://registro.br/rdap/

https://ftp.registro.br/pub/doc/tutorial-dnssec.pdf

https://registro.br/tecnologia/provedores-de-hospedagem/dnsshim/

https://registro.br/tecnologia/dnssec/root-anchor/

https://bind9.readthedocs.io/en/v9.18.14

https://bind9.readthedocs.io/en/latest/

https://kb.isc.org/docs

https://www.cloudflare.com/pt-br/dns/dnssec/how-dnssec-works/

https://ftp.registro.br/pub/doc/configuracao_dnssec_dominio.pdf

https://nsrc.org/activities/agendas/en/dnssec-3-days/dns/materials/labs/en/dnssec-bind-manual-ksk-rollover.html

https://www.rfc-editor.org/rfc/rfc6781

https://www.rfc-editor.org/rfc/rfc4034

https://www.rfc-editor.org/rfc/rfc4035

https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities

https://www.infoblox.com/dns-security-resource-center/dns-security-faq/what-is-dane/

https://weberblog.net/how-to-use-danetlsa/

https://www.antispam.br/admin/spf/

https://www.locaweb.com.br/ajuda/wiki/spf/

https://www.collegenote.net/curriculum/internet-technology-csit/37/161/

https://bind9.readthedocs.io/en/v9.18.1/advanced.html#tsig

DNS - Domain Name System​

Um pouco de história​

Softwares de DNS​

O Namespace​

Top Level Domain - TLD​

Estrutura de DNS no Mundo​

ICANN - Internet Corporation for Assigned Names and Numbers​

KSK Rollover​

IANA - Internet Assigned Numbers Authority​

Delegation Record​

Relação entre ICANN e IANA​

RIR - Regional Internet Registry​

LACNIC - Latin American and Caribbean Internet Addresses Registry​

RIPE NCC - Réseaux IP Européens Network Coordination Centre​

ARIN - American Registry for Internet Numbers​

APNIC - Asia-Pacific Network Information Centre​

AFRINIC - African Network Information Centre​

NIR - National Internet Registry​

LIR - Local Internet Registry​

Registry ccTLDs​

Registrars​

Regional ccTLD organizations​

LACTLD - Latin American and Caribbean Top Level Domains Organization​

Buscador LACTLD​

LACTLD Anycast Cloud​

O que é Anycast?​

CENTR - Council of European National Top-Level Domain Registries​

APTLD - Asia Pacific Top Level Domain Association​

AFTLD - Africa Top Level Domains Organization​

CIRA - Canadian Internet Registration Authority​

Registry Services, LLC​

ccNSO - Country Code Names Supporting Organization​

Outras Organizações​

DNS-OARC - DNS Operations, Analysis, and Research Center​

ISOC - Internet Society​

PIR - Public Interest Registry​

Introdução ao DNS​

O Protocolo DNS​

Domain Namespace Zones​

Root Servers​

Name Servers (NS)​

DNS Recursivo​

DNS Master​

DNS Slave​

DNS de Forward​

DNS Hidden Master​

DNS Resolver​

Delegação de subdomínios​

Introdução aos Tipos de TLDs​

generic Top-Level Domains - gTLDs​

country code Top Level Domain - ccTLD​

Second-Level Domains - SLDs​

Domínios de Terceiro Nível e abaixo​

Sponsored TLDs - sTLDs​

Consulta recursiva e iterativa​

FQDN​

PDQN​

Tipos de zonas​

Replicação de Zona​

Protocolo AXFR​

Protocolo IXFR​

NOTIFY​

Dynamic Update​

Alternativas de DDNS​

DNS Reverso​

Delegação de DNS Reverso​

Problemas na Delegação de Blocos CIDR Subdivididos​

RTT - Round-Trip Time​

Load Balancing​

Balanceando Serviços​

RRset Order​

Cliente DNS​

Systemd-Resolved​

resolv.conf e stub-resolv.conf​

Systemd-networkd​

Network-Manager​

Debian 11​

Resolv.conf​

/etc/hosts​

/etc/network​