Registre um domínio anonimamente: privacidade no WHOIS e o que ainda vaza

O que a redação realmente removeu

Em 2018, o registro da maioria dos domínios ficou em branco. O GDPR chegou, a ICANN mandou os registradores pararem de publicar nomes, endereços, telefones e e-mails de titulares na saída pública do WHOIS, e uma consulta que antes devolvia uma pessoa passou a devolver REDACTED FOR PRIVACY e um formulário de contato. Parece privacidade. É uma configuração de exibição.

Por baixo, nada mudou de lugar. O seu registrador ainda guarda o registro completo, ainda é obrigado a guardá-lo por força da sua credenciação, e ainda o entrega para quem tiver legitimidade para pedir — uma ordem judicial, uma requisição de autoridade policial e, na prática, algo bem mais barato. Uma reclamação de UDRP custa alguns milhares de dólares, não exige juiz, e dispara uma etapa de verificação do registrador que revela ao reclamante o titular por trás do domínio antes mesmo de o caso ser decidido. Essa é a via de desmascaramento que quase ninguém considera, e é a primeira a que um detentor de marca registrada recorre.

Outras duas coisas sobreviveram à redação. A primeira é o histórico: arquivos comerciais capturaram instantâneos do WHOIS por duas décadas, e esses instantâneos não expiram, então um nome registrado antes de 2018 com dados reais fica exposto permanentemente, não importa o que o registro diga hoje. A segunda é o resto da sua própria configuração — os servidores de nomes que você escolheu, o endereço enterrado no seu SOA, a caixa de relatórios do DMARC, todo certificado que você já solicitou. A redação apagou um campo e deixou outros quatro publicando, e é nesses quatro que este guia passa a maior parte do tempo.

Escolha a extensão antes de escolher o registrador

A política do registrador é subordinada à política do registro, e a política do registro é subordinada ao país onde a empresa operadora do registro está incorporada. Um registrador pode prometer o que quiser sobre privacidade; não pode prometer mais do que o seu registro permite, e nenhum dos dois pode prometer nada sobre um tribunal na própria jurisdição do registro. Por isso a ordem importa, e a maioria das pessoas faz o inverso: escolha primeiro a extensão, depois escolha quem vende ela para você.

Três propriedades separam as extensões. Onde fica o operador do registro decide quais tribunais podem mandar suspender um nome na raiz — para os grandes gTLDs legados isso são os Estados Unidos, por isso um .com em nome de alguém sem presença nenhuma nos EUA ainda pode ser apreendido por uma ordem americana, e por isso a sua própria jurisdição importa bem menos do que você gostaria. O que o registro publica por padrão varia enormemente: alguns registros de ccTLD redigem mais do que os gTLDs, outros imprimem o nome do titular para qualquer um que perguntar, e alguns exigem presença local verificada, que só dá para satisfazer com uma identidade real. Se serviços de privacidade são sequer permitidos é uma regra do registro, não um recurso do registrador — um punhado de extensões proíbe registro por proxy categoricamente, e um registrador que te vende privacidade em uma delas simplesmente vai ter isso removido depois.

Nada disso é estável o bastante para decorar, e qualquer lista de "TLDs amigáveis à privacidade" que você encontrar por aí já está parcialmente errada quando você a lê. Em vez disso, confira você mesmo: o passo dois roda as buscas que respondem às três perguntas para qualquer extensão que você esteja considerando, usando um domínio que não é seu. Rode-as antes de pagar, porque uma extensão ruim não se conserta transferindo de registrador. Só se conserta começando de novo com outro nome.

Três modelos de registrador, e o que cada um aguenta

Tirando o marketing, existem três arranjos disponíveis. No modelo proxy, você é o titular e o registrador publica os próprios dados de contato no lugar dos seus. Os seus dados já estão no banco de dados do registrador, a redação é cosmética por cima de um registro completo, e os próprios termos do provedor de proxy quase sempre reservam o direito de revelar você mediante uma solicitação "razoável" de terceiros. Isso derrota completamente scrapers e corretores de dados. Não derrota nada que chegue acompanhado de um advogado.

