Registrar un dominio de forma anónima: privacidad WHOIS y qué sigue filtrándose

Qué eliminó realmente la redacción

En 2018 el registro de la mayoría de los dominios quedó en blanco. Llegó el RGPD, ICANN dijo a los registradores que dejaran de publicar nombres, direcciones, teléfonos y correos de los titulares en la salida pública de WHOIS, y una consulta que antes devolvía una persona empezó a devolver REDACTED FOR PRIVACY y un formulario de contacto. Parece privacidad. Es un ajuste de visualización.

Por debajo, nada se movió. Tu registrador sigue teniendo el registro completo, sigue obligado a conservarlo por su acreditación, y sigue entregándolo a cualquiera con legitimación para pedirlo —una orden judicial, una solicitud policial y, en la práctica, algo bastante más barato. Una demanda UDRP cuesta unos pocos miles de dólares, no necesita juez, y activa un paso de verificación del registrador que revela al titular real al demandante antes incluso de que se resuelva el caso. Esa es la vía de desenmascaramiento que casi nadie contempla, y es la primera a la que recurre el titular de una marca.

Otras dos cosas sobrevivieron a la redacción. La primera es el historial: los archivos comerciales llevan dos décadas capturando instantáneas de WHOIS y esas instantáneas no caducan, así que un nombre registrado antes de 2018 con datos reales queda expuesto para siempre, diga lo que diga el registro hoy. La segunda es el resto de tu propia configuración —los nameservers que elegiste, la dirección enterrada en tu SOA, el buzón de reportes de DMARC, cada certificado que has solicitado alguna vez. La redacción dejó en blanco un campo y dejó otros cuatro publicando, y esos cuatro son donde esta guía pasa la mayor parte de su tiempo.

Elige la extensión antes de elegir el registrador

La política del registrador es consecuencia de la política del registro, y la política del registro es consecuencia de dónde está constituida la empresa que opera ese registro. Un registrador puede prometer lo que quiera sobre privacidad; no puede prometer más de lo que su registro permite, y ninguno de los dos puede prometer nada sobre un tribunal en la propia jurisdicción del registro. Así que el orden importa, y la mayoría de la gente lo hace al revés: elige primero la extensión, y después elige a quién se la compras.

Tres propiedades distinguen a las extensiones. Dónde se sienta el operador del registro decide qué tribunales pueden ordenar que se suspenda un nombre en la raíz —para los grandes gTLD heredados eso es Estados Unidos, razón por la cual un .com en manos de alguien sin presencia alguna en EE. UU. puede ser incautado igualmente por una orden estadounidense, y por la que tu propia jurisdicción importa mucho menos de lo que te gustaría. Qué publica el registro por defecto varía enormemente: algunos registros de ccTLD redactan más que los gTLD, otros imprimen el nombre del titular para quien lo pida, y unos pocos exigen una presencia local verificada que solo podrías satisfacer con una identidad real. Si los servicios de privacidad están siquiera permitidos es una regla del registro, no una función del registrador —un puñado de extensiones prohíben directamente el registro por proxy, y un registrador que te vende privacidad en una de ellas simplemente te la retirará más tarde.

Nada de eso es lo bastante estable como para memorizarlo, y cualquier lista de "TLD favorables a la privacidad" que encuentres en internet ya está parcialmente equivocada cuando la lees. Compruébalo tú mismo en su lugar: el paso dos ejecuta las búsquedas que responden a las tres preguntas para cualquier extensión que estés considerando, usando un dominio que no es tuyo. Ejecútalas antes de pagar, porque una mala extensión no se arregla transfiriendo de registrador. Solo se arregla empezando de nuevo con otro nombre.

Tres modelos de registrador, y qué sobrevive cada uno

Quita el marketing y quedan tres arreglos disponibles. En el modelo proxy, tú eres el titular y el registrador publica sus propios datos de contacto en lugar de los tuyos. Tus datos ya están en la base de datos del registrador, la redacción es cosmética por encima de un registro completo, y las propias condiciones del proveedor de proxy casi siempre se reservan el derecho de revelarte ante una solicitud de terceros "razonable". Frena por completo a los scrapers y a los data brokers. No frena nada que llegue con un abogado.

