DNS para servidores: resolução de nomes, zonas, registros e falhas comuns

O que é DNS (na prática de servidores)

DNS (Domain Name System) é o serviço que traduz nomes (como api.exemplo.com) em dados utilizáveis por aplicações, principalmente endereços IP, mas também informações de e-mail, autenticação e descoberta de serviços. Em servidores, DNS é parte do caminho crítico: se o nome não resolve, o serviço “cai” mesmo que a rede e o host estejam saudáveis.

Quando você configura um servidor para falar com db.interno.local ou quando um cliente tenta acessar www.exemplo.com, o DNS define: para onde conectar, por quanto tempo confiar na resposta (TTL) e qual servidor é a fonte autoritativa daquela informação.

Fluxo de resolução: stub resolver, recursivo e autoritativo

1) Stub resolver (no cliente/servidor que faz a consulta)

O stub resolver é o componente local que inicia a consulta DNS. Em Linux, ele pode ser parte da libc (via getaddrinfo()) e usar /etc/resolv.conf (ou systemd-resolved) para saber para quais servidores DNS enviar a pergunta. Em Windows, é o DNS Client Service.

• O stub normalmente não “varre a internet”; ele pergunta a um servidor recursivo configurado.
• Ele pode ter cache local (dependendo do sistema/serviço) e respeita TTL.

2) Resolvedor recursivo (recursive resolver)

O resolvedor recursivo recebe a pergunta do stub e faz o trabalho completo para encontrar a resposta. Ele pode ser um DNS corporativo (ex.: BIND/Unbound) ou um serviço do provedor. Ele também mantém cache, o que acelera consultas repetidas e reduz carga.

Se não tiver a resposta em cache, ele consulta a hierarquia DNS: servidores raiz, TLD (como .com) e, por fim, os servidores autoritativos do domínio.

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

3) Servidor autoritativo (authoritative)

O autoritativo é a fonte oficial dos registros de uma zona. Ele responde com autoridade para nomes dentro daquela zona (por exemplo, exemplo.com). Ele não precisa fazer recursão; ele responde com base nos dados configurados (zona primária/ secundária, ou backend dinâmico).

Fluxo resumido (visão operacional)

Aplicação → Stub resolver → DNS recursivo (cache) → (se necessário) raiz/TLD → DNS autoritativo → resposta → cache → aplicação

Cache e TTL: por que “demora para propagar”

TTL (Time To Live) é um campo do registro DNS que diz por quantos segundos aquela resposta pode ser mantida em cache. O cache existe em múltiplos pontos:

• No resolvedor recursivo (mais comum e impactante).
• No sistema operacional (stub/local cache, dependendo do ambiente).
• Em aplicações (algumas bibliotecas e runtimes fazem cache próprio).

Consequência prática: ao alterar um registro (por exemplo, trocar o IP de app.exemplo.com), clientes podem continuar usando o valor antigo até o TTL expirar em todos os caches envolvidos.

Boas práticas com TTL em mudanças

• Antes de uma migração planejada, reduza o TTL (por exemplo, de 3600 para 300) com antecedência maior que o TTL atual, para “drenar” caches antigos.
• Após estabilizar, aumente o TTL para reduzir consultas e melhorar performance.

Zonas DNS: forward, reverse e delegação

Zonas forward (nome → dado, geralmente IP)

Uma zona forward contém registros para resolver nomes como srv01.exemplo.com em um endereço (A/AAAA) ou em outro nome (CNAME), além de registros de e-mail, verificação e serviços.

Zonas reverse (IP → nome, PTR)

Uma zona reverse permite consultar um IP e obter um nome via registro PTR. Isso é usado em:

• E-mail: muitos servidores de e-mail verificam se o IP de origem tem reverse válido e coerente com o HELO/EHLO e/ou com o forward.
• Logs e auditoria: sistemas registram nomes a partir de IPs para facilitar investigação.
• Autenticação e controles: alguns sistemas fazem validações baseadas em nomes (ex.: listas de acesso, integrações legadas), e inconsistências podem causar falhas intermitentes.

Reverse em IPv4 usa a zona in-addr.arpa (ex.: 203.0.113.10 vira consulta para 10.113.0.203.in-addr.arpa). Em IPv6 usa ip6.arpa (nibbles hex invertidos).

Delegação e autoridade

Um domínio pode delegar subdomínios para outros servidores autoritativos via registros NS. Isso é comum ao separar corp.exemplo.com de exemplo.com, ou ao usar provedores diferentes para DNS público e interno.

Registros essenciais para servidores (com exemplos)

A e AAAA (nome → IP)

A aponta para IPv4 e AAAA para IPv6.

app.exemplo.com.   300   IN   A      203.0.113.10
app.exemplo.com.   300   IN   AAAA   2001:db8::10

Uso típico: endpoints HTTP(S), SSH, bancos de dados, balanceadores.

CNAME (alias de nome)

CNAME faz um nome apontar para outro nome. O cliente resolve o CNAME e depois resolve o alvo.

www.exemplo.com.   300   IN   CNAME  app.exemplo.com.