No modelo de titularidade delegada — o arranjo que a Njalla popularizou — o provedor registra o nome em nome próprio e concede a você um direito contratual de uso, então a sua identidade nunca chega a se tornar o titular. Não há nada no registro para revelar porque não há nada ali. A troca é real e vale a pena dizer com todas as letras: você não é o dono legal do domínio. Você está confiando na solvência de uma empresa, na disposição dela de resistir a uma solicitação, e no interesse contínuo dela no negócio. Se ela quebrar, for comprada, ou decidir que você dá mais trabalho do que vale, o seu recurso é uma disputa contratual sobre um ativo registrado em nome de outra pessoa.

O terceiro arranjo é uma identidade de titular limpa e própria: um registro de verdade sob um nome sem histórico, em uma caixa de entrada que não existe para mais nada, pago em cripto, em um registrador de uma jurisdição sem relação com o seu host e com você. Ele escala além de um único domínio, não depende da boa vontade de nenhuma empresa em particular, e é o que o resto deste guia constrói. Também é o que mais falha se você for descuidado, porque tudo depende dessa identidade nunca ser correlacionada com você em outro lugar — o modo de falha que o guia de titularidade percorre camada por camada. Os dois modelos combinam bem, aliás: um registro de titularidade delegada comprado a partir de uma identidade limpa é mais forte do que qualquer um dos dois sozinho.

O formulário de cadastro: o que você pode recusar, o que vai suspender você

O formulário pede um nome, um endereço postal, um telefone e um e-mail. Três desses são dados contratuais que o registrador é obrigado a guardar e quase nunca vai verificar. Um deles é estrutural. O e-mail é o que importa: segundo o acordo de credenciação do registrador, o endereço do titular tem de ser verificado depois do registro, e se ninguém clicar no link o domínio é suspenso — geralmente em até quinze dias. Uma caixa de entrada descartável que deixa de existir leva o domínio junto.

Então o endereço precisa ser um alias que você realmente controla e que ainda vai estar lendo daqui a três anos, em um provedor que não exige telefone para abrir conta e que não fecha a conta por inatividade. Tudo o mais nesse formulário é um problema de consistência, não de veracidade: escolha um conjunto plausível de dados, guarde-os criptografados, e use exatamente os mesmos no registrador, no perfil da conta e em qualquer chamado de suporte que você abrir. Inconsistência é o que encaminha uma conta para revisão manual, e revisão manual é onde um humano começa a pedir documentos.

Depois pague por um canal que não carregue nenhum nome legal até o registro. Um cartão derruba todo o exercício não importa o que o WHOIS diga, porque o registro do processador sobrevive ao registro do domínio e é trivialmente alcançável por intimação; o guia de pagamento anônimo classifica as opções pelo que cada uma vaza. Se o registrador aceita Monero diretamente, esse é o caminho limpo. Se só aceita Bitcoin, trate o pagamento como permanentemente rastreável e financie-o de acordo. Se não aceita nenhum dos dois, o registrador já te disse algo útil sobre que tipo de cliente ele quer.

O DNS é o segundo registro

No momento em que você publica uma zona, você se republica, em campos que ninguém pensa como identidade. O registro SOA carrega um endereço de e-mail codificado, com o primeiro ponto no lugar do @, e arquivos de zona escritos à mão rotineiramente carregam um endereço de verdade. Os nomes dos servidores de nomes são uma impressão digital: aponte dois domínios para os mesmos servidores de nomes personalizados e você os vinculou permanentemente, em uma base de dados que mecanismos de busca reversa de servidores de nomes indexam e mantêm. E quando esses servidores de nomes moram dentro do próprio domínio, o registro publica registros glue — os endereços IP deles, na zona raiz, fora do alcance de qualquer CDN que você coloque na frente do site. Gente passa uma semana escondendo uma origem e depois entrega o endereço dela de bandeja em um registro glue.

O DNSSEC merece um alerta específico, porque é vendido como recurso de segurança e se comporta como um de divulgação. Assinar uma zona com NSEC publica uma lista encadeada de todo nome nela, percorrível por qualquer um em segundos. O NSEC3 aplica hash aos nomes em vez disso, o que parece melhor e só encarece o ataque: os hashes são quebráveis offline e existem ferramentas que não fazem outra coisa. Assine a zona se você quer respostas autenticadas, e entre sabendo que isso não esconde a sua lista de subdomínios. Nunca escondeu.

