PowerDNS et dnsdist : DNS authoritative haute performance

BIND9 reste la référence DNS depuis trois décennies, mais l'écosystème a bougé. Pour des opérateurs qui doivent servir des millions de zones authoritative avec backend SQL, ou qui veulent un load-balancer DNS programmable devant leurs résolveurs, PowerDNS et dnsdist (de PowerDNS) prennent le relais.

PowerDNS Authoritative répond aux requêtes pour les zones qu'on opère. PowerDNS Recursor résout pour les clients (cache + lookup vers les authoritatives upstream). dnsdist se met devant l'un ou l'autre comme load-balancer, filtre, couche d'observabilité. Les trois sont open source GPL, écrits en C++, avec des perfs nettement supérieures à BIND9 sur les workloads modernes.

Pour un ISP, un hébergeur, un opérateur DNS authoritative, c'est la stack par défaut en 2026.

• Pourquoi PowerDNS plutôt que BIND9
• Architecture : Authoritative, Recursor, dnsdist
• Backends PowerDNS : SQL, GeoIP, ALIAS
• dnsdist : load-balancer DNS programmable
• Déploiement initial multi-noeuds
• DNSSEC en pratique
• Performance et tuning
• Pièges et limites

BIND9 reste valide pour des cas simples. PowerDNS gagne sur trois axes pour des déploiements scalés.

Performance. PowerDNS est nettement plus rapide sur les workloads avec millions de zones et requêtes/sec. BIND9 reste compétitif pour des zones simples avec peu de requêtes. Au-delà de 10k qps, l'écart se creuse.

Backends programmables. PowerDNS lit les zones depuis MySQL, PostgreSQL, BIND zonefile, LDAP, ou un backend Lua scripté. Pour un hébergeur qui a 50k zones gérées par une base CRM, la liaison directe est immédiate.

Modulaire. Les trois composants (Auth, Recursor, dnsdist) se déploient indépendamment, mis à jour indépendamment. BIND9 est monolithique.

dnsdist sans concurrent côté BIND. Aucun composant BIND9 ne remplace dnsdist. Programmable en Lua, gestion fine du trafic, observabilité prom-natif, throttling, filtering.

Cas où BIND9 reste préféré : configuration zonefile pure, équipe qui maîtrise déjà BIND, périmètres modestes (moins de 1000 zones, moins de 1000 qps).

PowerDNS Authoritative (pdns_server) répond pour les zones dont on est autoritatif. Pas de récursion. Lit zones depuis backend (BIND files, MySQL, PostgreSQL, LDAP, etc.). API REST pour management.

PowerDNS Recursor (pdns_recursor) est un résolveur récursif. Cache, prefetch, validation DNSSEC, support de DNS over HTTPS et DNS over TLS, filtres anti-malware. Idéal en résolveur d'entreprise ou ISP.

dnsdist est un proxy DNS L7. Se place devant Authoritative ou Recursor. Fait de la load-balancing par latence, du filtering, du logging, du rate-limiting. Programmable en Lua à chaud (recharge config sans drop de paquets).

Architecture typique d'un ISP :

• 4-6 dnsdist en frontend (anycast IP).
• Derrière chaque dnsdist : 2-4 Recursor.
• Stack Auth séparée pour les zones reverse de l'AS.

Pour un hébergeur :

• 4-6 dnsdist devant.
• Derrière : Pool d'Authoritative qui sert les zones clients depuis MySQL/PostgreSQL.
• API REST exposée aux interfaces de management.

Backend MySQL ou PostgreSQL :

CREATE TABLE domains (
  id INT AUTO_INCREMENT PRIMARY KEY,
  name VARCHAR(255) NOT NULL,
  master VARCHAR(128),
  type VARCHAR(6) NOT NULL,
  notified_serial INT
);

CREATE TABLE records (
  id BIGINT AUTO_INCREMENT PRIMARY KEY,
  domain_id INT,
  name VARCHAR(255),
  type VARCHAR(10),
  content VARCHAR(64000),
  ttl INT
);

Schémas standards documentés. Pour ajouter une zone, INSERT dans domains. Pour ajouter un record, INSERT dans records. PowerDNS répond immédiatement (cache local invalidé).

Backend GeoIP : retourne des réponses différentes selon la localisation du client. Utile pour servir des points de présence proches.

ALIAS records : pseudo-CNAME au sommet de zone (apex), résolu côté serveur. Permet example.fr → cdn.example.com sans la limitation classique CNAME apex.

