Votre propre résolveur DNS.
Le seul journal que personne ne pense à déplacer.

Deux machines complètement différentes se cachent derrière l'expression « mon propre serveur DNS », et presque tous les tutoriels construisent la mauvaise. Décidez-le avant d'installer quoi que ce soit, car c'est la différence entre un outil de confidentialité et un simple relais pour la politique de confidentialité de quelqu'un d'autre.

Un relais prend votre requête et la transmet à un autre résolveur — typiquement Cloudflare, Google, Quad9 ou votre FAI — puis met en cache ce qui revient. C'est simple, c'est rapide, et ça livre l'intégralité de votre flux de requêtes à un tiers unique. Tout guide qui se termine par « réglez maintenant votre upstream sur 1.1.1.1 » en a construit un.

Un résolveur récursif fait le travail lui-même. Pour trouver mail.example.com, il demande à un serveur racine qui gère .com, demande aux serveurs de .com qui gère example.com, puis demande aux propres serveurs de noms d'example.com l'enregistrement. Trois ou quatre courtes conversations avec trois ou quatre opérateurs différents, dont aucun n'apprend quoi que ce soit sur les autres. Avec la minimisation QNAME activée, il va plus loin : la racine n'est interrogée que sur .com, et les serveurs de .com uniquement sur example.com. Le nom complet n'est révélé qu'à une seule partie — celle qui héberge le nom, et qui allait de toute façon recevoir votre connexion trente millisecondes plus tard.

Les deux colonnes de droite ne sont pas des concurrentes — ce sont les deux moitiés d'une même construction. AdGuard Home possède le port 53, applique les listes de blocage et termine les transports chiffrés ; Unbound se trouve derrière, sur loopback, et fait la résolution. Aucune des deux moitiés ne fait bien le travail de l'autre, et la chaîne pèse environ une centaine de mégaoctets de RAM au total.

Si vous ne devez retenir qu'une seule chose de cette page, que ce soit celle-ci : un résolveur qui relaie vers un fournisseur DNS public n'a pas rendu votre DNS privé. Il a simplement déplacé le journal d'un saut, et ajouté un serveur à votre liste de maintenance. La récursion est tout l'enjeu.

Unbound est un résolveur récursif, à cache, qui valide, développé par NLnet Labs. Il est empaqueté partout, c'est ce qu'une grande partie d'internet fait déjà tourner, et par défaut il fait de la récursion — il faut s'en donner la peine pour le transformer en relais. Installez-le avec le paquet des root hints pour qu'il sache où sont les serveurs racine sans aller chercher de liste nulle part :

apt update && apt install -y unbound dns-root-data
unbound -V | head -2

Le paquet dns-root-data installe les root hints dans /usr/share/dns/root.hints et l'ancre de confiance racine DNSSEC dans /usr/share/dns/root.key, et garde les deux à jour via le canal normal des paquets. C'est la façon ennuyeuse mais correcte de les obtenir ; télécharger root.hints depuis une URL dans une tâche cron est la façon qui finit par échouer silencieusement.

/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

Quatre de ces lignes font le vrai travail et méritent chacune une phrase.

• 01access-control: 0.0.0.0/0 refuse — la réponse par défaut à internet est « non ». Tout ce qui vient après est une exception que vous avez écrite exprès. Cette seule ligne suffit à arrêter le scénario d'amplification de l'étape 02 avant même que le pare-feu n'ait à intervenir.
• 02qname-minimisation: yes — les serveurs racine ne sont interrogés que sur .com, pas sur le nom d'hôte complet. RFC 9156, activée par défaut dans les versions actuelles d'Unbound, et la raison pour laquelle un résolveur récursif fuit moins que ne le suggère le diagramme. Laissez le mode strict désactivé : un petit nombre de zones mal configurées cassent encore sous ce mode.
• 03refuse-any: yes — les requêtes ANY renvoient la plus grosse réponse possible pour la plus petite question possible, ce qui est précisément ce que veut une attaque par amplification. Rien de légitime n'en a besoin.
• 04serve-expired: yes — quand un serveur faisant autorité est injoignable, distribuer la réponse périmée et la rafraîchir en arrière-plan plutôt que d'échouer. C'est le réglage qui empêche une panne lointaine de ressembler, pour tout le monde dans la maison, à une panne d'internet.

Remarquez les deux écouteurs. Le loopback sur le port 5335 est ce qu'utilisera AdGuard Home à l'étape suivante ; 10.8.0.1 est l'adresse du tunnel, pour que les clients sur le VPN puissent interroger Unbound directement si vous décidez de sauter la couche de filtrage. Si vous ne faites pas encore tourner WireGuard, retirez cette seconde ligne d'interface pour l'instant — Unbound ne démarrera pas avec une adresse qui n'existe pas sur la machine.

Démarrez-le et prouvez qu'il fonctionne :

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:'

Le drapeau ad sur la première réponse signifie qu'Unbound a vérifié la chaîne de signatures depuis la racine jusqu'à l'enregistrement, et qu'elle a tenu. Le SERVFAIL sur la seconde signifie que la validation a rejeté une réponse falsifiée plutôt que de vous la transmettre. Si la seconde renvoie une adresse à la place, la validation n'est pas activée, et l'ancre de confiance est la première chose à examiner.

Un résolveur que personne ne peut atteindre n'est pas utile, et un résolveur que tout le monde peut atteindre est le mode de défaillance de l'étape 02. Il y a exactement deux bonnes réponses, et la plupart des gens finissent par faire tourner les deux — le tunnel à la maison et sur l'ordinateur portable, le DNS chiffré sur le téléphone et sur les réseaux où l'UDP est filtré.

