I. Présentation

Dans cet article, nous allons parler split-brain DNS et plus particulièrement sa configuration sur un serveur DNS sous Windows Server 2016. La configuration qui suit s'appuie essentiellement sur PowerShell.

II. Qu'est-ce que le split-brain DNS ?

Si l'on traduit tout bêtement split-brain, on obtient : cerveau divisé. Nous ne sommes pas si loin de la réalité, en fait. Grâce à la méthode du split-brain DNS, nous allons pouvoir demander à notre DNS de répondre différemment au client qui envoi la requête en fonction de son réseau source.

Prenons un exemple, nous avons le site internet www.it-connect.fr qui est accessible par tout le monde, sur un serveur web exposé sur Internet. Le serveur DNS connaît l'adresse IP associée à cet hôte, il s'agit d'une adresse IP publique diffusée partout.

Maintenant, imaginons que ce site soit accessible également par les utilisateurs connectés au réseau interne de la société IT-Connect. Sur le réseau local, nous avons un second serveur web, accessible uniquement en interne et l'on souhaite, à juste titre, qu'il soit utilisé lorsqu'une personne se connecte sur www.it-connect.fr à partir du réseau local. Pour parvenir à ce résultat, nous allons utiliser la méthode du split-brain DNS.

En résumé, avec un seul serveur DNS et une seule zone, vous pouvez retourner des réponses différentes (donc adresses IP différentes) à vos clients. Ce principe est notamment utilisé lorsque les serveurs sont répartis à différents endroits géographiques afin de permettre au client d'accéder au serveur le plus proche.

Je vous laisse admirer mon superbe dessin (il faut bien que je m'amuse avec le stylet de la Surface), où l'on voit bien un serveur DNS, au centre, et deux clients : l'un dans le réseau local et l'autre sur Internet. Dans le réseau local, nous avons également un serveur web avec une copie du site, et sur Internet, un second serveur avec lui aussi sa copie du site.

III. Configurer le split-brain DNS sur Windows Server

Reprenons l'exemple du schéma, avec le site www.it-connect.fr et deux hôtes qui hébergent le site :

• Depuis le réseau local, le premier hôte dispose de l'adresse IP : 192.168.1.100
• Depuis Internet, le deuxième hôte dispose de l'adresse IP : 90.90.1.100

Au centre, un serveur DNS sous Windows Server 2016 (dans mon cas) qui contient et gère la zone "it-connect.fr".

Connectez-vous sur votre serveur et ouvrez une console PowerShell en tant qu'administrateur.

Premièrement, nous allons créer un scope nommé "LAN" dans la zone "it-connect.fr". Pour créer un scope, il est nécessaire d'utiliser le cmdlet Add-DnsServerZoneScope. Voici la commande :

Add-DnsServerZoneScope -ZoneName "it-connect.fr" -Name "LAN"

Ensuite, nous allons créer un enregistrement DNS de type A (IPv4) pour l'hôte "www" avec l'adresse IP du serveur web interne. Cet enregistrement sera rattaché au scope "LAN" de notre zone.

Note : lorsque l'on crée un enregistrement DNS en PowerShell pour l'ajouter dans le scope par défaut (global), on utilise la même commande sauf qu'il n'est pas nécessaire d'utiliser le paramètre ZoneScope.

Ce qui donne :

Add-DnsServerResourceRecord -ZoneName "it-connect.fr" -A -Name "www" -IPv4Address "192.168.1.100" -ZoneScope "LAN"

Maintenant que l'on a notre scope et l'enregistrement qui lui est associé, il faut ajouter une dernière couche : la stratégie (policy). En fait, nous allons créer une politique pour indiquer que si une requête arrive sur l'interface 192.168.1.10 du serveur DNS, alors on affecte le scope "LAN" pour la zone "it-connect.fr".

La commande Add-DnsServerQueryResolutionPolicy s'utilise comme ceci :

Add-DnsServerQueryResolutionPolicy -Name "SplitBrain" -Action ALLOW -ServerInterface "eq,192.168.1.10" -ZoneScope "LAN,1" -ZoneName "it-connect.fr"

Vous remarquerez la présence du paramètre -Action : il sert à indiquer si l'on autorise, refuse ou ignore les paquets qui vont matcher avec la politique que l'on crée. Pour le paramètre -ZoneScope, la valeur "1" qui suit le nom du scope sert à indiquer le poids car on pourrait indiquer plusieurs scopes. Enfin, pour le paramètre -ServerInterfaceIP on indique l'adresse IP du serveur DNS utilisée par les clients (interface d'écoute). Il est possible de remplacer le "eq" pour equal/égal par la négation "ne" pour not equal.

