Como evitar falhas de DNS e domínios vencidos nos sites dos seus clientes

Erros HTTP vêm com um código de status e falhas de servidor deixam logs. Quando o DNS falha, o site simplesmente deixa de estar onde o nome dele diz que está. Os visitantes recebem um aviso do navegador de que não é possível acessar o site, ou veem a página de outra pessoa.

Para quem trabalha como freelancer com sites de clientes, três causas explicam quase tudo:

• O domínio venceu. A renovação automática falhou porque o cartão cadastrado expirou, ou os lembretes de renovação foram para um endereço que ninguém lê, como o endereço antigo do cliente.
• Um registro deu errado em uma migração. O registro A ainda aponta para o servidor antigo, ou um erro de digitação faz com que ele não aponte para lugar nenhum.
• Os servidores de nomes foram alterados. Alguém mudou o domínio para um novo provedor de DNS, ou uma transferência de registrador os alterou, e os registros não foram recriados no novo lugar.

O que realmente acontece quando um domínio vence

Para domínios genéricos como .com, .net e .org, a Expired Registration Recovery Policy da ICANN define a sequência:

1. O registrador envia lembretes ao titular registrado do domínio, normalmente por e-mail: cerca de um mês e cerca de uma semana antes do vencimento, e pelo menos mais um em até cinco dias depois. Se foi o cliente quem registrou o domínio, os lembretes vão para o cliente.
2. Depois do vencimento, o registrador precisa interromper o caminho de resolução DNS do domínio. O nome então deixa de resolver ou leva à página de destino do registrador, que precisa informar que o registro do domínio venceu e como renová-lo. Ou seja, o site nem sempre "some": ele pode ser substituído por uma página de renovação que continua carregando.
3. Se ninguém renovar e o registro do domínio for excluído, vem um período de 30 dias chamado Redemption Grace Period, durante o qual o operador do registro desativa a resolução DNS. A partir daí as consultas falham para todos, normalmente com NXDOMAIN ("domínio inexistente"), até que o domínio seja restaurado.

Domínios de país como .sk, .cz, .de ou .uk seguem as regras do próprio operador de registro, então confira os termos do registrador para o domínio de cada cliente.

O ponto prático: para uma verificação que só lê o código de status, o passo 2 pode parecer um site funcionando.

Um roteiro de diagnóstico

Quando um cliente disser "o site sumiu", rode estes comandos antes de mexer em qualquer coisa. Substitua example.com pelo domínio do cliente.

Veja o caminho dos servidores raiz até a resposta, e onde ele se interrompe:

dig +trace example.com

Compare os servidores de nomes que o operador do registro tem com os que você espera:

dig +short NS example.com
whois example.com | grep -iE "name ?server|nserver"

Verifique a data de vencimento (o nome do campo varia conforme o operador do registro, e alguns operadores de domínios de país não a publicam):

whois example.com | grep -iE "expir"

Pergunte a cada servidor de nomes autoritativo o número de série SOA. Números diferentes significam que um servidor de nomes ainda não recebeu a zona mais recente, ou que uma mudança ainda está sendo copiada:

for ns in $(dig +short NS example.com); do echo "$ns $(dig +short SOA example.com @$ns | awk '{print $3}')"; done

Compare um resolver público com a resposta autoritativa. Se o servidor autoritativo está certo e o resolver público não, você está esperando um cache expirar, e não diante de um registro errado:

dig +noall +answer example.com @1.1.1.1
dig +noall +answer example.com @<one of the NS names above>

Depois corrija no lugar certo: um domínio vencido no registrador, servidores de nomes errados no registrador, um registro errado no provedor de DNS.

Antes de uma migração: reduza o TTL primeiro

Resolvers guardam uma resposta pelo tempo que o TTL dela indica. Se o registro A tem um TTL de 86400 segundos (um dia), alguns visitantes podem continuar indo para o servidor antigo por um dia depois da mudança.

1. Verifique o TTL atual no servidor autoritativo: dig +noall +answer example.com @<nameserver> (segunda coluna).
2. Reduza-o para 300 segundos pelo menos um TTL antigo antes da mudança; para um TTL de um dia, um ou dois dias antes.
3. Faça a mudança e depois confirme-a no servidor autoritativo e em um resolver público.
4. Mantenha o servidor antigo funcionando até que o TTL antigo tenha passado.
5. Aumente o TTL de novo quando tudo estiver apontando para o novo lugar.

O que monitorar

• A data de vencimento de cada domínio de cliente, com lembretes que cheguem a você, e não só ao cliente.
• Os registros que importam: o registro A (ou AAAA) do site e o registro MX, se o e-mail do cliente depende dele.
• O valor desses registros, e não só que eles existam, para detectar um registro que aponte para o servidor errado.
• A própria página: durante a fase da página de renovação descrita acima, só uma verificação que lê o conteúdo da página percebe a diferença.

O que o monitor DNS e os alertas de domínio do Baromio cobrem

• Monitor DNS: consulta um tipo de registro (A, AAAA, MX, CNAME ou TXT) de um nome de host, pelo resolver normal do servidor do Baromio, com a frequência que o seu plano permite: a cada 5 minutos no Free, a cada minuto no Pro, a cada 30 segundos no Business. Ele falha quando nenhum registro volta. Se você preencher o campo Valor Esperado, ele também falha quando o primeiro registro da resposta não contém esse texto, sem diferenciar maiúsculas de minúsculas, então google.com corresponde a um registro MX como aspmx.l.google.com. Em um nome com vários registros A, o primeiro pode variar, então deixe o valor esperado vazio nesse caso, ou use uma parte que todos tenham em comum.
• O que o monitor DNS não faz: ele verifica a partir de um único servidor, não compara servidores de nomes nem números de série SOA e não testa a propagação entre resolvers. Para isso, use o roteiro acima.
• Vencimento do domínio: ative Monitorar Vencimento do Domínio em um monitor HTTP ou de palavra-chave (vem desativado por padrão). Uma vez por dia, o Baromio lê no WHOIS a data de vencimento do domínio e avisa você, por e-mail e nos seus canais conectados de Slack, Discord ou webhook, nos dias em que faltam 30, 14 e 7 dias. Não há alerta depois do de 7 dias, então trate esse como o último aviso. O card do monitor mostra um selo WHOIS com os dias restantes. Se o operador do registro não publica uma data de vencimento, nenhuma data aparece. Para domínios sob um sufixo de duas partes, como .co.uk, a consulta ainda não funciona; verifique esses manualmente.
• Planos: os dois estão disponíveis em todos os planos; o Free cobre 20 monitores, o Pro (9 EUR por mês) 30 e o Business (29 EUR por mês) 100.

Um checklist para cada cliente

1. Anote o registrador, o provedor de DNS e quem paga a renovação.
2. Garanta que os lembretes de renovação cheguem a você e que a renovação automática tenha um cartão válido.
3. Coloque um monitor DNS com valor esperado no registro principal do site, e outro no MX se o e-mail for importante.
4. Ative os alertas de vencimento de domínio no monitor HTTP ou de palavra-chave do site.
5. Reduza o TTL um ou dois dias antes de qualquer mudança de DNS e mantenha o servidor antigo no ar até que o TTL antigo tenha passado.

Fontes

• ICANN, Expired Registration Recovery Policy: prazos dos lembretes (2.1), interrupção do caminho de resolução DNS e página de renovação após o vencimento (2.2), o Redemption Grace Period de 30 dias após a exclusão, com a resolução DNS desativada (3.1, 3.2).