O que e DNS?
E o sistema que converte nomes de dominio em enderecos IP, a agenda telefonica da internet.
DNS, ou Domain Name System, e o sistema distribuido que traduz nomes de dominio legíveis por humanos, como curitibablog.com.br, em enderecos IP numericos que os computadores usam para se comunicar, como 31.97.252.45. Sem o DNS, para acessar qualquer site você precisária memorizar enderecos IP em vez de nomes. O DNS funciona como uma agenda telefonica global e distribuida: você consulta o nome e recebe o número. Foi criado em 1983 por Paul Mockapetris para substituir um arquivo HOSTS.TXT centralizado que não escalária para a internet em crescimento. Hoje o DNS e uma infraestrutura crítica que resolve trilhões de consultas por dia, com uma hierarquia distribuida de servidores ao redor do mundo que garante disponibilidade e desempenho globais.
Como funciona a resolução DNS passo a passo
Uma requisição percorre até quatro tipos de servidores antes de retornar um IP.
Quando você digita curitibablog.com.br no browser, ocorre o seguinte: primeiro, o sistema operacional verifica o cache local e o arquivo /etc/hosts. Se não encontrar, consulta o resolver recursivo configurado no dispositivo (geralmente o do provedor de internet ou 8.8.8.8 do Google). O resolver consulta um root server (existem 13 grupos de root servers no mundo) que conhece os servidores de TLD. O root server retorna o servidor TLD responsável pelo .br. O resolver consulta o TLD server, que retorna o servidor autoritativo do dominio curitibablog.com.br. O resolver consulta o servidor autoritativo, que retorna o registro A com o IP. O resolver cacheia a resposta pelo TTL e a retorna ao dispositivo. Todo esse processo acontece em milissegundos e e transparente para o usuário.
Tipos de registros DNS
Cada tipo de registro tem uma função específica no ecossistema DNS.
O DNS suporta diferentes tipos de registros, cada um com proposito específico. Registro A mapeia um nome para um IPv4 (curitibablog.com.br → 31.97.252.45). Registro AAAA mapeia para IPv6. Registro CNAME cria um alias para outro nome (www.empresa.com → empresa.com), util para apontar subdomínios para CDN ou serviços externos. Registro MX define os servidores de email do dominio com prioridade. Registro TXT armazena texto livre e e usado para verificação de dominio (Google Search Console, Cloudflare), SPF (define quais servidores podem enviar email pelo dominio), DKIM (chave pública para autenticação de email) e DMARC (política de tratamento de emails não autenticados). Registro NS define quais servidores são autoritativos para o dominio. Registro SOA contem informações administrativas sobre a zona DNS.
TTL e propagação de DNS
TTL define quanto tempo o registro fica em cache, e o que determina a velocidade de propagação.
TTL, ou Time To Live, e o número de segundos que um registro DNS pode ser cacheado por resolvers ao redor do mundo antes de precisar ser re-consultado ao servidor autoritativo. Um TTL alto (86400 = 24 horas) significa que mudancas no DNS levam até 24 horas para propagar globalmente, pois resolvers que tem o valor antigo em cache só consultarao novamente após o TTL expirar. Um TTL baixo (300 = 5 minutos) significa propagação rápida mas mais carga no servidor autoritativo. A prática recomendada e: em operação normal, use TTL alto (1 hora ou mais) para redução de carga. Antes de uma migração planejada, reduza o TTL para 5 minutos com algumas horas de antecedência. Após a migração, restaure o TTL alto. Essa estrategia permite rollback rápido se necessário e depois reduz a carga no servidor.
DNS recursivo vs autoritativo
Resolvers recursivos fazem o trabalho de consulta. Servidores autoritativos tem a resposta final.
Existem dois papeis principais no ecossistema DNS. O servidor recursivo (ou resolver) e o que o seu dispositivo consulta diretamente. Ele não tem autoridade sobre nenhum dominio, mas sabe como encontrar a resposta consultando outros servidores em nome do cliente. O resolver do Google (8.8.8.8) e o da Cloudflare (1.1.1.1) são resolvers recursivos públicos de alto desempenho. O servidor autoritativo e o que tem a resposta definitiva para um dominio específico. Quando você registra um dominio e configura registros no painel do seu provedor DNS (Cloudflare, AWS Route 53, Registro.br), você esta editando os registros no servidor autoritativo daquele dominio. A separação desses papeis e o que torna o DNS escalável: resolvers cacheiam resultados, reduzindo a carga nos servidores autoritativos.
DNS em microservicos, Kubernetes CoreDNS
Dentro de um cluster Kubernetes, DNS e a base do service discovery.
Em arquiteturas de microservicos, DNS e usado para service discovery, descobrir o endereco de um serviço pelo nome em vez de por IP fixo. No Kubernetes, o componente CoreDNS e responsável pela resolução de nomes dentro do cluster. Quando um Pod precisa se comunicar com o serviço de pagamentos, ele faz uma consulta DNS para payment-service.default.svc.cluster.local. O CoreDNS resolve esse nome para o IP do Service do Kubernetes, que por sua vez encaminha para um dos Pods saudáveis. Esse mecanismo e transparente para a aplicação: ela usa nomes em vez de IPs, e o DNS cuida de mapeamento. Em sistemas distribuidos maiores, ferramentas como Consul, Eureka ou etcd oferecem service discovery mais rico com health checking ativo e registro dinâmico de serviços.
DNS poisoning e DNSSEC
Ataques de envenenamento de cache DNS podem redirecionar usuários para servidores maliciosos.
DNS cache poisoning e um ataque onde um atacante injeta registros falsos no cache de um resolver, fazendo com que usuários que consultam aquele resolver sejam redirecionados para servidores maliciosos em vez do servidor legitimo. Historicamente, o protocolo DNS era vulnerável a esses ataques por não ter mecanismo de autenticação. DNSSEC (DNS Security Extensions) resolve esse problema adicionando assinaturas criptograficas aos registros DNS. Com DNSSEC, cada registro e assinado com a chave privada do dominio, e o resolver pode verificar a assinatura usando a chave pública publicada no DNS. Se a assinatura não bater, o resolver descarta a resposta. DNSSEC previne cache poisoning mas adiciona complexidade operacional, as chaves precisam ser rotacionadas periodicamente e a cadeia de confianca (chain of trust) precisa estar configurada corretamente do root até o dominio.
GeoDNS e load balancing via DNS
DNS inteligente roteia usuários para servidores baseado em localização e disponibilidade.
GeoDNS e a prática de retornar diferentes registros DNS baseado na localização geografica do resolver do cliente. Um usuário no Brasil recebe o IP do servidor em São Paulo. Um usuário na Europa recebe o IP do servidor em Frankfurt. Isso distribui o tráfego globalmente e reduz latência ao rotear cada usuário para o servidor mais próximo. AWS Route 53 oferece roteamento por geoproximidade, por latência real e por health check (failover DNS). Se o servidor primário falha no health check do Route 53, o tráfego e automaticamente redirecionado para o servidor secundário em outra regiao. DNS-based load balancing com múltiplos registros A e simples mas limitado, o TTL significa que mudancas levam tempo para propagar, e o DNS não ve conexões ativas, entao não pode fazer load balancing fino como um Layer 7 real.
Provedores de DNS
Cloudflare, Route 53 e Google DNS se diferenciam em desempenho, features e preço.
A escolha do provedor DNS impacta a performance e a disponibilidade do seu dominio. Cloudflare DNS e consistentemente ranqueado como o DNS autoritativo mais rápido do mundo, com latência media global de 11ms, tier gratuito generoso, DNSSEC fácil de ativar e integração nativa com todas as features do Cloudflare (CDN, WAF, Workers). AWS Route 53 e ideal para quem esta no ecossistema AWS, com integração nativa com ELB, CloudFront e EC2, suporte a GeoDNS sofisticado e SLA de 100%. Google Cloud DNS oferece latência baixa e integração com infraestrutura GCP. Para registro de domínios .br, o Registro.br e a autoridade. Para resolvers recursivos dos dispositivos, Cloudflare 1.1.1.1 e Google 8.8.8.8 são os mais rápidos e confiáveis publicamente disponíveis.
Resumo final
DNS e a infraestrutura invisível que conecta nomes a enderecos e faz a internet funcionar.
DNS e uma das tecnologias mais fundamentais e menos visíveis da internet. Cada vez que você acessa um site, envia um email ou faz uma chamada de API, o DNS esta trabalhando nos bastidores para traduzir nomes em enderecos. Entender DNS e essencial para qualquer pessoa que opera sistemas na internet: entender TTL e propagação evita surpresas em migrações, conhecer os tipos de registro permite configurar email corretamente com SPF e DKIM, entender DNSSEC ajuda a proteger usuários de ataques de envenenamento de cache, e GeoDNS permite distribuir tráfego globalmente com elegância. Cloudflare simplificou enormemente o gerenciamento de DNS com sua interface intuitiva e tier gratuito. A próxima vez que um site demorar para propagar, você sabe exatamente por que.
Tutoriais em Video
Latency Numbers Programmer Should Know, ByteByteGo
System Design 101, roadmap.sh
Scaling up to your first 10 million users, AWS re:Invent 2019
CS75 Scalability Harvard Web Development, David Malan
Intro to Architecture and Systems Design Interviews, Jackson Gabbard
System Design for Beginners Course, freeCodeCamp
Conceitos-chave
DNS
Domain Name System, converte nomes de dominio como curitibablog.com.br em enderecos IP, agenda telefonica da internet
Registros DNS
A = IPv4, AAAA = IPv6, CNAME = alias, MX = email, TXT = verificação e SPF/DKIM, NS = servidores de nome
Resolução DNS
Cliente consulta resolver local, depois root servers, depois TLD, depois authoritative server, processo iterativo
TTL
Time To Live, quanto tempo o registro fica em cache, baixo TTL = mudancas rápidas mas mais consultas; alto TTL = menos consultas mas propagação lenta
DNS poisoning
Ataque que injeta registros falsos no cache do resolver, DNSSEC adiciona assinaturas criptograficas para prevenir
GeoDNS
Retornar diferentes IPs baseado na localização geografica do cliente, base de CDNs e balanceamento geografico
No Instagram
@bytebytego
Reels
@bytebytego
No Facebook
No X (Twitter)
O que devs dizem
Fiz uma migração de servidor sem reduzir o TTL antes. Resultado: metade dos usuários ficou apontando para o servidor antigo por 24 horas. Desde entao, antes de qualquer migração, a primeira coisa que faco e reduzir o TTL para 300 segundos com 6 horas de antecedência. Aprendi da maneira difícil.
Configurar SPF, DKIM e DMARC corretamente nos registros TXT do nosso dominio de email reduziu nossa taxa de bounces de 18% para 2%. Os emails pararam de cair em spam dos clientes. O DNS e mais do que só apontar para um IP, e a infraestrutura de identidade do dominio.
Implementamos GeoDNS com Route 53 e o failover automático salvou nosso SLA duas vezes em seis meses. Quando nosso datacenter em São Paulo teve instabilidade, o Route 53 detectou a falha no health check e desviou o tráfego para Virginia em menos de 60 segundos sem que precisassemos acordar alguem.