En el modelo de titular delegado —el arreglo que Njalla popularizó— el proveedor registra el nombre a su propio nombre y te concede un derecho contractual de uso, de modo que tu identidad nunca llega a ser el titular. No hay nada en el registro que revelar porque no hay nada ahí. La contrapartida es real y merece decirse sin rodeos: no eres legalmente el propietario del dominio. Dependes de la solvencia de una empresa, de sus ganas de resistirse a una solicitud, y de que siga interesada en el negocio. Si quiebra, es adquirida, o decide que le das más problemas de los que vales, tu único recurso es una disputa contractual sobre un activo registrado a nombre de otro.

El tercer arreglo es una identidad de titular limpia y propia: un registro real bajo un handle sin historial, en un buzón que no existe para nada más, pagado en cripto, en un registrador de una jurisdicción sin relación con tu proveedor ni contigo. Escala más allá de un solo dominio, no depende de la buena voluntad de una sola empresa, y es lo que construye el resto de esta guía. También es lo que peor falla si eres descuidado, porque todo descansa en que esa identidad nunca se correlacione contigo en algún otro sitio —el modo de fallo que la guía de propiedad del servidor recorre capa por capa. Los dos modelos combinan bien, por cierto: un registro de titular delegado comprado desde una identidad limpia es más fuerte que cualquiera de los dos por separado.

El formulario de alta: qué puedes negarte a dar, qué te suspenderá

El formulario pide un nombre, una dirección postal, un teléfono y un correo. Tres de esos son datos contractuales que el registrador está obligado a conservar y que casi nunca va a verificar. Uno de ellos es estructural. El correo es el que importa: según el acuerdo de acreditación del registrador, la dirección del titular debe verificarse después del registro, y si nadie hace clic en el enlace el dominio se suspende —normalmente en un plazo de quince días. Un buzón desechable que deja de existir se lleva el dominio consigo.

Así que la dirección debe ser un alias que controles de verdad y que sigas leyendo dentro de tres años, en un proveedor que no exija un número de teléfono para abrir la cuenta y que no la cierre por inactividad. Todo lo demás del formulario es un problema de coherencia, no de veracidad: elige un conjunto de datos plausible, guárdalo cifrado, y usa exactamente los mismos en el registrador, en el perfil de la cuenta y en cualquier ticket de soporte que abras alguna vez. La incoherencia es lo que manda una cuenta a revisión manual, y la revisión manual es donde un humano empieza a pedir documentos.

Después paga por un canal que no arrastre ningún nombre legal hasta el registro. Una tarjeta echa por tierra todo el ejercicio diga lo que diga el WHOIS, porque el registro del procesador de pagos sobrevive al registro del dominio y es trivial citarlo judicialmente; la guía de pagos anónimos clasifica las opciones según lo que filtra cada una. Si el registrador acepta Monero directamente, ese es el camino limpio. Si solo acepta Bitcoin, trata el pago como permanentemente rastreable y fondéalo en consecuencia. Si no acepta ninguno de los dos, el registrador te ha dicho algo útil sobre los clientes que quiere.

El DNS es el segundo registro

En el momento en que publicas una zona te vuelves a registrar a ti mismo, en campos que nadie considera identidad. El registro SOA lleva una dirección de correo codificada con su primer punto haciendo de @, y los archivos de zona escritos a mano suelen llevar una de verdad. Los nombres de los nameservers son una huella: apunta dos dominios a los mismos nameservers personalizados y los has vinculado de forma permanente, en un conjunto de datos que los motores de búsqueda inversa por nameserver indexan y conservan. Y cuando esos nameservers viven dentro del propio dominio, el registro publica registros glue —sus direcciones IP, en la zona raíz, fuera del alcance de cualquier CDN que pongas delante del sitio. Hay quien se pasa una semana ocultando un origen y luego entrega su dirección en un registro glue.

