O DNS (Domain Name System) é a fundação invisível de toda a infraestrutura de rede moderna — resolve nomes em endereços IP, encaminha email, valida identidades e suporta centenas de outros serviços. Quando o DNS falha, tudo falha: websites, email, autenticação, VPN, Microsoft 365. Paradoxalmente, é também um dos sistemas menos compreendidos em detalhe pelos profissionais de IT.

Este artigo é uma referência completa para sysadmins e helpdesk — cobre todos os tipos de registo DNS relevantes para ambientes empresariais, como interpretar uma zona DNS, as ferramentas de diagnóstico essenciais e os problemas mais comuns com procedimento de resolução.

1. Como o DNS funciona — resolução iterativa e recursiva

Quando um utilizador escreve www.empresa.pt no browser, desencadeia-se uma cadeia de consultas DNS que demora tipicamente alguns milissegundos:

Passo O que acontece Resposta
1 Browser verifica cache local (hosts file + cache do SO) Se encontrar → resposta imediata
2 Consulta o resolver recursivo configurado (ex: 8.8.8.8 ou DNS do ISP) O resolver verifica a sua própria cache
3 Resolver pergunta aos Root Servers: “Quem gere .pt?” Referência para os servidores TLD .pt (FCCN)
4 Resolver pergunta ao TLD .pt: “Quem gere empresa.pt?” Referência para os nameservers autoritativos de empresa.pt
5 Resolver pergunta ao nameserver autoritativo: “Qual o IP de www.empresa.pt?” Resposta definitiva com o IP — guardada em cache pelo TTL

2. Tipos de registos DNS — referência completa

Tipo Função Exemplo Nota
A Nome → IPv4 www → 1.2.3.4 O registo mais fundamental — múltiplos A por nome para load balancing
AAAA Nome → IPv6 www → 2001:db8::1 IPv6 — equivalente ao A para IPv6. Crescentemente necessário
CNAME Alias para outro nome mail → empresa.pt Não pode coexistir com outros registos no mesmo nome. Não pode ser usado no apex (@)
MX Servidor de email do domínio @ 10 mail.empresa.pt O número é a prioridade — menor valor = maior prioridade. O valor tem de ser um nome (A record), nunca um IP
TXT Texto livre — SPF, DKIM, DMARC, verificação de domínio @ “v=spf1 include:…” Múltiplos TXT permitidos no mesmo nome. SPF, DKIM e verificações M365 usam TXT
NS Nameservers autoritativos da zona @ ns1.registrar.pt Definido no registar do domínio. Alteração tem impacto global na resolução do domínio
SOA Start of Authority — metadados da zona Serial, Refresh, Retry… Criado automaticamente. Serial deve ser incrementado em cada alteração à zona
PTR IP → Nome (DNS inverso) 4.3.2.1.in-addr.arpa → mail.empresa.pt Gerido pelo dono do bloco IP (ISP). Essencial para entregabilidade de email
SRV Localização de serviço (porta + servidor) _sip._tcp → 5060 sipserver.pt Usado por Lync/Teams, Autodiscover, SIP, LDAP
CAA Autoridade de emissão de certificados SSL @ 0 issue “letsencrypt.org” Define quais CAs podem emitir certificados para o domínio — boa prática de segurança

3. Anatomia de uma zona DNS — SOA, NS e TTL

Uma zona DNS é o conjunto de registos que define um domínio. O registo SOA (Start of Authority) é o primeiro e mais importante — define quem tem autoridade sobre a zona e os parâmetros de sincronização entre servidores DNS primário e secundários.

# Estrutura de um registo SOA completo
empresa.pt. IN SOA ns1.registar.pt. hostmaster.empresa.pt. (
    2024040701  ; Serial — formato YYYYMMDDNN — incrementar em cada alteração
    86400       ; Refresh — segundos antes do secundário verificar alterações (24h)
    7200        ; Retry — segundos de espera se o primário não responder (2h)
    604800      ; Expire — segundos até o secundário parar de responder sem contacto (7 dias)
    300         ; Minimum TTL — TTL de respostas negativas NXDOMAIN (5 min)
)

# Verificar SOA de um domínio
nslookup -type=soa empresa.pt
Resolve-DnsName empresa.pt -Type SOA

TTL — Time To Live

O TTL define quanto tempo os resolvers externos guardam em cache os registos DNS. É fundamental para gerir propagação de alterações:

Cenário TTL recomendado Motivo
Registos estáveis (MX, NS de subdomínios) 3600–86400 (1h–24h) Reduz carga nos nameservers; cache longa acelera resolução
Antes de alterar um registo importante 300 (5 min) — baixar 24–48h antes Acelera a propagação da alteração — o antigo TTL ainda determina quanto tempo leva a propagar
Após confirmar que a alteração propagou Repor para 3600+ TTL muito baixo aumenta a carga nos nameservers e latência de resolução
SPF, DKIM, DMARC (registos TXT de email) 3600 (1h) Equilíbrio entre propagação rápida e carga nos servidores

4. DNS interno vs externo — Split-Brain DNS

Em ambientes empresariais com Active Directory, é comum ter duas zonas DNS para o mesmo domínio: uma interna (no DNS do AD, resolvida pelos PCs dentro da rede) e uma externa (no registar/Cloudflare, resolvida pela Internet). Este modelo chama-se Split-Brain DNS (ou Split-Horizon).