• Evite CNAME no apex (raiz) do domínio (exemplo.com), a menos que use recursos específicos (ALIAS/ANAME) do provedor.
• CNAME não pode coexistir com outros registros no mesmo nome (regra importante para evitar erros).

MX (roteamento de e-mail)

MX define quais hosts recebem e-mail para o domínio e suas prioridades.

exemplo.com.      3600  IN   MX   10  mx1.exemplo.com.
exemplo.com.      3600  IN   MX   20  mx2.exemplo.com.

O host apontado por MX deve ter A/AAAA válidos. Muitos problemas de e-mail vêm de MX apontando para nome inexistente ou com IP errado.

TXT (verificações e políticas)

TXT é usado para metadados e validações. Em servidores, é muito comum para e-mail e autenticação/validação de domínio.

exemplo.com.  3600 IN TXT "v=spf1 ip4:203.0.113.10 -all"

Também é usado para validação de certificados, integrações e políticas como DKIM/DMARC (dependendo do cenário).

SRV (descoberta de serviços)

SRV permite que clientes descubram host e porta de um serviço, com prioridade e peso. Muito usado em ambientes corporativos (ex.: LDAP, SIP, alguns serviços internos).

_ldap._tcp.corp.exemplo.com.  300 IN SRV 10 50 389 dc1.corp.exemplo.com.
_ldap._tcp.corp.exemplo.com.  300 IN SRV 10 50 389 dc2.corp.exemplo.com.

Se SRV estiver errado, o cliente pode até “resolver”, mas conectar na porta errada ou no host errado.

PTR (reverse: IP → nome)

PTR vive na zona reverse e aponta o IP para um nome canônico.

10.113.0.203.in-addr.arpa.  3600 IN PTR mail.exemplo.com.

Para e-mail, é comum exigir coerência: o IP do servidor tem PTR para mail.exemplo.com e o forward de mail.exemplo.com aponta de volta para o mesmo IP.

Forward x Reverse: impacto direto em e-mail, autenticação e logs

E-mail (entrega e reputação)

• Reverse ausente: muitos destinos marcam como suspeito ou rejeitam.
• Reverse inconsistente: PTR aponta para um nome que não resolve (sem A/AAAA) ou resolve para outro IP.
• SPF/DKIM/DMARC (via TXT): políticas incorretas causam falhas de autenticação e queda de entrega.

Autenticação e serviços internos

Serviços que dependem de descoberta (SRV) ou de nomes canônicos podem falhar de forma intermitente quando:

• O cliente recebe respostas diferentes dependendo do DNS (split-horizon).
• Há cache com TTL longo e mudanças recentes.
• Há múltiplos registros (A/AAAA) e o cliente tenta primeiro o endereço “ruim”.

Logs e observabilidade

Ferramentas de log podem fazer reverse lookup para “humanizar” IPs. Se o reverse estiver errado ou lento, você terá:

• Logs com nomes incorretos (atrapalha investigação).
• Latência extra em pipelines que fazem lookup síncrono.

Cenários práticos de falhas e como diagnosticar

Ferramentas de validação (consultas e leitura de resposta)

Use consultas diretas para entender quem está respondendo, o que está respondendo e por quanto tempo a resposta é cacheável.

• dig (Linux/macOS): excelente para ver se a resposta é autoritativa, TTL, seção ANSWER/AUTHORITY/ADDITIONAL.
• nslookup: disponível em muitos sistemas, útil para checagens rápidas.
• Resolve-DnsName (PowerShell): detalhado no Windows.

Exemplos com dig:

# Consulta padrão (usa o resolvedor configurado)
dig app.exemplo.com A

# Consultar um DNS específico (ex.: recursivo corporativo)
dig @10.0.0.53 app.exemplo.com A

# Ver o caminho de delegação (útil para achar onde está o erro)
dig +trace app.exemplo.com

# Consultar MX e TXT
dig exemplo.com MX
dig exemplo.com TXT

# Reverse lookup (PTR)
dig -x 203.0.113.10

O que observar na resposta:

• STATUS: NOERROR, NXDOMAIN, SERVFAIL.
• ANSWER: registros retornados e seus TTLs.
• flags: aa (authoritative answer), rd (recursion desired), ra (recursion available).
• SERVER: qual servidor respondeu (para detectar split-horizon ou DNS errado).

Cenário 1: “Nome não resolve”

Sintoma: aplicação retorna erro de DNS (ex.: Temporary failure in name resolution, NXDOMAIN, no such host).

Causas comuns

• Nome inexistente na zona (registro não criado).
• Cliente usando DNS errado (resolv.conf apontando para servidor inválido).
• Autoritativo indisponível ou com erro (gera SERVFAIL via recursivo).
• Delegação quebrada (NS incorreto, glue faltando).
• Firewall bloqueando UDP/TCP 53 entre cliente e resolvedor (ou entre recursivo e autoritativos).

Passo a passo de diagnóstico

1. Verifique o DNS configurado no host (para saber para onde o stub está perguntando).

   # Linux
   cat /etc/resolv.conf
   
   # systemd-resolved (se aplicável)
   resolvectl status

2. Teste a resolução no resolvedor configurado e observe o status.

   dig app.exemplo.com A

