> Tech > DNS divisé (split DNS)

DNS divisé (split DNS)

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

  Pour des raisons de sécurité évidentes, la plupart des sociétés ne révèlent pas leur infrastructure de réseau interne. Cette discrétion concerne particulièrement les noms d'hôtes internes et les adresses IP correspondantes que vos serveurs DNS fournissent. Mais vous devez quand même fournir un service DNS à  Internet pour résoudre les

DNS divisé (split DNS)

noms d’hôtes et adresses IP externes (par exemple, les adresses de vos serveurs Web et serveurs e-mail sur Internet). La solution consiste à  diviser le service DNS en un service interne et externe, pour obtenir un DNS divisé. Quand vous établissez un service split DNS, le service DNS interne permet aux utilisateurs internes de résoudre les noms et adresses d’hôtes intranet et Internet. Le service DNS externe répond aux requêtes Internet externes concernant les noms et adresses d’hôtes externes de votre société. Vous pouvez mettre en oeuvre split DNS de deux manières, selon la version BIND en service. Split DNS dans BIND 8. La première méthode, illustrée figure 1, consiste à  placer un ou plusieurs serveurs DNS internes derrière un parefeu dans l’intranet, et de placer un ou plusieurs serveurs DNS externes dans la zone démilitarisée (DMZ) ou sur Internet. Seuls les clients DNS internes peuvent accéder au DNS interne, qui contient des informations d’hôte et d’adresse de domaine interne. Quand un client DNS externe interroge un nom d’hôte dans le domaine Internet de la société, le serveur DNS externe répond à  la requête. Aucune requête DNS provenant d’Internet ne va dans l’intranet. Quand le serveur DNS interne reçoit une requête pour un nom d’hôte Internet (par exemple, www.win2000mag.com), qui n’est pas dans sa cache, il retransmet une requête récursive au serveur DNS externe. Plutôt que de désactiver la récursion sur le serveur DNS externe, vous utilisez la méthode présentée dans le listing 2 pour restreindre la récursion sur ce serveur afin de ne permettre la récursion que pour des requêtes provenant de l’intranet. Le serveur externe localise le serveur DNS de win2000mag.com provenant du serveur root Internet, puis résout le nom www.win2000mag.com à  partir du serveur DNS de win2000mag.com. Pour permettre la retransmission sur le serveur DNS interne, appliquez l’instruction montrée dans le listing 4 à  la section options de named.conf. Le code du renvoi A dans le listing 4 s’assure que serveur DNS interne retransmet toujours les requêtes des domaines qu’il ne sert pas, à  l’un des serveurs DNS externes indiqués par le renvoi B.

  Envisagez de placer votre serveur BIND DNS externe dans votre DMZ, derrière un pare-feu externe, comme le montre la figure 1. Un bon pare-feu peut détecter et dénier une attaque comme DoS (Denial of Service). Pour utiliser ce mécanisme, il faut ouvrir le port UDP 53 sur le pare-feu externe pour permettre aux requêtes Internet d’atteindre le serveur DNS externe. Split DNS dans BIND 9. La seconde méthode de mise en oeuvre de Split DNS utilise la nouvelle fonction View de BIND 9. Elle permet d’utiliser le même matériel DNS pour fournir des services internes et externes. Supposons, par exemple, que votre société, Exampleco ait un domaine interne exampleco.com et un domaine externe exampleco.com. Le domaine interne a un fichier de zones qui contient des informations d’hôtes et d’adresses internes, et le domaine externe a un fichier de zones distinct qui contient des informations de noms d’hôtes et d’adresses externes. Un serveur DNS classique ne peut charger qu’une copie d’un fichier de zones pour exampleco.com. En revanche, BIND 9 permet d’utiliser un serveur DNS pour charger plusieurs fichiers de zones pour le même nom de domaine et pour répondre aux requêtes des clients provenant du fichier de zones approprié, d’après l’adresse du client (c’est-à -dire interne ou externe). Pour exécuter des fichiers de zones internes et externes pour exampleco.com sur un serveur BIND 9, vous pouvez appliquer les instructions présentées dans le listing 5, à  la section view de named.conf. (Un serveur BIND DNS résout les requêtes clients d’après l’ordre des instructions view existantes. Par conséquent, quand vous ajoutez une nouvelle instruction view, faites attention à  sa place par rapport aux éventuelles instructions view existantes.) La première instruction concerne le domaine interne ; la seconde concerne le domaine externe. Le domaine interne utilise le fichier de zones internal.exampleco ; le domaine externe utilise le fichier de zones external. exampleco. Quand le serveur DNS reçoit une requête, il détermine d’abord si l’adresse du client DNS se situe dans l’intervalle d’adresses de la sous-instruction que montre le renvoi A du listing 5. Si oui, le serveur DNS sait que le client est un client interne et par conséquent renvoie une réponse du domaine interne. Dans la négative, le serveur DNS détermine si l’adresse du client se situe dans l’intervalle d’adresses de la sous-instruction montrée par le renvoi B. Ici, la sous-instruction du renvoi B indique any, donc le serveur renvoie une réponse provenant du domaine externe à  any (n’importe quel) client ne correspondant pas à  la liste de clients internes.

 &nbso;Pour utiliser la fonction View, il faut exécuter BIND 9 sur une machine accessible aux clients intranet et Internet. Cette machine peut constituer le pare-feu entre l’Internet et l’intranet sur un serveur dans la DMZ. (Notons au passage qu’une bonne DMZ a un pare-feu interne et un parefeu externe. Le pare-feu interne ouvre vers l’extérieur UDP 53 pour les requêtes intranet vers le serveur DNS; le pare-feu externe ouvre vers l’intérieur UDP 53 pour les requêtes Internet vers le serveur DNS.)

Téléchargez cette ressource

Guide de Sécurité IA et IoT

Guide de Sécurité IA et IoT

Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010