Checklist de DNS: o que todo sysadmin precisa verificar

18 min de leitura  ·  Guia técnico

Checklist de DNS é um conjunto estruturado de verificações que todo administrador de sistemas deve executar para garantir que os registros de um domínio estejam corretos, seguros e propagados adequadamente. Para auditar o DNS do seu domínio de forma completa, siga estes passos:

1. Verifique os registros A, AAAA e CNAME apontando para os IPs corretos.
2. Confirme os registros MX e a prioridade dos servidores de email.
3. Valide os registros SPF, DKIM e DMARC para autenticação de email.
4. Teste a resolução DNS com dig e nslookup a partir de múltiplos resolvedores.
5. Verifique o TTL de cada registro e ajuste conforme a necessidade.
6. Confirme se o DNSSEC está ativo e as assinaturas são válidas.

Pré-requisitos para executar o checklist de DNS

• Acesso ao painel do registrador de domínio (ex: Registro.br, GoDaddy, Cloudflare).
• Acesso SSH ao servidor Linux (Debian 12, Rocky Linux 9 ou AlmaLinux 9 recomendados).
• Pacotes bind-utils (Red Hat/Rocky/Alma) ou dnsutils (Debian/Ubuntu) instalados.
• Permissão para editar registros DNS no servidor autoritativo ou no painel de hospedagem.
• Conhecimento básico de linha de comando Linux.

Checklist de DNS: verificação dos registros fundamentais (A, AAAA, CNAME)

Os registros fundamentais de DNS determinam para onde o tráfego do seu domínio é direcionado. Um erro aqui derruba o site inteiro, por isso esta é a primeira etapa do checklist de DNS que todo sysadmin deve executar.

Para verificar o registro A do domínio raiz, execute:

dig A seudominio.com.br +short

203.0.113.45

O IP retornado deve corresponder ao IP do seu servidor web. Se retornar um IP diferente ou nenhum resultado, o registro A está incorreto ou ainda não propagou.

Para verificar o registro AAAA (IPv6):

dig AAAA seudominio.com.br +short

2001:db8::1

Se o servidor não tiver IPv6 configurado, o registro AAAA não deve existir — sua presença com um IP inválido pode causar falhas de conexão em clientes que preferem IPv6.

Para verificar subdomínios com CNAME:

dig CNAME www.seudominio.com.br +short

seudominio.com.br.

Lembre-se: CNAME não pode ser usado no apex do domínio (o domínio raiz sem subdomínio). Use sempre um registro A ou AAAA na raiz. Para subdomínios como www, mail ou ftp, o CNAME é válido e prático.

Itens a confirmar nesta etapa:

• Registro A da raiz aponta para o IP correto do servidor web.
• Registro A de www ou CNAME de www aponta para a raiz ou IP correto.
• Registro AAAA existe apenas se o servidor tiver IPv6 funcional.
• CNAMEs de subdomínios não apontam para domínios inexistentes ou expirados.
• Nenhum CNAME está configurado no apex do domínio.

Para gerenciar esses registros diretamente no painel da AviraHost, consulte o artigo Como Configurar DNS Personalizado para Seu Domínio na AviraHost.

Verificação dos registros MX e entregabilidade de email

A configuração incorreta dos registros MX é uma das causas mais comuns de perda de emails em produção. Esta seção do checklist de DNS cobre a verificação completa da cadeia de entregabilidade.

Para listar os registros MX do domínio:

dig MX seudominio.com.br

;; ANSWER SECTION:
seudominio.com.br.  3600  IN  MX  10 mail.seudominio.com.br.
seudominio.com.br.  3600  IN  MX  20 mail2.seudominio.com.br.

O número antes do hostname é a prioridade: menor número = maior prioridade. O servidor com prioridade 10 será tentado primeiro; o 20 é o fallback.

Confirme que o hostname do MX resolve para um IP válido:

dig A mail.seudominio.com.br +short

203.0.113.45

Agora verifique os registros de autenticação de email — SPF, DKIM e DMARC:

SPF (Sender Policy Framework):

dig TXT seudominio.com.br +short | grep spf

"v=spf1 ip4:203.0.113.45 include:_spf.google.com ~all"

O registro SPF deve listar todos os IPs e serviços autorizados a enviar email pelo seu domínio. O mecanismo ~all (softfail) é mais permissivo; use -all (hardfail) em produção para rejeitar emails não autorizados.

DKIM (DomainKeys Identified Mail):

dig TXT default._domainkey.seudominio.com.br +short

"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ..."

O seletor (default no exemplo) varia conforme o servidor de email. Consulte o painel do seu servidor de email para identificar o seletor correto.

