DNS privé pour les réseaux VPS : comment ça marche et quand en avoir besoin

Vous démarrez un troisième serveur, vous voulez que les machines se joignent par nom plutôt que par IP, et vous cherchez « private DNS VPS ». Trois résultats remontent et ils ne disent pas la même chose. L'un est un réglage Android qui chiffre les requêtes de votre téléphone. L'autre est un guide cPanel pour personnaliser les serveurs de noms d'un domaine. Le troisième est un document AWS sur les zones hébergées privées. Le 20 juillet 2026, Cloudflare a rendu Internal DNS disponible en version générale et l'a décrit comme « parfois aussi appelé DNS privé », si bien que la confusion vient désormais aussi des fournisseurs d'infrastructure.

Le terme est surchargé. Cet article sépare les différents sens, puis se concentre sur celui du réseau VPS : une zone DNS interne pour la communication de serveur à serveur. À la fin, vous saurez identifier le système dont vous avez besoin, décider si votre parc exige un DNS privé et éviter les erreurs de conception courantes.

En bref

• « DNS privé » désigne au moins trois systèmes sans rapport entre eux : une zone DNS interne pour un réseau de serveurs, la fonction de chiffrement DNS-over-TLS d'Android et les serveurs de noms personnalisés de cPanel. Cet article emploie le terme au premier sens : une zone DNS interne pour un réseau VPS.
• Une zone DNS privée de VPS est un espace de noms interne limité au réseau, qui associe des noms d'hôte comme db.internal.example.com à des IP privées. Ses enregistrements ne sont pas publiés dans le DNS public.
• Pour une poignée de serveurs avec des IP stables, /etc/hosts suffit vraiment. Un serveur DNS interne devient rentable dès que le parc grandit, que les IP changent souvent ou que les services ont besoin d'une résolution de noms fiable.
• Pour la plupart des réseaux VPS en production, utilisez un sous-domaine qui vous appartient, tel que internal.example.com. N'utilisez l'espace de noms .internal que pour une installation isolée où les collisions de noms entre réseaux, la gestion des certificats d'une autorité de certification privée et un traitement DNSSEC particulier sont acceptables. Évitez .local, réservé par mDNS.

Ce que cet article n'aborde pas

Cet article se limite au sens réseau VPS du DNS privé. Il ne traite pas des usages grand public et d'hébergement sans rapport :

• Configurer le réglage DNS privé ou DNS-over-TLS d'Android sur un téléphone.
• Mettre en place des serveurs de noms privés cPanel pour une marque d'hébergement.
• Un tutoriel d'installation complet de BIND 9, Unbound, dnsmasq ou CoreDNS. L'implémentation reste ici au niveau de la référence, pas de la configuration pas à pas.
• Les résolveurs chiffrés grand public comme 1.1.1.1 ou NextDNS, au-delà de leur distinction d'avec le sens réseau.

Que signifie réellement « DNS privé » ?

« DNS privé » n'est pas un seul système. L'expression en désigne au moins trois sans rapport : une zone DNS restreinte au réseau qui résout les noms d'hôte internes dans un réseau VPS ou VPC, la fonction de chiffrement DNS-over-TLS d'Android et les serveurs de noms faisant autorité personnalisés de cPanel. Cet article traite du premier, la zone interne que vos serveurs interrogent pour se trouver. Un quatrième usage plus flou existe aussi : les résolveurs publics chiffrés commercialisés comme « privés ».

Les quatre sens partagent un nom et rien d'autre :

L'annonce de disponibilité générale d'Internal DNS de Cloudflare est un exemple managé actuel du premier sens, et l'une des raisons pour lesquelles la confusion devient visible : un fournisseur d'infrastructure emploie désormais « DNS privé » comme synonyme de DNS interne dans son texte de lancement. Le système décrit, un Gateway Resolver associé à Internal Authoritative DNS pour les clients Enterprise, relève de la même catégorie que ce que vous construisez vous-même sur un parc de VPS, en version managée.

À retenir de cette section : les principaux systèmes appelés « DNS privé » partagent une étiquette, pas une fonction. Identifiez le sens avant de suivre un guide d'installation.

Comment le DNS privé fonctionne-t-il sur un réseau VPS ?

