
O que é DNS
DNS é a sigla em inglês para Domain Name System (Sistema de Nomes e Domínios, em português), responsável por transformar os nomes dos domínios dos sites que as pessoas digitam nos navegadores web em números IP.
O DNS opera principalmente através de duas funções: examinar e atualizar bancos de dados e resolver nomes de domínios em endereços de rede.
O sistema de distribuição de nomes de domínio começou no ano de 1984, e através dele tornou-se possível que os nomes de hosts residentes em um banco de dados pudessem ser distribuídos entre vários servidores, diminuindo assim a carga em qualquer servidor.
O DNS baseia-se em nomes hierárquicos e permite a inscrição de vários dados digitados, além do nome do Host e do IP (Internet Protocol).
Pelo fato de o banco de dados ser distribuído, o tamanho é praticamente ilimitado e o desempenho não cai quando novos servidores entram.
a.root-servers.net a m.root-servers.net —, um limite herdado do tamanho máximo que um pacote UDP de DNS tinha nos anos 80. Cada uma dessas letras é, na verdade, centenas de máquinas espalhadas pelo planeta, respondendo pelo mesmo endereço IP por anycast: você fala com a mais próxima. Somadas, passam de 1.900 instâncias em mais de 150 países — inclusive várias no Brasil, hospedadas em pontos de troca de tráfego do NIC.br. Derrubar “os 13 servidores” não é uma operação possível.O servidor DNS traduz nomes em endereços IP e vice-versa. E a divisão clássica entre primário (onde a zona é editada) e secundário (que recebe uma cópia por transferência de zona) continua valendo — o registro.br, por exemplo, exige no mínimo dois servidores respondendo pelo seu domínio.
O que é DNS Reverso ?
O DNS Reverso resolve o endereço IP, buscando o nome de domínio associado ao host. Ou seja, quando temos disponível o endereço IP de um host e não sabemos o endereço do domínio(nome dado à máquina ou outro equipamento que acesse uma rede), tentamos resolver o endereço IP através do DNS reverso que procura qual nome de domínio está associado àquele endereço. Os servidores que utilizam o DNS Reverso conseguem verificar a autenticidade de endereços, verificando se o endereço IP atual corresponde ao endereço IP informado pelo servidor DNS. Isto evita que alguém utilize um domínio que não lhe pertence para enviar spam, por exemplo.
Conceito Básico
O DNS Reverso transforma 66.249.71.47 em dominio.com.br ou seja, um endereço IP em nome. O caminho clássico para resolução é: DNS resolver ➜ root servers ➜ ARIN (North American IP registry) ➜ Local ISP ➜ Acme Inc. DNS servers.
Quem quer que seja seu fornecedor de IPs deve ou adicionar suas entradas em seus servidores de DNS ou delegar autoridade de suas entradas de reverso para seus servidores de DNS. As entradas de DNS Reverso utilizam hostname com um endereço de IP reverso com “.in-addr.arpa” adicionado a ele. Por exemplo, “124.168.184.200.in-addr.arpa”.
O DNS padrão utiliza entradas do tipo “A Records” enquanto o DNS Reverso utiliza “PTR records” que se parecem com “124.168.184.200.in-addr.arpa. PTR host.example.com” (enquanto um DNS padrão seria algo como “host.example.com. A 66.249.71.47”).
Funcionamento DNS Padrão
É comum que muitas pessoas só conheçam o “padrão” DNS para resolução de hostname em endereço IP que transformaria dominio.com.br em 66.249.71.47. Esse processo começa com o registro de um domínio, no Brasil, o registro.br é uma das entidades (registrar) em que podemos criar novos domínios existem centenas de registrars em todo o mundo.
Ao criar um domínio você deve informar seus servidores de DNS que serão responsáveis em apontar o novo domínio para um endereço IP e, por outro lado, o registro.br envia essa informação aos servidores root (tecnicamente falando, o parent server para seu TLD). Dessa forma, qualquer pessoa no mundo pode acessar seus domínios e você pode enviar a elas qualquer endereço de IP que desejar. Você tem total controle sobre seus domínios e pode até enviar endereços de IPs que não te pertençam – nesse caso você precisaria de permissão do verdadeiro dono do IP que seus servidores DNS retornam como resultado de uma resolução.

