Configuration d'un Split DNS

Split DNS est la solution au problme d'utilisation du mme nom de zone en interne et en externe. En effet, l'utilisation du mme nom de domaine en interne et en externe peut poser beaucoup de problmes aux utilisateurs itinrants. Cet article vous explique comment mettre en oeuvre cette solution afin de contourner les divers problmes de rsolution de noms en environnement mobile.

Introduction
Pour comprendre quoi sert une infrastructure "split" dns, il faut comprendre le problme qu'elle rsout. Pour cela, il est important de noter que dans cet article je fais rfrence au firewall de Microsoft c'est dire ISA pour des raisons de simplicit car c'est le serveur que j'utilise. Mais sachez que l'implmentation d'une infrastructure split dns est la mme quelque soit le type de firewall, du moment que vous le matrisez. Prochainement, je ferais un article sur l'utilisation de Microsoft ISA afin de dtailler certains aspects techniques evoqus dans cet article.

1. Pourquoi crer une zone Split DNS 1.1. Introduction

Nous allons commencer par un exemple afin de vous montrer quels problmes peuvent se poser. Supposons que votre rseau interne utilise comme zone DNS intgre Active Directory supinfo.com. Vous accdez tous les serveurs internes en utilisant le service DNS pour faire la rsolution des FQDN's (Full Qualified Domain Name). Vous avez aussi des serveurs sur votre rseau interne qui sont accessible de l'extrieur via un mcanisme de type Nat ou quivalent. Il parait vident que les utilisateurs internes et externes doivent pouvoir accder aux mmes serveurs. Si vous n'tes pas dans une infrastructure split DNS, ce qui est peut tre le cas si vous lisez cet article, vous utilisez probablement une seule zone DNS pour le domaine supinfo.com. Cela veut dire que tous les enregistrements, aussi bien ceux pour les serveurs accessibles en interne et que ceux accessibles en externe, sont enregistr sur la mme zone. D'autre part, vous rendez votre seul serveur DNS accessible sur Internet afin que les utilisateurs externes puissent accder aux serveurs que vous avez rendu accessible (via NAT, ou publication dans ISA par exemple). Voici quoi pourrait ressembler un fichier de zone DNS de supinfo.com:

1.2. Processus en externe

www A 194.250.104.101 mail A 194.250.104.107 mailsrv A 192.168.129.12 campus A 192.168.129.11

1) Lorsqu'un client l'extrieur du rseau de supinfo veut atteindre un serveur, il a besoin de rsoudre le nom mail.supinfo.com en adresse IP publique sur votre firewall. 2) Le serveur DNS rpond avec l'adresse IP correspondante au firewall soit 194.250.104.107 pour le FQDN mail.supinfo.com. 3) le client externe se connecte sur cette adresse ip et accde au serveur de mail de l'entreprise Supinfo. Comme vous pouvez le constater, il n'y a aucun problme dans ce cas de figure, vous allez voir plus loin dans ce chapitre o se situe le problme d'une infrastructure non split dns.

1.3. Processus en interne

Malheureusement, comme nous utilisons qu'un seul serveur DNS, les clients internes vont suivre le mme processus, voyons ensemble le processus en interne. 1) le client interne fait une requte DNS pour le FQDN mail.supinfo.com 2) Le serveur DNS lui retourne la mme IP que prcdemment, c'est dire celle de l'interface externe du firewall soit 194.250.104.107 3) Le client interne fait donc une boucle travers le firewall pour revenir vers le serveur de courrier mail.supinfo.com 4) Transmission ou non de la requte par le firewall Ce qui se passe dans l'tape 4 dpend du type de client utilis, si vous utilisez un client de type firewall ou Proxy la requte aboutira avec succs; par contre si vous tes dans une configuration de clients SecureNat la requte n'aboutira pas. Vous comprenez que si vous utiliser ce type de configuration vous allez rencontrer beaucoup de difficults avec vos pc clients. D'autre part, mme si cette configuration fonctionne avec des clients proxy ou firewall il est inutile de surcharger un firewall lorsque les clients peuvent contacter les serveurs internes directement. Quelque soit le cas de figure, ce type de configuration n'est pas raisonnable, que ce soit en matire de performance que de scurit (vos enregistrements internes sont interrogeables sur Internet...).

2. Comment crer une zone Split DNS

Nous pouvons rgler tous les problmes prcdemment vus en crant une infrastructure split DNS. Entrons dans le vif du sujet, la cration d'une telle infrastructure consiste installer deux zones DNS pour un mme domaine, une zone pour la rsolution locale et l'autre pour la rsolution sur internet. Reprenons l'exemple prcdent mais seulement pour la zone externe: www A 194.250.104.101 mail A 194.250.104.107

Ensuite le mme domaine mais nous allons regarder sa zone interne: www cname intranet.supinfo.com mail cname mail.supinfo.com intranet A 192.168.129.1 mailsrv A 192.168.129.2 Quand les clients externes essayent de rsoudre le nom www.supinfo.com, ils obtiennent toujours l'adresse IP externe du firewall. C'est tout a fait ce qu'on veut car dans le cas contraire ils seraient incapable d'atteindre les serveurs. Quand les clients internes vont essayer de se connecter sur www.supinfo.com, ils vont utiliser l'adresse interne de ce serveur. Le seul point vrifier, c'est de bien configurer votre tendue DHCP afin d'envoyer les bons serveurs DNS vos clients internes, ainsi que de bien construire la table d'adresse locale et la table de domaine local quand vous utilisez ISA.

