Chapitre 314 minIntermédiaire
DNS interne et externe : split DNS et DNS d'Active Directory
Par Josselyn C., prof de BTS SIO. Mis à jour le .
À la fin de ce chapitre, tu sauras
- concevoir l'architecture DNS d'une organisation avec Active Directory ;
- choisir le nom DNS d'un domaine Active Directory ;
- configurer redirecteurs et redirecteurs conditionnels ;
- mettre en place un split DNS sans NAT en épingle ;
- régler le résolveur de pfSense pour la DMZ et les invités.
4 exercices corrigés1 schéma
Le DNS interne résout les noms du réseau de l'entreprise (serveurs, postes, annuaire) pour les seuls utilisateurs internes ; le DNS externe publie sur Internet les quelques noms que le public doit connaître (site web, messagerie). Quand un même nom doit recevoir une réponse différente selon qu'on le demande de l'intérieur ou de l'extérieur, on parle de split DNS (ou DNS à double horizon). Ce chapitre construit l'architecture DNS de Sorbier : qui fait autorité sur quoi, qui résout pour qui, et comment les deux mondes se rejoignent.
Deux publics, deux besoins
| DNS interne | DNS externe | |
|---|---|---|
| Qui pose les questions | Les postes et serveurs de Sorbier | N'importe qui sur Internet |
| Ce qu'il doit connaître | Tous les serveurs, les postes, les enregistrements SRV de l'annuaire, l'intranet | Le site public, le site de suivi, le serveur de messagerie, les enregistrements SPF, DKIM et DMARC |
| Ce qu'il ne doit jamais montrer | Rien à cacher aux salariés, mais aucun accès depuis Internet | Les noms et adresses internes |
| Serveurs chez Sorbier | srv-ad et srv-ad2 (zones intégrées à AD) ; le résolveur de pfSense pour la DMZ et les invités | ns1 dans la DMZ (primaire) et le secondaire de l'hébergeur |
Le principe de sécurité est simple : ce qui est interne reste interne. Publier les noms internes sur Internet revient à donner aux attaquants la carte du réseau.
Le domaine de l'annuaire : ad.sorbier.example
Le nom DNS d'un domaine Active Directory est choisi une fois pour toutes, à la création de la forêt : le changer ensuite est une opération lourde et risquée. Trois choix existent :
| Choix | Exemple | Verdict |
|---|---|---|
| Un sous-domaine du domaine public | ad.sorbier.example | Recommandé : tu possèdes le domaine parent, personne ne peut l'acheter à ta place, et l'interne reste séparé du public |
| Le domaine public lui-même | sorbier.example | Possible, mais impose de recopier en interne tous les noms publics (split DNS complet) |
| Un domaine inventé | sorbier.local, sorbier.lan | À éviter : .local est réservé au mDNS (RFC 6762) et entre en conflit avec les appareils Apple et Linux ; un TLD inventé peut un jour exister, et aucune autorité publique ne te délivrera de certificat pour ce nom |
Sorbier a choisi ad.sorbier.example. Ses deux contrôleurs, srv-ad (192.168.10.177) et srv-ad2 (192.168.10.181), portent le rôle DNS et la zone ad.sorbier.example, intégrée à Active Directory : stockée dans l'annuaire, répliquée avec lui, modifiable sur les deux serveurs, avec des mises à jour dynamiques sécurisées. L'installation de ces zones, des redirecteurs et du nettoyage des enregistrements périmés est détaillée dans le cours Windows Server, au chapitre DNS et DHCP. Ce chapitre-ci s'occupe de l'architecture.
L'architecture DNS de Sorbier
Quatre flux, à savoir décrire en épreuve :
- Postes et serveurs internes →
srv-ad/srv-ad2. Ils obtiennent les noms internes (srv-fichiers.ad.sorbier.example) et, par l'intermédiaire des contrôleurs, ceux d'Internet. srv-ad/srv-ad2→ Internet. Pour les noms qu'ils ne détiennent pas, ils font suivre la question à des redirecteurs (ici les résolveurs filtrants de Quad9,9.9.9.9et149.112.112.112) à travers le pare-feu, qui n'autorise le DNS sortant que depuis ces deux serveurs.- Internet →
ns1etdns2.hebergeur.example. Les résolveurs du monde entier interrogent les serveurs qui font autorité poursorbier.example.ns1est un serveur BIND en DMZ (chapitre 4), publié par le pare-feu sur UDP et TCP 53 ; le secondaire de l'hébergeur garde la zone en ligne si le site de Sorbier est coupé. - VLAN visiteurs et DMZ → résolveur du pare-feu. Les invités et
srv-webn'ont aucune raison de connaître les noms internes : ils utilisent le résolveur intégré de pfSense (Unbound), sur l'adresse du pare-feu dans leur réseau (192.168.10.62pour les visiteurs,192.168.10.238pour la DMZ).
Redirecteurs et redirecteurs conditionnels
Quand un serveur DNS interne reçoit une question sur un nom qu'il ne détient pas, il a trois façons de la traiter.
| Mode | Fonctionnement | Avantages | Inconvénients |
|---|---|---|---|
| Indications de racine | Le serveur enquête lui-même, depuis la racine | Aucune dépendance à un tiers | Il faut ouvrir le DNS sortant vers tout Internet |
| Redirecteur | Il fait suivre toutes les questions inconnues à un résolveur choisi | Un seul flux sortant, filtrage possible (résolveur filtrant), cache partagé | Si le redirecteur tombe, plus de résolution (sauf repli sur les racines) |
| Redirecteur conditionnel | Il fait suivre les questions sur un domaine donné à des serveurs désignés | Résoudre les noms internes d'un partenaire, d'une filiale, d'une autre forêt | Une règle par domaine à maintenir |
Sous Windows Server, les redirecteurs se règlent dans la console Gestionnaire DNS, propriétés du serveur, onglet Redirecteurs ; un redirecteur conditionnel se crée dans le dossier Redirecteurs conditionnels. En PowerShell :
# Redirecteurs vers les résolveurs filtrants de Quad9
Set-DnsServerForwarder -IPAddress 9.9.9.9, 149.112.112.112 -UseRootHint $true
# Les noms internes du transporteur partenaire, résolus par ses propres serveurs, via le VPN
Add-DnsServerConditionalForwarderZone -Name "partenaire.example" `
-MasterServers 10.50.0.10, 10.50.0.11 -ReplicationScope "Forest"
-UseRootHint $true laisse le serveur se replier sur les indications de racine si les redirecteurs ne répondent pas. -ReplicationScope "Forest" range le redirecteur conditionnel dans l'annuaire : tous les contrôleurs DNS de la forêt le reçoivent, sans le recréer sur chacun.
Le split DNS : un nom, deux réponses
Le site de suivi des livraisons, suivi.sorbier.example, est hébergé par srv-web dans la DMZ (192.168.10.225). De l'extérieur, le nom doit donner l'adresse publique 203.0.113.17 : le pare-feu reçoit la connexion et la transmet à srv-web. De l'intérieur, un commercial qui ouvre le même nom recevrait aussi 203.0.113.17, et sa connexion devrait sortir vers l'adresse publique du pare-feu pour rentrer aussitôt : c'est le NAT en épingle (hairpin NAT ou NAT reflection), désactivé par défaut sur pfSense et source de pannes difficiles à comprendre.
La solution propre est le split DNS : le même nom reçoit l'adresse publique à l'extérieur et l'adresse privée à l'intérieur.
Qui demande suivi.sorbier.example | Serveur interrogé | Réponse |
|---|---|---|
| Un client sur Internet | ns1 ou dns2.hebergeur.example (zone publique) | 203.0.113.17 |
| Un poste du VLAN 10 | srv-ad (zone interne) | 192.168.10.225 |
Il y a trois façons de le construire.
1. Une zone complète en double (split-brain). Les contrôleurs portent une zone sorbier.example interne, différente de la zone publique. C'est la seule solution si le domaine AD est le domaine public, mais elle impose de recopier à la main, en interne, tous les noms publics (www, mail…) : un nom ajouté chez l'hébergeur et oublié en interne devient introuvable pour les salariés.
2. Une zone « ciblée » pour un seul nom. Sur srv-ad, tu crées une zone qui porte exactement le nom suivi.sorbier.example, avec un seul enregistrement A à son apex. Les contrôleurs font autorité pour ce nom précis et pour rien d'autre : www.sorbier.example continue d'être résolu par Internet.
# Une zone qui ne contient que suivi.sorbier.example, répliquée sur les contrôleurs DNS du domaine
Add-DnsServerPrimaryZone -Name "suivi.sorbier.example" -ReplicationScope "Domain"
Add-DnsServerResourceRecordA -ZoneName "suivi.sorbier.example" -Name "@" -IPv4Address 192.168.10.225
Sorbier utilise la même technique pour l'intranet : la zone intranet.sorbier.example, avec un A vers srv-intranet (192.168.21.10), n'existe que sur les contrôleurs. Sur Internet, ce nom n'existe pas, ce qui est voulu.
3. Des stratégies DNS ou des vues. Un même serveur peut répondre différemment selon l'adresse du client : les stratégies de résolution de Windows Server (DNS policies, avec des étendues de zone) ou les vues (view) de BIND (chapitre 4). C'est puissant, mais plus difficile à lire et à dépanner : on le réserve aux cas où les deux publics interrogent le même serveur.
Le résolveur de pfSense pour la DMZ et les invités
pfSense intègre un résolveur DNS, Unbound, appelé DNS Resolver dans son interface (menu Services > DNS Resolver). Activé par défaut, il fonctionne en mode résolveur : il interroge lui-même les serveurs racines, et il valide DNSSEC par défaut (case DNSSEC). Les réglages à connaître :
| Réglage | Rôle chez Sorbier |
|---|---|
| Network Interfaces | Les interfaces sur lesquelles il écoute : par défaut toutes. Limite-le à DMZ, VISITEURS et localhost |
| Outgoing Network Interfaces | Les interfaces utilisées pour ses propres requêtes : WAN |
| DNS Query Forwarding | Coché, il fait suivre les questions aux serveurs DNS déclarés dans System > General Setup au lieu d'enquêter lui-même |
| Use SSL/TLS for outgoing DNS Queries to Forwarding Servers | Avec le mode précédent, chiffre ces requêtes en DNS over TLS (port 853) |
| Host Overrides | Répondre une adresse choisie pour un nom précis, par exemple suivi.sorbier.example → 192.168.10.225 pour la DMZ |
| Domain Overrides | Faire suivre un domaine entier à un serveur choisi : l'équivalent d'un redirecteur conditionnel |
Les noms internes et les certificats
Le choix d'un domaine que tu possèdes a une conséquence très concrète : les certificats. Une autorité de certification publique ne délivre de certificat que pour un nom dont tu prouves la propriété, et jamais pour un nom interne comme srv-ad tout court, sorbier.local ou une adresse privée.
| Nom | Certificat public (Let's Encrypt, autorité commerciale) | Certificat de l'autorité interne (AD CS) |
|---|---|---|
suivi.sorbier.example (public) | Oui | Oui, mais seuls les postes du domaine lui font confiance |
intranet.sorbier.example (n'existe qu'en interne) | Oui, par un défi DNS dans la zone publique | Oui |
srv-intranet.ad.sorbier.example | Possible par défi DNS, mais le nom apparaît dans les journaux publics de certificats | Oui : le choix normal pour les noms internes |
srv-intranet.sorbier.local | Non | Oui |
Le chapitre 8 détaille ces deux sources de certificats.
Exercices
Exercice 1 sur 4 Un poste qui n'ouvre plus de session Réussi À revoir
Depuis qu'un technicien a changé les réglages réseau du poste de Karim Morel, l'ouverture de session dure deux minutes et les lecteurs réseau n'apparaissent plus. Internet fonctionne. ipconfig /all affiche :
Serveurs DNS. . . . . . . . . . . . . : 8.8.8.8
192.168.10.177
- Explique le symptôme.
- Pourquoi Internet fonctionne-t-il ?
- Quelle correction proposes-tu, et comment éviter que ça se reproduise ?
Voir la réponseMasquer la réponse de l'exercice 1
- Le poste interroge d'abord
8.8.8.8, qui ne connaît pasad.sorbier.example: il répondNXDOMAIN. Une réponse négative est une réponse : le poste ne passe pas au second serveur. Il ne trouve plus les enregistrements SRV des contrôleurs de domaine, d'où une session lente (identifiants mis en cache), sans GPO ni lecteurs. - Google résout parfaitement les noms d'Internet.
- Remettre la carte en configuration automatique (DHCP), qui distribue
192.168.10.177et192.168.10.181(option 006). Pour éviter la récidive : retirer les droits d'administration locale aux utilisateurs, bloquer sur le pare-feu le DNS sortant des postes, et vérifier la configuration avec une GPO ou un inventaire (GLPI).
Tu avais trouvé ?
Exercice 2 sur 4 Concevoir le split DNS Réussi À revoir
Sorbier ouvre un portail client, portail.sorbier.example, hébergé sur srv-web (192.168.10.225) et publié par le pare-feu sur 203.0.113.17.
- Quel enregistrement ajoutes-tu dans la zone publique ?
- Que fais-tu sur les contrôleurs de domaine pour que les salariés joignent le portail sans passer par l'adresse publique ? Donne les commandes PowerShell.
- Le portail doit aussi être joignable depuis la DMZ elle-même (une tâche planifiée de
srv-webl'appelle). Quel réglage prévois-tu sur pfSense ?
Voir la réponseMasquer la réponse de l'exercice 2
-
portail IN A 203.0.113.17dans la zonesorbier.example, sans oublier d'augmenter le serial. -
Une zone ciblée sur les contrôleurs :
Add-DnsServerPrimaryZone -Name "portail.sorbier.example" -ReplicationScope "Domain" Add-DnsServerResourceRecordA -ZoneName "portail.sorbier.example" -Name "@" -IPv4Address 192.168.10.225Les autres noms de
sorbier.examplerestent résolus par Internet. -
Un Host Override dans Services > DNS Resolver :
portail.sorbier.example→192.168.10.225. La DMZ utilise le résolveur du pare-feu, pas l'annuaire.
Tu avais trouvé ?
Exercice 3 sur 4 Choisir le nom du domaine Active Directory Réussi À revoir
Une PME, Atelier Vercors, possède le domaine public ateliervercors.example. Son prestataire propose de nommer le nouveau domaine Active Directory vercors.local.
- Donne deux raisons de refuser.
- Propose un nom et justifie-le.
Voir la réponseMasquer la réponse de l'exercice 3
.localest réservé au mDNS (RFC 6762) : les appareils Apple, Linux et certaines imprimantes l'interrogent par diffusion locale, d'où des résolutions lentes ou fausses. Et aucune autorité publique ne délivre de certificat pour un nom en.local: tout ce qui est interne devra passer par une autorité interne.ad.ateliervercors.example(oucorp.,int.) : un sous-domaine du domaine qu'elle possède. Personne ne peut l'enregistrer à sa place, l'interne reste séparé du public, et des certificats publics restent possibles si besoin.
Tu avais trouvé ?
Exercice 4 sur 4 Les flux DNS du pare-feu Réussi À revoir
Écris les règles du pare-feu pour le DNS de Sorbier (source, destination, protocole et port, action), d'après l'architecture de ce chapitre. Termine par ce qui doit être refusé.
Voir la réponseMasquer la réponse de l'exercice 4
| Source | Destination | Protocole et port | Action |
|---|---|---|---|
srv-ad .177, srv-ad2 .181 | 9.9.9.9, 149.112.112.112 | UDP et TCP 53 | Autoriser |
| Internet | ns1 .230 (par la redirection de port de 203.0.113.17) | UDP et TCP 53 | Autoriser |
dns2.hebergeur.example | ns1 .230 | TCP 53 (transfert de zone) | Autoriser |
| VISITEURS, DMZ | Pare-feu (.62, .238) | UDP et TCP 53 | Autoriser |
| Postes et serveurs internes | srv-ad, srv-ad2 | UDP et TCP 53 | Autoriser, sur l'équipement qui route entre les VLAN (ACL de SW-COEUR, ou pare-feu s'il route les VLAN) |
| Toute autre source interne | Internet | UDP et TCP 53, TCP 853 | Refuser et journaliser |
Les notifications de ns1 vers le secondaire (NOTIFY, UDP 53 sortant) sont aussi à autoriser. Le pare-feu refuse tout le reste par défaut.
Tu avais trouvé ?