1. Introdução
Apesar de parecer simples — transformar nomes em endereços IP — o DNS é um dos pilares mais delicados de qualquer rede. Sem ele, serviços continuam online, mas se tornam invisíveis. A diferença entre um ambiente funcional e um cheio de timeouts costuma ser uma configuração de DNS mal feita, seja por falta de servidores internos, falta de separação entre consultas internas/externas ou erros básicos na zona. Entender DNS significa entender como o tráfego realmente se orienta dentro da sua rede.
2. Hierarquia do DNS
A hierarquia do DNS é distribuída e cooperativa. No topo estão os root servers, que não respondem nomes, mas indicam o caminho. Abaixo deles ficam os TLDs (.com, .org, .br). Cada domínio registrado aponta para seus servidores autoritativos, que têm a palavra final sobre os registros daquela zona.
Quando uma máquina faz uma consulta, ela não fala diretamente com essa hierarquia — quem assume esse papel é o resolvedor recursivo (geralmente seu roteador, seu provedor ou um servidor interno da empresa). Ele percorre a cadeia: pergunta ao root “quem sabe sobre .com?”, pergunta ao TLD “quem sabe sobre exemplo.com?” e finalmente consulta o servidor autoritativo do domínio. Só então devolve a resposta ao cliente.
Essa separação entre recursivo (que busca) e autoritativo (que decide) é fundamental quando montamos DNS interno, porque a mesma máquina pode desempenhar um papel, o outro, ou ambos — e isso afeta diretamente a forma como a rede resolve nomes.
3. Entendendo uma consulta real com dig
Uma consulta real ajuda a visualizar tudo isso. Exemplo:
> dig dev.to
; <<>> DiG 9.10.6 <<>> dev.to
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65291
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;dev.to. IN A
;; ANSWER SECTION:
dev.to. 245 IN A 151.101.2.217
dev.to. 245 IN A 151.101.194.217
dev.to. 245 IN A 151.101.130.217
dev.to. 245 IN A 151.101.66.217
;; Query time: 9 msec
;; SERVER: 10.0.0.1#53(10.0.0.1)
;; WHEN: Mon Dec 08 15:34:10 -03 2025
;; MSG SIZE rcvd: 99
Elementos essenciais do output:
QUESTION SECTION: O que foi perguntado. Útil para ver se não houve anexação de sufixos automáticos.
ANSWER SECTION: Resposta final, geralmente contendo um registro A/AAAA ou um CNAME.
AUTHORITY SECTION: Indica quais servidores são responsáveis pela zona consultada caso a resposta venha de delegação.
ADDITIONAL SECTION: Traz informações extras, como endereços IP dos servidores autoritativos.
Query time: Mostra se há lentidão na recursão.
SERVER: Indica qual resolvedor respondeu; isso revela rapidamente se o cliente está consultando DNS interno ou o DNS do provedor sem querer.
Essa leitura ajuda a detectar loops, consultas externas indevidas e comportamentos que escapam da topologia planejada.
4. Montando um DNS interno com Bind9
Ambientes corporativos normalmente mantêm um DNS interno para resolver nomes que não devem — e nem podem — existir no DNS público. Isso inclui servidores internos, serviços administrativos, endereços de infraestrutura e aliases operacionais.
Para isso, define-se uma zona autoritativa privada, carregada somente pelos servidores internos.
Definição da zona no named.conf.local:
zone "empresa.lan" {
type master;
file "/etc/bind/db.empresa.lan";
};
zone "empresa.lan"— nome da zona. É o sufixo que todos os registros vão compartilhar.type master— indica que este servidor é a origem autoritativa da zona.file— caminho do arquivo de zona.
Um arquivo de zona simples pode conter:
$TTL 86400
@ IN SOA ns1.empresa.lan. admin.empresa.lan. (
2025010101 ; serial
3600 ; refresh
1800 ; retry
604800 ; expire
86400 ; minimum
)
IN NS ns1.empresa.lan.
; Registros A (IPv4)
ns1 IN A 10.20.0.2
host1 IN A 10.20.0.10
nginx IN A 10.20.0.20
; Registros AAAA (IPv6)
webv6 IN AAAA fd00:20::50
; Alias / CNAME
api IN CNAME nginx.empresa.lan.
; Serviço fictício para demonstrar registros mistos
db IN A 10.20.0.30
db IN AAAA fd00:20::30
Vamos olhar em detalhes cada parte:
$TTL 86400
Tempo padrão de cache para todos os registros que não tiverem TTL próprio.
@ IN SOA ns1.empresa.lan. admin.empresa.lan. ( ... )
O registro SOA (Start of Authority) define a origem autoritativa da zona.
-
ns1.empresa.lan.: servidor responsável pela zona -
admin.empresa.lan.: contato do administrador (o "@" vira um ponto) -
serial: número de versão da zona, que deve ser incrementado a cada mudança -
refresh,retry,expire,minimum: parâmetros de controle de cache e atualização
IN NS ns1.empresa.lan.
Lista os servidores que respondem pela zona.
Em ambientes internos, normalmente só existe um servidor, mas pode haver redundância.
ns1 IN A 10.20.0.2
host1 IN A 10.20.0.10
nginx IN A 10.20.0.20
Associa um nome a um endereço IPv4.
Base de qualquer resolução dentro de LANs.
webv6 IN AAAA fd00:20::50
Associa um nome a um endereço IPv6.
Usado quando a rede interna já opera com IPv6 — especialmente útil para testes.
api IN CNAME nginx.empresa.lan.
Define um apelido: api.empresa.lan → nginx.empresa.lan.
- o CNAME redireciona o nome, não o IP;
- um nome que é CNAME não pode ter outros registros A/AAAA/NS/MX;
- útil para abstrair serviços (“api”, “db”, “mail”), permitindo mover o backend sem quebrar clientes.
db IN A 10.20.0.30
db IN AAAA fd00:20::30
O nome db.empresa.lan tem resoluções distintas para IPv4 e IPv6.
Clientes dual-stack escolhem de acordo com a pilha habilitada.
5. Reverse DNS (PTR) — quando faz sentido
O reverse é o oposto do DNS convencional: dado um IP, retorna o nome. Ele vive em zonas como:
0.20.10.in-addr.arpa
Em redes internas ele não é obrigatório, mas é extremamente útil para logs, auditoria, integração com sistemas de e-mail e ferramentas de monitoramento. Sem PTR, várias interfaces aparecem só com IP, o que dificulta depuração e análise de tráfego.
6. Testando corretamente
O teste mais confiável é direcionar a consulta explicitamente ao servidor interno:
dig @10.20.0.2 host1.empresa.lan
Depois, teste a cadeia completa fazendo consultas externas e internas do mesmo cliente para garantir que:
- nomes públicos continuam resolvendo via resolvedor externo;
- nomes internos não vazam para a Internet;
- o cliente está usando o DNS correto (verifique a seção “SERVER” no
dig); - forwarders do Bind9 estão funcionando (em casos em que ele também atua como resolvedor).
Use tcpdump se precisar observar se pedidos internos estão escapando para fora — problema comum causado por má configuração de search domains ou múltiplos DNS no /etc/resolv.conf.
7. Problemas frequentes e como identificá-los
Leak de DNS: clientes internos enviam consultas para DNS públicos. Sintomas: lentidão, respostas inconsistentes, falha em resolver nomes internos.
Servidor interno sem forwarders: consultas para domínios externos demoram ou falham porque o Bind9 só atua como autoritativo, não como recursivo.
Zona mal definida: SOA incorreto, serial não incrementado, registros ausentes, TTLs exagerados. Tudo isso faz com que mudanças não propaguem ou causem respostas erradas.
Esses problemas não são óbvios no início, mas se tornam triviais quando você olha o dig com atenção.
8. Conclusão
DNS só parece simples à distância. Quando você entende o papel dos resolvedores, da hierarquia e das zonas internas, percebe que uma rede estável depende de um DNS coerente e bem isolado. Montar um servidor interno não é complicado, mas exige disciplina: manter zonas organizadas, testar rotas de consulta e garantir que nenhum cliente escape para fora da estrutura planejada. Uma base sólida de DNS deixa todo o restante — roteamento, firewall, serviços — mais previsível e muito menos sujeito a falhas silenciosas.
Top comments (0)