DMARC:

dig TXT _dmarc.seudominio.com.br +short

"v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100"

Itens a confirmar nesta etapa:

• Pelo menos um registro MX existe e resolve para IP válido.
• Registro SPF existe como TXT na raiz do domínio.
• Registro DKIM existe no subdomínio correto com a chave pública.
• Registro DMARC existe em _dmarc.seudominio.com.br.
• Nenhum MX aponta para um CNAME (viola a RFC 2181).

Verificação do TTL e planejamento de alterações de DNS

O TTL (Time to Live) define por quantos segundos os resolvedores DNS ao redor do mundo podem armazenar em cache um registro. Um TTL mal configurado pode fazer com que alterações demorem horas para propagar — ou que o cache expire rápido demais, aumentando a carga no servidor autoritativo.

Para verificar o TTL atual de um registro:

dig A seudominio.com.br

;; ANSWER SECTION:
seudominio.com.br.  86400  IN  A  203.0.113.45

O número 86400 representa 24 horas em segundos. Este é um valor adequado para registros estáveis em produção.

Valores de TTL recomendados por cenário:

• Produção estável: 3600 a 86400 segundos (1 a 24 horas).
• Antes de uma migração planejada: reduza para 300 segundos (5 minutos) com 24 horas de antecedência.
• Após a migração concluída: restaure para 3600 ou 86400 segundos.
• Registros MX: 3600 segundos é o padrão recomendado.
• Registros TXT (SPF, DKIM, DMARC): 3600 segundos.

Para verificar o TTL atual de todos os registros de uma zona de forma rápida, use:

dig ANY seudominio.com.br +noall +answer

Atenção: alguns resolvedores modernos ignoram a query ANY por questões de segurança. Prefira consultar cada tipo de registro individualmente em ambientes de produção.

Verificação de DNSSEC e segurança dos registros DNS

O DNSSEC (Domain Name System Security Extensions) protege contra ataques de envenenamento de cache, garantindo que os registros DNS retornados são autênticos e não foram adulterados no caminho. Esta é uma das verificações mais negligenciadas no checklist de DNS de sysadmins.

Para verificar se o DNSSEC está ativo no domínio:

dig DS seudominio.com.br +short

12345 8 2 ABC123DEF456...

Se o comando retornar vazio, o DNSSEC não está configurado. Para validar a cadeia de confiança completa:

dig A seudominio.com.br +dnssec +short

Verifique também o registro DNSKEY:

dig DNSKEY seudominio.com.br +short

257 3 8 AwEAAb3...
256 3 8 AwEAAc4...

O flag 257 indica a KSK (Key Signing Key) e o flag 256 indica a ZSK (Zone Signing Key). Ambas devem estar presentes em uma zona DNSSEC corretamente configurada.

Para testar a validação DNSSEC usando o resolvedor do Google:

dig @8.8.8.8 seudominio.com.br +dnssec

Procure pelo flag ad (Authenticated Data) na seção de flags da resposta:

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

A presença do flag ad confirma que a resposta foi validada com sucesso pelo DNSSEC.

Itens a confirmar nesta etapa:

• Registro DS existe na zona pai (TLD) e corresponde ao DNSKEY da zona filha.
• KSK e ZSK estão presentes e válidos.
• Flag ad aparece nas respostas de resolvedores validadores.
• A renovação automática das assinaturas DNSSEC está configurada no servidor autoritativo.

Diagnóstico de resolução DNS no servidor Linux

Quando um domínio não resolve corretamente a partir do servidor, o problema pode estar no resolvedor local, nos servidores recursivos configurados ou na própria zona DNS. Esta seção cobre o diagnóstico completo de resolução DNS em servidores Linux.

Primeiro, verifique o arquivo de configuração do resolvedor local:

cat /etc/resolv.conf

nameserver 8.8.8.8
nameserver 1.1.1.1
search seudominio.com.br

Em servidores com systemd-resolved (Ubuntu 22.04+, Debian 12), o arquivo /etc/resolv.conf pode ser um symlink. Verifique o estado real do resolvedor:

systemd-resolve --status | head -40

Global
       Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 8.8.8.8
       DNS Servers: 8.8.8.8 1.1.1.1

Para testar a resolução forçando um resolvedor específico (útil para comparar resultados):

dig @8.8.8.8 seudominio.com.br A
dig @1.1.1.1 seudominio.com.br A
dig @208.67.222.222 seudominio.com.br A

Se os resultados divergirem entre resolvedores, a propagação ainda está em andamento. Se todos retornarem o mesmo IP errado, o problema está na zona DNS autoritativa.