Note : à la place de l'adresse IP du serveur, on peut spécifier un subnet source grâce au paramètre -ClientSubnet. Pour créer le subnet, il faudra au préalable utiliser le cmdlet Add-DnsServerClientSubnet.

Voici le résultat de la commande nslookup avant et après la mise en place de la politique.

Précision : j'ai réalisé les tests directement depuis le serveur DNS, l'adresse IP utilisée est donc 127.0.0.1 : ce qui ne correspond pas à la politique, j'ai donc créer une autre politique pour indiquer l'adresse IP 127.0.0.1 mais j'aurais pu faire autrement. Par exemple, utiliser le "ne" pour exclure l'adresse IP externe du serveur DNS et ainsi conserver son IP sur le réseau local et l'adresse localhost.

IV. Afficher et gérer la configuration

La console DNS de Windows Server n'affiche pas les scopes et les stratégies donc il est nécessaire d'avoir recours à PowerShell pour consulter la configuration.

Pour lister les scopes associés à une zone, nous pouvons utiliser le cmdlet Get-DnsServerZoneScope, comme ceci :

Get-DnsServerZoneScope -ZoneName "it-connect.fr"

Cela va afficher les scopes associés à la zone "it-connect.fr" 😉

Note : par défaut une zone DNS dans Windows contient un scope qui englobe tout, afin de répondre aux clients avec l'enregistrement "principal" (associé à aucun scope).

Pour afficher les stratégies associées à une zone, on va rajouter une seconde commande à la suite de celle que l'on a vu précédemment. Cela donne la commande suivante :

Get-DnsServerZoneScope -ZoneName "it-connect.fr" | Get-DnsServerQueryResolutionPolicy

Les stratégies vont s'afficher avec le nom, le poids de la règle, son état (actif/inactif) et l'action associée (accepter, bloquer ou refuser). Pour finir, voici les commandes qui servent à supprimer les objets :

• Supprimer un scope : Remove-DnsServerZoneScope
• Supprimer une stratégie : Remove-DnsServerQueryResolutionPolicy
• Modifier une stratégie : Set-DnsServerQueryResolutionPolicy

V. Cas avec deux DNS différents

Pour finir, je tiens à partager une autre méthode d'utilisation de ce que l'on peut assimiler à du split-brain DNS dans le cas où l'on utilise deux DNS différents.

Imaginons un nom de domaine géré par un registrar (OVH, par exemple), avec un enregistrement DNS qui renvoi vers un serveur hébergé on-premise en DMZ, accessible par une adresse IP publique. Si l'on se situe sur Internet, on va y accéder grâce à l'adresse IP publique. Par contre, si l'on est sur le réseau local, il est préférable d'y accéder via l'adresse IP privée sauf que le DNS va répondre avec l'IP publique.

Dans ce cas, il existe une astuce : créer une zone sur votre serveur DNS on-premise, en indiquant comme nom de zone le nom complet de l'hôte, par exemple "www.it-connect.fr" pour faire un overload par rapport à l'enregistrement situé au niveau du registrar. Il suffit de créer un enregistrement par défaut dans la zone et d'y attribuer l'adresse IP privée ! 😉

Il est important de ne pas créer la zone "it-connect.fr" car sinon vous allez devoir gérer en doublon votre zone dans les deux serveurs DNS indépendant. En créant la zone sur un nom spécifique, le serveur DNS on-premise se limitera à utiliser sa zone pour ce nom, et pour les autres requêtes liées à ce domaine, il va solliciter le serveur DNS externe qui lui contient la zone publique.