Une zone DNS privée de VPS est un espace de noms limité au réseau, servi par un résolveur que vos serveurs sont configurés pour utiliser. Elle associe des noms d'hôte internes tels que db.internal.example.com à des IP privées dans une plage que vous contrôlez. Les enregistrements ne sont pas publiés dans le DNS public, même si les requêtes peuvent transiter par un tunnel privé ou un plan de contrôle DNS managé avant d'atteindre le résolveur. Cette séparation est au cœur de la distinction entre DNS privé et DNS public : le protocole est le même, mais la visibilité de la zone et son périmètre d'accès diffèrent.

Trois éléments font le travail. Un serveur faisant autorité ou une source de zone détient la zone interne et ses enregistrements. Un résolveur répond aux requêtes envoyées par vos serveurs. Et les enregistrements A et AAAA de la zone associent les noms d'hôte internes à des adresses privées, si bien que app.internal.example.com pointe vers la couche applicative et db.internal.example.com pointe vers la base de données. D'autres types d'enregistrements peuvent fournir des alias ou des informations de service. Lorsque la zone et le chemin du résolveur sont correctement configurés, le résolveur répond localement à la requête interne au lieu de l'envoyer vers la racine du DNS public.

Les plateformes cloud rattachent cela au réseau plutôt qu'à la machine, ce qui constitue un modèle de référence utile. Les zones hébergées privées d'AWS Route 53 ne fonctionnent que si le VPC a enableDnsHostnames et enableDnsSupport tous deux à true, et le résolveur répond depuis la zone privée pour chaque VPC que vous y associez. Les zones privées de Google Cloud sont limitées aux réseaux VPC autorisés, et dans l'ordre de résolution standard d'un VPC elles sont consultées avant le DNS public, sauf si une politique de serveur sortant modifie le chemin. Voyez ces exemples comme des illustrations du principe, pas comme des tutoriels de plateforme : un serveur DNS interne autogéré repose sur la même idée, exécutée sur votre propre VPS.

Garder la zone hors du DNS public ne fait que la moitié du travail. Liez le service DNS à une interface privée ou limitez le port 53 en UDP et TCP à votre réseau privé ou à votre VPN. N'exposez pas le service récursif à l'internet public : un résolveur ouvert peut être détourné dans des attaques par amplification DNS.

Les zones privées et publiques utilisent le même modèle d'enregistrements et de mise en cache DNS. Les enregistrements portent un TTL, et les résolveurs à cache réutilisent normalement une réponse jusqu'à l'expiration de ce TTL, même si des réglages propres au résolveur peuvent modifier la durée de cache effective. Ce comportement est traité dans notre guide pour pointer un domaine vers un VPS, y compris les bases de la propagation DNS et du TTL, si bien que ce n'est pas réexpliqué ici.

Quand votre réseau VPS a-t-il vraiment besoin d'un DNS privé ?

Pour deux ou trois serveurs statiques, /etc/hosts suffit vraiment. Un serveur DNS interne devient rentable quand le parc grandit, que les IP changent régulièrement ou que les applications ont besoin d'une découverte de services fiable. Le véritable déclencheur, c'est la complexité opérationnelle, pas un nombre fixe de serveurs.

/etc/hosts est une table statique nom d'hôte vers IP qui existe déjà sur chaque machine Linux. Elle ne nécessite ni démon ni fichier de zone, mais des copies périmées ou incohérentes constituent de vrais modes de défaillance. Ajoutez l'IP privée de chaque serveur au fichier, gardez les copies synchronisées, et les machines se trouveront par leur nom. Pour un parc petit et stable, c'est la bonne réponse, et déployer BIND 9 à la place ne fait qu'ajouter un démon à maintenir sans aucun bénéfice.

Cette approche atteint ses limites dans trois situations. Quand vous ajoutez et retirez souvent des serveurs, garder un fichier statique cohérent sur chaque hôte devient une corvée manuelle. Quand les IP changent, par autoscaling, reconstruction ou réattribution par le fournisseur, le fichier devient obsolète en silence. Et quand des conteneurs ou des runtimes isolés n'héritent pas des entrées de l'hôte, la correspondance cesse d'être universelle. N'importe laquelle de ces situations est le véritable déclencheur. Le nombre de serveurs à lui seul n'est qu'une approximation, pas le vrai signal.

À retenir de cette section : le déclencheur, c'est le taux de changement opérationnel, pas le nombre de serveurs. Un parc figé de dix machines peut très bien vivre avec /etc/hosts; un parc de trois machines reconstruit chaque nuit, probablement pas.

Développez sur un VPS Linux avec accès root, NVMe et la puissance AMD EPYC.

Voir les plans Linux

Quel serveur DNS choisir : BIND 9, Unbound, dnsmasq ou CoreDNS ?

