Cada dominio que consultan tus dispositivos es una línea con marca de tiempo en el archivo de otro — el de tu ISP, o el de un resolver público gratuito. Seis pasos para trasladar ese archivo a una máquina que te pertenezca: Unbound resolviendo desde la raíz, AdGuard Home filtrando por delante, DNS cifrado sobre un certificado real, y un puerto 53 que nunca da la cara a internet. La máquina cuesta $3.90 al mes. Probado en Debian 12.
Forma
Recursivo, no reenviador
Cerrar
El puerto 53, antes de que se abra
Resolver
Unbound, validando
Filtrar
AdGuard Home, DoH, DoT
Alcanzar
Primero el túnel, luego los clientes
Verificar
Fugas, DNSSEC, disponibilidad
Cifra el disco, tuneliza el tráfico, paga en Monero, date de alta sin correo electrónico — y luego deja que el portátil le pida a un resolver en el que nunca has pensado que traduzca cada nombre de host que toca, una consulta cada vez, en claro, todo el día. La resolución de nombres es la parte de la pila que la gente refuerza en último lugar, y es la parte que produce el registro más limpio de lo que alguien hace realmente.
Merece la pena ser precisos sobre qué contiene ese registro, porque "el DNS filtra tu navegación" es a la vez cierto y perezoso. Un registro de consultas es una lista de nombres de dominio con marca de tiempo, atribuidos a la dirección IP que preguntó. No son las páginas que lees, y normalmente tampoco es la URL exacta. Es algo más silencioso y, para elaborar perfiles, mejor: la forma de una vida. El banco. El empleador. La app de citas que se conecta cada cuatro minutos. El sitio médico visitado una sola vez a las 02:00. Los tres dominios que solo aparecen juntos porque pertenecen al mismo cliente de mensajería. Nadie necesita el contenido cuando el índice es así de bueno.
Cuatro partes pueden tener ese índice, y el autoalojamiento lo traslada de las dos primeras a la cuarta:
| Configuración | Quién ve todas las consultas que haces | Visible en el cable | Conjunto de anonimato |
|---|---|---|---|
| Resolver del ISP, en claro (lo predeterminado) | Tu ISP, por nombre y cuenta | Todo, para cualquiera en la ruta | Sus abonados |
| Resolver público, cifrado (DoH/DoT) | Esa única empresa, vinculada a tu IP | Nada salvo el destino | Millones |
| Tu propio resolver, reenviando a un upstream | El upstream que elegiste — sin cambios | Nada salvo el destino | Uno |
| Tu propio resolver, recursivo desde la raíz | Nadie — cada zona ve solo sus propios nombres | Nada salvo el destino | Uno, en una IP que no eres tú |
La tercera fila es la que atrapa a la gente. Instalar un resolver en tu propio servidor y luego decirle que reenvíe todo a 1.1.1.1 cambia exactamente una cosa: tus consultas ahora llegan a Cloudflare desde una dirección IP distinta. El registro sigue existiendo, sigue perteneciendo a otro, y has añadido una máquina que mantener a cambio de nada.
La última columna es el coste honesto, y esta guía vuelve sobre él dos veces. Un resolver usado por un solo hogar es un resolver cuyas consultas son inequívocamente de ese hogar. Lo que hace que el intercambio merezca la pena es que la IP que pregunta es un servidor nórdico de alquiler sin ningún documento de identidad detrás — no una línea doméstica con un nombre de abonado, ni una cuenta de hyperscaler con una tarjeta registrada. El conjunto de anonimato se reduce; lo que realmente se rompe es el vínculo con una persona.
Hay dos máquinas completamente distintas escondidas detrás de la frase "mi propio servidor DNS", y casi todos los tutoriales construyen la equivocada. Decide esto antes de instalar nada, porque es la diferencia entre una herramienta de privacidad y un simple proxy para la política de privacidad de otro.
Un reenviador toma tu consulta y la pasa a otro resolver — típicamente Cloudflare, Google, Quad9 o tu ISP — y luego guarda en caché lo que sea que vuelva. Es simple, es rápido, y entrega todo tu flujo de consultas a un único tercero. Toda guía que termina con "ahora configura tu upstream en 1.1.1.1" ha construido uno de estos.
Un resolver recursivo hace el trabajo por sí mismo. Para encontrar mail.example.com le pregunta a un servidor raíz quién gestiona .com, les pregunta a los servidores de .com quién gestiona example.com, y luego les pregunta a los propios servidores de nombres de example.com por el registro. Tres o cuatro conversaciones breves con tres o cuatro operadores distintos, ninguno de los cuales sabe nada de los demás. Con la minimización de QNAME activada va más allá: a la raíz solo se le pregunta por .com, y a los servidores de .com solo por example.com. El nombre completo se revela a exactamente una parte — la que aloja el nombre, y que de todos modos iba a recibir tu conexión treinta milisegundos después.
| Propiedad | Unbound, recursivo | Cualquier reenviador | AdGuard Home solo |
|---|---|---|---|
| Una sola parte ve todas las consultas | No | Sí | Sí — su upstream |
| DNSSEC validado localmente | Sí | Delegada en el upstream | Delegada en el upstream |
| Listas de bloqueo y reglas por dispositivo | Solo mediante zonas locales | Depende del daemon | Sí, con interfaz web |
| Receptores DoH / DoT para clientes | DoT de forma nativa, DoH mediante un proxy | Depende del daemon | Ambos, integrados |
| Latencia de arranque en frío | 3–4 idas y vueltas | 1 ida y vuelta | 1 ida y vuelta |
| La respuesta correcta | La mitad de privacidad de la pila | Solo como respaldo deliberado | La mitad de filtrado, por delante |
Las dos columnas de la derecha no son competidoras — son las dos mitades de la misma construcción. AdGuard Home es dueño del puerto 53, aplica las listas de bloqueo y termina los transportes cifrados; Unbound se sitúa detrás, en loopback, y se encarga de resolver. Ninguna de las dos mitades hace bien el trabajo de la otra, y la cadena completa ronda los cien megabytes de RAM.
Si solo te llevas una cosa de esta página, que sea esta: un resolver que reenvía a un proveedor de DNS público no ha hecho privado tu DNS. Ha desplazado el registro un salto más allá y ha añadido un servidor a tu lista de mantenimiento. La recursión es todo el sentido de esto.
Pide primero la máquina. En el panel: Order → VPS → Sentinel, imagen Debian 12, en el bastión que esté más cerca de los dispositivos que lo van a usar — Helsinki, Stockholm, Oslo o Reykjavík. No hace falta ninguna dirección de correo para abrir la cuenta, y la factura se liquida en Monero, Bitcoin, Lightning o cualquier otro activo admitido, lo cual aquí importa más de lo habitual: todo el valor de un resolver personal descansa en que la dirección IP que pregunta no pueda rastrearse hasta un nombre.
Después repasa la lista de refuerzo de la primera hora — solo claves SSH, sin inicio de sesión con contraseña, actualizaciones desatendidas — porque todo lo que sigue asume una máquina que no está ya comprometida.
Un resolver recursivo que responde a toda internet se llama resolver abierto, y los rastreadores que escanean toda la red lo encontrarán en cuestión de horas desde que se abra el puerto. El DNS funciona sobre UDP, las direcciones de origen UDP son triviales de falsificar, y una consulta de 60 bytes puede producir una respuesta docenas de veces más grande — así que un resolver abierto es un amplificador gratuito para un ataque de denegación de servicio contra un tercero. La secuencia que sigue es siempre la misma: empieza el tráfico, llegan los informes de abuso, y la IP acaba con un null route. Es, con diferencia, la forma más común en que acaba un primer servidor DNS. Dos reglas lo evitan por completo: rechazar por defecto en la configuración del resolver, y no permitir nunca 53/udp desde 0.0.0.0/0 en el firewall.
Así que el firewall va primero, mientras todavía no escucha nada. Las reglas de abajo asumen un túnel WireGuard en 10.8.0.0/24 — si no has construido uno, la guía de WireGuard enlazada al final de esta página es un desvío de quince minutos, y es el transporte con el que todo este diseño se siente más cómodo.
ufw default deny incoming
ufw allow 22/tcp # or your moved SSH port
ufw allow 51820/udp # WireGuard
ufw allow in on wg0 to any port 53 proto udp
ufw allow in on wg0 to any port 53 proto tcp
ufw enable
# DNS is NOT opened to the world. Confirm it:
ufw status numbered | grep 53
Fíjate en lo que falta a propósito: no hay ninguna regla que abra el 53 en la interfaz pública. El puerto 53 solo existe en wg0 y en loopback. Si más adelante añades DNS-over-TLS o DNS-over-HTTPS, eso son TCP 853 y TCP 443, se autentican con un certificado, y reciben sus propias reglas en el paso 05 — el puerto UDP en claro sigue cerrado en cualquier caso.
Ahora despeja el puerto. En Ubuntu — y en cualquier Debian donde alguien lo haya activado — systemd-resolved ya está escuchando en 127.0.0.53:53, y Unbound se negará a arrancar con un error de bind que la gente se pasa veinte minutos malinterpretando. Comprueba primero, y luego desactiva solo el stub listener, manteniendo systemd-resolved como interfaz local del lado del cliente:
ss -lunp 'sport = :53' # who owns UDP/53 right now?
mkdir -p /etc/systemd/resolved.conf.d
cat > /etc/systemd/resolved.conf.d/no-stub.conf <<'EOF'
[Resolve]
DNSStubListener=no
EOF
systemctl restart systemd-resolved
ss -lunp 'sport = :53' # should now be empty
En un Debian 12 limpio, el primer comando no imprime nada y no hay nada que hacer. Ejecútalo de todos modos — tarda un segundo, y la alternativa es diagnosticar un "address already in use" contra un servicio que no sabías que estaba corriendo.
Unbound es un resolver recursivo, con caché y validación, de NLnet Labs. Está empaquetado en todas partes, es lo que ya ejecuta buena parte de internet, y de fábrica hace recursión — tienes que esforzarte deliberadamente para convertirlo en un reenviador. Instálalo junto con el paquete de root hints para que sepa dónde están los servidores raíz sin tener que descargar una lista de ningún sitio:
apt update && apt install -y unbound dns-root-data
unbound -V | head -2
El paquete dns-root-data instala los root hints en /usr/share/dns/root.hints y el ancla de confianza raíz de DNSSEC en /usr/share/dns/root.key, y mantiene ambos actualizados a través del canal normal de paquetes. Esa es la forma aburrida y correcta de obtenerlos; descargar root.hints desde una URL en un cron job es la forma que, tarde o temprano, falla en silencio.
/etc/unbound/unbound.conf.d/nb-resolver.conf
server:
# ---- Who may ask. Deny first, allow narrowly.
interface: 127.0.0.1@5335
interface: 10.8.0.1
access-control: 0.0.0.0/0 refuse
access-control: ::0/0 refuse
access-control: 127.0.0.0/8 allow
access-control: 10.8.0.0/24 allow
# ---- Privacy of the recursion itself.
qname-minimisation: yes
qname-minimisation-strict: no
hide-identity: yes
hide-version: yes
rrset-roundrobin: yes
# ---- DNSSEC. The anchor is maintained by the dns-root-data package.
auto-trust-anchor-file: "/var/lib/unbound/root.key"
root-hints: "/usr/share/dns/root.hints"
harden-dnssec-stripped: yes
harden-glue: yes
harden-below-nxdomain: yes
harden-large-queries: yes
harden-short-bufsize: yes
aggressive-nsec: yes
val-clean-additional: yes
# ---- Do not be a reflector, even by accident.
refuse-any: yes
ratelimit: 1000
ip-ratelimit: 200
edns-buffer-size: 1232
# ---- Cache. This is where the 4 GB actually earns its keep.
msg-cache-size: 128m
rrset-cache-size: 256m
cache-min-ttl: 60
cache-max-ttl: 86400
prefetch: yes
prefetch-key: yes
serve-expired: yes
serve-expired-ttl: 3600
# ---- Never chase a name that has no business being on the internet.
private-address: 10.0.0.0/8
private-address: 172.16.0.0/12
private-address: 192.168.0.0/16
private-address: 169.254.0.0/16
private-address: fd00::/8
private-address: fe80::/10
num-threads: 2
so-reuseport: yes
verbosity: 0
logfile: ""
remote-control:
control-enable: yes
control-interface: /run/unbound.ctl
Cuatro de esas líneas hacen el trabajo de verdad y merecen una frase cada una.
Fíjate en los dos receptores. El loopback en el puerto 5335 es lo que usará AdGuard Home en el siguiente paso; 10.8.0.1 es la dirección del túnel, para que los clientes de la VPN puedan consultar a Unbound directamente si decides saltarte la capa de filtrado. Si todavía no tienes WireGuard funcionando, quita por ahora esa segunda línea de interfaz — Unbound no arrancará con una dirección que no existe en la máquina.
Arráncalo y demuestra que funciona:
unbound-checkconf
systemctl restart unbound && systemctl enable unbound
apt install -y dnsutils
dig @127.0.0.1 -p 5335 nordbastion.com +short
# DNSSEC: the first must come back with the "ad" flag set,
# the second must FAIL — its signatures are deliberately broken.
dig @127.0.0.1 -p 5335 dnssec-tools.org +dnssec | grep -E 'flags:|status:'
dig @127.0.0.1 -p 5335 dnssec-failed.org | grep 'status:'
El flag ad en la primera respuesta significa que Unbound comprobó la cadena de firmas desde la raíz hasta el registro y que se sostuvo. El SERVFAIL en la segunda significa que la validación rechazó una respuesta manipulada en lugar de pasártela. Si la segunda devuelve una dirección en su lugar, la validación no está activada y el ancla de confianza es lo primero que hay que revisar.
Este paso es opcional en sentido estricto — Unbound por sí solo ya es un resolver privado — y aun así casi todo el mundo lo quiere. AdGuard Home te da listas de bloqueo, políticas por cliente, un registro de consultas legible mientras depuras, y, lo más útil, receptores nativos de DNS-over-TLS y DNS-over-HTTPS para que los teléfonos y los navegadores puedan hablar con tu resolver desde redes donde una VPN no resulta práctica.
El montaje es una cadena, y acertar con los puertos es todo el truco: AdGuard Home es dueño del 53 y da la cara a los clientes, Unbound se sitúa en 127.0.0.1:5335 y da la cara a internet. Ninguna otra cosa en la máquina escucha en el 53.
curl -fsSL https://raw.githubusercontent.com/AdguardTeam/AdGuardHome/master/scripts/install.sh | sh -s -- -v
# Web interface: http://<vps>:3000 — reach it over the SSH tunnel below,
# never by opening 3000 to the internet.
ssh -N -L 3000:127.0.0.1:3000 root@<vps>
Haz el asistente de primer arranque a través de ese túnel. Configura el receptor de administración en 127.0.0.1 o en la dirección del túnel, nunca en 0.0.0.0, y ponle una contraseña larga — esta interfaz puede reescribir cada nombre que resuelve tu red, lo que la hace tan sensible como el propio resolver.
Después configura exactamente un upstream: en Ajustes → Ajustes de DNS, borra la lista predeterminada e introduce tu instancia de Unbound. Una línea, nada más. Si se deja un resolver público en ese campo, todo lo del paso 01 queda deshecho.
127.0.0.1:5335
Deja "Parallel requests" desactivado — con un único upstream no hace más que duplicar tráfico — y desactiva "Use private reverse DNS resolvers" a menos que realmente gestiones una zona interna. Configura los servidores de bootstrap con algo de confianza; solo se usan para resolver los nombres de host de los servidores upstream, y con un upstream en forma de IP directa nunca llegarán a consultarse.
Listas de bloqueo: empieza acotado. El instinto es activarlo todo en la página de listas y disfrutar del contador. Resístete. Cada lista es un conjunto de decisiones de criterio tomadas por otra persona sobre qué puede alcanzar tus dispositivos, y los fallos son silenciosos y confusos — una página que carga a medias, un botón que no hace nada, una app bancaria que se niega a abrir. Empieza con el filtro DNS predeterminado de AdGuard, o con un único agregado bien mantenido como OISD, convive con él durante dos semanas, y solo entonces añade más. Mantén una lista de permitidos y úsala sin remordimientos.
Acabas de construir una máquina cuyo propósito es impedir que otro mantenga una lista de cada nombre que resuelven tus dispositivos — y lo primero que hace AdGuard Home es mantener exactamente esa lista, activada por defecto, durante noventa días. Es genuinamente útil mientras estás ajustando las listas de bloqueo, y es el archivo más sensible del servidor con diferencia. Decide de forma deliberada: 24 horas bastan para responder "¿qué acaba de pedir ese dispositivo?", cero es el ajuste honesto una vez terminado el ajuste fino, y noventa días es una decisión que nadie debería tomar por dejar un valor predeterminado intacto. Ajustes → General → Registro de consultas, y de paso configura ahí mismo la retención de estadísticas.
Apunta el firewall al nuevo montaje — AdGuard Home es ahora dueño del puerto 53 en la interfaz del túnel, y Unbound solo es alcanzable por loopback. Nada cambia en la interfaz pública: sigue sin tener ningún DNS en absoluto.
Un resolver al que nadie puede llegar no sirve de nada, y un resolver al que puede llegar todo el mundo es el modo de fallo del paso 02. Hay exactamente dos buenas respuestas, y la mayoría de la gente acaba usando las dos — el túnel en casa y en el portátil, DNS cifrado en el teléfono y en redes donde UDP está filtrado.
Opción A — sobre WireGuard. La mejor de las dos, y la razón por la que esta guía no deja de señalar la guía de WireGuard. El puerto 53 sigue invisible para internet, la consulta en sí nunca cruza una red no confiable de ninguna forma, y no hay ningún certificado que renovar. Si el VPS ya es tu salida de VPN, esto es una línea en la configuración de cada par:
# On the client, in the [Interface] section of the peer config:
DNS = 10.8.0.1
Una sutileza que muerde a la gente: en Linux, wg-quick configura esa dirección a través de resolvconf o de systemd-resolved, y si ninguno de los dos está instalado, no hace nada en silencio mientras el túnel se levanta perfectamente. Compruébalo con resolvectl status o leyendo /etc/resolv.conf después de levantar el túnel — un túnel que funciona con el resolver antiguo todavía configurado es exactamente la fuga de la que trata todo este ejercicio.
Opción B — DNS-over-TLS y DNS-over-HTTPS. Necesario cuando el dispositivo no puede estar siempre en el túnel. Ambos se autentican con un certificado, lo que implica un nombre de host: apunta un registro A al VPS, y luego deja que AdGuard Home tenga el certificado directamente, o colócalo detrás de un proxy inverso que ya termine TLS por ti. Los receptores son 853/tcp para DoT y 443/tcp para DoH.
ufw allow 853/tcp # DNS-over-TLS
ufw allow 443/tcp # DNS-over-HTTPS
# 53/udp is still NOT open on the public interface. It never will be.
ufw status
Dale al endpoint de DoH una ruta que no se pueda adivinar — AdGuard Home te permite servirlo bajo /dns-query/<random>, y una ruta distinta por persona significa que el acceso se puede revocar a una persona cada vez sin tener que rotar nada para el resto. No es autenticación en ningún sentido fuerte, pero evita que un receptor público sea, en el fondo, un resolver abierto con pasos extra.
| Cliente | Dónde vive el ajuste | Transporte que utiliza |
|---|---|---|
| Android 9 y posteriores | Ajustes → Red → DNS privado → nombre de host | Solo DNS-over-TLS |
| iOS y macOS | Un perfil de DNS .mobileconfig firmado | DoH o DoT, en todo el sistema |
| Windows 11 | Ajustes → Red → Asignación del servidor DNS | DoH, por adaptador |
| Firefox | Ajustes → Privacidad → DNS sobre HTTPS → Personalizado | DoH, solo en el navegador |
| Router (toda la red) | DNS de la WAN, u opción 6 de DHCP | DNS en claro — así que tunelízalo |
La fila del router es la que hay que pensar bien. Repartir tu resolver por DHCP cubre de golpe todos los dispositivos de la casa, incluidos los que no tienen pantalla de ajustes — pero el salto del router al VPS pasa a ser entonces DNS en claro por la internet abierta, que es precisamente lo que te propusiste detener. Ejecuta el túnel en el propio router, o acepta que la última milla va sin cifrar y deja que la recursión sea la victoria.
Una última configuración que conviene conocer: un navegador que tenga DNS-over-HTTPS activado usará su propio resolver e ignorará silenciosamente el ajuste del sistema, haya túnel o no. Tanto Firefox como Chrome lo traen activado por defecto en algunas regiones. O apuntas también el navegador a tu endpoint, o desactivas su DoH para que siga al sistema operativo.
1. ¿Está abierto a internet? Ejecuta esto desde una máquina que no esté en el túnel — un teléfono con datos móviles, otro VPS, lo que sea. Un timeout es la respuesta correcta y deseable. Una respuesta real significa que cualquier rastreador de internet lo encontrará también, y deberías volver al paso 02 de inmediato.
dig @<public-ip-of-vps> +timeout=3 example.com
# Expected: ";; connection timed out; no servers could be reached"
2. ¿Lo está usando realmente el dispositivo? Esta es la comprobación que falla más a menudo, y el fallo es invisible: el túnel está levantado, el ajuste parece correcto, y el sistema operativo le sigue preguntando al resolver que le dio la cafetería por DHCP. Pregúntale al propio resolver quién cree que eres, y luego confírmalo desde el otro lado.
# On the client — which resolver is the system actually using?
resolvectl status | grep -A2 'Current DNS' # Linux
scutil --dns | grep nameserver # macOS
# On the server — does the query actually arrive?
tail -f /var/log/syslog | grep -i unbound &
unbound-control stats_noreset | grep total.num.queries
Después carga desde el dispositivo una de las páginas públicas de test de fugas de DNS y lee el resultado. Si nombra a tu proveedor de VPS, la ruta es la correcta. Si nombra a tu ISP o a un gran resolver público, algo por encima del túnel sigue respondiendo.
3. ¿Está la validación realmente activada? Repite los dos comandos dig del paso 03, pero esta vez a través de toda la cadena — cliente, AdGuard Home, Unbound — en lugar de contra Unbound directamente. Un nombre con la firma rota tiene que fallar también aquí. Si a AdGuard Home se le ha quedado un segundo upstream olvidado en algún ajuste, aquí es donde se nota.
4. ¿Está la caché haciendo su trabajo? Tras un día de uso normal, la tasa de aciertos debería rondar entre el setenta y el noventa por ciento. Mucho más baja suele significar que la caché es demasiado pequeña o que se está ignorando cache-min-ttl porque todo lo que llega del upstream tiene un TTL muy corto; mucho más alta en una red con bastante tráfico es una señal feliz de que prefetch está funcionando.
unbound-control stats_noreset | grep -E 'total.num.(queries|cachehits)'
# hit rate = cachehits / queries
Y luego las dos decisiones operativas. Primero: qué pasa cuando esta máquina se reinicia. Todos los dispositivos que apunten a ella pierden la resolución de nombres, algo que todos en el hogar reportarán como que internet está roto. Configura el servicio para que se reinicie tras un fallo y arranque al inicio, y luego reinicia el VPS una vez a propósito y observa cómo vuelve. Segundo: un respaldo. O bien pones un resolver público como secundario en tus clientes y aceptas que esas consultas escapan a tu control durante una caída, o ejecutas una segunda instancia en un segundo VPS en otro bastión. Las dos opciones son defendibles. Descubrir la pregunta a las 23:00 de un domingo no lo es.
systemctl enable unbound AdGuardHome
systemctl show unbound -p Restart -p RestartUSec
reboot # then, from a client: dig nordbastion.com +short
Un resolver privado es una mejora real, y no es una capa de invisibilidad. Cualquiera que te lo venda como tal te está vendiendo algo. Aquí está la lista de lo que sigue siendo visible después de hacer todo lo anterior, porque conocer la forma de la exposición que queda es la diferencia entre una defensa de verdad y una manta de seguridad.
La conexión sigue ocurriendo. Un milisegundo después de la consulta, tu dispositivo abre una conexión TCP a la dirección que acaba de aprender. Cualquiera que esté observando tu línea ve esa dirección. En un sitio con IP propia, la dirección es el sitio. El DNS cifrado elimina la pregunta; no elimina la respuesta.
El saludo TLS suele nombrar el sitio. Server Name Indication se envía en claro al principio de casi toda conexión HTTPS, así que un observador pasivo lee igualmente el nombre de host. Encrypted Client Hello soluciona esto, pero está desplegado de forma desigual — donde tanto el navegador como el sitio lo admiten, el nombre queda oculto, y donde no, no. No des por hecho que está activado.
El operador del resolver eres ahora tú, y tú eres una sola persona. Cada servidor autoritativo con el que habla tu resolver ve una única dirección IP preguntando por su zona. A lo largo de muchas zonas, esa IP tiene un patrón distintivo, y el patrón es un hogar. Este es el coste de conjunto de anonimato del primer capítulo, y lo único que lo atenúa es que la IP no se pueda rastrear hasta un nombre — un VPS sin KYC pagado en cripto — e, idealmente, que sea la misma IP por la que ya sale tu tráfico.
El proveedor puede ver los paquetes, como siempre. El VPS funciona sobre el hardware de alguien, en el centro de datos de alguien. NordBastion no inspecciona el tráfico de los clientes, y el informe de transparencia y el warrant canary describen qué pasaría si se nos preguntara — pero la afirmación arquitectónica honesta es que una máquina que alquilas es una máquina que otro puede alcanzar físicamente. Lo que cambia el autoalojamiento es que no hay ningún registro de consultas a nivel de producto, ningún pipeline de analítica y ninguna política de privacidad que se pueda modificar; solo hay un proceso que mantiene una caché en RAM, configurado por ti, en una jurisdicción que elegiste a propósito.
Lo que has comprado en realidad, con precisión: la fuente más rica y más barata de datos de comportamiento sobre ti ha dejado de ser recogida por una parte cuyo modelo de negocio consiste en recogerla. Es una afirmación limitada, y es una afirmación real. Nada en esta página sustituye a Tor cuando el modelo de amenaza pide Tor — y para eso, la guía de servicios onion de abajo es la siguiente lectura honesta.
| Nivel | Mensual | Recursos | Qué ejecuta con holgura |
|---|---|---|---|
| Sentinel | $3.90 | 2 vCPU · 4 GB · 120 GB | Resolver + WireGuard para un hogar. La respuesta correcta. |
| Garrison | $7.90 | 4 vCPU · 8 GB · 240 GB | Lo mismo, más un Vaultwarden, un SearXNG y un destino de backup |
| Ravelin | $16.90 | 8 vCPU · 16 GB · 480 GB | Un equipo pequeño, veinticinco pares de túnel, además de otros servicios |
| Un segundo Sentinel | $3.90 | En otro bastión | El resolver de respaldo, para que una caída no sea una caída de internet |
Nada en esta tabla está elegido pensando en el DNS. Un resolver para treinta dispositivos usa unos pocos cientos de megabytes de caché y una fracción de un núcleo, y mueve unos pocos cientos de megabytes de tráfico al mes. Elige el nivel por los pares de WireGuard, los demás servicios y el disco — y deja que el resolver viaje gratis de propina.
Una regla de firewall de más, o una línea de access-control dejada en allow. Los rastreadores encuentran el puerto en horas, empieza el tráfico de amplificación, llega el informe de abuso, la IP se apaga. Rechaza por defecto, permite solo el túnel, y prueba desde fuera de la red.
AdGuard Home instalado, el upstream dejado en la lista predeterminada, todo funcionando de maravilla — y el registro de consultas sigue acumulándose en una empresa cuyo nombre está en el cuadro de ajustes. Configura un único upstream, y que sea tu Unbound.
wg-quick no pudo aplicar el ajuste de DNS porque resolvconf no está instalado, o un navegador está haciendo su propio DNS-over-HTTPS. Todo parece correcto y cada consulta sigue yendo a la red en la que estás sentado. Verifícalo desde el lado del resolver, no desde la pantalla de ajustes del cliente.
Nada se anuncia como un fallo de DNS — una página carga a medias, un botón no hace nada. Seis listas agresivas activadas el primer día hacen esto imposible de rastrear. Empieza con una, añade despacio, mantén una lista de permitidos, y conserva suficiente registro de consultas para responder a la pregunta.
Todo este montaje existe para impedir que alguien mantenga esta lista, y la capa de filtrado la conserva de fábrica, en disco, durante tres meses. Fija la retención a propósito — 24 horas mientras ajustas, cero después — y recuerda que cubre a todos los de la red, no solo a ti.
Un resolver es infraestructura en el momento en que otras personas dependen de él. Activa los dos servicios en el arranque, define Restart=on-failure, reinicia una vez a propósito para comprobarlo, y decide el respaldo antes de necesitarlo, no durante.
Once preguntas que surgen mientras construyes esto — incluidas las dos que deciden si merece la pena construirlo siquiera.
Es diferente, y es mejor en el sentido que más importa — pero la respuesta honesta tiene dos mitades. Lo que ganas: con un resolver recursivo, ninguna parte llega a ver jamás tu flujo completo de consultas. Los servidores raíz se enteran de que alguien preguntó por .com, los servidores de .com se enteran de que alguien preguntó por example.com, y solo el operador de example.com conoce el nombre completo — y ninguno de ellos ve los siguientes mil nombres que consultes. Un resolver público, en cambio, ve cada una de tus consultas, en orden, con marca de tiempo, para siempre, y su política de privacidad es lo único que se interpone entre esa lista y otra persona. Lo que pierdes: un resolver personal tiene un conjunto de anonimato de uno. Las consultas que salen de un gran resolver público se mezclan con las de millones de personas más; las que salen del tuyo son inequívocamente tuyas. Ese intercambio merece la pena cuando la IP del resolver no está vinculada a tu identidad — que es exactamente lo que te da un VPS sin KYC pagado en cripto, y exactamente lo que no te da un hyperscaler con tu tarjeta registrada. Coloca el resolver detrás del mismo VPS del que ya sale tu VPN y el conjunto de anonimato no se reduce en absoluto, porque esa IP ya se encargaba de tu navegación.
Ligeramente más lento en la primera consulta de un nombre, notablemente más rápido en cada repetición, y a grandes rasgos un empate. Un resolver recursivo que arranca en frío tiene que recorrer toda la cadena de delegación — raíz, TLD, autoritativo — lo que son tres o cuatro idas y vueltas en lugar de la única ida y vuelta a un resolver público que ya tenía la respuesta en caché por la consulta de otra persona. Una vez que tu caché está caliente, lo que en un hogar tarda alrededor de un día, los nombres habituales se sirven desde la RAM en bastante menos de un milisegundo y ya vas por delante. Activa prefetch para que los registros populares se renueven antes de expirar y el caso de arranque en frío prácticamente desaparece. El único sitio donde de verdad puedes perder rendimiento es la geolocalización de CDN: los grandes resolvers públicos envían una versión truncada de tu ubicación de red al servidor autoritativo (EDNS Client Subnet) para que la CDN pueda elegir un nodo cercano. Unbound no la envía, por diseño. Si tu resolver está en la misma región que tú, esto no cambia nada perceptible. Si el resolver está en Reykjavík y tú estás en Singapur, algunas CDN te entregarán un nodo europeo y lo notarás.
Solo para el transporte cifrado. El DNS en claro sobre un túnel WireGuard no necesita dominio, ni certificado, ni ninguna exposición pública — el resolver escucha en una dirección privada como 10.8.0.1 y solo responde a los pares del túnel. Esa configuración es a la vez la más simple y la más privada de esta guía. Necesitas un dominio en el momento en que quieras DNS-over-TLS o DNS-over-HTTPS, porque ambos se autentican con un certificado y un certificado se emite para un nombre. Esa es la configuración que conviene elegir cuando los dispositivos no pueden estar siempre en la VPN — un portátil de trabajo, un teléfono en una red que bloquea UDP, un familiar que no va a mantener un túnel. Si registras uno, regístralo en algún sitio que no exija la misma identidad que has cuidado en otros lugares, y mantén activada la privacidad WHOIS.
Resuelven problemas distintos y la combinación no es redundante. Unbound es el resolver: recorre el DNS desde la raíz, valida las firmas DNSSEC y almacena los resultados en caché. AdGuard Home no es un resolver en absoluto — es una capa de filtrado con interfaz web y receptores cifrados, que reenvía a un upstream todo lo que no bloquea. Si ejecutas AdGuard Home solo, su upstream es un resolver público, lo que devuelve todo tu flujo de consultas al registro de otra persona. Si ejecutas Unbound solo, obtienes un resolver genuinamente privado, pero sin listas de bloqueo, sin reglas por dispositivo y sin interfaz. Encadenados — AdGuard en el puerto 53, Unbound en 127.0.0.1:5335 como su único upstream — obtienes filtrado y transporte cifrado delante de un resolver que responde desde la raíz. Si quieres la superficie de ataque más pequeña posible y no te importa el bloqueo de anuncios, Unbound solo es una respuesta completamente respetable, y es la mitad de la pila que realmente aporta la privacidad.
Un resolver abierto es un resolver recursivo que responde consultas desde cualquier dirección de origen en internet. Es un problema grande porque el DNS funciona sobre UDP, las direcciones de origen UDP se falsifican con trivial facilidad, y una consulta pequeña puede producir una respuesta grande. Un atacante envía a tu servidor una consulta de 60 bytes con la dirección de una víctima falsificada como origen; tu servidor, obediente, envía a la víctima una respuesta docenas de veces más grande. Multiplícalo por miles de resolvers abiertos y tienes un DDoS de reflexión y amplificación, y tu servidor es una de las armas. En la práctica la secuencia es rápida y predecible: rastreadores que escanean toda la internet encuentran el puerto 53 recién abierto en cuestión de horas, empieza el tráfico, llegan las quejas por abuso, y el proveedor aplica un null route a la IP para proteger su red. Esto no es una hipótesis y no es raro — es la forma más común, con diferencia, en que acaba mal un primer servidor DNS. La solución cuesta una regla de firewall y una línea de configuración: rechazar por defecto, permitir solo tu túnel.
Oculta la consulta, no la visita. DNS-over-TLS y DNS-over-HTTPS significan que tu ISP ya no ve una pregunta en claro que dice example.com. Lo que sigue viendo es la conexión que haces un milisegundo después: la dirección IP de destino, y — a menos que ambos extremos admitan Encrypted Client Hello — el nombre del servidor en el saludo TLS, en claro. En un sitio con IP dedicada, la dirección por sí sola lo identifica; en un sitio detrás de una gran CDN la dirección es compartida y el SNI es lo que lo delata. Así que el DNS cifrado eleva el coste del registro pasivo y elimina la superficie de vigilancia más fácil y barata que existe, pero no hace tu navegación invisible. Si el modelo de amenaza es tu ISP o una red hostil viéndolo todo, la herramienta para eso es el túnel — el DNS cifrado cierra la fuga que una VPN por sí sola todavía puede tener, cuando el sistema operativo sigue usando el resolver del ISP fuera del túnel.
Mucho más pequeño de lo que la gente espera. Las respuestas DNS son de cientos de bytes y el trabajo por consulta es una búsqueda en una tabla hash, así que el resolver de un hogar o un equipo pequeño está inactivo casi todo el tiempo. Un Sentinel — 2 vCPU, 4 GB, $3.90 al mes — servirá a docenas de dispositivos sin que la carga media se despegue de cero, y la mayor parte de esos 4 GB está disponible para gastar en caché, que es el único recurso que realmente mejora la experiencia. Dale a Unbound unos cientos de megabytes de caché de mensajes y de RRset y tu tasa de aciertos se situará entre el ochenta y el noventa por ciento. El motivo para subir de tamaño nunca es el DNS: es que la misma máquina también está terminando tu túnel WireGuard, o ejecutando un Vaultwarden, o alojando un repositorio de backups. El ancho de banda no es un problema — un resolver doméstico con uso intenso mueve unos pocos cientos de megabytes al mes.
Todos los dispositivos configurados para usarlo dejan de resolver nombres, algo que quienes los usan describirán como que "se ha caído internet". Este es el coste operativo real de alojar tu propio DNS, y merece una decisión, no un descubrimiento. Tres defensas, en orden creciente de esfuerzo. Configura un resolver secundario en tus clientes — uno público como Quad9 o dns0.eu — y acepta que durante una caída esas consultas escapan a tu control; esto es lo que debería hacer la mayoría de la gente. O ejecuta una segunda instancia en un segundo VPS en otro bastión y lista ambos, lo que mantiene todo interno al precio de una segunda máquina de $3.90. O, en el túnel, ejecuta una pequeña caché local en cada cliente para que una caída breve pase inadvertida. Elijas lo que elijas, define Restart=on-failure en la unidad, actívala en el arranque, y prueba el reinicio una vez a propósito — un resolver que no vuelve por sí solo siempre elegirá el peor momento para demostrarlo.
Sí, de vez en cuando, y la forma en que lo gestiones marca la diferencia entre una configuración que dura y una que se arranca de cuajo a las dos semanas. Las listas de bloqueo las mantienen personas que toman decisiones de criterio, y de tanto en tanto una de esas decisiones atrapa algo que necesitas: el endpoint de detección de fraude de un banco, un widget de seguimiento de entregas, un flujo de inicio de sesión que redirige a través de un dominio de analítica. El fallo resulta confuso porque no parece cosa del DNS — la página carga a medias, o un botón no hace nada. Tres hábitos lo arreglan. Empieza con una lista conservadora en vez de seis agresivas. Mantén una lista de permitidos y añade a ella sin remordimientos. Y mantén el registro de consultas activo el tiempo suficiente para poder responder "¿qué acaba de pedir este dispositivo, y qué le hemos rechazado?" — que es el momento en que descubres que un resolver de filtrado es, en sí mismo, un dispositivo que lo registra todo, y que su ajuste de retención es una decisión de privacidad que estás tomando por todos los de la red.
Sí, y es una de las mejores razones para construirlo — una sola máquina de $3.90 puede sanear el DNS de todo un hogar o de un puñado de amigos. Dos reglas lo hacen seguro. Primero, compártelo por el túnel o mediante un endpoint cifrado y autenticado, nunca abriendo el puerto 53 al mundo; con DNS-over-HTTPS puedes dar a cada persona una ruta distinta para poder revocar el acceso individualmente, y AdGuard Home puede entonces aplicar un filtrado diferente por cliente. Segundo, sé consciente de lo que estás asumiendo: ahora tienes el registro de consultas de todo el que lo usa. Fija la retención a cero o a un día, diles cuál es el ajuste, y recuerda que, si alguna vez es tu propia privacidad la que estás protegiendo, un resolver usado por cinco personas es también un resolver en el que cualquier consulta individual es más difícil de atribuir a una sola de ellas.
En absoluto — un resolver privado y con acceso controlado es una carga de trabajo normal, y la política de uso aceptable no tiene nada que decir al respecto. Lo que sí le importa a la política, y lo que le importa a cualquier red seria, es un resolver abierto usado como reflector de amplificación contra un tercero, porque el tráfico de ataque sale de nuestra red y aterriza en la de otro. Sigue el paso 02 y eso no pasa nunca: rechazar por defecto, permitir el túnel, limitar la tasa del resto. Si quieres ejecutar deliberadamente un resolver público como servicio para otros, esa es una conversación que merece la pena tener de antemano y no después del primer informe de abuso — los requisitos técnicos (limitación de tasa de respuesta, sin ANY, monitorización) están bien entendidos, y el problema es ejecutar uno por accidente, no ejecutar uno a propósito.
Sentinel — 2 vCPU y 4 GB por $3.90 al mes, en Helsinki, Stockholm, Oslo o Reykjavík. Suficiente para el resolver, el túnel WireGuard detrás del cual debería vivir, y cualquier otra cosa que decidas dejar de alquilar en otro sitio. Sin correo al darte de alta, sin documento de identidad, y sin ningún registro a nivel de producto de nada de lo que consultes.
Última revisión · 2026-10-12 · Fuentes · Documentación de Unbound y de AdGuard Home, RFC 9156 (minimización de QNAME), RFC 7858 (DNS-over-TLS), RFC 8484 (DNS-over-HTTPS), systemd-resolved(8) · Cadencia · anual
This guide is one spoke of a larger series. The pillar walks the three privacy layers end to end — the sibling spokes below dive into the specifics.
Three independent layers — signup, payment, network — explained, legal context included, common mistakes flagged.
Your own WireGuard tunnel — server config, peer keys, kill-switch.
A v3 .onion address that survives reboots and IP changes.
Su propio servidor de control de Tailscale — ACL, MagicDNS, nodo de salida, DERP propio.
Deploy your own MCP server on a no-KYC VPS — TLS, streamable HTTP, OAuth.
Alojamiento privado, construido en el Norte.