Onde a zona é servida é uma decisão separada de quem registrou o nome, e dividir isso entre duas empresas em dois países vale mais do que cada escolha sozinha. Rodar os seus próprios servidores de nomes compra controle e uma impressão digital pequena e distintiva; usar os de um provedor grande compra anonimato em meio à multidão e uma empresa que registra em log toda consulta e vai responder a uma solicitação sobre ela. Não existe opção grátis aqui, só uma escolha sobre qual registro você prefere que exista. Se o site atrás da zona fica atrás de um edge, o guia de IP de origem cobre o resto dessa cadeia.

Os vazamentos que chegam depois do cadastro

Transparência de certificados é a grande vilã. Todo certificado publicamente confiável é escrito em um log público, somente para acréscimo e pesquisável para sempre, então todo nome que você já pediu para uma CA assinar é descobrível — incluindo os hosts staging., vpn. e old- que você presumia que ninguém conhecia, e incluindo o nome interno que você emitiu por acidente uma vez e apagou na mesma tarde. Você não consegue retratar uma entrada de log. O único controle é a montante: peça um certificado wildcard via validação DNS-01 para que hostnames individuais nunca entrem em um log, e mantenha nomes genuinamente privados em uma CA interna que não registra nada em log.

O e-mail publica mais dois. Um registro SPF nomeia o relay pelo qual você envia. Um registro DMARC geralmente nomeia um humano, porque rua= é para onde vão os relatórios e as pessoas colocam a caixa de entrada real delas ali. E um MX apontando para a máquina que também serve o site entrega o endereço de origem para qualquer um que rode uma única consulta — e-mail é a forma mais comum de uma origem escapar de trás de um edge.

A última categoria é correlação, e é o que desfaz um trabalho cuidadoso em tudo o mais. O mesmo conjunto de servidores de nomes usado em duas personas as vincula. O mesmo vale para um certificado cobrindo os dois nomes, o mesmo identificador de analytics, o mesmo favicon — scanners que varrem a internet inteira indexam hashes de favicon precisamente porque eles funcionam muito bem como impressão digital — o mesmo cabeçalho de resposta incomum, o mesmo registrador na mesma hora da mesma noite. Qualquer um desses isoladamente é evidência fraca. Três juntos não são. Os passos quatro e seis rodam as buscas que um adversário rodaria, contra o seu próprio domínio, que é a única forma honesta de descobrir o que você realmente publicou.

Renovação, transferência, e a falha do terceiro ano

Domínios anônimos raramente morrem por intimação. Morrem por registro vencido. A caixa de entrada alias parou de ser lida, o aviso de renovação retornou, o saldo secou, e um nome que levou um ano para construir caiu de volta no grupo de nomes liberados, onde um drop-catcher estava esperando. Ative a renovação automática, mantenha crédito suficiente no registrador para cobrir vários anos, e coloque a data de expiração em algum alerta que você realmente olha — o passo sete puxa ela direto do registro, então o lembrete não depende da caixa de entrada com mais chance de falhar.

Travas são a outra metade, e são grátis. clientTransferProhibited, clientUpdateProhibited e clientDeleteProhibited levam um clique cada uma e desligam toda uma classe de ataque que começa com alguém entrando na sua conta no registrador. Alguns registros também oferecem uma trava de registro, que exige confirmação fora de banda antes de qualquer mudança e vale a pena pagar nela em um nome que você não pode se dar ao luxo de perder. Mantenha o código de autorização de transferência criptografado e offline, e saiba que trocar o contato do titular dispara uma proibição de transferência de sessenta dias — então faça essa faxina quando você não estiver com pressa, nunca no meio de um incidente.

