Faut‑il configurer des DNS publics dans la portée DHCP de vos PC joints à Active Directory ? Voici la réponse argumentée, les risques concrets, et un guide pas à pas pour une configuration robuste (IPv4/IPv6, GPO, sécurité, supervision).
Contexte et question
Dans de nombreuses infrastructures, la tentation est grande d’ajouter des DNS « de secours » (ceux de l’ISP, 1.1.1.1, 8.8.8.8, etc.) en tertiaire/quaternaire dans la portée DHCP, « au cas où » les serveurs DNS internes — le plus souvent hébergés sur les contrôleurs de domaine — deviendraient indisponibles. Cette pratique semble offrir un filet de sécurité pour l’accès Internet, mais elle compromet silencieusement Active Directory.
Réponse courte (best practice)
- N’annoncez via DHCP que des DNS internes (Option 006 en IPv4, Option 23 en DHCPv6). Prévoyez au moins deux serveurs par site.
- Résolvez l’externe à partir des serveurs internes grâce à des forwarders (vers vos résolveurs de confiance) et, si besoin, des root hints.
- N’insérez jamais de DNS publics dans la portée DHCP des machines jointes au domaine.
- Assurez la disponibilité avec deux DC/DNS minimum (par site si possible), sauvegardes, supervision et tests réguliers.
Pourquoi éviter les DNS publics sur des postes joints à l’AD
Les clients modernes ne respectent pas strictement un ordre « primaire > secondaire > tertiaire ». Ils effectuent des sélections basées sur la latence, l’historique de succès et, selon les versions, peuvent paralléliser des requêtes sur plusieurs interfaces (Wi‑Fi, VPN, Ethernet). Résultat : si vous annoncez des DNS publics, des requêtes pour des noms internes (zones AD intégrées, enregistrements SRV, _ldap._tcp, split‑DNS, etc.) peuvent partir vers l’extérieur. Cela provoque :
- échecs de logon, Kerberos et recherche de contrôleur de domaine (DC Locator),
- GPO appliquées de manière aléatoire ou en retard,
- accès intermittents aux partages, au catalogue global, à la PKI interne,
- fuites d’information (noms d’hôtes, suffixes internes) vers l’Internet.
Et lorsque tous les DC/DNS internes sont réellement hors service, l’AD est de toute façon dégradé : l’authentification, les scripts de logon, la distribution des secrets et la découverte de services sont impactés. Offrir l’Internet via des DNS publics aux postes de domaine n’apporte presque aucun bénéfice opérationnel et introduit des risques le reste du temps.
Comment Windows résout les noms en pratique
- Résolveur multi‑accès : Windows peut interroger plusieurs serveurs ou interfaces en parallèle dans certains cas (ex. Smart Multi‑Homed Name Resolution). Ce comportement optimise la vitesse mais peut envoyer des requêtes là où vous ne le souhaitez pas.
- Suffixes DNS et DC Locator : le client s’appuie sur la Primary DNS Suffix, les enregistrements SRV (
_ldap._tcp.dc._msdcs.) et les zones AD. Un DNS public ne connaît pas ces enregistrements. - Cache & échecs négatifs : un échec contre un serveur non autoritatif peut être mis en cache, aggravant des pannes « fantômes ».
Architecture recommandée
Poste joint au domaine
│ requête interne (SRV, A/CNAME zone AD)
▼
DNS interne (AD-integrated) ──► Si nom externe : Forwarders ──► Résolveurs de confiance ──► Internet
│
└──► Réponse autoritative pour les zones internes (dont _msdcs, sites AD, split-DNS)
Multi‑sites et latence
- Au moins deux DNS internes par site AD, idéalement sur des hôtes différents et zones de disponibilité distinctes.
- Sites et sous‑réseaux AD correctement renseignés pour que les clients utilisent en priorité des résolveurs locaux.
Comparatif des approches
| Approche | Avantages | Risques | Pertinence |
|---|---|---|---|
| DNS internes only + forwarders | Contrôle complet, résolution AD fiable, journalisation centralisée | Nécessite une vraie HA des DC/DNS | Recommandée pour postes joints à l’AD |
| DNS publics en 3ᵉ/4ᵉ | Apparent « secours » Internet | Fuites, GPO instables, logon aléatoire, split‑DNS cassé | À proscrire |
| VLAN invité séparé | Accès Internet de secours contrôlé | Segmentation à concevoir | Adapté pour postes non joints ou cas d’urgence |
Configuration pas à pas
DHCP : annoncer uniquement des DNS internes
IPv4 (Option 006)
- Dans votre console DHCP, ouvrez la portée → Options de la portée.
- Activez 006 DNS Servers et renseignez
10.0.0.10,10.0.0.11(exemple). - Supprimez toute adresse DNS publique.
# PowerShell (serveur DHCP Windows)
Set-DhcpServerv4OptionValue -DnsServer 10.0.0.10,10.0.0.11 -ComputerName DHCP01
# Par portée
Set-DhcpServerv4OptionValue -ScopeId 10.0.10.0 -DnsServer 10.0.0.10,10.0.0.11 -ComputerName DHCP01
IPv6 (Option 23)
- Sur DHCPv6, définissez DNS Servers avec vos résolveurs internes (ex.
2001:db8::10,2001:db8::11). - Si vous utilisez des RA (Router Advertisements), annoncez vos DNS internes via RDNSS.
# PowerShell (serveur DHCPv6 Windows)
Set-DhcpServerv6OptionValue -DnsServer 2001:db8::10,2001:db8::11 -ComputerName DHCP01
# Par préfixe (exemple)
Set-DhcpServerv6OptionValue -Prefix 2001:db8:10:: -DnsServer 2001:db8::10,2001:db8::11 -ComputerName DHCP01
DNS internes : activer des forwarders
- Sur chaque serveur DNS interne, définissez des forwarders vers des résolveurs de confiance (ISP, filtrage, etc.).
- Conservez les root hints uniquement si nécessaire ou comme secours contrôlé.
# PowerShell (DNS Windows)
Add-DnsServerForwarder -IPAddress 1.1.1.1,8.8.8.8 -PassThru
Get-DnsServerForwarder
# Pour retirer/ajuster
Remove-DnsServerForwarder -IPAddress 8.8.8.8
Zones internes et split‑DNS
- Conservez les zones AD‑intégrées (
_msdcs, zone racine interne, zones par sites). - Pour les noms externes spécifiques (SaaS, partenaires), envisagez des conditional forwarders plutôt que des copies de zones.
- Évitez de dupliquer une zone publique entière en interne, sauf si vous maîtrisez le split‑horizon.
GPO et paramètres client
Appliquez des politiques pour empêcher les contournements et stabiliser la résolution :
- Désactiver Smart Multi‑Homed Name Resolution (GPO : Computer Configuration → Administrative Templates → Network → DNS Client → Turn off smart multi-homed name resolution = Enabled).
- Contrôler DoH (DNS over HTTPS) : Configure DNS over HTTPS (DoH) name resolution = Disabled ou Allow DoH uniquement vers vos résolveurs internes désignés.
- Suffixes DNS : privilégiez « Append primary and connection specific DNS suffixes » et fournissez une Search List maîtrisée si nécessaire.
Sécurité & conformité
- Filtrage egress : bloquez
53/UDP,53/TCPet853/TCP(DoT) vers Internet pour les postes clients. Autorisez ces ports uniquement depuis vos serveurs DNS internes. - DoH : limitez
443/TCPvers des points DoH approuvés (ou désactivez DoH côté OS/navigateurs via GPO). - Enregistrements dynamiques sécurisés : activez les mises à jour dynamiques sécurisées, l’aging/scavenging et utilisez un compte d’enregistrement DHCP dédié pour éviter les enregistrements orphelins.
- Journalisation : activez les logs de requêtes sur les DNS internes (en tenant compte de la volumétrie et du RGPD) et centralisez‑les.
Particularités IPv6
- Si IPv6 est actif, appliquez les mêmes règles : uniquement des DNS internes via DHCPv6/RA.
- Vérifiez RDNSS dans les RA pour ne pas annoncer de DNS publics par inadvertance.
- Surveillez que le client n’utilise pas un résolveur privacy relay ou un DNS de l’opérateur 4G en cas de multi‑accès.
Scénarios d’accès Internet de secours
Besoin d’Internet alors que l’AD est indisponible ? Offrez‑le via un réseau invité/VLAN séparé (non joint au domaine) ou un portail captif. Les postes de production restent, eux, sur des DNS internes uniquement. Cette séparation maintient la sécurité et évite les contournements permanents.
Vérifications rapides
# Résolution des enregistrements SRV AD
Resolve-DnsName _ldap._tcp.dc._msdcs.votre-domaine.local
# Test résolution interne/externe
nslookup serveur-fichier.interne
nslookup [www.exemple.com](http://www.exemple.com)
# Contrôle des DNS reçus par le client
Get-DnsClientServerAddress
# Santé DNS côté DC
dcdiag /test\:dns Troubleshooting avancé
| Symptôme | Cause probable | Actions correctives |
|---|---|---|
| Logon lent, GPO incomplètes | Requêtes SRV partant vers DNS publics, cache négatif | Retirer DNS publics du DHCP, vider cache (ipconfig /flushdns), corriger GPO réseau |
| Noms internes résolus aléatoirement | Split‑DNS cassé, clients interrogeant plusieurs serveurs | DNS internes only, conditional forwarders, vérifier Search Suffixes |
| Pertes d’accès pendant panne d’un DC | Pas de DNS secondaire local, dépendance mono‑hôte | Ajouter un 2ᵉ DC/DNS par site, supervision et bascule testée |
| Fuites DNS vers Internet | DoH/DoT non contrôlé, egress ouvert | Bloquer 53/853 en sortie, GPO DoH, proxy DNS interne |
| Erreurs DNS au démarrage des DC | Zones AD non chargées (latence AD) | Vérifier événements 4000/4013/4015, ordre de démarrage, redondance |
Audit & remédiation automatisée (PowerShell)
Rechercher des DNS publics dans les portées DHCPv4
$public = @('1.1.1.1','8.8.8.8','9.9.9.9')
Get-DhcpServerv4Scope | ForEach-Object {
$o = Get-DhcpServerv4OptionValue -ScopeId $_.ScopeId -ErrorAction SilentlyContinue
$dns = ($o | Where-Object {$_.OptionId -eq 6}).Value
if ($dns){
$hit = $dns | Where-Object { $public -contains $_ }
if ($hit){ "{0} : {1}" -f $_.ScopeId, ($hit -join ',') }
}
}
Forcer les DNS internes sur une portée
Set-DhcpServerv4OptionValue -ScopeId 10.0.10.0 -DnsServer 10.0.0.10,10.0.0.11
Lister et définir des forwarders DNS
Get-DnsServerForwarder
Add-DnsServerForwarder -IPAddress 1.1.1.1,8.8.8.8 -PassThru
Audit des clients pour détecter un DNS non conforme
Get-DnsClientServerAddress | Where-Object {
$_.ServerAddresses -match '^(1\.1\.1\.1|8\.8\.8\.8|9\.9\.9\.9)$'
}
Bonnes pratiques de disponibilité
- Deux DC/DNS minimum par site, VM sur hôtes/ZA distincts, sauvegardes testées.
- DHCP failover en mode load‑balanced et alerting proactif.
- Surveillance : disponibilité DNS (sondes
A/SRV), latence des forwarders, journaux d’événements. - Maintenance : vérifier aging/scavenging, nettoyer les enregistrements orphelins, valider la réplication AD.
FAQ ciblée
Et si mes utilisateurs sortent du réseau (télétravail) ?
Utilisez un VPN always‑on ou des profils qui poussent les DNS internes quand le tunnel est établi. Hors tunnel, le poste n’est plus « joint et connecté » au SI : fournissez l’Internet via un réseau invité ou des politiques distinctes.
Puis‑je configurer directement 1.1.1.1/8.8.8.8 sur mes serveurs DNS internes ?
Oui en forwarders (si conforme à votre politique). Ne mettez pas de DNS publics sur les clients de domaine.
Les root hints suffisent‑ils ?
Ils fonctionnent, mais les forwarders vers un résolveur de confiance offrent souvent de meilleures performances, du filtrage et de la visibilité.
Je fais de l’IPv6 : dois‑je traiter différemment ?
Non. Même principe : annoncer uniquement vos DNS internes en DHCPv6/RA et utiliser des forwarders côté serveurs.
Checklist de validation
- DHCPv4/v6 n’annoncent que des adresses de DNS internes.
- Les forwarders sont configurés et testés depuis chaque DNS interne.
- GPO : SMHNR désactivé, DoH contrôlé, suffixes DNS maîtrisés.
- Egress bloqué pour le trafic DNS/DoT, exceptions uniquement pour les serveurs DNS.
- Tests :
Resolve-DnsName _ldap._tcp.dc._msdcs.<domaine>,nslookupinterne/externe,dcdiag /test:dns. - Supervision et alertes opérationnelles en place.
Erreurs fréquentes à éviter
| Erreur | Conséquence | Prévention |
|---|---|---|
| DNS publics ajoutés en « secours » dans DHCP | Instabilité AD, fuites de requêtes, GPO aléatoires | DNS internes only + forwarders |
| Un seul DC/DNS dans un site | Point de défaillance unique | Deux DC/DNS minimum sur hôtes/ZA distincts |
| DoH/DoT non maîtrisé | Contournement des politiques DNS | GPO + filtrage egress + résolveurs internes DoH |
| Search list débridée | Résolution imprévisible | Suffixes ciblés et documentés |
Conclusion
Pour des postes joints à Active Directory, la ligne directrice est claire : annoncez exclusivement des DNS internes via DHCP. Confiez la résolution externe aux forwarders de vos serveurs DNS, investissez dans la redondance (au moins deux DC/DNS par site), dans la supervision et dans le contrôle des sorties (DNS/DoT/DoH). En procédant ainsi, vous protégez l’intégrité d’AD, stabilisez les GPO et éliminez une catégorie entière d’incidents sournois liés aux fuites de requêtes vers des résolveurs publics.