Bloqueio no Registrar vs Defesa em Camadas: Quando Cada Um Vence

Imagine acordar e descobrir que todos os domínios da sua empresa — produção, staging, aquele que sustenta seus registros MX — foram suspensos pelo seu registrar de domínios durante a noite. Nenhum deploy quebrou. Nenhum servidor caiu. Alguém de uma equipe de trust-and-safety (ou, mais provavelmente, um pipeline automatizado de abuso) acionou um interruptor, e toda a sua presença na internet sumiu. Não é hipotético: acontece com frequência suficiente para que os fóruns de sysadmins estejam cheios de relatos de registrars desativando contas por causa de denúncias de abuso não verificadas, tuítes ambíguos ou uma única imagem sinalizada entre milhões de uploads de usuários.

Passei anos em resposta a incidentes para equipes de infraestrutura, e o padrão é sempre o mesmo. Engenheiros desenham redundância elaborada para computação — multi-AZ, multi-região, runbooks de failover — e depois deixam o único recurso que não pode ser reimplantado, o próprio nome de domínio, numa única conta protegida por senha e talvez um código SMS. Este artigo compara duas filosofias para lidar com esse risco: a abordagem tradicional de bloqueio no registrar (escolha um registrar sólido, reforce a conta, confie neles) versus a abordagem de defesa em camadas (presuma que seu registrar vai falhar com você e projete em torno disso). Spoiler: você precisa das duas, mas a segunda é o que realmente salva você às 3 da manhã.

Por que seu registrar é um tipo diferente de ponto único de falha

A maioria dos pontos únicos de falha na sua stack são coisas que você controla. Um primário de banco de dados, um NAT gateway, um message broker — você pode replicá-los, e você mesmo escreveu o plano de failover. Seu registrar é diferente por três motivos. Primeiro, é uma dependência do plano de controle que você não consegue replicar. Você não pode ter dois registrars para o mesmo domínio; o registro tem exatamente um patrocinador oficial. Segundo, as falhas do registrar são lentas. Uma transferência de domínio em condições normais leva de cinco a sete dias, e se o registrar atual desativou sua conta, você pode nem conseguir o código de autorização para começar. Terceiro, a falha costuma ser adversarial de um jeito estranho: não é um atacante, é o próprio provedor agindo contra você com base numa denúncia de abuso que você nunca viu.

O raio de impacto também é pior do que as pessoas imaginam. Quando um registrar suspende um domínio, normalmente aponta os registros NS para uma página de bloqueio ou simplesmente para de responder. Isso derruba seu site, claro. Mas também derruba seu e-mail (os registros MX vivem no DNS), seu SSO se os callbacks referenciam seu domínio, seus clientes de API, sua página de status se estiver no mesmo domínio e — meu favorito pessoal — o endereço de e-mail que você usaria para receber as instruções de recuperação. Se o e-mail da sua conta no registrar é admin@seudominio.com e seudominio.com está suspenso, agora você está tentando provar sua identidade para o suporte a partir de um endereço em que eles não vão confiar. Já vi esse ciclo exato consumir um dia inteiro de incidente.

E os incentivos econômicos jogam contra você. Quando um registrar é adquirido por private equity — como já aconteceu com vários grandes —, a receita é previsível: cortar suporte humano, automatizar o tratamento de abuso, aumentar preços. Sistemas automatizados de abuso otimizam para o risco deles, não o seu. Suspender um domínio que depois se prova inocente não custa nada para eles. Deixar no ar um domínio que depois se prova culpado custa problemas no registro e má publicidade. Adivinhe para qual lado a automação erra.

Abordagem um: bloqueio no registrar — reforçar o ponto único

A filosofia do bloqueio diz: aceite que o registrar é um ponto único de falha e torne esse ponto o mais forte possível. Esta é a estratégia que a maioria das empresas realmente adota, tenham ou não articulado isso. Bem feita, fica assim:

• Escolha um registrar pela qualidade do suporte, não pelo preço. Os US$ 3 por ano que você economiza por domínio não significam nada diante de um dia de indisponibilidade. Você quer suporte por telefone, um gerente de conta nomeado para portfólios grandes e uma empresa que você poderia processar na sua jurisdição se chegasse a isso.
• Ative o registrar lock (clientTransferProhibited) em todos os domínios e o registry lock nos críticos. O registry lock exige verificação fora de banda — normalmente uma ligação telefônica com uma senha — antes de qualquer alteração de nameservers ou transferências. É chato, e esse é o objetivo.
• Use autenticação de dois fatores com chave de hardware ou TOTP, nunca SMS. As histórias de guerra sobre agentes de suporte que removem o 2FA depois de uma conversa convincente são incontáveis; alguns registrars agora oferecem políticas de 'nenhuma mudança na conta sem a chave de hardware'. Adote.
• Use um endereço de e-mail dedicado, baseado em função, para a conta no registrar que NÃO esteja em um domínio registrado nesse mesmo registrar. domains-admin@exemplo.org registrado em outro lugar completamente.
• Restrinja quem tem acesso. Duas ou três pessoas nomeadas, credenciais em um cofre corporativo, não um login compartilhado em uma planilha.
• Documente tudo: número da conta, PINs, caminhos de escalonamento do suporte, os documentos exatos com que a conta foi verificada. Coloque isso no seu runbook de incidentes.

