Com O Crescimento Da Internet Foi Necessario Criar Um Sistema

Como funcionava antes de existir algo melhor

No início dos anos 80, se você queria acessar um computador na rede, precisava saber o endereço IP dele. E havia um arquivo chamado HOSTS.TXT que mapeava nomes para IPs. A Internet Assigned Numbers Authority mantinha esse arquivo e todo mundo baixava ele quando precisava. Funcionou por um tempo. O problema apareceu quando a rede saiu dos laboratórios militares e universidades. Milhares de novas máquinas começavam a aparecer todo mês. O arquivo Hosts crescia. E crescia rápido. Em 1983, já tinha uns poucos milhares de entradas. Para 1984, o número estava fora de controle. Ninguém conseguia manter o arquivo atualizado manualmente. Atualizações chegavam com semanas de atraso. Nomes duplicados causavam conflitos. Era uma bagunça logística.

com o crescimento da internet foi necessario criar um sistema

O sistema que resolveram criar foi o DNS, o Domain Name System. A ideia era simples em teoria: em vez de todo mundo carregar uma cópia completa do catálogo de endereços, haveria servidores especializados que respondem perguntas sobre nomes. Cada dono de domínio cuida do próprio registro. A consulta é feita sob demanda.

Paul Mockapetris escreveu as especificações originais. O RFC 882 e o 883 apareceram em novembro de 1983. O primeiro servidor DNS rodou no mesmo ano. A mudança do arquivo Hosts para o DNS foi oficialmente feita em 1º de janeiro de 1984. Sistemas antigos que não suportavam DNS simplesmente não conseguiam mais se conectar à rede principal depois dessa data. Isso foi um choque para quem não estava preparado.

Como o DNS funciona na prática

Quando você digita um endereço no navegador, seu computador envia uma consulta UDP para um servidor DNS. Esse servidor procura o registro correspondente. Se ele souber a resposta, devolve o IP. Se não souber, repassa a pergunta para outro servidor até chegar no autoridade certa. O processo geralmente leva de 10 a 50 milissegundos em condições normais. Pode levar segundos se houver problemas de rede ou cache vazio. Os registros mais comuns que você vai encontrar são o A, que aponta para um IPv4. O AAAA, que faz o mesmo para IPv6. O CNAME, que cria um apelido para outro nome. O MX, que diz qual servidor recebe e-mail do domínio. E o TXT, que serve para coisas variadas como verificação de domínio e políticas de segurança.

A hierarquia funciona assim: servidores raiz conhecem os registradores de todos os TLDs. Os servidores do .com, .br, .org sabem quais são os.ns de cada domínio registrado. Quando você configura um domínio, o registrador inscreve os servidores ns que você escolheu. A partir daí, qualquer consultor no mundo pode encontrar o caminho até seus registros.

Problema real que eu enfrentei e como resolvi

Em 2019, migrei o tráfego de um domínio principal para um novo provedor de hospedagem. Configurei todos os registros nos servidores ns do novo lugar. Na teoria, a propagação levaria algumas horas. Na prática, alguns usuários da América do Sul continuavam caindo no servidor antigo por mais de 48 horas. O problema era que os resolveidores ISP deles tinham cache extremamente agressivo, ignorando o TTL que eu tinha definido como 300 segundos. A solução foi reduzir o TTL para 60 segundos dois dias antes da migração, fazer a troca dos registros nos servidores ns, e depois configurar uma regra de NAT no firewall do servidor antigo redirecionando todas as requisições para o novo. Assim, mesmo quem ainda consultava o servidor velho era redirecionado corretamente. Sem essa workaround, eu teria perdido acesso de usuários corporativos que usam DNS cacheado dos provedores de banda larga locais.

O que ninguém te conta sobre DNS

O DNS não é confiável por padrão. Consultas trafegam em UDP sem garantia de entrega. Um pacote perdido significa que a consulta precisa ser repetida. Resolução recursiva pode falhar silenciosamente. Você vê um erro de timeouts, mas não sabe se foi o resolver local, o servidor intermediário, ou o autoritativo. A camada de segurança do DNS veio tarde, com o DNSSEC, e ainda hoje poucos lugares o implementam de verdade.

Outra coisa que as pessoas subestimam é a importância do cache. O cache reduz a carga nos servidores raiz e de TLD. Mas cache mal configurado pode causar problemas de propagação que duram dias. Se você colocar um TTL alto demais em um registro que precisa mudar rápido, vai passar sufoco. TTL baixo demais gera tráfego desnecessário e pode sobrecarregar seu servidor authoritative. O DNS também é amplamente usado como vetor de ataque. DNS cache poisoning, amplification attacks, tunneling de dados. Muitos firewalls bloqueiam consultas DNS para portas diferentes da 53 sem motivo claro. Isso quebra soluções legítimas de load balancing geo-direcionado que usam portas alternativas. Vale saber antes de se deparar com isso no meio de uma crise.

Configurando um domínio básico

Vá até o painel do seu registrador. Procure a seção de DNS ou Nameservers. Anote os servidores ns que seu provedor de hospedagem passou. Se você usar serviços como Cloudflare, eles vão te dar dois ns próprios. Insira esses ns no registrador. A propagação leva de alguns minutos a algumas horas dependendo do registrador e do TLD.

Depois de propagação concluída, adicione os registros que seu serviço precisa. Um registro A apontando para o IP do servidor. Um registro MX se for usar e-mail. Um CNAME para subdomínios como www. Verifique se o TTL está entre 300 e 3600 segundos. Mais baixo para ambientes de teste. Mais alto para produção estável. Use ferramentas como dig, nslookup ou o dig web do FDN para testar. Execute uma consulta A e uma consulta MX. Confirme se a resposta vem do servidor correto. Cheque o TTL retornado. Se tudo bater, seu domínio está resolvendo corretamente.

Alternativas e limitações

O DNS tradicional tem falhas conhecidas. Não há criptografia nativa nas consultas. A maioria dos resolveidores open resolvem em texto puro. O DoH e o DoT surgiram para resolver isso, mas muitos provedores ainda não os adotaram completamente. Se privacidade for crítica, considere usar resolveidores que suportam essas extensões.

Em ambientes corporativos, a gestão manual de DNS escala mal. Mais de cem domínios com configurações espalhadas em múltiplos provedores vira uma dor de cabeça operacional. Ferramentas como DNSMadeEasy, AWS Route53 ou o Bind9 com zone editing automatizado ajudam. A automação com Terraform ou Ansible paraGerenciar zonas DNS reduziu o tempo de configuração de minutos por domínio para segundos em lote no meu caso. O DNS também não serve para tudo. Não é adequado para descoberta de serviços em tempo real em microsserviços. Para isso, soluções como Consul, etcd ou o CoreDNS com plugins específicos são mais apropriados. O DNS foi feito para mapear nomes para endereços, não para substituir um service mesh completo.

Dica prática sobre propagacao

Sempre teste a resolução DNS de múltiplos locais fora da sua rede. Um teste local pode mostrar que está tudo certo porque seu resolver já tem o registro em cache. Use o serviço do ViewDNS ou faça consultas diretas para resolveidores diferentes usando dig com o parâmetro @server. Se os resultados variam, a propagação ainda não terminou. Espere. Não altere os registros novamente nesse período, senão você reinicia o contador.

O DNS foi criado porque o sistema anterior colapsou sob o peso do crescimento. A arquitetura hierárquica e distribuída sobreviveu por décadas exatamente porque funciona bem sob carga. Ainda assim, entender como ele opera por baixo do capô evita muita dor de cabeça na hora que algo dá errado. E algo sempre dá errado.