Chapitre 2 Administrer un serveur DNS Table des matières 1 Présentation du module sr005 2 I Administration d un serveur DNS..................................... 2 II Organisation................................................ 2 2 Administrer un serveur DNS 3 I Comprendre le protocole DNS....................................... 3 1. Introduction.............................................. 3 2. Protocole DNS............................................ 3 3. Mécanisme de délégation...................................... 4 4. Messages DNS............................................ 5 II Serveur DNS................................................ 7 1. État de l art.............................................. 7 2. Installation............................................... 8 3. Piège fatal............................................... 11 4. Pièges................................................. 13 5. Sécurisation.............................................. 13 I Comprendre le protocole DNS 1. Introduction Dans la séquence de cours précédente, nous avons vu que toutes les machines connectées à un réseau sont adressables par une adresse IP afin qu elles puissent communiquer entre elles. Le problème, c est qu il est difficilement possible de mémoriser toutes les adresses des ordinateurs. C est 3
I. Comprendre le protocole DNS pour cela qu il est nécessaire d utiliser un protocole qui va faire la correspondance entre un nom de machine (mémorisable par un humain) et son adresse IP (et vice-versa). Ce mécanisme, appelé résolution de noms, est fourni par le protocole Domain Name System (DNS). Ce service est, après le routage IP, la partie laplus critique et importante de votre réseau ; si celui-ci tombe en panne ou fournit des informations erronées à la suite d une erreur de configuration, vos utilisateurs vont très vite venir vous voir. Inquiétant non? Mais le plus inquiétant est que cette situation arrive beaucoup plus fréquemment qu on ne le croit puisqu il suffit d une virgule mal placée pour provoquer une catastrophe. Dans cette séquence, nous étudierons le protocole DNS, la mise en place d un serveur offrant ce service ainsi que des recommandations quant à sa configuration pour vous empêcher de vous tirer dans le pied lors de mises à jour de la configuration. 2. Protocole DNS Le protocole DNS est défini par l IETF dans une dizaine de RFC, mais les grands principes sont présentés dans les RFC 1034[?] et 1035[?]. La résolution DNS se fait par l envoi d une question et la réception d une réponse depuis le serveur. Comme nous allons le voir un peu plus tard, l émetteur de la question n est pas forcément un «client» (au sens classique) mais peut être un autre serveur DNS. Mettons tout de suite un terme à l idée que le protocole DNS n utilise que le protocole de transport UDP, en effet, lorsque les serveurs ou clients DNS ont besoin d envoyer une réponse ou une question DNS faisant une taille supérieure à 512 octets, ils doivent passer par TCP qui est un protocole de transport en mode connecté et fiable. Dans les deux cas (UDP ou TCP), le port 53 est utilisé. 3. Mécanisme de délégation a. Principe Lorsqu un client désire se connecter à un autre ordinateur, il est obligé de récupérer son adresse IP ou, dans la terminologie DNS, de résoudre le nom d hôte en adresse IP. Pour cela, le client va envoyer une requête (une question) à son serveur préféré. Si ce serveur dispose de l information, il y répond tout de suite. Autrement, si la requête porte sur un domaine complètement extérieur, le serveur va aller poser la question à un autre serveur responsable du domaine en question. C est ici qu interviennent les échanges entre serveurs vus un peu plus haut. Pourquoi? Il est impossible de stocker les données DNS du monde entier sur une seule machine, d une part car le résultat serait énorme en ressources disque (ou de traitement) et d autre part car ça ne correspond pas à l esprit originel d Internet (ou plutôt d Arpanet) où le réseau devait fonctionner correctement même si des liens étaient tombés ou des services injoignables. De plus, il y aurait en permance des problèmes de synchronisation. C est pour celà qu on été mis en place les délégations : chaque serveur ne connaît que la zone qui lui a été déléguée (son réseau local par exemple) mais sait comment accéder au reste du monde s il n a pas été configuré pour. La figure 2.1 montre ce mécanisme simplifié : 4
I. Comprendre le protocole DNS FIG. 2.1 Délégation simplifiée des zones b. Détails FIG. 2.2 Délégation des zones Lorsqu un serveur DNS veut résoudre le nom foobar.domainea.org, il va traiter celui-ci à l envers. C est-à-dire qu il va tout d abord déterminer à qui est déléguée la zone.org, pour cela, il s adresse aux root-servers. Ensuite, il lui demande à qui s adresser pour connaître l adresse IP d une machine de la zone domaineb.org. Notre serveur contacte alors son équivalent de domaineb.org et reçoit enfin sa réponse. Quelle perte de temps vous dîtes-vous? Oui... et non puisque pour éviter ces nombreuses requêtes à chaque question, on peut utiliser des caches au niveau des différents serveurs. Ainsi, si on a déjà posé la question, la réponse sera immédiate. c. Terminologie Maintenant que vous connaissez sommairement le fonctionnement du DNS, il est temps d utiliser les mots justes ; Un serveur DNS en charge des informations d un domaine est autoritaire (ou primaire), c est-à-dire qu il n a besoin de contacter personne pour répondre à une question au sujet de sa zone. Une zone est le domaine pour lequel on est autoritaire. 5
I. Comprendre le protocole DNS À l opposé des serveurs autoritaires se trouvent les serveurs de cache (ou esclaves). Ces derniers ne possèdent pas d information propre, ils ne savent que poser des questions à l extérieur et les mettre en cache pour accélérer les prochaines questions. Ils ont un rôle de forwarder et sont (généralement) récursifs. La résolution de nom par le client est faite par l intermédiaire d un mécanisme/processus appelé resolver. Intéressons-nous maintenant aux messages DNS pour savoir à quoi ils ressemblent précisément et quelles sont leurs fonctions. 4. Messages DNS a. Composition d un message Les entêtes DNS La structure d un message DNS est définie précisement dans la RFC 1035, donc nous ne rentrerons pas dans les détails, mais il faut savoir qu on peut envoyer une ou plusieurs questions dans un même message DNS pour gagner du temps. Ainsi, il est nécessaire d avoir une «enveloppe DNS» annoncant ce qui arrive. Enveloppe et diverses options : Cette enveloppe contient un identifiant(supposé unique), le nombre de questions ou de réponses 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 ID QR Opcode AA TC RD RA Z RCODE QDCOUNT ANCOUNT NSCOUNT ARCOUNT Ces champs sont : Le champ ID (sur seize bits) permet d associer une requête à un identifiant. Son rôle majeur est de permettre au client d envoyer plusieurs questions en même temps et de pouvoir identifier les réponses grâce à cet entier. Le bit QUERY indique si c est une requête ou une réponse DNS. Le champ OPCODE indique le type de question (question normale, requête inversée, erreur, etc.). Les bits AA, TC, RD, RA donnent des informations sur la nature de la réponse. QDCOUNT indique le nombre de questions incluses dans le message DNS. ANCOUNT indique le nombre de réponses NSCOUNT indique le nombre d enregistrements dans la partie Name server ARCOUNT indique le nombre d enregistrements dans la partie Authoritative. 6
I. Comprendre le protocole DNS À la suite de cette enveloppe, on trouve les données utiles (questions, réponses, erreurs, etc.), on les appelle des enregistrements ou des ressources records (RR). Examinons maintenant ces octets... Ressource Record 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 / / / NAME / TYPE CLASS TTL RDLENGTH +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+-- / RDATA / / / Tous les enregistrements ont ce format de base indépendemment de la nature du message, celui-ci permet de connaître le type de donnée : une question ou une réponse par exemple. Le champ RDLENGTH indique la longueur du champ RDATA, c est lui qui contient, dans un format variable en fonction du type de message, les véritables données. Le champ TTL (Time To Live) indique la durée maximale pendant laquelle un client peut mettre la réponse en cache. b. Différents types Une requête peut porter sur la résolution d un nom de domaine en une adresse IP, mais le service DNS peut fournir beaucoup plus d informations comme les requêtes DNS inverses (adresse IP vers un (ou plusieurs) nom(s) de domaine), connaître la machine responsable des mails, ou se renseigner sur une zone. En fait, on peut tout mettre dans une zone DNS grâce aux champs de type TXT : ces derniers peuvent contenir des clefs de chiffrement publiques, des informations pour lutter contre le spam (connaître les serveurs de mail sortant) ou même permettre de se frayer un tunnel pour contourner les firewalls... Voici une liste non-exhaustive des types les plus fréquemment rencontrés, liste extraite de la RFC1035[?] : A NS CNAME 1 Nom vers Adresse 2 Récupére le nom du serveur autoritaire d un domaine 5 Alias 7
SOA PTR MX TXT 6 Zone d Autorité 12 Adresse vers nom 15 Récupération du serveur de mail 16 Chaîne de caractères Ainsi, la requête la plus courante, la résolution de nom, est une requête de type A. Une requête inverse est de type PTR. Maintenant que l on connaît globalement les mécanismes mis en jeu par le DNS, mettons en place ce service. II Serveur DNS 1. État de l art Plusieurs implémentations de serveurs DNS existent, chacune concerne un public différent : amateurs de fonctionnalités avancées, sécurité ou compatibilité parfaite. Malheureusement, aucune des solutions existantes ne propose toutes ces bonnes choses sans compromis : bind 1 est l ancêtre de tous les serveurs, il possède de nombreuses fonctionnalités intéressantes, même s il est en retard sur quelques points comme le stockage des zones. C est le serveur le plus respectueux des RFC et donc le plus compatible avec tous les clients et autres serveurs. C est un logiciel mûr même si bind a eu quelques vulnérabilités dans son histoire. PowerDNS 2 est le plus avancé en terme de fonctionnalités avec la possibilité de stocker les zones dans des bases de données ou de faciliter le load balancing. Ce logiciel semble 3 être attentif à la sécurité, mais cela est à prendre avec des pincettes puisqu on peut douter que leur code ait été audité autant que celui de bind. Attention, PowerDNS est un serveur limité à être autoritaire! MaraDNS 4 a été conçu à l origine pour être un serveur sécurisé. Il peut servir de cache ou comme serveur autoritaire. djbdns 5 est également un serveur DNS réputé pour sa sécurité, malheureusement, il n est pas compatible sur certains points (comme le transfert de zones) avec d autres serveurs classiques. De plus, son auteur (très controversé pour son attitude cavalière) publie son logiciel sous une licence non libre. La meilleure solution, par sa maturité et ses fonctionnalités, est donc l utilisation de bind. Plusieurs versions majeures existent pour bind, on trouve encore quelques réseaux utilisant une version 4.x mais c est une branche obsolète et qui n est plus mise à jour. Aujourd hui, et pour bénéficier de plus de fonctionnalités (comme les views, les acls, il faut utiliser la version stable 9.X. 2. Installation Pour ne pas se tromper lors de la mise en place de votre serveur, choississez toujours la version fournie par votre distribution en utilisant les paquets créés. Vous serez ainsi sûr de toujours avoir une version à jour d un point de vue sécurité. 1 bind - http://www.isc.org/ 2 PowerDNS - http://www.powerdns.com/ 3 http ://doc.powerdns.com/security-policy.html 4 MaraDNS - http://www.maradns.org/ 5 djbdns - http://cr.yp.to/djbdns.html 8
Sous Debian GNU/Linux, installez le paquet bind9 et pour vous aider dans le debugging, le paquet bind9-host. a. Prérequis Matériel Le service DNS n est pas consommateur en ressources, pour servir votre réseau, une simple machine bas de gamme (mais fiable!) est suffisante, un surplus de RAM n est pas de refus. La seule chose importante est d avoir une carte réseau correcte. Côté Humain Une fois installé, le service DNS ne nécessite pas de maintenance particulière autre que l administration classique de la machine (lecture des logs, mise à jour des logiciels, etc.). Les tâches hebdomadaires sont l ajout ou la supression d entrées dans la zone de votre réseau. Au niveau des compétences requises, seule une bonne compréhension des réseaux IP est rééllement nécessaire et savoir lire les pages de manuel. b. Configuration La configuration de bind n est basée que sur des fichiers textes, conceptuellement, il n y a qu un fichier de configuration nécessaire, /etc/bind/named.conf, qui décrit toutes les zones et options du serveur. Voici un exemple d option : options { directory "/var/cache/bind"; allow-query { 10.10.0.0/24; 127.0.0.1; allow-transfer { none; } ; allow-recursion { 10.0.0.0/24; 127.0.0.1;} ; Ensuite, pour chaque zone, vous devez indiquer le type de service que vous proposez : autoritaire ou secondaire. Un serveur primaire est un serveur autoritaire pour un domaine et est le «maître» à l opposé des serveurs secondaires qui sont autoritaires, mais qui sont des simples miroirs : ils n ont qu un droit de lecture seule sur les données.ainsi, pour un serveur secondaire, il suffit d indiquer qui est le maître de la zone et la zone va être automatiquement transférée vers vous. Pareil, si une modification est faite de la zone sur le serveur autoritaire, le serveur secondaire est notifié du changement et un transfert de zone a de nouveau lieu. // Serveur secondaire pour la zone foo.bar.org // en interogeant le maître 10.2.3.4 zone "foo.bar.org." { type slave; masters { 10.2.3.4; Si vous n êtes ni le serveur maître, ni le serveur esclave d une zone mais que vous savez qui contacter sans passer par l interrogation des root-servers (exemple des zones internes d une entreprise divisée en de nombreux départements), vous pouvez donner un ou plusieurs forwarders. 9
// on sait que la zone hq.bar.org est servie // par 10.0.0.2 donc posons lui nos questions! zone "hq.bar.org" { type XXX; forwarders { 10.0.0.2; Ce type de directive est souvent utilisé lorsque vous êtes un serveur de cache : Vous transmettez toutes vos requêtes au serveur dns de votre fournisseur d accès qui se chargera d interroger les root-servers à votre place, ne vous laissant plus qu à mettre en cache la réponse. Si vous êtes le serveur primaire, vous devez préciser le chemin vers le fichier qui contient votre zone. C est ce fichier de zone qui va vous intéresser et vous donner beaucoup de peine au long de votre apprentissage. zone "testme.fr" { notify no; type master; file "/etc/bind/db.testme.fr"; Ici, on indique que nous sommes le maître (autoritaire) de la zone testme.fr et qu elle est décrite dans le fichier db.testme.fr. C est ce fichier qui va nous intéresser, en voici un exemple : $TTL 604800 @ IN SOA ns0.testme.fr. hostmaster.testme.fr. ( 2005081100 ; numéro de série 8H ; raffraichissement 2H ; essai 1W ; expiration 1D ) ; minimum TXT "Private Network" NS ns0.testme.fr. NS ns1.testme.fr. MX 10 mx1 MX 20 mx.monfai.fr. homer IN A 10.0.0.42 homer IN AAAA 2001:660:305:1::1:2 maggie IN A 10.0.0.33 marge IN A 10.0.0.88 La première ligne indique que le TTL est fixé à une semaine (604800/3600/24) par défaut. La ligne suivante indique le Start Of Autority, c est-à-dire qu on se déclare autoritaire pour la zone nommée dans le fichier de configuration named.conf (testme.fr). Le caractère @ est un raccourci pour désigner cette zone. 10
ns0.testme.fr correspond au serveur primaire responsable de cette zone. hostmaster.testme.fr correspond à l adresse email de l administrateur du service DNS en cas de problème, pour que l adresse soit valide, il faut remplacer le premier point par un @. Les différents chiffres des lignes suivantes représentent successivement le numéro de série (la «version de la zone»), le temps de rafraichissement minimal pour la zone, le temps d attente avant de réessayer en cas d échec et la durée de validité maximale de la zone. Après cet «épilogue», on passe aux véritables données : la résolution de nom. On peut décomposer les lignes en quatre parties : La partie gauche correspond au nom qu on définit, si cette partie est vide, on désigne l objet courant.c est le cas pour les trois premières lignes (TXT et NS) où on décrit la zone @ (soit testme.fr) La colonne suivante indique la classe, à moins de travailler dans un environnement très exotique, ce sera toujours la classe IN (pour Internet). On précise ensuite le type d enregistrement, A,NS, MX, CNAME, etc. Enfin, dernière colonne, on a la «donnée». 3. Piège fatal Dans le morceau de configuration précédent, vous n avez pas dû avoir prêté attention à un caractère minuscule, le point. Pourtant, il est d une importance primordiale et vous vous ferez piegez à coup sûr. En effet, lorsque vous mettez un nom (homer, marge, etc), vous n êtes pas obligé d ajouter à la fin de chaque nom de machine le domaine courant, cette fonctionnalité repose sur la règle suivante : si un nom ne se termine pas par un point, alors cela ajoute à la fin le domaine courant. Autrement, c est que l on désigne le nom pleinement qualifié (Fully Qualified Domain Name [FQDN]). a. Exemple Simple nom de machine homer IN A 10.0.0.42 On définit le nom homer (appartenant au domaine @, ou testme.fr car il n y a pas de point à la fin du mot) comme pointant vers une adresse de classe IN 10.0.0.42. La déclaration suivante est identique : homer.testme.fr. IN A 10.0.0.42 Service mail testme.fr. testme.fr. MX 10 mx0 MX 20 mx1 Lorsqu un serveur SMTP (le service chargé de la messagerie) veut envoyer un mail à un nom de domaine, il doit récupérer l adresse de la ou des machines qui en ont la charge. Cette information, appelée Mail exchanger (MX), est récupérée par une requête DNS. Ainsi, on peut indiquer, par ordre de priorité, quels sont les serveurs à contacter : le serveur avec la plus petite priorité est utilisé en premier. 11
Adresse vers nom de domaine À partir d une adresse IP, nous pouvons lui faire correspondre un nom de domaine. Similairement à la hiérarchie de résolution classique, nous avons les mêmes mécanismes pour les requêtes inverses. FIG. 2.3 Résolution DNS inverse Ainsi, pour résoudre 10.0.0.42, on utilise une zone spéciale, in-addr.arpa comme racine et on descend dans l arbre comme indiqué dans la figure 2.3. On lit l adresse IP de gauche à droite contrairement à la résolution classique où on lit de droite à gauche. Alias www IN CNAME homer cvs IN CNAME homer Lorsque vous êtes client d un réseau, il est toujours recommandé d utiliser des noms de services comme adresse plutôt que les véritables noms de machine. D une part car il est plus facile et logique de mémoriser cvs.testme.fr plutôt que homer.testme.fr mais surtout car le service CVS pourrait être déplacé sur un autre serveur. Dans ces conditions, il faut utiliser les alias au niveau DNS : les Canonical Name, ou CNAME. Mais attention! Un CNAME ne doit jamais se trouver sur la partie droite d un enregistrement. C est à dire que la configuration suivante est invalide : mail IN CNAME homer testme.fr MX 10 mail Puisque mail est un CNAME, cet alias n a pas le droit de se trouver dans la partie droite. Deux raisons principales à cela : Il est possible de faire des boucles Cela ajoute une requête DNS (une pour savoir que c est un CNAME, une autre pour connaître l adresse associée à la «valeur de l alias») De plus, cette interdiction est explicitement marquée dans les RFC. 12
Serveur de nom mondomaine.fr. IN NS ns0.domaine.fr. Un enregistrement Nameserver (NS) sert à déclarer les serveurs DNS responsables d un nom de domaine. Ici,on ne fait pas de différenciation entre les serveurs primaires ou secondaires, ils doivent simplement être autoritaires. La configuration de bind se résume donc à l utilisation de ces quelques enregistrements. Restropectivement, ce n était pas si compliqué, non? Avant de répondre, regardons tout de même les pièges dans lesquels vous tomberez certainement. 4. Pièges L erreur la plus fréquente est l oubli ou l ajout du point dans les noms de domaines, donc soyez-y très attentifs. Un autre oubli est d incrémenter le numéro de série de la zone lorsque vous la modifiez, ce qui a pour conséquence de ne pas mettre à jour les serveurs secondaires si vous en avez. Un bon schéma à suivre pour écrire ce serial est de concaténer l année (sur quatre chiffres), le mois, le jour et un numéro sur deux chiffres. Par exemple, pour le 18 août 2005 : 2005081800. Cette numérotation permet d être assuré que les numéros de séries se suivent de facon cohérente et qu il n y a pas d erreur. Si dans une journée, vous faîtes plus d une modification, incrémentez simplement les deux derniers chiffres. Et si c est une autre journée, réécrivez intégralement le numéro de série : le 20 août 2005 (2005082000) est forcément supérieur à celui du 18 août car 2005082000 > 2005081800. Enfin, n oubliez pas qu un CNAME ne doit pas être dans la partie droite d un enregistrement. Ainsi, pas de MX pointant sur un CNAME (erreur la plus fréquente). Il existe encore des dizaines de pièges mais vous les cultiverez avec le temps et l expérience, la RFC1912[?] documente les principales erreurs. L erreur est humaine et c est bien pour cela qu il faut vous habituez à l utilisation de logiciels de vérification de zone. ZoneCheck 6 est l un des meilleurs. 5. Sécurisation a. Pourquoi sécuriser? Quels sont les menaces? Le service DNS est primordial quant à la sécurité de votre réseau : si votre serveur délivre des réponses controlées par un attaquant, celui-ci peut tout contrôler. Ainsi, il pourra répondre que l adresse IP de security.debian.org est une machine contrôlée et ajouter des backdoors dans les paquets Debian. Ceci n est qu un exemple des nombreuses possibilités qui sont offertes à un pirate et qui doivent vous pousser à ne pas négliger la sécurité de ce service. Voici un aperçu des différentes menaces qui reposent sur votre serveur : 6 ZoneCheck : http://www.zonecheck.fr/ 13
L empoisonnement de cache est le fait d ajouter des information falsifiées dans le cache du serveur DNS (à des fins de redirections, déni de service, etc.). Les grands serveurs libres (bind, djbdns,maradns...) sont protégés de ces attaques, mais c est moins vrai pour certains serveurs DNS propriétaires. Un Open DNS est un serveur de cache qui accepte les requêtes du monde entier et peut exploiter cela pour différents méfaits mais en particulier le DNS Cache Snooping Le DNS Cache Snooping 7 est une technique permettant à un attaquant de voir si un enregistrement DNS existe dans le cache. Conséquence : fuite d information. Le transfert de zone est le mécanisme utilisé par les serveurs secondaires pour charger une zone complète d un domaine. Ces données sont suffisamment sensibles (voulez-vous que tout le monde puisse connaître la topologie de votre réseau?) pour que vous n autorisiez que les bonnes personnes à les télécharger, autrement, c est une grosse fuite d informations. Une attaque Man in the middle DNS est un moyen pour l attaquant de se faire passer pour le serveur autoritaire et de répondre à sa place (en sa faveur bien sûr). Le seul moyen de parer à ces attaques est l utilisation de la cryptographie, mais nous ne l aborderons pas dans ce cours. Afin de se protéger de toutes ces menaces, détaillons les points critiques et avant tout, où placer votre ou vos serveurs DNS. b. Architecture Il n existe pas de réponse universelle pour le placement de votre service DNS, votre architecture sera différente si vous êtes un serveur autoritaire, primaire, secondaire ou simplement de cache. Le point essentiel lors du déploiement des machines est le principe du moindre privilège, dans l absolu, il faudrait une machine par service. Ce réseau de serveurs devrait lui-même être contenu dans un réseau à part entière (différent du réseau des machines clientes) (DMZ, ou zone démilitarisée). Il en est de même pour le DNS, si possible, il faut un serveur pour traiter les «requêtes autoritaires», un autre pour les clients internes de votre réseau (pour leur servir de cache) et, dans le meilleur des mondes, un serveur de cache uniquement pour servir votre DMZ. Malheureusement, sauf dans de rares cas, vous n aurez pas accès à toutes ces machines disponibles. C est pour cela que bind (depuis la version 9) a la capacité de faire tourner différentes vues, on peut voir une vue comme une instance de bind indépendante des autres. Dans un réseau avec une architecture simple, on pourra faire tourner un bind avec deux vues : une pour les clients et une autre pour servir le monde entier (si nous sommes autoritaires pour un quelconque domaine). Voici une configuration minimale : // On est autoritaire et on sert de serveur cache pour // les clients du réseau interne. // De plus, on propose la zone complète testme.fr pour // ces clients view "internal" { match-clients { 10.0.0.0/8; recursion yes; zone "testme.fr" { 7 DNS Cache Snooping par Luis Grangeia (http://community.sidestep.pt/~luis/dns-cache-snooping/) 14
type master; file "db.full.testme.fr"; // Une vue externe pour les requêtes provenant d Internet // On offre une vue limitée de la zone testme.fr (juste // ce qu il faut) et on interdit la récursion (on ne // veut pas servir de serveur de cache) view "external" { match-clients { any; recursion no; zone "testme.fr" { type master; file "db.limited.testme.fr.conf"; À vous de peaufiner votre configuration pour qu elle corresponde à vos besoins (ajout de serveurs secondaires, transfert de zone, limitation des zones, délégations, etc.). Pour brider votre serveur, il va falloir utiliser les directives allow-transfer, allow-query, allow-recursion ou allow-notify. 15