O bloqueio tem pontos fortes reais. Ele previne o desastre mais comum com registrars, que não é o confisco — é o sequestro. Transferências por engenharia social e tomadas de conta já roubaram domínios valiosos por anos, e o registry lock somado ao 2FA de hardware bloqueia quase todos eles. Também é barato e não exige engenharia contínua.

Mas aqui está a verdade incômoda: o bloqueio protege você de atacantes, não do próprio registrar. Cada controle acima é operado pelo registrar. Se a automação de abuso deles desativar sua conta, seu registrar lock agora está trancando você para fora, seu PIN de suporte está num sistema que você não alcança, e a pessoa que poderia sobrescrever tudo isso talvez nem exista mais, porque o suporte foi 'otimizado' no último trimestre. Profissionais relatam tempos de restauração de seis horas ou mais mesmo em casos diretos de falso positivo, e sagas de vários dias quando a suspensão cai num fim de semana. O bloqueio é necessário. Não é suficiente.

Abordagem dois: defesa em camadas — presuma que o registrar vai trair você

A filosofia em camadas parte de uma premissa mais sombria: um dia, por má intenção, automação ou erro, seu registrar vai derrubar seus domínios, e você precisará estar de volta online antes que a fila de suporte chegue até você. É a mesma mentalidade por trás da engenharia defensiva contra falhas catastróficas — você não impede o desastre, você torna o desastre sobrevivível.

A técnica central é separar camadas que normalmente vêm agrupadas. A maioria das pequenas empresas compra o domínio, usa o DNS do registrar, hospeda no braço de hospedagem do registrar e também fica com o e-mail. São quatro pontos únicos de falha empilhados em uma conta. Desagregue:

• Registro: no registrar A, escolhido por estabilidade e suporte.
• DNS autoritativo: em um provedor de DNS independente B (ou dois provedores em configuração dual-primary), gerenciado como código.
• Hospedagem: onde fizer sentido para a carga de trabalho, sem relação com nenhum dos dois.
• E-mail: um provedor dedicado, com os endereços de recuperação de conta de A e B morando em outro domínio ainda.
• Domínio reserva: um domínio de contingência pré-provisionado em um registrar diferente, com certificados TLS emitidos e uma versão mínima dos seus serviços mais críticos já respondendo nele.

O domínio reserva merece destaque porque quase ninguém o tem, e é a jogada de maior alavancagem. Quando seus domínios principais são suspensos, os TTLs do DNS e os caches dos resolvers significam que você não pode simplesmente 'trocar para o backup' — o backup precisa ter existido, estar aquecido e ser resolvível antes do incidente. Um fallback como example-status.net, registrado em outro lugar, hospedando sua página de status, comunicações de incidente e um registro MX de emergência, transforma uma interrupção que mataria a empresa numa terça-feira constrangedora.

DNS como código: a camada que todo mundo pula

Aqui está uma falha que vi duas vezes em incidentes reais: a equipe recupera o domínio depois de uma suspensão no registrar, religa tudo — e o DNS está errado, porque a 'fonte da verdade' da zona era a interface web do registrar, que estava inacessível durante o incidente e já tinha se desviado da memória de qualquer um. Reconstruir de cabeça um arquivo de zona com 200 registros durante uma indisponibilidade é um tipo especial de sofrimento. Como já escrevemos antes, erros de configuração de DNS continuam quebrando produção mesmo em condições normais; durante um incidente com o registrar, eles são catastróficos.

A correção é entediante: gerencie a zona de DNS como código, em controle de versão, implantada por CI. Ferramentas como dnscontrol ou os provedores de DNS do Terraform permitem descrever a zona de forma declarativa e enviá-la a vários provedores. Agora o estado do seu DNS sobrevive à perda do plano de controle de qualquer provedor, e 'fazer failover para o provedor de DNS B' é uma mudança de uma linha e um deploy, não uma sessão heroica de copiar e colar.

# dnsconfig.js — one zone, two providers, deployed by CI
var REG_NONE = NewRegistrar('none');
var DSP_CLOUDFLARE = NewDnsProvider('cloudflare');
var DSP_ROUTE53 = NewDnsProvider('route53');
D('example.com', REG_NONE,
DnsProvider(DSP_CLOUDFLARE),
DnsProvider(DSP_ROUTE53),   // dual-authoritative: either can die
A('@', '203.0.113.10'),
A('www', '203.0.113.10'),
MX('@', 10, 'mail.example.net.'),   // MX on a DIFFERENT TLD/provider domain
TXT('@', 'v=spf1 include:_spf.example.net -all'),
CNAME('status', 'statuspage.example.net.')
);