Depois planeje para a versão disso em que você não está disponível. Um domínio mantido sob uma identidade anônima não tem inventário, não tem escada de suporte e nenhuma prova de propriedade além das próprias credenciais, o que faz de uma cópia criptografada dos dados da conta, dos códigos de recuperação e do código de autorização — guardada onde alguém de sua confiança consiga eventualmente acessar — a única coisa entre um projeto de vida longa e um nome morto. A mesma lógica vale para a máquina por trás dele: um backup criptografado fora do site que ninguém consegue restaurar é um backup que você não tem.

Um modelo de ameaça realista

Seja preciso sobre o que isso derrota. Contra scrapers, corretores de dados, concorrentes, pesquisadores de código aberto e o oportunista que salta de um dos seus nomes para todos os outros, uma identidade de titular limpa com uma zona livre de vazamentos funciona, e funciona completamente — não há nada no registro público a partir do qual saltar. Contra um reclamante civil, isso eleva o custo de uma busca gratuita para um processo judicial, o que é uma diferença real e muitas vezes decisiva. Contra uma UDRP movida por um detentor de marca registrada, o modelo proxy te dá muito pouco, e o modelo de titularidade delegada te dá uma empresa que precisa decidir o quanto quer lutar em seu nome.

Contra um estado com jurisdição sobre o seu registro, isso não vence, e nenhum arranjo de registradores vence: o nome pode ser suspenso na raiz independentemente de quem o detém. Esse é um argumento para escolher a extensão deliberadamente e para ser dono do seu conteúdo o bastante para poder movê-lo, não para um registrador mais esperto. E contra os seus próprios erros isso não oferece nada. Um login a partir de um perfil de navegador pessoal, um chamado de suporte escrito na sua voz de sempre a partir do seu endereço de sempre, um certificado cobrindo as duas personas, e o registro que você passou este guia inteiro mantendo limpo é costurado de volta em uma tarde.

Construa para o adversário que você realmente tem. Para a maioria das pessoas a resposta honesta é corretores e oportunistas, e fechar os registros nos passos cinco e seis já basta. Se a sua exposição é maior, lembre-se de que o domínio é uma camada entre várias: combine-o com um host que nunca perguntou quem você é, uma máquina protegida desde o primeiro dia, e um pagamento que não carrega nome nenhum. Privacidade é uma corrente, e cada guia aqui descreve um elo diferente da mesma corrente.

Passo a passo

1. 01

   Audite o que o nome já publica

   Comece pelo domínio que você já tem, ou por um que você está prestes a comprar de outra pessoa. O RDAP é o serviço de registro legível por máquina que substituiu o WHOIS de porta 43 para os gTLDs, ele fala JSON sobre HTTPS, e o rdap.org te encaminha ao registro certo. Muitos ccTLDs ainda só respondem na porta 43, e vários deles publicam mais do que um gTLD publicaria.

   # gTLDs: RDAP is the authoritative registration record
   curl -s https://rdap.org/domain/example.com | jq '{
     status,
     ns:     [.nameservers[]?.ldhName],
     events: [.events[] | {(.eventAction): .eventDate}],
     roles:  [.entities[]?.roles[]?]
   }'
   
   # the fields that are supposed to be blank -- read them, do not assume
   curl -s https://rdap.org/domain/example.com \
     | jq -r '.. | objects | select(has("vcardArray")) | .vcardArray[1][]
              | select(.[0]=="fn" or .[0]=="email" or .[0]=="adr")
              | "\(.[0]): \(.[3])"'
   
   # ccTLDs: many are port-43 only, and less redacted than you expect
   whois example.de | grep -viE '^%|^$'

   Se um nome real, um endereço real ou um e-mail pessoal aparecer, pare aqui: transferir o domínio não vai apagar isso, porque os arquivos já têm. Esse nome está queimado para fins de privacidade, e a jogada honesta é registrar um novo e redirecionar.