3. Compare com um resolvedor alternativo (por exemplo, outro DNS corporativo). Se um resolve e outro não, o problema é no resolvedor/caminho, não no domínio em si.

   dig @10.0.0.53 app.exemplo.com A
   dig @10.0.0.54 app.exemplo.com A

4. Se for domínio público, use +trace para localizar onde quebra (delegação/autoridade).

   dig +trace app.exemplo.com

5. Se o erro for SERVFAIL, suspeite de DNSSEC mal configurado, timeouts para autoritativos, ou falha no recursivo. Verifique logs do recursivo (Unbound/BIND) e conectividade TCP/UDP 53 para os autoritativos.

Cenário 2: “Resolve para IP antigo”

Sintoma: o nome resolve, mas aponta para um IP que já não deveria estar em uso (migração de serviço, troca de load balancer, failover).

Causas comuns

• Cache no recursivo ainda não expirou (TTL alto).
• Cache local no host/aplicação.
• Existem múltiplos registros A/AAAA e o cliente escolhe um “antigo”.
• Split-horizon: interno resolve para um IP, externo para outro, e você está testando no lugar errado.

Passo a passo de diagnóstico

1. Veja o TTL retornado e compare com o esperado.

   dig app.exemplo.com A

2. Consulte diretamente o autoritativo (se você souber qual é) para ver a “verdade” da zona, sem influência do cache do recursivo.

   # Descobrir NS
    dig exemplo.com NS
   
   # Consultar um NS diretamente
    dig @ns1.exemplo.com app.exemplo.com A

3. Limpe caches quando aplicável (com cuidado em produção):

   • No recursivo (BIND/Unbound): flush seletivo do nome pode ser possível.
   • No host: reiniciar serviço de resolvedor local (ex.: systemd-resolved) ou limpar cache do Windows DNS Client.
   • Na aplicação: reiniciar pode ser necessário se ela cacheia DNS.

4. Cheque se há múltiplos A/AAAA e se algum ainda é antigo.

   dig app.exemplo.com A
   dig app.exemplo.com AAAA

Cenário 3: Split-horizon (DNS diferente para rede interna e externa)

Definição: split-horizon (ou split-brain DNS) é quando o mesmo nome retorna respostas diferentes dependendo de onde a consulta vem (rede interna vs internet). Isso é comum para:

• Expor app.exemplo.com externamente via IP público, mas internamente via IP privado.
• Manter nomes internos não roteáveis publicamente (ex.: db.corp.exemplo.com).

Riscos e falhas comuns

• Usuários em VPN resolvem pelo DNS “errado” e tentam acessar IP público por dentro (ou vice-versa).
• Certificados e validações dependem do nome; se o tráfego vai para o destino errado, pode haver erro de TLS.
• Serviços internos (como LDAP via SRV) podem apontar para hosts inacessíveis fora do segmento esperado.

Como validar split-horizon corretamente

1. Teste a resolução a partir de cada contexto (um host interno e um externo) e compare.

   # Interno
    dig @10.0.0.53 app.exemplo.com A
   
   # Externo (ou usando um resolvedor público)
    dig @1.1.1.1 app.exemplo.com A

2. Confirme qual servidor DNS respondeu (campo SERVER no dig) para garantir que você está testando o caminho certo.

3. Verifique consistência de registros críticos entre visões (por exemplo, MX/TXT geralmente devem ser públicos e consistentes; já A/AAAA podem variar conforme a estratégia).

Validação de forward e reverse para serviços críticos

Checklist prático para um servidor de e-mail

Checklist prático para autenticação/serviços via SRV (ex.: LDAP)

Interpretação de respostas: NXDOMAIN, NOERROR, SERVFAIL

NXDOMAIN

O nome consultado não existe. Normalmente indica registro ausente ou consulta ao domínio errado (typo, sufixo de busca, ambiente interno vs externo).

NOERROR (com resposta vazia)

O domínio existe, mas não há aquele tipo de registro. Exemplo: NOERROR sem ANSWER para AAAA pode ser normal se só há A. Para e-mail, NOERROR sem MX pode significar que o domínio não recebe e-mail (ou que usará fallback para A, dependendo do servidor remetente).

SERVFAIL

Falha ao obter resposta válida. Pode indicar indisponibilidade de autoritativos, problemas de rede, timeouts, ou validação (como DNSSEC) falhando no recursivo. Em ambiente corporativo, também pode ocorrer por políticas de bloqueio/filtragem no resolvedor.

Dicas operacionais para reduzir incidentes de DNS em servidores

• Padronize TTLs por tipo de registro (curto para endpoints que mudam, maior para registros estáveis).
• Documente split-horizon: quais nomes têm visão interna/externa e quais registros devem ser idênticos.
• Evite dependência de um único resolvedor: configure redundância (dois recursivos) e monitore latência/erros.
• Monitore registros críticos (A/AAAA de serviços, MX/TXT de e-mail, SRV de autenticação) com checagens periódicas e alerta em mudança inesperada.
• Ao migrar serviços, reduza TTL antes, valide autoritativo diretamente, e teste de múltiplas redes (interna, VPN, externa).