DNS autoritativo duplo é subestimado. A maioria dos resolvers tenta todos os nameservers listados sem problemas, então, se um provedor tiver uma indisponibilidade (e os grandes provedores de DNS já tiveram), a resolução continua. O desafio é manter os dois provedores sincronizados — exatamente o que o DNS como código oferece de graça. Sem isso, DNS com dois provedores é uma fábrica de divergências e, discutivelmente, pior do que um provedor único.

Uma ressalva sobre TTLs: as equipes adoram subir os TTLs para 86400 'por performance' e depois descobrem, durante um incidente, que um quarto da internet mantém em cache os registros antigos de nameserver por um dia inteiro. Para registros ligados a nameservers e para qualquer coisa que você possa precisar mudar numa emergência, mantenha TTLs entre 300 e 900 segundos. O custo em volume de consultas é insignificante comparado à agilidade.

Cara a cara: quando cada abordagem vence

Vamos ser diretos sobre o trade-off, porque as duas estratégias otimizam para ameaças e organizações diferentes.

• Modelo de ameaça: o bloqueio vence contra sequestro e engenharia social — os desastres estatisticamente comuns. A defesa em camadas vence contra falhas do lado do registrar: automação de abuso, confisco de conta, insolvência ou colapso do suporte.
• Custo: o bloqueio custa quase nada — taxas de registry lock, uma chave de hardware, disciplina. A defesa em camadas custa a fatura de um segundo provedor, um domínio reserva, a infraestrutura de CI e atenção contínua para evitar divergências.
• Tempo de recuperação: num cenário de confisco, equipes que dependem só do bloqueio ficam à mercê da fila de suporte (horas a dias, segundo todas as histórias que ouvi). Equipes em camadas com um domínio reserva aquecido voltam em minutos a horas.
• Carga operacional: o bloqueio é configurar e esquecer. A defesa em camadas apodrece se não for mantida — um domínio de fallback não testado, com certificado expirado, é teatro de segurança.
• Adequação à organização: uma startup de cinco pessoas com um produto SaaS deve adotar o bloqueio completo mais os dois movimentos em camadas mais baratos (DNS como código externo e e-mail de recuperação fora do domínio). Uma empresa cuja receita morre junto com o domínio precisa da pilha em camadas completa.

O bloqueio protege seus domínios de atacantes. A defesa em camadas protege seu negócio do seu registrar. Você está exposto aos dois, então precisa dos dois.

O runbook de recuperação que ninguém escreve até ser tarde demais

Qualquer que seja a postura escolhida, escreva o runbook de confisco agora. Os incidentes que vi correrem bem tinham um; os desastres estavam improvisando. O seu deve cobrir, em ordem: confirmar o escopo (é um domínio ou a conta inteira — verifique os códigos de status do whois como clientHold ou serverHold), abrir o chamado de suporte com os identificadores documentados da conta, ativar o domínio de fallback e atualizar as comunicações de status, notificar clientes por canais que não dependam do domínio morto, e iniciar o processo de transferência para fora em paralelo — não espere a resolução para decidir que você vai sair.

Ensaie também as partes chatas. Você consegue de fato entrar no registrar a partir de um dispositivo limpo, com a chave de hardware, sem o gerenciador de senhas que fica atrás do SSO no domínio suspenso? A senha do registry lock está onde o plantonista consegue encontrá-la? Equipes testam o failover de banco de dados todo trimestre, e a recuperação do registrar nunca. Como a falha do registrar derruba o SSO que você usa para chegar a todo o resto, essa prioridade está invertida.

Minha recomendação

Faça o bloqueio completo — é uma tarde de trabalho e barra o ataque mais provável. Depois implemente exatamente três peças de defesa em camadas, nesta ordem: mova o DNS autoritativo para fora do registrar e gerencie-o como código; mova o e-mail de recuperação da conta no registrar para um domínio em outro registrar; e monte um domínio de fallback aquecido, com certificados, página de status e MX de emergência. Essas três cobrem os modos de falha dominantes por algumas centenas de dólares por ano. Reserve a arquitetura completa com dois registrars e dois DNS para organizações que conseguem articular quanto custa um dia de perda total de domínio — se esse número tiver seis dígitos, você já sabe o que fazer.

E se você ainda escolhe o registrar principalmente pelo preço, pare. O mercado de registrars baratos está se consolidando sob donos cujo incentivo é substituir o julgamento humano por automação que suspenderá você com prazer num falso positivo e chegará ao seu chamado na quinta-feira. Seu domínio é a única peça de infraestrutura que você não pode reimplantar a partir de uma imagem de contêiner. Trate-o assim.