Os tipos de registro que você vai usar
Uma zona de DNS é uma lista de registros, cada um com um tipo. Estes são os que aparecem no dia a dia:
| Tipo | Para que serve | Exemplo do que guarda |
|---|---|---|
A |
Nome → endereço IPv4 | 203.0.113.10 |
AAAA |
Nome → endereço IPv6 | 2001:db8::10 |
CNAME |
Apelido de outro nome | www aponta para site.exemplo.com.br |
MX |
Para onde vai o e-mail do domínio | 10 mail.exemplo.com.br |
TXT |
Texto livre — hoje é onde vivem SPF, DKIM e DMARC | v=spf1 mx -all |
NS |
Quem responde por esta zona | ns1.provedor.com.br |
PTR |
IP → nome (o DNS reverso) | 10.113.0.203.in-addr.arpa |
SOA |
Dados administrativos da zona: serial, TTLs | serial 2026090701 |
CAA |
Quais autoridades podem emitir certificado para o domínio | 0 issue "letsencrypt.org" |
SRV |
Serviço em um host e porta | usado por SIP, XMPP, Active Directory |
Se você administra e-mail, três desses definem se a sua mensagem chega ou vai para o spam: MX, o PTR do IP de saída e os TXT de SPF, DKIM e DMARC. O assunto está detalhado em A história do Postfix.
Consultando na prática: o dig
Toda a teoria acima se verifica com um comando. O dig vem no pacote dnsutils (Debian/Ubuntu) ou bind-utils (Fedora/RHEL):
# o básico: qual o IP deste nome?
dig +short exemplo.com.br
# um tipo específico
dig exemplo.com.br MX +short
dig exemplo.com.br TXT +short
dig exemplo.com.br NS +short
# DNS reverso
dig -x 203.0.113.10 +short
# perguntando a um resolvedor específico, ignorando o seu
dig @1.1.1.1 exemplo.com.br
dig @8.8.8.8 exemplo.com.br
# perguntando direto ao servidor autoritativo, sem cache no meio
dig @ns1.provedor.com.br exemplo.com.br
# a resolução inteira, passo a passo: raiz → TLD → autoritativo
dig +trace exemplo.com.br
O +trace é o comando que ensina DNS de verdade — ele mostra na tela a mesma cadeia de perguntas descrita neste post, uma linha por etapa.
Para o dia a dia, dois atalhos:
host exemplo.com.br # resposta curta e legível
resolvectl query exemplo.com.br # o que o systemd-resolved está usando
resolvectl status # quais servidores a sua máquina consulta
resolvectl flush-caches # limpar o cache local
TTL: por que a mudança demora a “pegar”
Todo registro carrega um TTL — o tempo, em segundos, que os resolvedores do mundo inteiro podem guardar aquela resposta em cache. É a explicação para a pergunta mais comum de quem troca de servidor: “mudei o IP e o site ainda abre no antigo”.
# ver o TTL restante (sem o +short)
dig exemplo.com.br | grep -A1 "ANSWER SECTION"
A regra de ouro de migração: baixe o TTL para 300 segundos com pelo menos 24 horas de antecedência, faça a troca, confirme que está tudo certo e só então volte o TTL para 3600 ou mais. Quem esquece esse passo convive com um dia inteiro de tráfego dividido entre servidor velho e novo.
O que mudou desde 2017: DNSSEC e DNS criptografado
O DNS foi desenhado em 1983 sem nenhuma preocupação com segurança — a resposta chega em texto puro e sem assinatura. Duas camadas foram criadas para tapar buracos diferentes, e é comum confundi-las:
- DNSSEC resolve a autenticidade: assina criptograficamente os registros, de modo que o resolvedor detecta se alguém adulterou a resposta no caminho. Não esconde nada — só prova que veio de quem devia. No
.bré suportado desde 2009 e habilitado no painel do registro.br. - DoT (DNS over TLS, porta 853) e DoH (DNS over HTTPS, porta 443) resolvem a privacidade: criptografam a consulta para que o provedor de internet e quem estiver no meio do caminho não vejam quais sites você procura. Não dizem nada sobre a resposta estar correta.
Um complementa o outro. No systemd-resolved, o DoT liga assim:
sudo tee /etc/systemd/resolved.conf.d/dot.conf >/dev/null <<'EOF'
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 9.9.9.9#dns.quad9.net
DNSOverTLS=yes
DNSSEC=allow-downgrade
EOF
sudo systemctl restart systemd-resolved
resolvectl status | grep -E "DNSOverTLS|DNSSEC|Current DNS"
# conferir se um domínio está assinado com DNSSEC
dig exemplo.com.br +dnssec | grep -E "RRSIG|flags:"
# a flag "ad" (authenticated data) na resposta indica validação bem-sucedida
Quando alguma coisa não resolve
Roteiro de diagnóstico, do mais provável ao menos:
- É cache?
resolvectl flush-cachese teste de novo. Compare comdig @1.1.1.1, que ignora o seu resolvedor. - O autoritativo responde?
dig @ns1.provedor.com.br o-dominio. Se o autoritativo não responde, o problema não é seu. - A delegação está certa?
dig o-dominio NS +trace— confira se os NS que o registrador publicou são os mesmos da zona. - O TTL antigo ainda vale? Se você acabou de mudar, espere o TTL anterior expirar.
- DNSSEC quebrado? Assinatura expirada derruba o domínio inteiro para quem valida.
dig +cddesabilita a validação: se funcionar com+cde falhar sem, achou o culpado. - É a sua máquina?
resolvectl statusmostra qual servidor está sendo usado de fato — muitas vezes não é o que você configurou.
Como funciona a Internet
Serie feita pelo Nic.br de como funciona a Internet, caso você esteja criando ou administrando um Servidor de E-mail, Sites, DNS, pare um pouco e veja esses 4 vídeos do Nic.br.
- Parte 1: O protocolo IP
- Parte 2: Sistemas Autônomos, BGP, PTTs
- Parte 3: DNS
- Parte 4: Governança da Internet
- A importância do DNS nas redes
Links
- registro.br — onde se registra domínio
.bre se configura DNSSEC - root-servers.org — o mapa ao vivo das instâncias dos servidores raiz
- DNSViz — visualiza a cadeia DNSSEC de um domínio e aponta onde quebrou
Aqui no blog: A história do Postfix explica por que MX, PTR e SPF decidem a entrega do seu e-mail; Sobre o arquivo hosts mostra o atalho que existia antes do DNS — e que ainda é consultado primeiro; e a Série Servidores Linux põe tudo isso em prática.