3. Exemple de configuration
3.1. Implmentation
Maintenant que vous avez compris quoi sert le split DNS, nous allons voir une configuration plus scurise appele split-split DNS. Cette configuration est plus robuste, elle tolre la panne mais en revanche elle ncessite beaucoup plus de matriels pour la mettre en oeuvre. Cette configuration ncessite l'utilisation de: - Deux serveurs DNS autoritaires dans une DMZ (demilitarized zone) - Deux serveurs DNS en mode cache dans une DMZ (demilitarized zone) - Deux serveurs DNS interne sur le rseau local Il y a 2 serveurs de chaque type pour permettre la tolrance de panne et la rpartition de charge. Pour chacun des types de serveur DNS, il y aura un primaire et un secondaire. Il y a des transferts de zones entre les serveurs primaires et secondaires.

Un DNS autoritaire est un serveur de DNS contenant des zones pour des domaines dont il a l'autorit. Par exemple, si vous aviez l'autorit sur supinfo.net, supinfo.com et campusbooster.com vous mettriez des zones pour chacun de ces domaines sur le serveur DNS autoritaire. Le DNS autoritaire doit tre protg contre la pollution de son cache et ne fait pas de requte rcursive. Pour configurer un "advertiser", vous devez faire ce qui suit: Dans les proprits avances de serveur pour le serveur de DNS, cochez la case "Dsactiver la rcursivit" Dans les proprits avances de serveur pour le serveur de DNS, cochez la case "Protger le cache contre la pollution " Retirez toutes les entres de serveur de racine DNS dans l'onglet serveur racine Renommez le fichier cache.dns sur le serveur; il se trouve dans le dossier \\system32\dns

Vous ne voulez pas que le serveur autoritaire excute des requtes rcursives. Le serveur autoritaire fournit des informations pour les zones sous votre autorit. Si un client de DNS essaye d'interroger un nom dont le serveur n'a pas d'autorit, le serveur renvoie un message " de panne de serveur ". Vous empchez la plupart et les plus dangereux exploits de DNS en dsactivant la rcursivit. Les DNS Resolvers dans la DMZ sont des serveurs de DNS en mode cache qui agissent en tant qu'expditeurs pour les serveurs de DNS sur le rseau interne. Ces serveurs DNS en mode cache n'ont aucune zone d'installe. Ils ne servent qu' rsoudre et mettre en cache les requtes qu'ils ont rsolues pour les serveurs de DNS sur le rseau interne. Puisque ces machines ne sont autoritaires sur aucun domaine, il n'y a aucun risque que vos domaines soient sujets des attaques DNS sur ces serveurs. Les serveurs de DNS internes rsolvent les requtes pour les clients internes de rseau. Rappelezvous que le chemin emprunt par les clients du rseau interne pour accder des ressources sur le rseau interne dot tre diffrent des chemins emprunts par les clients externes. La diffrence rside dans le contenu des zones hberges par le serveur DNS interne et le serveur DNS autoritaire. Par exemple, dans votre DMZ, les DNS autoritaires auraient les enregistrements DNS suivants: supinfo.net www A 194.250.104.101 mail A 194.250.104.107 mx mail.supinfo.net Notez que ce sont les adresses d'IP sur l'interface externe du serveur d'ISA en front end qui sont utilises pour publier les serveurs qui sont dans la DMZ.

Les serveurs DNS internes auraient les enregistrements DNS suivants pour les mmes ressources : supinfo.net www A 192.168.129.1 mail A 192.168.129.7

3.2. Explication des diffrents scnario

1) Les clients internes du rseau envoient une requte pour www.supinfo.com au serveur DNS interne 2) Les serveurs DNS internes envoient l'adresse prive interne au client. Ensuite le client se connecte au serveur interne directement en vitant ainsi les problmes isotropic bounce. (cf. chap.1) 3) Les clients internes se connectent au serveur en utilisant l'adresse prive du serveur dans la zone DMZ dos--dos.

1) Les clients externes interrogent le serveur DNS autoritaire dans la DMZ en utilisant l'adresse publique sur l'interface externe du firewall. 2) Les serveurs DNS autoritaires retournes les adresses publiques via l'interface externe du firewall. 3) Les clients externes se connectent au serveur web via l'adresse IP externe du firewall utilis pour publier ce serveur Web

Conclusion
L'infrastructure split DNS est quelque chose que vous devriez utiliser chaque fois que vous utilisez le mme nom de domaine en interne et en externe. Celle ci permet d'optimiser les accs des clients internes sur vos serveurs sans pour autant faire de loopback sur votre firewall ISA. Par contre; si vous grer des rseaux trs grands, notamment si vous tes dans une configuration ISA dos dos avec une DMZ au milieu il est prfrable et plus scuris d'utiliser une configuration splitsplit DNS comme expliquer dans le chapitre 3. C'est la configuration optimale en terme de scurit car elle n'expose pas vos serveurs DNS internes (les plus sensibles...) aux attaques connues.