Choisissez selon la forme de votre parc. dnsmasq convient aux petits réseaux qui veulent un DNS léger et, le cas échéant, du DHCP depuis le même démon. Unbound est un résolveur récursif validant et sobre, capable aussi de répondre pour une zone locale modeste. BIND 9 offre de larges capacités faisant autorité et récursives, avec la surface de configuration la plus étendue. CoreDNS convient aux parcs à conteneurs et Kubernetes où le DNS fait partie de la découverte de services.

La logique de sélection est courte. Si vous avez besoin d'un petit résolveur adossé à un fichier de type hosts, ou si vous distribuez déjà des baux DHCP, dnsmasq supprime une pièce mobile. Si vous avez surtout besoin d'un résolveur validant qui transmet vers l'extérieur et répond pour une zone interne modeste, Unbound offre ce périmètre plus étroit sans un déploiement complet de BIND 9. S'il vous faut un contrôle autoritaire total, de la délégation et le plus vaste corpus de documentation sur lequel s'appuyer à 3 h du matin, BIND 9 reste le choix prudent malgré sa surface de configuration plus large. Si le DNS fait déjà partie d'une pile de découverte de services en conteneurs ou Kubernetes, CoreDNS s'y intègre naturellement. La règle empirique : faites tourner la plus petite chose qui couvre la forme de votre parc.

Pour un parc en production, ne faites pas d'une seule instance DNS l'unique chemin vers chaque nom interne. Faites tourner au moins deux instances DNS capables de répondre pour la zone, placez-les sur des domaines de panne distincts quand c'est possible, et configurez les clients pour qu'ils joignent les deux. Sinon, une seule panne DNS peut faire passer des services en bonne santé pour morts.

Comment nommer votre domaine interne : .internal, .local ou un sous-domaine ?

Pour la plupart des réseaux VPS en production, utilisez un sous-domaine qui vous appartient, tel que internal.example.com. N'utilisez l'espace de noms .internal que pour une installation isolée où les collisions de noms entre réseaux, la gestion des certificats d'une autorité de certification privée et un traitement DNSSEC particulier sont acceptables. Évitez .local, réservé par mDNS.

Le problème de .local est concret. RFC 6762 réserve aux noms se terminant par .local un traitement spécial pour Multicast DNS ; une zone unicast BIND 9 ou Unbound utilisant le même suffixe peut donc entrer en conflit avec le comportement mDNS sur les appareils Apple et d'autres systèmes compatibles mDNS. Utilisez un autre espace de noms plutôt que de compter sur des contournements propres à chaque client.

Astuce de pro : si vous avez hérité d'une zone interne en .local, considérez-la comme une dette technique. Certains clients envoient les requêtes .local vers mDNS plutôt que vers votre serveur DNS unicast, ce qui peut produire des pannes dépendantes du client ou d'apparence intermittente.

Le Conseil d'administration de l'ICANN a réservé définitivement .internal , en l'excluant de toute délégation dans la racine du DNS public en juillet 2024, à la suite d'une recommandation antérieure du SSAC. Par conception, les noms situés sous ce TLD ne se résoudront pas via le DNS mondial. Cela s'accompagne de compromis : les noms en .internal ne sont pas uniques à l'échelle mondiale, les autorités de certification publiques ne sont pas censées émettre de certificats pour eux, et les résolveurs qui valident DNSSEC en s'appuyant sur l'ancre de confiance mondiale échoueront à les résoudre. Si vous voulez du HTTPS sur .internal, prévoyez d'exploiter une autorité de certification privée.

Distinguez bien deux choses ici. La réservation de l'ICANN est définitive. Un autre document, un Internet-Draft actif, draft-davies-internal-tld-06, a été publié le 6 mai 2026 pour documenter cet espace de noms et le comparer à l'adressage privé de la RFC 1918. Il reste un Internet-Draft en cours de travaux, et non une RFC publiée : décrivez donc .internal comme un TLD à usage privé réservé par l'ICANN, pas comme une norme de l'IETF.

Pour la plupart des parcs de VPS, un sous-domaine d'un domaine que vous contrôlez reste le choix par défaut le plus sûr. L'ISC recommande une hiérarchie de sous-domaines, par exemple un sous-domaine interne de votre propre domaine, plutôt que de maintenir des versions internes et publiques séparées et incomplètes de la même zone parente. Cette préférence n'est pas une question de style : elle évite la panne décrite dans la section suivante.