Backend Lua : règles dynamiques, intégration custom (par exemple, lookup en temps réel dans une API d'inventaire).

dnsdist est probablement le composant qui justifie à lui seul d'adopter la stack PowerDNS.

Configuration en Lua :

-- Frontends
addLocal("203.0.113.10:53")
addLocal("203.0.113.10:443", { tlsCertificate = "/etc/dnsdist/cert.pem",
                                tlsCertificateKey = "/etc/dnsdist/key.pem" })

-- Backends
newServer({ address = "10.0.0.10:53", pool = "recursor", checkType = "A",
            checkName = "powerdns.org" })
newServer({ address = "10.0.0.11:53", pool = "recursor" })

-- Round-robin sur le pool recursor
setServerPolicy(roundrobin)

-- Rate limiting par client
addAction(MaxQPSIPRule(20), DropAction())

-- Block des requêtes de versions ANY (anti-amplification)
addAction(QTypeRule(DNSQType.ANY), TCAction())

-- Logging vers Loki via syslog
setRingBuffersSize(2000000, 100000)
addAction(AllRule(), RemoteLogAction(remoteLogger("/dev/log", "1")))

Ce qui est exposé : load-balancing par latence, par moindre charge, par hash sticky, ou random. Filtres par type de requête, par client, par regex sur le nom. Throttling. Caching local en mémoire. DNS over TLS (DoT), DNS over HTTPS (DoH), DNSCrypt.

Pour des opérateurs qui veulent du DoH/DoT public, dnsdist est le frontend le plus performant.

Stack minimale pour un hébergeur :

# Sur 2 noeuds, install Authoritative
apt install pdns-server pdns-backend-mysql

# Créer la base et schéma
mysql -u root -p < /usr/share/doc/pdns-backend-mysql/schema.mysql.sql

# Configurer /etc/powerdns/pdns.conf
cat <<EOF > /etc/powerdns/pdns.conf
launch=gmysql
gmysql-host=db.internal
gmysql-dbname=pdns
gmysql-user=pdns
gmysql-password=<secret>
api=yes
api-key=<secret>
webserver=yes
webserver-address=0.0.0.0
EOF

systemctl enable --now pdns

Sur 2 noeuds dnsdist en frontend :

apt install dnsdist
# Config Lua /etc/dnsdist/dnsdist.conf comme plus haut
systemctl enable --now dnsdist

Anycast les frontaux derrière la même IP via BGP avec FRR ou anycast routing pour la HA. Voir haute disponibilité avec keepalived pour des patterns simples.

PowerDNS supporte DNSSEC nativement. Activation par zone :

pdnsutil secure-zone example.fr
pdnsutil show-zone example.fr

PowerDNS génère KSK et ZSK, signe les zones automatiquement, gère la rotation.

Pour publier les DS records vers le registry, voir la sortie de pdnsutil show-zone et publier les hash auprès du registrar.

Pour le contexte général DNSSEC, notre article dnssec-configuration reste valide.

Quelques chiffres de référence sur du matériel récent (Xeon 16c, 32 Go RAM, SSD NVMe).

Tuning principal :

• distributor-threads côté Auth.
• query-cache-ttl et recursive-cache-ttl côté Recursor.
• setMaxUDPOutstanding côté dnsdist.
• Réseau : tuning kernel UDP (rmem/wmem buffer sizes).

Pour les très grosses charges, plusieurs instances dnsdist en parallèle, chacune sur des CPU pinnés.

Backend SQL en SPOF. Si la DB tombe, les zones disparaissent. Architecture : MySQL/PostgreSQL en HA (Galera, Patroni), ou backend BIND zonefile pour la résilience.

API key exposée. Sur des dnsdist exposés Internet avec console activée, attention au binding 0.0.0.0. Limiter à des IPs admin internes.

DNSSEC rotation. La rotation KSK demande coordination avec le registrar. Planifier, ne pas improviser. Échec à publier le DS = chaîne de validation cassée = zone injoignable depuis les résolveurs validants.

Compatibilité dnsdist / Recursor. Attention aux versions. Recursor 5.x avec dnsdist 1.9+ s'aligne bien. Mixer des versions divergentes provoque des comportements subtils.

Logs DoH/DoT. Volume très élevé, prévoir capacité d'ingestion vers Loki ou ELK. Pas en local sur disque, sinon saturation.

RPZ (Response Policy Zone). PowerDNS Recursor supporte RPZ pour le filtering anti-malware. Configuration moins simple que sur BIND. Suivre la doc.

Pour un hébergeur ou un ISP régional, la stack PowerDNS délivre les performances et l'opérabilité que demande un parc DNS authoritative large. L'intérêt se confirme dès qu'on dépasse le millier de zones ou plusieurs milliers de qps. Pour les volumétries plus modestes, BIND9 reste valide. Rotation DNSSEC, alignement des versions, supervision des qps : du suivi régulier qui, faute de bras interne, se confie en exploitation.

• PowerDNS documentation officielle : Authoritative, Recursor, dnsdist en référence.
• GitHub PowerDNS/pdns : code source, releases.
• dnsdist documentation : référence Lua config, features.
• DNSSEC RFC 4033-4035 : spécification DNSSEC.
• DNS over HTTPS RFC 8484 : spec DoH supportée par dnsdist.
• DNS over TLS RFC 7858 : spec DoT.