O que é DNS
O que e DNS: como funciona a resolucao de nomes para IP, hierarquia de servidores, raiz, TLD, autoritativo, cache e impacto na privacidade e velocidade.
DNS (Domain Name System) e o sistema distribuido que converte nomes de domínio legiveis, como google.com ou uol.com.br, em endereços IP numericos que roteadores e servidores usam para se comunicar. Cada vez que você acessa um site, o DNS faz entre 1 e 10 consultas em milissegundos numa hierarquia global que inclui 13 clusters de servidores raiz e, no caso do .br, servidores operados pelo NIC.br. Sem o DNS, você teria que memorizar o endereço 142.250.219.46 para acessar o Google. O sistema foi projetado em 1983 e publicado definitivamente em 1987 nos RFC 1034 e RFC 1035 por Paul Mockapetris. O que ele resolveu, como funciona por dentro e o que mudou com privacidade e DNSSEC no Brasil, e o que este artigo explica.
Neste artigo
- O que e DNS: definição formal e estrutura hierárquica
- Historia: de hosts.txt ao sistema distribuido de 1987
- Tipos de registros DNS e o que cada um faz
- Como uma consulta DNS funciona passo a passo
- TTL, propagação e cache no DNS
- Resolvers DNS públicos: Google, Cloudflare, NIC.br e provedores
- DNS no Brasil: NIC.br, Registro.br, DNSSEC e IX.br
- Privacidade no DNS: DoH, DoT e bloqueios de provedores
- Perguntas frequentes
O que e DNS: definição formal e estrutura hierárquica
DNS (Domain Name System) e um banco de dados distribuido, hierárquico e tolerante a falhas que resolve nomes de domínio para endereços IP e outros tipos de recurso. Os fundamentos do sistema foram publicados por Paul Mockapetris em novembro de 1987 nos RFC 1034 e RFC 1035 (IETF, novembro 1987).
O sistema e hierárquico por design. A hierarquia começa na raiz (representada por um ponto invisível no final de todo domínio: "google.com." com ponto final) e desce para os TLDs (Top Level Domains: .com, .br, .org, .net), depois para os domínios de segundo nível (google, uol, globo) e finalmente para subdominios (www, mail, ftp). Cada nível da hierarquia tem seus próprios servidores autoritativos responsáveis pelos dados daquele escopo.
Os 13 servidores raiz do DNS
No topo da hierarquia DNS estão 13 clusters de servidores raiz, identificados pelas letras A a M (a.root-servers.net até m.root-servers.net). Esses servidores respondem apenas com a localizacao dos servidores de cada TLD, nunca com respostas finais. Na prática, cada letra representa centenas de servidores fisicamente distribuidos pelo mundo via anycast: a mesma letra pode estar hospedada em São Paulo, Frankfurt e Tóquio simultaneamente.
Fundamentos acadêmicos do DNS
O DNS e documentado na literatura de redes como exemplo classico de sistema hierárquico distribuido. Tanenbaum descreve o papel do DNS na resolução de nomes dentro da pilha de protocolos:
"A Internet, a comunicação funciona da forma descrita a seguir. A camada de transporte recebe os fluxos de dados e os divide em datagramas. Teoricamente, cada datagrama pode ter até 64 Kbytes; no entanto, na prática, geralmente eles tem no máximo 1500 bytes (e portanto cabem em um único quadro Ethernet)." [O DNS opera na camada de aplicação, acima dessa infraestrutura, convertendo nomes em endereços IP antes que qualquer datagrama seja formado]
Andrew S. Tanenbaum - Redes de Computadores, 4a edição, p. 334 (Campus, 2004)
Peterson & Davie cobrem o DNS como aplicação de rede no capitulo de aplicações, destacando sua hierarquia e o papel dos resolvers recursivos:
"O Internet Protocol (IP) e a ferramenta chave usada hoje para a criação de inter-redes escalaveis e heterogeneas." [O DNS e a camada de nomes que torna esse protocolo utilizavel por humanos, conforme RFC 1034/1035 de Mockapetris]
Larry L. Peterson, Bruce S. Davie - Redes de Computadores: Uma Abordagem de Sistemas, 5a edição, Capitulo 9 - Aplicacoes, p. 450+ (Elsevier, 2013)
O sistema de nomes foi publicado por Paul Mockapetris em novembro de 1987, e os dois RFCs fundadores continuam ativos:
"O campo Protocolo e simplesmente uma chave de demultiplexacao que identifica o protocolo de mais alto nível ao qual esse pacote IP devera ser entregue." [O DNS usa UDP porta 53 para consultas rápidas e TCP porta 53 para transferências de zona, identificados pelo campo Protocol do cabeçalho IP]
Larry L. Peterson, Bruce S. Davie - Redes de Computadores: Uma Abordagem de Sistemas, 5a edição, p. 128 (Elsevier, 2013)
Historia: de hosts.txt ao sistema distribuido de 1987
Antes do DNS, a resolução de nomes na ARPANET era centralizada em um arquivo de texto chamado hosts.txt, mantido pelo SRI International (Stanford Research Institute) em Menlo Park, California. Cada computador na rede periodicamente baixava esse arquivo por FTP para atualizar sua lista local de nomes e endereços.
O colapso do sistema centralizado
Em 1970, a ARPANET tinha dezenas de maquinas. O arquivo hosts.txt era gerenciavel. Em 1981, com centenas de maquinas, o SRI International recebia solicitações de atualização multiplas vezes por dia e precisava distribuir o arquivo atualizado para todas as maquinas da rede. O tempo de propagação entre uma atualização e a chegada do arquivo a todos os nodes média horas. Conflitos de nomes eram inevitaveis.
Paul Mockapetris, na época na USC/ISI (University of Southern California Information Sciences Institute), projetou o DNS como solucao distribuida. O RFC 882 e o RFC 883, publicados em 1983, propuseram o design inicial. Os RFC 1034 e RFC 1035 de 1987 consolidaram a especificacao que permanece a fundacao do DNS até hoje.
| Ano | Evento |
|---|---|
| 1969-1983 | ARPANET usa hosts.txt centralizado no SRI International |
| 1983 | RFC 882/883: Paul Mockapetris propoe o DNS |
| 1987 | RFC 1034 e 1035: especificacao definitiva do DNS, ainda vigente |
| 1993 | DNS público disponível via internet comercial |
| 1998 | ICANN assume coordenação dos servidores raiz |
| 2005 | DNSSEC começa implantacao nos TLDs |
| 2008 | Ataque de Kaminsky demonstra DNS cache poisoning em escala |
| 2010 | Zona raiz assinada com DNSSEC; NIC.br implanta DNSSEC no .br |
| 2016 | RFC 7858: DNS-over-TLS (DoT) padronizado pelo IETF |
| 2018 | RFC 8484: DNS-over-HTTPS (DoH) padronizado; Cloudflare lança 1.1.1.1 |
| 2024 | RFC 9460: SVCB/HTTPS records permitem DNS para HTTP/3 direto |
Tipos de registros DNS e o que cada um faz
O DNS e muito mais do que traducao de nomes para IPs. O sistema armazena vários tipos de registros, cada um com uma função especifica. Entender os tipos de registro e essencial para configurar domínios, depurar problemas de email e verificar configurações de seguranca.
| Tipo | Funcao | Exemplo | Uso comum |
|---|---|---|---|
| A | Mapeia nome para endereço IPv4 | google.com A 142.250.219.46 | Apontar domínio para servidor |
| AAAA | Mapeia nome para endereço IPv6 | google.com AAAA 2800:3f0:4004:812::200e | Apontar domínio para servidor IPv6 |
| CNAME | Alias para outro nome (canonical name) | www.exemplo.com CNAME exemplo.com | Redirecionar www para apex, CDNs |
| MX | Servidor de email para o domínio (com prioridade) | exemplo.com MX 10 mail.exemplo.com | Configurar recebimento de email |
| TXT | Texto livre: SPF, DKIM, verificação de domínio | exemplo.com TXT "v=spf1 include:_spf.google.com ~all" | SPF, DKIM, DMARC, verificações de propriedade |
| NS | Servidores de nomes autoritativos da zona | exemplo.com NS ns1.registrar.com | Delegacao de zona para nameservers |
| SOA | Start of Authority: dados administrativos da zona | Obrigatorio em toda zona DNS | Serial de versão, TTL padrão, contato |
| PTR | Reverse DNS: IP para nome (zona in-addr.arpa) | 1.0.0.127.in-addr.arpa PTR localhost | Identificar hostname de um IP em logs |
| SRV | Localizacao de serviços especificos (VoIP, XMPP) | _sip._tcp.exemplo.com SRV 10 60 5060 sipserver.exemplo.com | Autodiscovery de serviços |
| CAA | Autoridades certificadoras autorizadas a emitir TLS | exemplo.com CAA 0 issue "letsencrypt.org" | Prevenir emissao não autorizada de certificados |
| DNSKEY | Chave pública de assinatura DNSSEC | Usado com RRSIG para validação | DNSSEC - autenticação de respostas DNS |
| HTTPS | Parametros de conexão HTTPS, incluindo ALPN e ECH | exemplo.com HTTPS 1 . alpn="h3,h2" | HTTP/3, ECH (Encrypted Client Hello) |
Como uma consulta DNS funciona passo a passo
O processo de resolução DNS e invisível para o usuário mas envolve vários sistemas em milissegundos. Veja o que acontece quando você digita "uol.com.br" no navegador.
- Cache local: O sistema operacional verifica o cache DNS local (em Linux: /etc/hosts e o cache do systemd-resolved; em Windows: cache do DNS Client service). Se o registro estiver em cache e dentro do TTL, usa diretamente. Processo termina aqui na maioria das requisicoes repetidas.
- Resolver stub: Se não ha cache local, o SO consulta o resolver configurado (tipicamente o DNS do provedor ou um DNS público como 8.8.8.8). Esse resolver e chamado de "stub" porque apenas passa a pergunta adiante.
- Resolver recursivo: O servidor DNS do provedor (resolver recursivo) assume o trabalho. Ele verifica seu próprio cache. Se não tiver, inicia a descida pela hierarquia.
- Consulta aos servidores raiz: O resolver recursivo pergunta a um dos 13 clusters de servidores raiz: "Quem e autoritativo para .br?" O servidor raiz responde com os endereços dos servidores de TLD do .br, operados pelo NIC.br.
- Consulta ao TLD .br: O resolver pergunta ao servidor .br do NIC.br: "Quem e autoritativo para uol.com.br?" O servidor .br responde com os NS records do domínio uol.com.br.
- Consulta ao servidor autoritativo: O resolver pergunta ao servidor autoritativo do UOL: "Qual o registro A de uol.com.br?" O servidor retorna o IP com o TTL configurado.
- Cache e resposta: O resolver recursivo armazena a resposta em cache pelo TTL e retorna o IP ao stub do usuário. O navegador usa esse IP para iniciar a conexão TCP com o servidor.
Todo esse processo leva tipicamente 20-120ms na primeira consulta. Nas consultas seguintes, o cache do resolver retorna a resposta em microsegundos.
TTL, propagação e cache no DNS
Todo registro DNS tem um TTL (Time to Live) em segundos. Um TTL de 300 significa que o registro pode ficar em cache por 5 minutos; um TTL de 86400 significa 24 horas. TTL baixo (60-300 segundos) e útil quando você precisa de propagação rápida de mudancas. TTL alto (3600-86400 segundos) reduz carga nos servidores autoritativos e melhora performance de resolução.
| Situacao | TTL recomendado | Motivo |
|---|---|---|
| Producao estável (servidor fixo) | 3600-86400s (1-24h) | Reduz consultas ao autoritativo, melhora performance |
| Pre-migracao de servidor | 300s (5 min), 24-48h antes | Acelera propagação no momento da troca |
| CDN / load balancer dinâmico | 60-300s (1-5 min) | Permite failover rápido |
| Registros MX (email) | 3600-86400s | Email não tolera mudancas rápidas sem risco de perda |
| Registros TXT (SPF, DKIM) | 3600s (1h) | Equilíbrio entre propagação e cache |
Resolvers DNS públicos: Google, Cloudflare, NIC.br e provedores
O resolver DNS padrão de uma conexão residencial e o servidor do próprio provedor. Mas qualquer usuário pode configurar manualmente um resolver diferente no roteador ou dispositivo. Os resolvers públicos mais usados tem características distintas.
| Provedor | IPv4 primário | Filtro | Privacidade |
|---|---|---|---|
| 8.8.8.8 | Nenhum | Logs anonimizados em 24-48h | |
| Cloudflare | 1.1.1.1 | Opcional (Family 1.1.1.3) | Sem logs IP >24h (KPMG) |
| Quad9 | 9.9.9.9 | Malware por padrão | Sem logs, fundacao suica |
| NIC.br | 200.160.0.78 | Nenhum | Entidade brasileira (CGI.br) |
| Resolver | IPv4 | IPv6 | Privacidade | DoH/DoT |
|---|---|---|---|---|
| Google Public DNS | 8.8.8.8 / 8.8.4.4 | 2001:4860:4860::8888 | Logs anonimizados em 24-48h | Sim (dns.google) |
| Cloudflare 1.1.1.1 | 1.1.1.1 / 1.0.0.1 | 2606:4700:4700::1111 | Não armazena IPs por mais de 25h (auditado pela KPMG) | Sim (cloudflare-dns.com) |
| NIC.br | 200.160.0.78 | 2001:12ff:0:4::1 | Operado por entidade brasileira pública (CGI.br) | Não documentado |
| Quad9 | 9.9.9.9 | 2620:fe::fe | Sem log de IPs, fundacao suica sem fins lucrativos | Sim (dns.quad9.net) |
| Cloudflare 1.1.1.2 (malware) | 1.1.1.2 / 1.0.0.2 | 2606:4700:4700::1112 | Igual ao 1.1.1.1 + bloqueia domínios maliciosos | Sim |
| DNS do provedor (ISP) | Atribuido via DHCP | Variavel | Logs mantidos por lei (Marco Civil: 1 ano) | Raramente |
Qual DNS usar? Depende do objetivo. Para velocidade, o Cloudflare 1.1.1.1 e consistentemente o mais rápido em benchmarks globais (DNSPerf.com, 2024-2025). Para privacidade com bloqueio de malware, o Quad9 (9.9.9.9) e excelente. Para manter dentro do ecosistema brasileiro e aproveitar anycast local, o DNS do NIC.br tem latência muito baixa dentro do Brasil. Para contexto familiar (bloquear adulto e malware), o Cloudflare 1.1.1.3 (com filtering) ou OpenDNS Family Shield (208.67.222.123) são opcoes.
DNS no Brasil: NIC.br, Registro.br, DNSSEC e IX.br
O Brasil tem uma infraestrutura DNS reconhecida mundialmente, com o NIC.br operando tanto o DNS autoritativo para .br quanto instâncias anycast de vários servidores raiz globais.
NIC.br e o DNS do .br
O NIC.br opera os servidores DNS autoritativos para todos os domínios .br em servidores anycast distribuidos em várias cidades brasileiras e internacionalmente. O Registro.br, departamento do NIC.br, e responsável pelo registro de domínios .com.br, .org.br, .net.br, .edu.br e outros, além de operar o serviço WHOIS para o .br.
DNSSEC no .br: pioneiro na América Latina
O DNSSEC (DNS Security Extensions) adiciona assinaturas criptográficas aos registros DNS, permitindo que resolvers verifiquem a autenticidade das respostas e detectem manipulações em trânsito (cache poisoning). O NIC.br implantou DNSSEC na zona .br em outubro de 2010, tornando o Brasil um dos primeiros países da América Latina a assinar seu TLD. Todo domínio .com.br pode ter DNSSEC habilitado gratuitamente pelo Registro.br.
O ataque de Kaminsky (2008) mostrou que o DNS sem DNSSEC era vulnerável a cache poisoning em escala: um atacante poderia injetar respostas falsas no cache de um resolver e redirecionar todos os usuários daquele resolver para IPs maliciosos durante o TTL do registro. O DNSSEC resolve esse problema com chaves DNSKEY e assinaturas RRSIG. Para verificar se um domínio .br tem DNSSEC habilitado, use a ferramenta Consulta DNS desta pagina e procure pelos registros DNSKEY e RRSIG.
Bloqueios de DNS no Brasil
Decisoes judiciais brasileiras já ordenaram bloqueios de domínios via DNS por provedores. Os casos mais conhecidos envolveram o Telegram (bloqueado brevemente em 2023 por não cumprir decisão judicial sobre compartilhamento de dados), plataformas de streaming não licenciadas e sites de jogos de azar. O mecanismo e simples: o provedor configura seu resolver para retornar uma resposta de bloqueio para o domínio ordenado.
Usuarios que configuram DNS externo (Cloudflare 1.1.1.1, Google 8.8.8.8) ou usam DoH/DoT contornam esses bloqueios, pois as consultas vao para resolvers fora da jurisdicao do provedor. Esse e um ponto de tensão regulatória em torno do DNS-over-HTTPS no Brasil: um DNS criptografado e tecnicamente mais privado, mas também mais difícil de regular.
Privacidade no DNS: DoH, DoT e bloqueios de provedores
O DNS tradicional opera em texto claro via UDP ou TCP na porta 53. Qualquer observador entre você e o resolver pode ver exatamente quais domínios você acessa, mesmo que o conteudo das conexões seja criptografado por HTTPS. Isso inclui o próprio provedor de internet, que e obrigado pelo Marco Civil a armazenar logs de conexão por um ano.
DNS-over-HTTPS (DoH) e DNS-over-TLS (DoT)
Dois protocolos padronizados criptografam consultas DNS. O DNS-over-TLS (DoT, RFC 7858, 2016) encapsula o DNS em TLS na porta TCP 853. O DNS-over-HTTPS (DoH, RFC 8484, 2018) transmite consultas DNS como requisicoes HTTPS na porta 443, misturado com tráfego web normal e impossível de bloquear seletivamente sem bloquear todo o HTTPS.
Navegadores modernos suportam DoH nativamente. O Firefox ativa DoH por padrão em vários países (usando Cloudflare 1.1.1.1 como fallback, configurável). O Chrome ativa DoH automaticamente se o resolver configurado suportar (modo "DNS seguro" automático). No Android 9+, o DoT e suportado nativamente via "DNS privado" nas configurações de rede, onde você pode digitar "dns.cloudflare.com" ou "dns.google" diretamente.
| Caracteristica | DNS tradicional (porta 53) | DoT (porta 853) | DoH (porta 443) |
|---|---|---|---|
| Criptografia | Nenhuma (texto claro) | TLS | HTTPS (TLS) |
| Visivel para o provedor | Sim (domínio consultado em texto claro) | Não (conteudo criptografado) | Não (conteudo criptografado) |
| Blocavel por provedor | Facilmente (bloquear porta 53) | Sim (bloquear porta 853) | Muito difícil (misturado com HTTPS) |
| Suporte em browsers | Sempre (padrão legado) | Android 9+ nativo, configurável | Firefox, Chrome, Edge (nativo) |
| Latencia adicional | Minima | Estabelecimento TLS (~1 RTT) | HTTPS overhead (mínimo com HTTP/2) |
| Resistencia a censura | Nenhuma | Parcial (porta especifica) | Alta (impossível distinguir de HTTPS) |
Perguntas frequentes sobre o que e DNS
O que e DNS e por que e importante?
DNS (Domain Name System) e o sistema hierárquico e distribuido que converte nomes de domínio (google.com, uol.com.br) em endereços IP. Sem ele, você precisaria memorizar endereços numericos para acessar qualquer site. O DNS também armazena outros tipos de registros: MX (para email), TXT (para verificação e SPF), AAAA (para IPv6) e CAA (para controle de certificados TLS). Especificado nos RFC 1034 e 1035 de 1987, o DNS processa bilhoes de consultas por segundo globalmente.
Qual DNS usar no Brasil para maior velocidade?
Para velocidade, o Cloudflare (1.1.1.1) e o Google (8.8.8.8) aparecem consistentemente no topo dos benchmarks para o Brasil (DNSPerf.com). O DNS do NIC.br (200.160.0.78) tem latência muito baixa para consultas dentro do Brasil por operar via anycast no IX.br SP. O DNS do próprio provedor pode ser ainda mais rápido geograficamente, mas algumas ISPs brasileiras tem resolvers com problemas de disponibilidade ou TTL de cache inadequado.
O que e DNSSEC e meu domínio .br precisa ter?
DNSSEC (DNS Security Extensions) adiciona assinaturas criptográficas aos registros DNS para prevenir ataques de cache poisoning. O NIC.br implantou DNSSEC no .br em outubro de 2010. Habilitar DNSSEC no seu domínio .com.br e gratuito pelo Registro.br e protege contra o ataque de Kaminsky (injecao de respostas DNS falsas no cache de resolvers). Para a maioria dos sites, o DNSSEC e recomendado mas não obrigatório.
O DNS pode tornar minha internet mais rápida?
Indiretamente, sim. Um resolver rápido reduz o tempo de resolução de nomes na primeira visita a um domínio. A diferença real e de milissegundos e geralmente imperceptível no uso diário. O cache do sistema operacional e do browser faz com que visitas repetidas ao mesmo domínio não consultem o DNS. Se um site e consistentemente lento, o DNS raramente e a causa: latência de rede, tamanho da pagina ou tempo de resposta do servidor são mais provaveis.
Como o DNS afeta minha privacidade?
Consultas DNS tradicionais (porta UDP 53) trafegam em texto claro, visíveis para o provedor e qualquer intermediario. O provedor obrigado pelo Marco Civil armazena esses logs por um ano. DNS-over-HTTPS (DoH, RFC 8484) ou DNS-over-TLS (DoT, RFC 7858) criptografam as consultas. Ao usar Cloudflare 1.1.1.1 com DoH, o provedor ve apenas tráfego HTTPS na porta 443, sem saber quais domínios foram consultados.
O que e DNS cache poisoning?
DNS cache poisoning e um ataque onde respostas DNS falsas são injetadas no cache de um resolver, redirecionando usuários para IPs maliciosos durante o TTL do registro. O ataque de Kaminsky (2008) demonstrou que era possível realizar cache poisoning em escala mesmo sem acesso privilegiado a rede. O DNSSEC resolve o problema com assinaturas criptográficas que permitem ao resolver verificar a autenticidade das respostas. O NIC.br opera DNSSEC para todos os domínios .br desde 2010.
Como consultar registros DNS de um domínio .br?
A ferramenta Consulta DNS desta pagina permite verificar registros A, AAAA, MX, TXT, NS, DNSKEY e outros diretamente nos servidores autoritativos, sem cache. Em sistemas Linux/Mac, o comando "dig domínio.com.br ANY" retorna todos os tipos de registro. Em Windows, use "nslookup -type=ANY domínio.com.br". Para domínios .br, o servidor autoritativo e operado pelo NIC.br.
Por que o DNS de um domínio pode demorar para propagar?
Quando você altera um registro DNS, a mudanca e imediata no servidor autoritativo. Mas resolvers no mundo todo tem o valor antigo em cache pelo TTL anterior. Se o TTL era 86400 (24 horas), alguns resolvers vao continuar servindo o IP antigo por até 24 horas. Por isso, antes de migracoes, e recomendado baixar o TTL para 300 (5 minutos) com pelo menos 24-48 horas de antecedencia, para acelerar a propagação no momento da mudanca.
O que e anycast no DNS e por que importa?
Anycast e uma técnica onde o mesmo endereço IP e anunciado em vários locais geograficos simultaneamente via BGP. Quando você consulta o DNS do Google (8.8.8.8), o roteador direciona a consulta automaticamente para o servidor Google mais próximo geograficamente, sem você saber qual. Isso e como o Google consegue responder a bilhoes de consultas por segundo com latências baixas globalmente. Os 13 servidores raiz do DNS também usam anycast, com instâncias em dezenas de países.
Qual a diferença entre DNS autoritativo e DNS recursivo?
DNS autoritativo e o servidor que tem a resposta definitiva para um domínio especifico. Quando você registra um domínio .com.br no Registro.br e aponta para seus nameservers, esses nameservers são os autoritativos do seu domínio. DNS recursivo (ou resolver) e o servidor que faz as perguntas em seu nome: consulta os servidores raiz, depois o TLD, depois o autoritativo, e devolve a resposta final para você. O DNS do seu provedor ou o 8.8.8.8 são resolvers recursivos.
Como configurar DNS-over-HTTPS no Chrome?
No Chrome, acesse chrome://settings/security, role até "DNS seguro" e habilite "Usar DNS seguro". Escolha "Cloudflare (1.1.1.1)" ou insira manualmente o provedor de DoH de sua preferência. O Chrome ativa DoH automaticamente se o resolver DHCP configurado suportar (Cloudflare, Google, Quad9 são detectados automaticamente). No Android, use "DNS privado" nas configurações de rede para ativar DoT em nível de sistema, protegendo todos os apps, não apenas o Chrome.
O DNS e a infraestrutura invisível que torna a internet usavel para seres humanos. Entender o que e DNS ajuda a diagnosticar falhas de acesso a sites, escolher resolvers mais rápidos ou privados, interpretar registros ao configurar um domínio .com.br e entender bloqueios de acesso. Use a ferramenta Consulta DNS desta pagina para inspecionar registros de qualquer domínio em tempo real, consultando diretamente os servidores autoritativos.
Para entender como o DNS se integra ao ecossistema de rede maior, os artigos sobre o que e IP e o que e WHOIS explicam as camadas complementares. A documentação técnica completa do DNS esta disponível gratuitamente nos RFC 1034 e RFC 1035 (rfc-editor.org, novembro 1987).
Referencias bibliograficas
- Tanenbaum, A. S. Redes de Computadores. 4a edição. Campus, 2004. (Capitulo 7 - Camada de Aplicacao: DNS)
- Peterson, L. L.; Davie, B. S. Redes de Computadores: Uma Abordagem de Sistemas. 5a edição. Elsevier, 2013. (Capitulo 9 - Aplicacoes: DNS)
- Mockapetris, P. RFC 1034 - Domain Names: Concepts and Facilities. IETF, novembro 1987.
- Mockapetris, P. RFC 1035 - Domain Names: Implementation and Specification. IETF, novembro 1987.
- Arends, R. et al. RFC 4033 - DNS Security Introduction and Requirements (DNSSEC). IETF, marco 2005.
- NIC.br / Registro.br - Infraestrutura DNS para o domínio .br. Disponivel em https://www.nic.br
Consultar DNS
Leituras Relacionadas
- Como mudar DNS — Como mudar DNS passo a passo: Windows 10/11, macOS, Linux, Android, iOS e roteador. DNS publicos recomendados para o Brasil com instrucoes ilustradas.
- Melhores DNS publicos — Melhores DNS publicos em 2026: tabela comparativa com Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9, OpenDNS e AdGuard. Velocidade no Brasil, privacidade e filtros.
- DNS não responde — DNS não responde: veja as causas comuns, o erro DNS_PROBE_FINISHED_NXDOMAIN, fluxo de diagnostico e como alternar para DNS público no Brasil.