Módulo 8 · 8.4
Erros comuns
Módulo 8: Segurança e resolução de problemas · Tempo de leitura: 10 minutos
Objetivo de aprendizagem: Após esta lição reconhece os dez erros de DNS mais frequentes pelo seu sintoma e sabe como resolvê-los.
Conceitos-chave: ponto final, nome de domínio duplicado, alterar no sítio errado, dois registos SPF, CNAME no domínio raiz, AAAA esquecido, MX sem endereço, proxy para o e-mail, DS antigo após uma transferência, cache
Como usar esta lição
Os erros abaixo não vêm de um manual, mas de perguntas que os prestadores de hosting recebem todas as semanas. Para cada erro vê: o que o utilizador nota, como o demonstra com uma pergunta, e qual é a solução. Perante um problema, comece sempre com as mesmas duas perguntas: quais os servidores de nomes do domínio (dig +short NS example.com) e o que devolve o servidor de nomes autoritativo (dig @<nameserver> <naam> <type>). Com isso já resolve metade dos casos.
1. Esquecer o ponto final
Sintoma: um CNAME, MX ou NS não funciona; um serviço diz "registo não encontrado".
Demonstração: dig +short CNAME shop.example.com devolve shops.platform.example.example.com.
Causa: numa zona, um nome sem ponto final é relativo: o painel acrescenta o seu próprio domínio no fim (lição 2.2).
Solução: escreva o nome de destino como nome completo com ponto (shops.platform.example.). Alguns painéis colocam o ponto automaticamente; verifique depois de guardar o que está realmente lá.
2. O nome de domínio duplicado no nome
Sintoma: uma verificação ou controlo DKIM num serviço não é bem-sucedida, mesmo com o registo "presente".
Demonstração: dig +short TXT k2._domainkey.example.com não devolve nada, mas dig +short TXT k2._domainkey.example.com.example.com devolve.
Causa: o serviço indica o nome completo (k2._domainkey.example.com) e o seu painel acrescenta o domínio outra vez no fim.
Solução: no campo do nome, preencha apenas a parte antes do seu domínio: k2._domainkey. O painel costuma mostrar o nome completo por baixo do campo: verifique-o.
3. Alterar no sítio errado
Sintoma: altera um registo, mas nada muda, mesmo ao fim de um dia.
Demonstração: dig +short NS example.com devolve servidores de nomes de uma entidade diferente daquela onde alterou (por exemplo, de um construtor de sites ou do Cloudflare).
Causa: só a entidade dos servidores de nomes determina o DNS (lição 2.1). Registos num sítio diferente não têm qualquer efeito.
Solução: altere o registo junto da entidade dos servidores de nomes, ou reponha os servidores de nomes anteriores. Um exemplo real: alguém configurou os servidores de nomes para uma plataforma de construção de sites, mas o registo A para mail não estava lá. Resultado: enviar funcionava, receber não, porque o MX apontava para mail.example.com e esse nome já não existia.
4. Dois registos SPF
Sintoma: o e-mail vai mais vezes para o spam ou é rejeitado, desde que associou um novo serviço.
Demonstração: dig +short TXT example.com devolve duas linhas que começam por v=spf1.
Causa: o novo serviço disse "adicione este registo SPF", e isso foi feito à letra. Com dois registos SPF, o SPF fica inválido (permerror, RFC 7208), o que é pior do que não ter SPF.
Solução: junte-os num único registo: v=spf1 a mx include:_spf.hosting.example include:spf.service.example ~all. Tenha atenção ao limite de dez pesquisas (lição 4.3).
5. Um CNAME no domínio raiz
Sintoma: o painel recusa o registo, ou depois de guardar o seu e-mail deixa de funcionar.
Demonstração: o serviço pede "crie um CNAME para @".
Causa: um CNAME não pode coexistir com outros registos, e no domínio raiz existem sempre registos SOA e NS (e frequentemente MX e TXT). Ver lição 3.2.
Solução: use em @ o registo A (e eventualmente AAAA) indicado pelo serviço, e o CNAME apenas para www ou um subdomínio. Algumas entidades de DNS têm um ALIAS ou "CNAME flattening" para este caso.
6. Esquecer o AAAA numa transferência
Sintoma: após uma transferência, parte dos visitantes (frequentemente em dispositivos móveis) continua a ver o site antigo, ou surge um erro de certificado.
Demonstração: dig +short A example.com devolve o novo endereço, mas dig +short AAAA example.com devolve ainda um endereço do servidor antigo.
Causa: os dispositivos com IPv6 preferem usar o AAAA. Só o A foi alterado.
Solução: altere o AAAA também, ou remova-o se o novo servidor não tiver IPv6. Um exemplo real: ao associar uma plataforma de loja online, além do novo registo A foi necessário remover também o AAAA antigo, caso contrário a loja continuava inacessível para parte dos visitantes.
7. Um MX que não aponta para nada
Sintoma: não recebe e-mail; os remetentes recebem uma mensagem de erro.
Demonstração: dig +short MX example.com devolve 10 mail.example.com., mas dig +short A mail.example.com não devolve nada (NXDOMAIN).
Causa: um MX aponta para um nome, e esse nome tem de ter um registo A ou AAAA. Frequentemente, o registo A para mail desapareceu numa transferência de servidores de nomes. Um MX também não pode apontar para um endereço IP nem para um CNAME (RFC 2181).
Solução: crie um registo A para o nome do servidor de e-mail, ou faça o MX apontar para um nome que tenha um endereço.
8. E-mail noutro lugar, mas o servidor antigo pensa que deve entregar o e-mail
Sintoma: o e-mail externo chega bem ao seu novo fornecedor, mas o e-mail do seu próprio site (formulário de contacto, loja online) nunca chega. Por vezes recebe 550 Unknown user.
Demonstração: o MX aponta para o novo fornecedor, mas no servidor web a entrega local de e-mail ainda está ativa.
Causa: isto não é um erro de DNS, mas parece ser. Um servidor web que pensa ter ele próprio as caixas de correio não olha para o MX.
Solução: desative a entrega local no painel do seu alojamento (no DirectAdmin: a opção "Use this server to handle my e-mails"). Outros painéis têm uma definição semelhante, frequentemente "Remote mail exchanger" ou "e-mail externo".
9. Proxy ativo para o e-mail
Sintoma: numa entidade de DNS com função de proxy (como a nuvem laranja no Cloudflare), o site funciona, mas o seu programa de e-mail não consegue ligar-se, ou o certificado do site não é renovado.
Demonstração: dig +short A mail.example.com devolve um endereço do proxy em vez do seu servidor de e-mail.
Causa: um proxy web apenas encaminha tráfego web, não e-mail.
Solução: desative o proxy (nuvem cinzenta, "DNS only") para mail e todos os nomes usados pelo seu programa de e-mail. Para certificados: desative o proxy temporariamente até o certificado estar emitido, ou use o modo SSL correto no proxy.
10. DS antigo após uma transferência
Sintoma: após uma transferência de servidores de nomes, o seu domínio fica inacessível para parte do mundo; outras pessoas não notam nada.
Demonstração: dig example.com @1.1.1.1 devolve SERVFAIL, dig +cd example.com @1.1.1.1 devolve uma resposta. O DNSViz (https://dnsviz.net/, lição 8.1) assinala o DS a vermelho e desenha por baixo uma chave cinzenta e tracejada que já não está na sua zona. O Zonemaster e o Verisign DNSSEC Debugger reportam o mesmo por palavras.
Causa: na registry ainda está o DS da entidade anterior (lição 8.1). Só os resolvers validadores falham, por isso nem todos notam.
Solução: atualize o DS com a chave da nova entidade, ou remova-o e volte a ativar o DNSSEC depois.
E o "erro" que não é um erro: a cache
Muitas vezes está tudo correto, mas continua a ver a resposta antiga. Reconhece-se assim: dig @<nameserver> devolve a resposta nova, um verificador online noutros países também, só o seu computador não. Solução: janela privada, telemóvel via 4G/5G, ou limpar a cache (lição 8.2). Também uma linha esquecida no ficheiro hosts do seu computador (de um teste anterior a uma transferência) dá este mesmo resultado: remova essa linha.
Uma armadilha relacionada: pedir um nome novo antes de o ter criado. O resolver guarda então "não existe" (cache negativa) e demora mais tempo até o nome novo funcionar (lição 6.2).
Na prática: é assim que se apresenta num painel
Muitos painéis evitam parte destes erros. O meu WebOké, por exemplo, avisa quando falta o ponto final e mostra por baixo do campo do nome o nome completo; o DirectAdmin recusa registos inválidos com "Error Writing Records". O Cloudflare e outras entidades têm avisos semelhantes. Antes de alterações maiores, faça uma cópia de segurança ou exportação da sua zona, para poder sempre voltar atrás.
Resumo
- Comece sempre por: quais são os servidores de nomes, e o que diz o servidor de nomes autoritativo.
- A maioria dos erros está no nome (ponto, nome de domínio duplicado) ou no sítio (entidade errada).
- Um único registo SPF, nenhum CNAME em @, transferir o AAAA junto, MX para um nome com endereço.
- SERVFAIL após uma transferência costuma ser um DS antigo.
- Se só você vê a resposta antiga, é a sua cache ou o ficheiro hosts.
Quiz
Exercício
Exercício Z8.4: Reconhecer erros. Recebe cinco casos breves com a respetiva saída do dig (no ambiente do curso). Escolha, para cada caso, qual dos dez erros se trata. Depois, uma pesquisa real: descubra com o dig ou uma ferramenta online qual registo está errado para dnssec-failed.org (estado e o que +cd devolve), e se wikipedia.org tem exatamente um registo SPF.
Para saber mais
Estes artigos descrevem as soluções nos painéis do WebOké; noutras entidades, os botões têm nomes diferentes.
- O seu site ou e-mail não funciona após uma migração ou alteração de DNS: verifique o seu domínio
- Quanto tempo demora uma alteração de nameserver ou DNS, e o que fazer se não a conseguir ver?
- Manual DirectAdmin 18.7: O meu domínio ainda não funciona após uma transferência ou alteração
- Manual DirectAdmin 18.9: Deixei de receber e-mail
- Manual DirectAdmin 5.4: Registos CNAME e o ponto final
- Não consigo enviar e-mail via PHP: os registos MX apontam para outro lado
- Utilizar nameservers próprios ou externos (como a Cloudflare) para o seu domínio