DNSSEC merece una advertencia concreta, porque se vende como función de seguridad y se comporta como una de divulgación. Firmar una zona con NSEC publica una lista enlazada de cada nombre que contiene, recorrible por cualquiera en segundos. NSEC3 aplica hash a los nombres en su lugar, lo cual suena mejor y solo encarece el precio: los hashes son crackeables sin conexión y hay herramientas que no hacen otra cosa. Firma la zona si quieres respuestas autenticadas, y entra sabiendo que no estás ocultando tu lista de subdominios. Nunca lo estuviste.

Dónde se sirve la zona es una decisión separada de quién registró el nombre, y repartirlas entre dos empresas en dos países vale más que cualquiera de las dos opciones por separado. Llevar tus propios nameservers te compra control y una huella pequeña y distintiva; usar los de un proveedor grande te compra anonimato entre la multitud y una empresa que registra cada consulta y responderá a una solicitud sobre ellas. Aquí no hay opción gratis, solo una elección sobre qué registro prefieres que exista. Si el sitio detrás de la zona está detrás de un edge, la guía de la IP de origen cubre el resto de esa cadena.

Las filtraciones que llegan después del alta

La transparencia de certificados es la grande. Todo certificado de confianza pública se escribe en un log público, de solo apéndice y permanentemente consultable, así que cualquier nombre que le hayas pedido firmar alguna vez a una CA es descubrible —incluidos los hosts staging., vpn. y old- que dabas por hecho que nadie conocía, y el nombre interno que emitiste por accidente una vez y borraste esa misma tarde. No puedes retirar una entrada de un log. El único control está aguas arriba: pide un comodín validado por DNS-01 para que los hostnames individuales nunca entren en ningún log, y mantén los nombres genuinamente privados en una CA interna que no registre nada.

El correo publica dos más. Un registro SPF nombra el relay por el que envías. Un registro DMARC suele nombrar a una persona, porque rua= es adonde van los informes y la gente pone ahí su buzón real. Y un MX que apunta a la misma máquina que sirve el sitio entrega la dirección de origen a cualquiera que ejecute una sola consulta —el correo es la forma más común, con diferencia, en que un origen se escapa de detrás de un edge.

La última categoría es la correlación, y es lo que deshace un trabajo por lo demás cuidadoso. El mismo conjunto de nameservers en dos identidades distintas las vincula. Lo mismo hace un certificado que cubra ambos nombres, el mismo identificador de analítica, el mismo favicon —los escáneres de todo internet indexan hashes de favicon precisamente porque son una huella excelente— la misma cabecera de respuesta poco habitual, el mismo registrador a la misma hora de la misma noche. Cualquiera de esos por separado es evidencia débil. Tres juntos no lo son. Los pasos cuatro y seis ejecutan las búsquedas que haría un adversario, contra tu propio dominio, que es la única forma honesta de saber qué has publicado en realidad.

Renovación, transferencia, y el fallo del año tres

Los dominios anónimos rara vez mueren por una citación judicial. Mueren por un registro caducado. El buzón alias dejó de leerse, el aviso de renovación rebotó, el saldo se agotó, y un nombre que costó un año construir cayó en el pool donde un drop-catcher estaba esperando. Activa la renovación automática, mantén suficiente saldo en el registrador para cubrir varios años, y pon la fecha de caducidad en cualquier sistema de alertas que de verdad consultes —el paso siete la extrae directamente del registro, así que el recordatorio no depende del buzón que más probablemente falle.

Los bloqueos son la otra mitad, y son gratis. clientTransferProhibited, clientUpdateProhibited y clientDeleteProhibited cuestan un clic cada uno y cierran toda la clase de ataque que empieza con alguien entrando en tu cuenta del registrador. Algunos registros también ofrecen un bloqueo de registro, que exige una confirmación fuera de banda antes de que cambie nada y que merece la pena pagar en un nombre que no puedes permitirte perder. Mantén el código de autorización de transferencia cifrado y offline, y ten en cuenta que cambiar el contacto del titular activa una prohibición de transferencia de sesenta días —así que haz esa tarea de mantenimiento cuando no tengas prisa, nunca en mitad de un incidente.