Para identificar qual servidor é autoritativo para o domínio:

dig NS seudominio.com.br +short

ns1.avirahost.com.br.
ns2.avirahost.com.br.

Consulte diretamente o servidor autoritativo para ver o estado real da zona:

dig @ns1.avirahost.com.br seudominio.com.br A +short

Se o autoritativo retornar o valor correto mas os resolvedores públicos ainda retornarem o antigo, é questão de aguardar o TTL expirar.

Para verificar o caminho completo de resolução (trace):

dig +trace seudominio.com.br A

Este comando mostra cada etapa da resolução, desde os root servers até o servidor autoritativo, permitindo identificar exatamente onde a cadeia quebra.

Para mais informações sobre como gerenciar domínios no painel, consulte o artigo Como gerenciar um domínio.

Verificação de registros especiais: CAA, PTR e SRV

Além dos registros básicos, um checklist de DNS completo deve incluir a verificação de registros especiais que impactam segurança SSL, reputação de email e serviços específicos.

Registro CAA (Certification Authority Authorization):

O CAA define quais autoridades certificadoras podem emitir certificados SSL para o domínio. Sem ele, qualquer CA pode emitir um certificado — o que representa um risco de segurança.

dig CAA seudominio.com.br +short

0 issue "letsencrypt.org"
0 issuewild "letsencrypt.org"
0 iodef "mailto:[email protected]"

Registro PTR (Reverse DNS):

O PTR é o DNS reverso — mapeia um IP para um hostname. É fundamental para a reputação do servidor de email: servidores sem PTR configurado têm emails frequentemente rejeitados como spam.

dig -x 203.0.113.45 +short

mail.seudominio.com.br.

O PTR deve corresponder ao hostname configurado no HELO/EHLO do servidor de email. Esta configuração é feita no painel do provedor de hospedagem ou VPS, não no painel DNS do domínio.

Registro SRV (Service):

Usado por serviços como SIP, XMPP e Microsoft Teams/Skype for Business:

dig SRV _sip._tcp.seudominio.com.br +short

10 20 5060 sip.seudominio.com.br.

Itens a confirmar nesta etapa:

• Registro CAA existe e lista apenas as CAs autorizadas.
• DNS reverso (PTR) do IP do servidor de email aponta para o hostname correto.
• PTR e registro A são consistentes (forward-confirmed reverse DNS).
• Registros SRV existem para todos os serviços que os requerem.

Problemas comuns e como resolver

Sintoma: domínio não resolve após alteração de registros DNS

Causa: O TTL do registro anterior ainda não expirou nos resolvedores recursivos ao redor do mundo. Resolvedores como o 8.8.8.8 e 1.1.1.1 armazenam em cache os registros pelo tempo definido no TTL anterior.
Solução: Aguarde o TTL expirar. Use dig seudominio.com.br +ttl para ver quanto tempo resta no cache. Para futuras alterações, reduza o TTL para 300 segundos com 24 horas de antecedência. Você pode verificar a propagação global em ferramentas como o DNSChecker.org.

Sintoma: emails sendo rejeitados ou marcados como spam

Causa: Registros SPF ausentes ou incorretos, DKIM não configurado, DMARC faltando, ou DNS reverso (PTR) do IP do servidor de email não configurado.
Solução: Execute dig TXT seudominio.com.br +short e confirme a presença do SPF. Verifique o DKIM com o seletor correto do seu servidor de email. Configure o PTR no painel do seu provedor VPS. Use o MXToolbox Email Health para um diagnóstico completo.

Sintoma: certificado SSL não emite — erro de validação de domínio

Causa: O registro CAA está configurado e não inclui a CA que está tentando emitir o certificado. Ou o registro A do domínio não aponta para o servidor onde a validação HTTP está sendo feita.
Solução: Execute dig CAA seudominio.com.br +short e adicione a CA necessária (ex: letsencrypt.org). Confirme que o registro A aponta para o servidor correto antes de solicitar o certificado. Para mais detalhes sobre redirecionamento HTTP/HTTPS, veja o artigo Como redirecionar um site http para https.

Sintoma: dig +trace para na delegação e não chega ao autoritativo

Causa: Os nameservers configurados no registrador de domínio não correspondem aos nameservers reais da zona, ou os nameservers estão inacessíveis.
Solução: Execute dig NS seudominio.com.br @a.dns.br +short para ver os NS registrados no TLD. Compare com os NS configurados no seu painel DNS. Se divergirem, atualize os nameservers no registrador. Aguarde a propagação (pode levar até 48 horas para alterações de NS).

Sintoma: DNSSEC com flag ad ausente ou erro SERVFAIL

