Pourquoi héberger son propre DNS

Le DNS est le service le plus discret d'Internet, et l'un des plus révélateurs : chaque site visité laisse une requête auprès du résolveur configuré. Utiliser le résolveur de son fournisseur d'accès, ou un résolveur public comme Google (8.8.8.8) ou Cloudflare (1.1.1.1), c'est confier l'intégralité de son historique de navigation — nom de domaine par nom de domaine — à un tiers qui peut le journaliser.

AdGuard Home répond à ce besoin : un résolveur DNS auto-hébergé qui filtre la publicité et les traqueurs à la source (avant même que la page ne commence à charger), tout en gardant la main sur ce qui est réellement interrogé et vers qui.

AdGuard Home, un résolveur DNS avec filtrage

Techniquement, AdGuard Home se comporte comme un résolveur DNS classique côté client (LAN), mais confronte chaque requête entrante à des listes de blocage avant de la transmettre à un serveur DNS upstream. Concrètement :

1. Un appareil du réseau interroge AdGuard Home pour résoudre exemple.com.
2. AdGuard Home vérifie le domaine contre ses listes de blocage (publicité, tracking, malware).
3. Si le domaine est bloqué : réponse NXDOMAIN ou 0.0.0.0, la requête ne sort jamais du réseau local.
4. Sinon : la requête est transmise à l'upstream configuré, qui effectue la résolution réelle.

Installation

Le plus simple reste Docker :

docker run -d \
  --name adguardhome \
  -p 53:53/tcp -p 53:53/udp \
  -p 3000:3000/tcp \
  -v adguard-work:/opt/adguardhome/work \
  -v adguard-conf:/opt/adguardhome/conf \
  --restart unless-stopped \
  adguard/adguardhome

Le port 3000 sert uniquement à l'assistant de configuration initial et à l'interface web ; le port 53 (TCP/UDP) est le port DNS standard, à écouter sur l'interface réseau du LAN et non sur l'interface publique.

Libérer le port 53 sur l'hôte

Sur une machine Ubuntu/Debian classique, systemd-resolved occupe déjà le port 53 en local. Il faut le libérer avant de pouvoir démarrer AdGuard Home dessus :

sudo sed -i 's/#DNSStubListener=yes/DNSStubListener=no/' /etc/systemd/resolved.conf
sudo systemctl restart systemd-resolved

Choisir son upstream : simplicité vs vie privée

Upstream	Avantage	Inconvénient
DNS du FAI	Aucune config	Confiance obligatoire, souvent sans DNSSEC
Cloudflare (1.1.1.1) / Quad9	Rapide, DNS-over-HTTPS/TLS disponible	Reste un tiers qui voit toutes les requêtes
Unbound (récursif local)	Aucune requête ne quitte le réseau vers un tiers — résolution directe depuis les serveurs racine	Plus de configuration, résolution parfois un peu plus lente au premier appel (pas de cache tiers déjà chaud)

Le choix le plus cohérent avec l'objectif de départ (ne rien confier à un tiers) est de coupler AdGuard Home à Unbound, un résolveur DNS récursif qui interroge directement les serveurs racine IANA plutôt que de relayer vers un DNS public.

Coupler AdGuard Home à Unbound

Configuration minimale d'Unbound pour un usage en résolveur récursif local, avec validation DNSSEC :

# /etc/unbound/unbound.conf
server:
  interface: 0.0.0.0
  port: 53
  do-ip4: yes
  do-ip6: no
  access-control: 0.0.0.0/0 refuse
  access-control: 127.0.0.1/8 allow
  access-control: 192.168.0.0/16 allow
  hide-identity: yes
  hide-version: yes
  auto-trust-anchor-file: "/var/lib/unbound/root.key"
  root-hints: "/var/lib/unbound/root.hints"

Attention à access-control : autoriser 0.0.0.0/0 en allow transforme Unbound en résolveur DNS ouvert, interrogeable en récursif par n'importe qui sur Internet — c'est exactement le type de configuration exploité pour des attaques par amplification DNS. La bonne pratique est un refus par défaut (0.0.0.0/0 refuse) suivi d'autorisations ciblées sur les seuls sous-réseaux de confiance (loopback, LAN). Cela s'ajoute à la précaution déjà citée plus bas de ne jamais exposer le port 53 sur Internet — les deux mesures sont complémentaires, pas redondantes.

Dans AdGuard Home, il suffit ensuite de déclarer l'adresse d'Unbound comme unique serveur DNS upstream (interface Paramètres → DNS), au lieu d'un résolveur public.

Maintenir les root hints à jour

Le fichier root.hints (liste des serveurs racine IANA) change rarement, mais doit être rafraîchi périodiquement :

curl -o /var/lib/unbound/root.hints https://www.internic.net/domain/named.root
systemctl restart unbound

Un cron mensuel suffit largement ; comparer le fichier téléchargé à l'existant avant de redémarrer évite un redémarrage inutile du service à chaque exécution.

Filtrage et listes de blocage

AdGuard Home embarque par défaut plusieurs listes de filtres (AdGuard DNS filter, listes de trackers) activables depuis Filtres → Listes de blocage. Il est possible d'en ajouter d'autres (au format hosts ou AdBlock), par exemple des listes anti-malware ou anti-phishing spécialisées.

Réécritures DNS (split DNS)

Au-delà du filtrage, AdGuard Home permet de définir des réécritures DNS locales — utile pour attribuer un nom de domaine interne à une machine du réseau sans dépendre d'un DNS public, ou pour faire pointer un domaine réel vers l'IP locale d'un serveur auto-hébergé plutôt que vers son IP publique (évite un aller-retour inutile via Internet pour du trafic purement local, et contourne les problèmes de hairpin NAT dans certaines configurations réseau).

# Filtres → Réécriture DNS
exemple.mondomaine.fr → 192.168.1.10

Sécuriser l'accès

• Interface d'administration : ne jamais exposer le port 3000/80 d'AdGuard Home directement sur Internet — le réserver au réseau local, ou le placer derrière un reverse proxy avec authentification (basicauth ou SSO).
• Port 53 : ne pas l'exposer publiquement non plus, sous peine de servir de relais dans une attaque par amplification DNS.
• Chiffrement client → AdGuard Home : possible en DNS-over-HTTPS/TLS/QUIC si des appareils du réseau doivent interroger AdGuard Home depuis l'extérieur (mobile en 4G par exemple), via un certificat valide.

En résumé

• AdGuard Home bloque publicité et trackers au niveau DNS, avant même le chargement de la page.
• Coupler AdGuard Home à un résolveur récursif comme Unbound évite de déléguer la visibilité de toutes les requêtes à un tiers (FAI ou DNS public).
• Les réécritures DNS permettent un split DNS pratique pour les domaines/machines du réseau local.
• Le port 53 et l'interface d'administration ne doivent jamais être exposés directement sur Internet.