Después planifica la versión de esto en la que tú no estás disponible. Un dominio sostenido sobre una identidad anónima no tiene sucesión, ni escalado de soporte, ni más prueba de propiedad que las propias credenciales, lo cual convierte una copia cifrada de los datos de la cuenta, los códigos de recuperación y el código de autorización —guardada donde alguien de tu confianza pueda llegar a alcanzarla— en lo único que se interpone entre un proyecto de larga vida y un nombre muerto. La misma lógica se aplica a la máquina que hay detrás: una copia de seguridad cifrada fuera de sitio que nadie puede restaurar es una copia de seguridad que no tienes.

Un modelo de amenaza realista

Sé preciso sobre qué es lo que esto derrota. Contra scrapers, data brokers, competidores, investigadores de código abierto y el oportunista que salta de uno de tus nombres a todos los demás, una identidad de titular limpia con una zona sin filtraciones funciona, y funciona por completo —no hay nada en el registro público desde donde saltar. Contra un demandante civil, eleva el coste de una consulta gratuita a un proceso legal, lo cual es una diferencia real y a menudo decisiva. Contra una UDRP presentada por el titular de una marca, el modelo proxy te da muy poco, y el modelo de titular delegado te da una empresa que tiene que decidir cuánto está dispuesta a pelear en tu nombre.

Contra un estado con jurisdicción sobre tu registro no gana, y ningún arreglo de registradores lo hace: el nombre puede suspenderse en la raíz sin importar quién lo tenga. Eso es un argumento para elegir la extensión de forma deliberada y para ser dueño de tu contenido lo bastante bien como para poder moverlo, no para buscar un registrador más listo. Y contra tus propios errores no ofrece absolutamente nada. Un inicio de sesión desde un perfil de navegador personal, un ticket de soporte escrito con tu voz habitual desde tu dirección habitual, un certificado que cubra ambas identidades, y el registro que te has pasado esta guía manteniendo limpio queda recompuesto en una tarde.

Construye pensando en el adversario que realmente tienes. Para la mayoría de la gente la respuesta honesta son los brokers y los oportunistas, y cerrar los registros de los pasos cinco y seis es suficiente. Si tu exposición es mayor, recuerda que el dominio es una capa de varias: combínalo con un proveedor que nunca preguntó quién eres, una máquina endurecida desde el primer día, y un pago que no arrastre ningún nombre. La privacidad es una cadena, y cada guía de aquí describe un eslabón distinto de la misma.

Paso a paso

1. 01

   Audita lo que el nombre ya publica

   Empieza por el dominio que ya tienes, o por uno que estés a punto de comprarle a otra persona. RDAP es el servicio de registro legible por máquina que sustituyó al WHOIS de puerto 43 para los gTLD, habla JSON sobre HTTPS, y rdap.org te llevará al registro correcto. Muchos ccTLD todavía solo responden por el puerto 43, y varios de ellos publican más de lo que publicaría un gTLD.

   # 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 '^%|^$'

   Si te devuelve un nombre real, una dirección real o un correo personal, para aquí: transferir el dominio no lo borrará, porque los archivos ya lo tienen. Ese nombre está quemado a efectos de privacidad y lo honesto es registrar uno nuevo y redirigir.

2. 02

   Pon a prueba la extensión antes de comprometerte con ella

   Compara las extensiones candidatas de forma empírica, no a partir de una entrada de blog. Busca un dominio que no sea tuyo en cada una y lee lo que devuelve realmente el registro, después comprueba quién opera ese registro y dónde. La forma de la salida difiere entre registros, que es exactamente por lo que merece la pena ejecutarlo en vez de suponerlo.

   # 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

   Tres respuestas lo deciden. ¿Publica el registro un nombre de titular por defecto? ¿Exige una presencia local verificada? ¿Y a qué tribunales responde el operador del registro? Cualquier cosa que exija presencia local queda descartada a menos que puedas satisfacerla con la verdad, y cualquier cosa cuyo operador se encuentre en una jurisdicción que estés evitando específicamente queda descartada sin importar lo bien que se vea el registrador.