Causa: As assinaturas DNSSEC expiraram (comum quando a renovação automática não está configurada), ou o registro DS na zona pai não corresponde ao DNSKEY atual.
Solução: Verifique a validade das assinaturas com dig DNSKEY seudominio.com.br +dnssec. Se as assinaturas expiraram, re-assine a zona no servidor DNS autoritativo. Confirme que o DS no registrador corresponde ao DNSKEY atual. Em caso de emergência, desative temporariamente o DNSSEC no registrador para restaurar a resolução.

Perguntas frequentes sobre checklist de DNS

Quanto tempo leva a propagação de DNS após uma alteração?

A propagação de DNS pode levar de alguns minutos até 48 horas, dependendo do TTL configurado no registro anterior e dos servidores recursivos ao redor do mundo. Para acelerar, reduza o TTL para 300 segundos (5 minutos) pelo menos 24 horas antes de fazer a alteração. Após a mudança, restaure o TTL para um valor entre 3600 e 86400 segundos. Ferramentas online de verificação de propagação permitem monitorar o avanço em diferentes regiões geográficas simultaneamente.

O que é DNSSEC e por que devo ativar no meu domínio?

DNSSEC (Domain Name System Security Extensions) é um conjunto de extensões que adiciona assinaturas criptográficas aos registros DNS, impedindo ataques de envenenamento de cache (DNS spoofing). Sem DNSSEC, um atacante pode redirecionar usuários para servidores falsos sem que eles percebam. A ativação é feita no painel do registrador de domínio e no servidor DNS autoritativo. Uma vez ativo, monitore a renovação automática das assinaturas para evitar interrupções de serviço.

Como verificar se os registros MX estão configurados corretamente?

Execute o comando dig MX seudominio.com.br no terminal Linux ou use ferramentas online como MXToolbox. O output deve listar os servidores de email com suas prioridades numéricas (menor número = maior prioridade). Confirme também que os registros A ou CNAME apontados pelos MX resolvem para IPs válidos dos seus servidores de email. Lembre-se que registros MX não podem apontar para CNAMEs — isso viola a RFC e causa falhas de entrega.

Qual é a diferença entre registro A, AAAA e CNAME no DNS?

O registro A mapeia um hostname para um endereço IPv4 (ex: 192.168.1.1). O registro AAAA faz o mesmo para IPv6 (ex: 2001:db8::1). O CNAME cria um alias que aponta para outro hostname, não para um IP diretamente — por isso não pode ser usado na raiz do domínio (apex). Use CNAME para subdomínios que precisam seguir o IP de outro hostname automaticamente, como www apontando para o domínio raiz.

Como diagnosticar falha de resolução DNS em um servidor Linux?

Comece verificando o arquivo /etc/resolv.conf para confirmar quais servidores DNS recursivos estão configurados. Em seguida, execute dig @8.8.8.8 seudominio.com.br para testar a resolução via DNS público do Google. Se o resultado divergir do esperado, verifique os registros no painel do registrador e aguarde a propagação. O comando systemd-resolve --status mostra o estado do resolvedor local no Ubuntu e Debian, incluindo o servidor DNS ativo e o modo de operação.

Conclusão

Executar um checklist de DNS completo regularmente é uma das práticas mais importantes para garantir a disponibilidade e segurança de qualquer domínio em produção. Os pontos críticos a revisar periodicamente são:

• Registros A, AAAA, CNAME e MX: verifique mensalmente se ainda apontam para os destinos corretos, especialmente após migrações de servidor ou mudanças de provedor de email.
• Autenticação de email (SPF, DKIM, DMARC) e DNS reverso (PTR): revise sempre que adicionar um novo serviço de envio de email ou migrar o servidor de email.
• DNSSEC e CAA: monitore a validade das assinaturas DNSSEC e mantenha o registro CAA atualizado com as CAs autorizadas para emitir certificados SSL no domínio.

Leia também

• Otimizar a propagação de DNS: por que demora e como acelerar
• Solucionar problemas de DNS no VPS Linux gratuito vs pago: vale a pena investir em 2025?
• Qual servidor DNS escolher para VPS Linux: comparativo direto

Precisa de ajuda com DNS e infraestrutura de servidores?

Configurar e manter DNS corretamente exige atenção a detalhes que podem impactar diretamente a disponibilidade do seu site e a entregabilidade dos seus emails. A AviraHost oferece servidores VPS com suporte técnico especializado para ajudar na configuração e auditoria de DNS, garantindo que sua infraestrutura esteja sempre operando corretamente.

Conheça os planos de VPS da AviraHost