2. 02

   Teste a extensão antes de se comprometer com ela

   Compare as extensões candidatas empiricamente, não a partir de um post de blog. Consulte um domínio que não é seu em cada uma delas e leia o que o registro realmente devolve, depois confira quem opera aquele registro e onde. O formato da saída varia entre registros, e é exatamente por isso que vale a pena rodar em vez de presumir.

   # what does each registry publish about a registrant?
   for d in example.com example.de example.is example.nl; do
     printf '\n== %s\n' "$d"
     curl -s "https://rdap.org/domain/$d" \
       | jq -r '.entities[]? | "\(.roles|join(",")): \(
           [.vcardArray[1][]? | select(.[0]=="fn")][0][3] // "redacted")"' \
       2>/dev/null || whois "$d" | grep -iE '^(registrant|owner|admin-c)'
   done
   
   # who runs the registry, and under whose law does that company sit?
   curl -s https://www.iana.org/domains/root/db/is.html \
     | sed -n 's/.*Organisation:*//p;/Registry Information/,+6p' | head -20

   Três respostas decidem isso. O registro publica o nome do titular por padrão? Ele exige presença local verificada? E de quem são os tribunais que alcançam o operador do registro? Qualquer coisa que exija presença local está fora, a menos que você consiga satisfazer isso de verdade, e qualquer coisa cujo operador esteja em uma jurisdição que você está especificamente evitando está fora, não importa o quão bom o registrador pareça.

3. 03

   Construa a identidade antes de abrir a conta

   Gere a identidade de uma vez só e não escreva nada em texto puro. O nome não deve carregar histórico nenhum — nem um apelido que você já usou em outro lugar, nem uma palavra que tenha significado para você. A caixa de entrada deve ser um alias em um provedor que não exige telefone, e precisa sobreviver a três anos de abandono, porque o e-mail de verificação do registrador e todo aviso de renovação caem ali.

   # a handle with no history and no meaning
   head -c 10 /dev/urandom | base32 | tr -d '=' | tr 'A-Z' 'a-z'
   
   # a key for the secrets this account is about to hand you
   age-keygen -o registrar.key            # public key is printed on stderr
   
   # store profile details, recovery codes and (later) the auth code
   age -r age1... -o registrar.age registrar.txt && shred -u registrar.txt
   
   # read it back only when you need it
   age -d -i registrar.key registrar.age

   Use um perfil de navegador que nunca tocou em uma conta pessoal, e acesse o registrador sempre pelo mesmo caminho de rede — misturar uma conexão residencial e uma VPN entre sessões chama mais atenção do que usar consistentemente qualquer uma das duas. Registre os dados exatos do perfil que você enviou; você vai precisar repeti-los ao pé da letra em um chamado de suporte daqui a dois anos.

4. 04

   Registre, depois olhe para si mesmo como um estranho

   Registre o nome, clique no link de verificação no mesmo dia, e então espere o cadastro se propagar até o registro antes de checar — a saída interessante aparece algumas horas depois, não imediatamente. O que você está procurando é qualquer campo que não tenha sido redigido, e os códigos de status que dizem se a verificação realmente foi concluída.

   # the public record, 24h in
   curl -s https://rdap.org/domain/example.com | jq '{status, events}'
   # expect: "active" -- NOT "pendingVerification" or "clientHold"
   
   # anything at all that survived redaction
   curl -s https://rdap.org/domain/example.com \
     | jq -r '.. | objects | .vcardArray? // empty | .[1][]
              | select(.[0]=="fn" or .[0]=="email" or .[0]=="adr" or .[0]=="tel")
              | "\(.[0]): \(.[3])"'
   
   # and the archive view: does this name have a past you did not buy?
   curl -s 'https://crt.sh/?q=example.com&output=json' \
     | jq -r '.[] | "\(.not_before)  \(.name_value)"' | sort -u | head -20

   Um status clientHold ou pendingVerification uma semana depois significa que o e-mail de verificação nunca chegou ou nunca foi clicado, e o domínio está numa contagem regressiva para suspensão. Resolva isso antes de qualquer outra coisa — é a forma mais comum de um domínio anônimo corretamente registrado se perder no primeiro mês.