DNS Interno (AD) DNS Externo (Registar / Cloudflare)
Quem usa PCs e servidores dentro da rede LAN Toda a Internet
www.empresa.pt resolve para IP privado do servidor web (192.168.x.x) IP público do servidor web
Registos específicos Servidores internos, DCs, impressoras, ERPs MX, SPF, DKIM, DMARC, Autodiscover
Problema típico Alteração no DNS externo não reflecte no DNS interno — dois lugares para actualizar Não contém IPs privados — correcto

5. Ferramentas de diagnóstico — nslookup, Resolve-DnsName e dig

# ─── NSLOOKUP (Windows/Linux) ────────────────────────────────────────────────
nslookup empresa.pt                          # Registo A do domínio
nslookup -type=mx empresa.pt               # Registos MX
nslookup -type=txt empresa.pt              # Registos TXT (SPF, DKIM, verificações)
nslookup -type=ns empresa.pt               # Nameservers do domínio
nslookup empresa.pt 8.8.8.8                # Consultar especificamente o DNS do Google (bypassar cache local)
nslookup empresa.pt 1.1.1.1                # Consultar especificamente o DNS da Cloudflare

# ─── RESOLVE-DNSNAME (PowerShell — mais legível) ──────────────────────────────
Resolve-DnsName empresa.pt -Type A          # Registo A
Resolve-DnsName empresa.pt -Type MX         # Registos MX ordenados por prioridade
Resolve-DnsName empresa.pt -Type TXT        # Registos TXT
Resolve-DnsName empresa.pt -Server 8.8.8.8  # Usar servidor DNS específico
Resolve-DnsName empresa.pt -NoHostsFile -DnsOnly  # Ignorar cache local e hosts file

# ─── DIG (Linux / WSL / macOS) ───────────────────────────────────────────────
dig empresa.pt                               # Registo A (output detalhado)
dig MX empresa.pt                           # Registos MX
dig TXT empresa.pt                          # Registos TXT
dig empresa.pt +short                       # Apenas o IP, sem output verbose
dig empresa.pt +trace                       # Trace da resolução desde os root servers
dig @8.8.8.8 empresa.pt                    # Usar DNS do Google

# Verificar propagação DNS — comparar dois resolvers
Resolve-DnsName empresa.pt -Server 8.8.8.8     # Google DNS
Resolve-DnsName empresa.pt -Server 1.1.1.1     # Cloudflare DNS

# Limpar cache DNS local (Windows)
ipconfig /flushdns
Clear-DnsClientCache

6. Problemas comuns e resolução

Problema Causa provável Diagnóstico e resolução
Alteração DNS não propagou após 48h TTL elevado do registo antigo; alteração feita no servidor errado Verificar com dig +trace se a alteração chegou ao autoritativo. Confirmar que o SOA serial foi incrementado
NXDOMAIN — nome não existe Registo não existe; zona errada; typo no nome Confirmar registo no painel DNS autoritativo. Verificar se a zona está correcta
SERVFAIL — servidor DNS falhou Nameserver inacessível; DNSSEC inválido; lame delegation Testar cada NS com nslookup. Verificar DNSSEC. Confirmar delegação no registar
Email vai para spam — SPF falha IP de saída não incluído no SPF; dois registos SPF; lookup limit excedido MXToolbox → SPF Lookup → verificar IPs e número de lookups
CNAME e MX/TXT no mesmo nome CNAME não pode coexistir com outros tipos no mesmo hostname Remover o CNAME e substituir por registo A com o IP, ou reorganizar os registos noutro subdomínio
Clientes resolvem IPs diferentes — cache stale TTL antigo em cache nos resolvers dos utilizadores ipconfig /flushdns nos clientes. Aguardar o TTL antigo expirar nos resolvers externos

7. DNS no Windows Server — gestão e logs

# Gerir DNS no Windows Server via PowerShell

# Ver todas as zonas DNS configuradas
Get-DnsServerZone

# Ver todos os registos de uma zona
Get-DnsServerResourceRecord -ZoneName "empresa.pt" | Format-Table -AutoSize

# Adicionar registo A
Add-DnsServerResourceRecordA -ZoneName "empresa.pt" -Name "webapp" -IPv4Address "192.168.1.50" -TimeToLive 01:00:00

# Adicionar registo CNAME
Add-DnsServerResourceRecordCName -ZoneName "empresa.pt" -Name "mail" -HostNameAlias "servidor.empresa.pt"

# Limpar cache do servidor DNS
Clear-DnsServerCache

# Ver log de diagnóstico DNS (Event Viewer)
# Applications and Services Logs → Microsoft → Windows → DNS-Server → Audit
Get-WinEvent -LogName "Microsoft-Windows-DNS-Server/Audit" -MaxEvents 50 |
    Select-Object TimeCreated, Id, Message | Format-List

8. Boas práticas e TTLs recomendados

Boa prática Motivo
Usar Cloudflare ou serviço DNS gerido para domínios externos Alta disponibilidade, Anycast global, DDoS mitigation integrada e propagação rápida
Nunca colocar CNAME no apex do domínio (@) Viola RFC — não é compatível com MX, NS e SOA. Usar registo A ou ALIAS/ANAME se o provider suportar
Ter sempre pelo menos 2 nameservers (NS) para cada zona Redundância — se um falhar, o domínio continua a resolver
Reduzir TTL para 300 s antes de migrações Minimiza o tempo de propagação da alteração e permite rollback rápido
Configurar registo PTR para o IP de saída de email DNS reverso em falta é causa frequente de email marcado como spam
Documentar todas as alterações DNS com data e motivo Problemas de propagação DNS são difíceis de diagnosticar sem histórico de alterações

Este artigo foi útil?

Duarte Spínola

Artigos  

Deixe um Comentário