À retenir de cette section : le choix d'espace de noms vous engage sur la durée. Un sous-domaine que vous contrôlez est le choix par défaut pour la plupart des environnements de production, car il préserve l'unicité mondiale et fonctionne avec la PKI publique. Utilisez .internal lorsqu'un espace de noms privé isolé convient mieux et que vous acceptez ses compromis en matière de DNSSEC, de certificats et de collisions.

Le DNS à horizon partagé et les erreurs qui le cassent

Le DNS à horizon partagé renvoie pour un même nom d'hôte une réponse différente selon qui pose la question : l'IP privée en interne, l'IP publique en externe. Il casse le plus souvent à cause du piège NXDOMAIN sur un même domaine, mais aussi de résolveurs alternatifs qui contournent la vue prévue et de chemins DNS de conteneurs qui n'atteignent pas l'amont attendu. Le faire correctement dépend de trois choses à la fois, pas d'une seule.

Le piège NXDOMAIN est précisément la panne contre laquelle l'ISC met directement en garde. Si vos serveurs internes font autorité sur le domaine parent mais que leur version de la zone ne contient pas un enregistrement public tel que l'hôte www, un client interne interrogeant ce nom reçoit NXDOMAIN alors même que la zone publique le contient. La zone interne fait autorité et ne bascule pas vers le DNS public pour le domaine parent. C'est précisément pour cela que l'approche par hiérarchie de sous-domaines vue plus haut est le design que privilégie l'ISC.

Astuce de pro : avant de pointer vos serveurs vers un montage à horizon partagé sur un même domaine, testez depuis l'intérieur du réseau la résolution d'un nom public connu de ce domaine. Une réponse NXDOMAIN pour un nom qui se résout très bien depuis l'extérieur est la signature de ce piège.

Trois autres pièges passent facilement inaperçus. Un résolveur alternatif configuré sur un hôte ou un conteneur peut contourner la séparation ; selon l'implémentation du résolveur, il peut être interrogé après un délai d'attente ou en parallèle, si bien que les réponses varient. Les conteneurs sur le bridge par défaut de Docker reçoivent au démarrage une copie de la configuration DNS de l'hôte, tandis que ceux placés sur des réseaux personnalisés interrogent le résolveur intégré de Docker à l'adresse 127.0.0.11. Ce résolveur transmet les requêtes externes aux serveurs DNS configurés pour l'hôte ou le conteneur : le comportement du split-DNS dépend donc de la configuration de Docker et de l'hôte, et pas seulement du fichier resolver propre au conteneur. Si un service interne se trouve derrière un reverse proxy comme Gestionnaire de Proxy Nginx, la validation du certificat peut échouer si celui-ci ne couvre pas le nom d'hôte demandé ou si son autorité émettrice n'est pas approuvée par le client. Utiliser simplement un certificat différent en interne n'est pas en soi une erreur. Ce sont des lacunes de configuration, pas des bogues des outils.

Les clients distants peuvent rencontrer la même panne lorsqu'un VPN auto-hébergé ne pousse pas ou ne route pas les requêtes DNS vers le résolveur interne prévu.

Il y a aussi une dimension sécurité. Si des noms d'hôte internes et des IP privées fuitent dans des enregistrements DNS publics, vous exposez une partie de votre plan de nommage et d'adressage interne à quiconque interroge la zone. L'horizon partagé existe en partie pour garder cette carte à l'intérieur, et une zone publique mal configurée annule cela en silence.

À retenir de cette section : les pannes de l'horizon partagé sont des pièges de configuration, pas des défauts des outils. La justesse dépend de la discipline de nommage, du fait de savoir quel résolveur chaque client interroge réellement et d'un périmètre de zone correct, pas d'un réglage unique.

LIRE

Comment pointer un domaine vers VPS : guide rapide

Conclusion : choisir la bonne conception de DNS privé

Vous savez désormais identifier quel système « DNS privé » vous visez réellement. Pour le réseau d'un VPS, il s'agit de la zone DNS interne, et non du réglage DNS-over-TLS d'Android ni de serveurs de noms faisant autorité personnalisés. Si votre parc est petit et stable, /etc/hosts reste un choix défendable. Sinon, prenez un sous-domaine qui vous appartient comme espace de noms par défaut, choisissez le plus petit serveur DNS adapté à votre parc, et gardez explicites l'accès, la redondance et la portée interne ou publique de la zone. N'utilisez .internal que lorsqu'un espace de noms isolé convient mieux et que vous acceptez ses compromis de certificats, de DNSSEC et de collisions.

Foire aux questions