3. 03

   Construye la identidad antes de abrir la cuenta

   Genera la identidad de una sola sentada y no anotes nada en texto plano. El handle no debe tener historial —ni un apodo que hayas usado en otro sitio, ni una palabra que signifique algo para ti. El buzón debe ser un alias en un proveedor que no exija número de teléfono, y necesita sobrevivir a tres años de abandono, porque ahí llegan el correo de verificación del registrador y cada aviso de renovación.

   # 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

   Usa un perfil de navegador que nunca haya tocado una cuenta personal, y llega al registrador siempre por la misma ruta de red —mezclar una conexión doméstica y una VPN entre sesiones es más distintivo que usar cualquiera de las dos de forma consistente. Anota los datos exactos de perfil que envíes; tendrás que repetirlos literalmente en un ticket de soporte dentro de dos años.

4. 04

   Regístralo, y luego mírate a ti mismo como un desconocido

   Registra el nombre, haz clic en el enlace de verificación el mismo día, y luego espera a que se propague hasta el registro antes de comprobarlo —la salida interesante aparece unas horas después, no de inmediato. Lo que estás buscando es cualquier campo que no se haya redactado, y los códigos de estado que te dicen si la verificación realmente se completó.

   # 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

   Un estado clientHold o pendingVerification una semana después significa que el correo de verificación nunca llegó o nunca se hizo clic en él, y el dominio está en cuenta atrás hacia la suspensión. Arregla eso antes que cualquier otra cosa —es la forma más común, con diferencia, en que un dominio anónimo correctamente registrado se pierde en su primer mes.

5. 05

   Publica una zona que no te nombre

   Ahora la parte que más filtra y menos se revisa. Lee tu propia zona como la leería un desconocido: la dirección del SOA, los nombres de los nameservers, el glue que el registro publica en tu nombre, y si cualquiera puede simplemente descargarse todo entero.

   # 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"

   Arregla en este orden: sustituye la dirección del SOA por un buzón de rol en el propio dominio, mueve los nameservers fuera del dominio (o directamente fuera de tu propia máquina) para que no haga falta ningún glue, rechaza AXFR de cualquiera que no sean tus secundarios, y añade un registro CAA. Si firmas con DNSSEC, usa NSEC3 y acepta que tu lista de subdominios sigue siendo enumerable por cualquiera dispuesto a dedicarle una hora.

6. 06

   Cierra las filtraciones de certificados y de correo

   Hay dos conjuntos de datos públicos que saben más sobre tu infraestructura que tu propio DNS. La transparencia de certificados conoce cada hostname que le has hecho firmar alguna vez; tus propios registros de correo nombran tu relay, tu buzón de informes y con frecuencia tu origen. Enuméralos ambos contra ti mismo.

   # 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

   Traslada la emisión futura a un comodín validado por DNS-01 para que los hostnames dejen de entrar en los logs, apunta rua= a una dirección del propio dominio en lugar de a un buzón personal, y saca el correo del origen —un relay o una máquina aparte, nunca la caja donde corre el sitio. Los nombres que ya están en los logs no se pueden borrar; desactívalos o acepta que serán públicos para siempre.

7. 07

   Bloquéalo, vigílalo, y planifica tu ausencia

   Por último: haz que el registro sea difícil de mover y difícil de olvidar. Los tres bloqueos de cliente son gratis y detienen toda la clase de ataque que empieza dentro de tu cuenta del registrador. La fecha de caducidad pertenece a tu sistema de alertas, no a un buzón que puede que dejes de leer.

   # 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

   Ejecuta esa comprobación de caducidad desde cron y avisa a los noventa días. Guarda el paquete cifrado —datos de la cuenta, códigos de recuperación, código de autorización de transferencia— en algún sitio al alcance de alguien de tu confianza, porque un dominio anónimo no tiene sucesión ni escalado de soporte. Después vuelve a ejecutar los pasos cuatro a seis una vez al año: las zonas se descuidan, hay certificados que emite gente que se olvida, y la filtración que cerraste en enero suele estar de vuelta para el otoño.