Resolução de Nomes: DNS na Era da Nuvem

Os quatro artigos anteriores construíram o caminho até uma máquina. Nenhum deles perguntou como descobrimos qual máquina deve receber uma requisição.

A pergunta parece administrativa, mas não é. O sistema que a responde opera continuamente desde 1987 e atravessa fronteiras administrativas, provedores e continentes. Essa distribuição permite que partes inteiras falhem sem apagar todo o espaço de nomes. Porém, ela também introduz dependências capazes de fazer uma aplicação saudável parecer indisponível. As duas propriedades nascem do mesmo mecanismo: o DNS aceita respostas temporariamente antigas para continuar respondendo e expressa esse compromisso em um número que quase ninguém revisa.

O número tem nome, TTL, e este artigo é em boa parte sobre a aritmética dele. Vamos calcular a taxa de acerto do cache, o tempo esperado para uma mudança se propagar, a carga que uma redução de TTL despeja sobre a infraestrutura autoritativa e, principalmente, quanto tempo um serviço pode continuar indisponível depois que a verificação de saúde já detectou o problema.

Continuamos com a régua do Artigo 1: $\text{RTT}=76,65$ ms entre São Paulo e Ashburn quando precisarmos de uma rota longa. O piso físico da Tabela 2 daquele artigo continua sendo o critério para rejeitar qualquer afirmação impossível sobre latência.

1. A hierarquia e a delegação

O espaço de nomes do DNS é uma árvore invertida. A raiz, escrita como um ponto solitário, tem filhos que são os domínios de topo, como com, org e br. Esses domínios têm filhos registrados, como example.com, e a árvore prossegue até nomes mais específicos. Um nome de domínio plenamente qualificado, ou FQDN, de Fully Qualified Domain Name, identifica o caminho completo até a raiz. Em www.example.com., lemos a especificidade da esquerda para a direita e a hierarquia da direita para a esquerda: www pertence a example, que pertence a com, que pertence à raiz. O ponto final representa essa raiz e faz parte do nome absoluto, embora interfaces quase sempre o omitam.

O que faz o sistema escalar não é apenas a árvore. É a delegação. Nenhum servidor conhece todos os nomes. Os servidores raiz sabem quais servidores respondem por cada domínio de topodomínio de topo. Os servidores de com, por sua vez, sabem quais servidores respondem por cada zona delegada abaixo deles. O servidor autoritativo de example.com é quem finalmente publica os conjuntos de registros daquela zona. Cada nível conhece o próximo, não o destino inteiro. Em 12 de setembro de 2026, os treze identificadores de servidores raiz correspondiam a $2045$ instâncias operacionais, mantidas por doze operadores independentes. O número de identificadores é pequeno. A implantação física não é.

Há três papéis que a leitora precisa separar, porque confundi-los produz diagnósticos errados a vida inteira.

O servidor autoritativo publica os dados de uma zona. Ele responde com autoridade sobre os nomes dessa zona e fornece delegações para zonas filhas. Não percorre a árvore em nome do cliente.

O resolvedor recursivo procura a resposta. Ele recebe a consulta do cliente, percorre a hierarquia, guarda em cache o que aprendeu e devolve o resultado. Pode ser o resolvedor do provedor de acesso, um serviço público configurado pela leitora ou um resolvedor interno de um cluster Kubernetes, que o Artigo 14 retomará.

O resolvedor cliente, chamado stub resolver nas especificações, é a biblioteca do sistema operacional que recebe o pedido da aplicação e o encaminha ao resolvedor recursivo. Ele costuma executar pouca lógica, mas seu cache e sua política local ainda alteram o tempo observado pela aplicação.

Três papéis, três responsabilidades

O autoritativo publica os dados de uma zona. Ele responde com autoridade sobre os nomes que administra e delega zonas filhas. Não percorre a árvore em nome de ninguém.

O recursivo percorre a árvore em nome do cliente. Pergunta à raiz, ao domínio de topo, ao autoritativo. Guarda o que aprendeu em cache e é ele que paga o custo de uma resolução fria.

O cliente (stub resolver) é a biblioteca do sistema operacional que recebe o pedido da aplicação e o encaminha ao recursivo. Ele também tem cache, e esse cache pode alterar o tempo que a aplicação observa.

Quando alguém diz que o DNS não resolve, quase sempre o recursivo não conseguiu responder. Quando diz que o DNS está errado, quase sempre o autoritativo publica um valor que não é o esperado. Quando diz que o DNS está lento, quase sempre o cliente pagou o custo de uma resolução fria. Separar os três é o primeiro passo do diagnóstico.