Comparaison des solutions DNS¶

Cette page alimente un ADR (Architecture Decision Record) pour le choix du serveur DNS interne. Méthodologie : voir ADR dans Documenter son code.

Grille de comparaison¶

Analyse détaillée¶

CoreDNS — Recommande¶

Forces :

• DNS par defaut de Kubernetes (projet CNCF graduated)
• Architecture 100% plugins : on active uniquement ce dont on a besoin
• Corefile declaratif, simple a versionner dans Git
• Metriques Prometheus nativement intégrées
• Leger : un seul binaire Go, pas de dependances
• Service discovery Kubernetes natif (plugin kubernetes)
• Extensible : plugins pour etcd, route53, file, forward, cache, etc.

Faiblesses :

• DNSSEC moins mature que BIND
• Moins de documentation pour les cas d'usage DNS classiques (hors Kubernetes)
• Pas de web UI d'administration

Verdict : choix par defaut pour toute infrastructure incluant Kubernetes. Sa simplicité et son ecosysteme de plugins en font le meilleur choix pour un DNS interne moderne.

BIND 9 — Référence historique¶

Forces :

• Standard de facto du DNS depuis 30 ans
• Implementation DNSSEC la plus complète et eprouvee
• Supporte tous les cas d'usage DNS imaginables
• Documentation exhaustive, vaste base de connaissances

Faiblesses :

• Configuration complexe (named.conf verbeux et fragile)
• Pas d'integration Kubernetes native
• Empreinte mémoire plus elevee
• Metriques necessitent des exporters tiers
• Courbe d'apprentissage raide

Verdict : pertinent pour les environnements legacy avec un existant BIND, ou quand DNSSEC avance est un requis dur. Planifier une migration vers CoreDNS pour les nouveaux déploiements.

PowerDNS — API-first¶

Forces :

• API REST native pour la gestion des zones et enregistrements
• Backends multiples (PostgreSQL, MySQL, LDAP) pour la gestion dynamique
• Separation propre autoritatif / recursor (deux binaires)
• Bonne performance avec backend base de données

Faiblesses :

• Deux composants a déployer et opérer (autoritatif + recursor)
• Pas d'integration Kubernetes
• GPL 2.0 (contrainte pour certains usages embarqués)
• Complexité operationnelle plus elevee que CoreDNS

Verdict : excellent choix si une API REST de gestion des zones est un requis fort (par exemple, provisioning automatise massif via API, integration avec un portail self-service).

Unbound — Resolver optimise¶

Forces :

• Resolver recursif le plus performant
• Tres leger et securise (code audite, sandbox)
• Excellent support DNSSEC (validation)
• Configuration simple pour le cas d'usage resolver

Faiblesses :

• Resolver uniquement : ne sert pas de serveur autoritatif
• Pas de service discovery
• Pas d'integration Kubernetes
• Gestion des zones limitee (local-zone uniquement)

Verdict : a utiliser en complement comme resolver/cache local devant un serveur autoritatif. Ne peut pas etre le DNS interne a lui seul.

Matrice de decision¶

graph TD
    Besoin["Besoin principal"]
    Besoin --> K8s["Kubernetes"]
    Besoin --> Legacy["Legacy/DNSSEC"]
    Besoin --> API["API REST"]
    K8s --> CoreDNS["CoreDNS<br/>+ Unbound comme<br/>cache local (optionnel)"]
    Legacy --> BIND["BIND 9"]
    API --> PowerDNS

Decision recommandee¶

Pour une DSI orientee développement avec Kubernetes dans le paysage :

Decision : CoreDNS comme serveur DNS interne (autoritatif + forwarder), déployé à la fois comme cluster DNS Kubernetes et comme DNS standalone pour l'infrastructure hors cluster.

Justification : integration Kubernetes native, architecture plugins, metriques Prometheus, simplicité operationnelle, projet CNCF graduated. Unbound peut etre ajoute comme cache local si le volume de requêtes le justifie.