Consulta de registros DNS

Os registos, e para que servem de facto

«Propagação» é a palavra errada

A coisa mais útil que há a perceber sobre DNS, porque transforma uma espera imprevisível num número que está sob o seu controlo.

Nada se propaga. Não há envio, nem distribuição, nem vaga de actualizações a percorrer a internet. O seu servidor de nomes tem o valor novo no instante em que grava. O que leva tempo é que todos os resolvedores do mundo guardam uma cópia em cache da resposta antiga, e cada um a mantém até expirar o TTL que lhe foi dado.

Portanto o atraso não é misterioso — é exactamente o TTL que estava publicado quando cada resolvedor perguntou pela última vez. Se o seu registo tinha um TTL de 3600 segundos, uns resolvedores voltam a perguntar em cinco minutos e outros ao fim de uma hora, e é por isso que uma alteração parece chegar às pessoas de forma desigual.

O que dá o procedimento para qualquer alteração planeada:

1. Um dia antes, baixe o TTL para 300 segundos. Espere que o TTL antigo expire, para que toda a gente tenha apanhado o curto.
2. Faça a alteração. Passa a demorar cinco minutos em vez de um dia.
3. Quando tudo assentar, volte a subir o TTL.

A razão para o voltar a subir é que um TTL baixo significa mais consultas, mais latência quando falha a cache, e uma avaria mais dura se os seus servidores de nomes ficarem inacessíveis — ninguém terá uma resposta em cache utilizável a que recorrer.

Os registos de correio, onde estão a maioria dos problemas

Três registos TXT determinam se o seu correio é acreditado. São mal configurados com frequência e a falha é silenciosa — o correio é entregue no spam em vez de devolvido, portanto ninguém lho diz.

SPF

Enumera que servidores podem enviar correio em nome do seu domínio. Os erros, por ordem de frequência:

• Dois registos SPF. O RFC 7208 exige que os destinatários tratem isso como erro permanente, portanto a verificação falha por inteiro. Junte-os num só.
• Mais de dez consultas de DNS. Cada include: conta, e os includes encaixam-se. Um fornecedor de correio mais uma plataforma de marketing mais um serviço de apoio levam-no lá depressa, e ultrapassar o limite reprova a verificação.
• Terminar em `~all` ou `?all`. Ambos significam «provavelmente não somos nós, mas façam como quiserem». Só o -all pede aos destinatários que rejeitem.

DKIM e DMARC

O DKIM assina cada mensagem com uma chave cuja metade pública vive num registo TXT sob um nome de selector como selector1._domainkey.example.com — é preciso saber o selector para o consultar, e é por isso que não está na consulta predefinida acima. O DMARC vive em _dmarc.example.com e diz aos destinatários o que fazer quando o SPF e o DKIM discordam, além de para onde enviar relatórios.

Consulte _dmarc.yourdomain.com na ferramenta acima. Se não voltar nada, os destinatários não têm instrução nenhuma e aplicarão o seu próprio critério a tudo o que se faça passar por si.

A regra do CNAME no ápice

Um CNAME não pode coexistir com qualquer outro registo para o mesmo nome. O ápice de um domínio tem obrigatoriamente registos SOA e NS, portanto o ápice não pode ter um CNAME — e é por isso que apontar example.com para um fornecedor SaaS é incómodo enquanto www.example.com é trivial.

As soluções de recurso dependem do fornecedor: ALIAS, ANAME ou achatamento de CNAME, que resolvem o destino do lado do servidor e respondem com um registo A. Funcionam, não são padrão, e vale a pena conhecê-las antes de lhes dedicar uma tarde inteira.

Relacionado

Quando os registos apontarem para onde queria, verifique o certificado que o anfitrião apresenta de facto e que cabeçalhos devolve. Para saber que rede é dona de um endereço para onde um registo aponta, a consulta de ASN responde a isso.