5. 05

   Publique uma zona que não te identifique

   Agora a parte que mais vaza e menos se checa. Leia a sua própria zona do jeito que um estranho leria: o endereço no SOA, os nomes dos servidores de nomes, o glue que o registro publica em seu nome, e se alguém consegue simplesmente baixar tudo.

   # SOA -- the second field is an email, first dot standing in for @
   dig +short SOA example.com
   # ns1.example.com. hostmaster.example.com. 2026090601 7200 3600 1209600 3600
   #                  ^-- must not be a personal address
   
   # glue: if your nameservers live inside the domain, the ROOT holds their IPs
   dig +norec +short NS example.com @a.gtld-servers.net
   dig +norec +short ns1.example.com A @a.gtld-servers.net
   
   # can anyone download the entire zone?
   dig AXFR example.com @ns1.example.com | head
   # want: "Transfer failed" -- anything else is your full host inventory
   
   # pin issuance to one CA, and give abuse somewhere impersonal to land
   dig +short CAA example.com
   # 0 issue "letsencrypt.org"
   # 0 iodef "mailto:abuse@example.com"

   Corrija nesta ordem: troque o endereço do SOA por um endereço funcional no próprio domínio, mova os servidores de nomes para fora do domínio (ou para fora da sua própria máquina por completo) para que nenhum glue seja necessário, recuse AXFR de qualquer coisa que não sejam os seus secundários, e adicione um registro CAA. Se você assinar com DNSSEC, use NSEC3 e aceite que a sua lista de subdomínios ainda é enumerável por qualquer um disposto a gastar uma hora nisso.

6. 06

   Feche os vazamentos de certificado e e-mail

   Duas bases de dados públicas sabem mais sobre a sua infraestrutura do que o seu DNS sabe. A transparência de certificados conhece todo hostname que você já mandou assinar; os seus próprios registros de e-mail nomeiam o seu relay, a sua caixa de relatórios e frequentemente a sua origem. Enumere os dois contra si mesmo.

   # every name you have ever asked a CA to sign, including deleted ones
   curl -s 'https://crt.sh/?q=%25.example.com&output=json' \
     | jq -r '.[].name_value' | tr ' ' '\n' | sort -u
   
   # the mail records, read for identity rather than deliverability
   dig +short TXT example.com          # SPF include: names your relay
   dig +short TXT _dmarc.example.com   # rua=mailto: usually names a human
   dig +short MX  example.com          # an MX on the origin IS the origin
   
   # does the site answer on its own address, ignoring the edge?
   curl -sI --resolve example.com:443:203.0.113.10 https://example.com/ | head -1

   Passe a emissão futura para um wildcard validado via DNS-01 para que hostnames parem de entrar nos logs, aponte rua= para um endereço no próprio domínio em vez de uma caixa de entrada pessoal, e tire o e-mail de cima da origem — um relay ou uma máquina separada, nunca a mesma caixa que roda o site. Nomes que já estão nos logs não podem ser retirados; aposente-os ou aceite que eles são públicos para sempre.

7. 07

   Trave, monitore, e planeje para a sua ausência

   Por último: torne o registro difícil de mover e difícil de esquecer. As três travas de cliente são grátis e travam toda uma classe de ataque que começa dentro da sua conta no registrador. A data de expiração pertence ao seu sistema de alertas, não a uma caixa de entrada que você pode parar de ler.

   # what the registry says about locks and dates
   curl -s https://rdap.org/domain/example.com \
     | jq -r '.status[], (.events[] | "\(.eventAction) \(.eventDate)")'
   # want: clientTransferProhibited, clientUpdateProhibited, clientDeleteProhibited
   
   # days until expiry, straight from the registry -- no email involved
   exp=$(curl -s https://rdap.org/domain/example.com \
         | jq -r '.events[] | select(.eventAction=="expiration") | .eventDate')
   echo $(( ( $(date -d "$exp" +%s) - $(date +%s) ) / 86400 )) days left
   
   # keep the escape hatch encrypted and off the machine it protects
   age -r age1... -o auth-code.age auth-code.txt && shred -u auth-code.txt

   Rode essa checagem de expiração pelo cron e alerte com noventa dias de antecedência. Guarde o pacote criptografado — dados da conta, códigos de recuperação, código de autorização de transferência — em algum lugar acessível por uma pessoa de sua confiança, porque um domínio anônimo não tem inventário nem escada de suporte. Depois rode de novo os passos quatro a seis uma vez por ano: zonas desviam do previsto, certificados são emitidos por gente que esquece, e o vazamento que você fechou em janeiro geralmente está de volta no outono.