Option A — via WireGuard. La meilleure des deux, et la raison pour laquelle ce guide continue de pointer vers le guide WireGuard. Le port 53 reste invisible depuis internet, la requête elle-même ne traverse jamais un réseau non fiable sous quelque forme que ce soit, et il n'y a aucun certificat à renouveler. Si le VPS est déjà votre sortie VPN, c'est une seule ligne dans la configuration de chaque pair :

# On the client, in the [Interface] section of the peer config:
DNS = 10.8.0.1

Une subtilité qui piège les gens : sur Linux, wg-quick règle cette adresse via resolvconf ou systemd-resolved, et si aucun des deux n'est installé, il ne fait silencieusement rien pendant que le tunnel se monte parfaitement. Vérifiez avec resolvectl status ou en lisant /etc/resolv.conf une fois le tunnel monté — un tunnel qui fonctionne avec l'ancien résolveur encore configuré est exactement la fuite qui est au cœur de tout cet exercice.

Option B — DNS-over-TLS et DNS-over-HTTPS. Nécessaire quand l'appareil ne peut pas toujours être sur le tunnel. Les deux sont authentifiés par un certificat, ce qui suppose un nom d'hôte : pointez un enregistrement A vers le VPS, puis laissez AdGuard Home détenir le certificat directement, ou placez-le derrière un reverse proxy qui termine déjà le TLS pour vous. Les écouteurs sont 853/tcp pour le DoT et 443/tcp pour le 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

Donnez au point de terminaison DoH un chemin qui ne soit pas devinable — AdGuard Home vous permet de le servir sous /dns-query/<random>, et un chemin différent par personne signifie que l'accès peut être révoqué une personne à la fois sans rien changer pour tous les autres. Ce n'est pas une authentification au sens fort, mais ça évite qu'un écouteur public ne soit rien de plus qu'un résolveur ouvert avec des étapes en plus.

La ligne du routeur est celle à laquelle il faut réfléchir. Distribuer votre résolveur via DHCP couvre tous les appareils de la maison d'un coup, y compris ceux qui n'ont pas d'écran de réglages — mais le saut du routeur vers le VPS se fait alors en DNS en clair à travers internet ouvert, ce qui est exactement ce que vous cherchiez à arrêter. Faites tourner le tunnel sur le routeur lui-même, ou acceptez que le dernier kilomètre soit non chiffré et laissez la récursion être le gain.

Une dernière configuration qu'il vaut la peine de connaître : un navigateur qui a le DNS-over-HTTPS activé utilisera son propre résolveur et ignorera tranquillement le réglage système, tunnel ou pas. Firefox et Chrome livrent tous les deux cette option activée par défaut dans certaines régions. Soit vous pointez aussi le navigateur vers votre point de terminaison, soit vous désactivez son DoH pour qu'il suive le système d'exploitation.

Un résolveur privé est une réelle amélioration, et ce n'est pas une cape d'invisibilité. Quiconque le vend comme telle vous vend quelque chose. Voici la liste de ce qui reste visible une fois tout ce qui précède fait, parce que connaître la forme de l'exposition restante fait toute la différence entre une défense et une couverture de sécurité illusoire.

La connexion, elle, a toujours lieu. Une milliseconde après le lookup, votre appareil ouvre une connexion TCP vers l'adresse qu'il vient d'apprendre. Quiconque surveille votre ligne voit cette adresse. Pour un site sur sa propre IP, l'adresse, c'est le site. Le DNS chiffré supprime la question ; il ne supprime pas la réponse.

La poignée de main TLS nomme généralement le site. Le Server Name Indication est envoyé en clair au début de presque chaque connexion HTTPS, donc un observateur passif lit le nom d'hôte de toute façon. L'Encrypted Client Hello corrige cela et est déployé de façon inégale — là où le navigateur et le site le prennent en charge tous les deux, le nom est caché, et là où ce n'est pas le cas, il ne l'est pas. Ne présumez pas qu'il est activé.

L'opérateur du résolveur, c'est désormais vous, et vous n'êtes qu'une seule personne. Chaque serveur faisant autorité auquel parle votre résolveur voit une unique adresse IP l'interroger sur sa zone. À travers de nombreuses zones, cette IP a un motif distinctif, et ce motif, c'est un foyer. C'est le coût en ensemble d'anonymat évoqué dans le premier chapitre, et la seule chose qui l'atténue, c'est que l'IP ne soit pas traçable jusqu'à un nom — un VPS sans KYC payé en crypto — et, idéalement, que ce soit la même IP dont sort déjà votre trafic.

Le prestataire peut voir les paquets, comme toujours. Le VPS tourne sur le matériel de quelqu'un, dans le datacentre de quelqu'un. NordBastion n'inspecte pas le trafic des clients, et le rapport de transparence ainsi que le warrant canary décrivent ce qui se passerait si on le demandait — mais l'énoncé architectural honnête, c'est qu'une machine que vous louez est une machine que quelqu'un d'autre peut atteindre physiquement. Ce que change l'auto-hébergement, c'est qu'il n'y a aucun journal de requêtes au niveau du produit, aucun pipeline d'analytique et aucune politique de confidentialité qui puisse être modifiée ; il n'y a qu'un processus qui tient un cache en RAM, configuré par vous, dans une juridiction que vous avez choisie exprès.

Ce que vous avez réellement acheté, précisément : la source de données comportementales sur vous la plus riche et la moins chère qui soit n'est plus collectée par une partie dont le modèle économique consiste à la collecter. C'est une affirmation étroite, et c'est une affirmation réelle. Rien sur cette page ne remplace Tor quand le modèle de menace exige Tor — et pour cela, le guide sur les services onion ci-dessous est la lecture suivante honnête.