Fichiers de configuration BIND

/etc/named.conf

Le fichier /etc/named.conf est une suite de déclarations utilisant des options insérées placées entre accolades { }. Un fichier /etc/named.conf commun est organisé comme le montre la Figure 14-2.

<statement-1> ["<statement-1-name>"] [<statement-1-class>] {
   <option-1>;
   <option-2>;
   <option-N>;
};

<statement-2> ["<statement-2-name>"] [<statement-2-class>] {
   <option-1>;
   <option-2>;
   <option-N>;
};

<statement-N> ["<statement-N-name>"] [<statement-N-class>] {
   <option-1>;
   <option-2>;
   <option-N>;
};

Le "<statement-name>" n'est nécessaire qu'avec les déclarations acl, include, server, view et zone. Le <statement-N-class> ne peut être spécifié qu'avec la déclaration zone.

Des commentaires peuvent être placés dans /etc/named en caractères insérés de style C /* */ ou après les caractères // et #.

Les déclarations suivantes peuvent être utilisées dans /etc/named.conf:

• acl <acl-name> — Configure une liste de contrôle d'accès d'adresses IP qui se verront autoriser ou interdire certains services named. La plupart du temps, les adresses IP individuelles ou la notation de réseau IP (comme 10.0.1.0/24) servent à identifier les IP exactes.

  Quelques listes de contrôle d'accès sont déjà définies. Vous n'avez donc pas besoin de configurer une déclaration acl pour les définir :

  • any — Correspond à toutes les adresses IP.

  • localhost — Correspond à toute adresse IP utilisée par le système local.

  • localnets — Correspond à toute adresse IP sur tout réseau auquel le système local se connecte avec ses interfaces.

  • none — Ne correspond à aucune adresse IP.

  Lorsqu'elles sont utilisées avec d'autres déclarations /etc/named.conf et leurs options, les déclarations acl peuvent se révéler très utiles pour mieux utiliser votre serveur de noms BIND. Observez l'exemple dans la Figure 14-3.

  acl black-hats { 10.0.2.0/24; 192.168.0.0/24; }; acl red-hats { 10.0.1.0/24; }; options { blackhole { black-hats; }; allow-query { red-hats; }; allow-recursion { red-hats; }; }

  Figure 14-3. Exemple d'utilisation de déclaration acl

  Ce named.conf contient deux listes de contrôle d'accès (black-hats et red-hats.

• controls — Configure diverses contraintes de sécurité nécessaires â l'utilisation de la commande rndc pour utiliser le démon named.

  Consultez la la section intitulée /etc/named.conf pour voir à quoi devrait ressembler la déclaration controls, y compris les options diverses qui peuvent ne peuvent être utilisées qu'avec elle.

• include "<file-name>" — Comprend le fichier spécifié dans le fichier de configuration en cours, permettant de placer des données de configuration sensibles (comme keys) dans un fichier séparé avec des permissions qui empêchent les utilisateurs sans privilèges de les lire.

• key "<key-name>" — Définit une clé par son nom. Les clés servent à valider diverses actions, comme les mises à jour sécurisées ou l'utilisation de la commande rndc. Deux options sont utilisées avec key :

  • algorithm <algorithm-name> — Le type d'algorythme utilisé, comme dsa ou hmac-md5.

  • secret "<key-value>" — La clé cryptée.

  Vous trouverez dans la Figure 14-22 un exemple de la déclaration key.

• logging — Permet d'utiliser de multiples types de logs, appelés des channels. En utilisant l'option channel dans la déclaration logging, vous pouvez construire un type de log personnalisé, avec son propre nom de fichier (file), sa limite de taille (size), sa version (version) et son niveau d'importance (severity). Une fois qu'un canal personnalisé a été défini, une option category est utilisée pour qualifier le canal et commencer le logging lorsque named est redémarré.

  Par défaut, named envoie des messages de log standards au démon syslog, qui les place dans /var/log/messages. Cela est dû au fait que plusieurs canaux standards sont compris dans BIND, avec plusieurs niveaux d'importance, comme celui qui traite les messages de logging informationnels (default_syslog) et celui qui traite spécifiquement les messages de débogage (default_debug). Une catégorie par défaut, appelée default, utilise les canaux compris dans BIND pour accomplir le logging normal sans configuration spéciale.

  La personnalisation du processus de logging peut être un processus très détaillé et cela dépasse le cadre du présent chapitre. Pour obtenir plus d'informations sur la création de logs personnalisés dans BIND, consultez le BIND 9 Administrator Reference Manual.

• options — assigne des valeurs à de nombreuses options liées, y compris des commandes pour faire suivre, l'emplacement du dossier de fonctionnement de named, le nom de divers fichiers et bien plus.

  Les options suivantes sont parmi les plus couramment utilisées :

  • allow-query — Spécifie les hôtes qui seront autorisés à entamer des requêtes auprès de ce serveur de noms. Par défaut, tous les hôtes sont autorisés à présenter des requêtes. Ici une liste de contrôle d'accès ou collection d'adresses IP peut être utilisée pour n'autoriser que certains hôtes à entamer des requêtes auprès du serveur de noms.

  • allow-recursion — Similaire à l'option allow-query, si ce n'est qu'elle s'applique à des requêtes récursives. Par défaut, tous les hôtes sont autorisés à présenter des requêtes récursives auprès du serveur de noms.

  • directory — Transforme le dossier de fonctionnement de named en autre chose que le dossier par défaut /var/named.

  • forward — Contrôle la façon de faire suivre, si l'option forwarders contient des adresses IP valides désignant où envoyer les requêtes.

    Si l'option first est utilisée, alors les serveurs de noms spécifiés dans l'option forwarders font l'objet des premières requêtes d'informations. S'ils ne les possèdent pas, named va tenter la résolution lui-même.

    Si l'option only est utilisée, named ne tentera pas la résolution lui-même si les serveurs de noms pour faire suivre ont échoué.

  • forwarders — Spécifie une liste de serveurs de noms vers lesquels il faut faire suivre les requêtes pour résolution.

  • listen-on — Spécifie l'interface de réseau que named va utiliser pour percevoir les requêtes. Par défaut, toutes les interfaces sont utilisées.

    Cette option est utile si vous disposez de plusieurs interfaces de réseau et voulez limiter les systèmes qui peuvent effectuer des requêtes auprès de votre serveur de noms. Par exemple, si votre ordinateur sert de portail et de serveur de noms et que vous voulez bloquer toutes les requêtes exceptées celles qui proviennent de votre réseau privé, votre option listen-on devrait ressembler à Figure 14-4.

    options { listen-on { 10.0.1.1; }; };

    Figure 14-4. Exemple d'option listen-on

    De cette manière, seules les requêtes qui proviennent de l'interface de réseau servant le réseau privé (10.0.1.1) seront acceptées.

  • notify — Détermine si named envoie notification aux serveurs esclaves quand une zone est mise à jour. Par défaut le choix est yes, mais vous pouvez régler sur no, pour n'envoyer de notification qu'aux serveurs de la liste also-notify.

  • pid-file — Vous permet de spécifier l'emplacement du fichier de processus ID créé par named lorsqu'il démarre.

  • statistics-file — Vous permet de spécifier l'emplacement du fichier de statistiques qui est créé. Par défaut, les statistiques de named sont enregistrées dans /var/named/named.stats.

  De nombreuses autres options sont également disponibles, dont beaucoup dépendant l'une de l'autre pour fonctionner correctement. Consultez le BIND 9 Administrator Reference Manual pour plus de détails.

• server — Définit des options particulières qui affectent la façon dont named doit se comporter envers les serveurs de noms distants, particulièrement en ce qui concerne les notifications et les transferts de zone.

  L'option transfer-format détermine si un enregistrement de ressource est envoyé avec chaque message (one-answer) ou si des enregistrements de ressource multiples sont envoyés avec chaque message (many-answers). Bien que many-answers soit plus efficace, seuls les plus récents serveurs de noms BIND peuvent la comprendre.

• trusted-keys — Contient des clés publiques assorties utilisées pour DNSSEC. Consultez la la section intitulée Sécurité pour une introduction à la sécurité sous BIND.

• view "<view-name>" — Crée des vues spéciales qui répondent par un type d'informations particulier selon l'hôte qui contacte le serveur de noms. Ceci permet à certains hôtes de recevoir une réponse concernant une zone particulière pendant que d'autres hôtes reçoivent des informations totalement différentes. Alternativement, certains hôtes peuvent se voir accorder l'accès à certaines zones alors que les autres hôtes non autorisés continuent à effectuer des requêtes pour d'autres zones.

  Vous pouvez utiliser de multiples view, pour autant que leurs noms soient uniques. L'option match-clients spécifie les adresses IP qui s'appliquent à une vue particulière. Toute déclaration option peut aussi être utilisée dans une vue, avec priorité sur les options globales déjà configurées pour named. La plupart des déclarations view contiennent de multiples déclarations zone qui s'appliquent à la liste match-clients. L'ordre dans lequel les déclarations view sont listées est important, puisque c'est la première déclaration view qui correspond à l'adresse IP d'un client qui est utilisée.

  Consultez la la section intitulée Vues multiples pour obtenir plus d'informations sur la déclaration view.

• zone "<zone-name>" — Spécifie des zones particulières pour lesquelles ce serveur de noms fait autorité. La déclaration zone est surtout utilisée pour spécifier le fichier contenant la configuration de la zone et transmettre certaines options concernant cette zone à named. Ces options auront la priorité sur la totalité des autres déclarations option situées dans /etc/named.conf.

  Le nom de la zone est important, puisqu'il constitue la valeur par défaut assignée à la directive $ORIGIN utilisée dans le fichier zone et qu'il est lié aux non-FQDN. Par exemple, si cette déclaration zone définit l'espace de nom pour domain.com, il faut utiliser domain.com en tant que <zone-name> pour qu'il soit placé à la fin des noms d'hôtes utilisés dans le fichier de zone.

  Les options les plus courantes de la déclaration zone comprennent :

  • allow-query — Spécifie les clients qui sont autorisés à requérir des informations à propos de cette zone. Par défaut toutes les requêtes d'informations sont autorisées.

  • allow-transfer — Spécifie les serveurs esclaves qui sont autorisés à requérir un transfert des informations de la zone. Par défaut toutes les requêtes de transfert sont autorisées.

  • allow-update — Spécifie les hôtes qui sont autorisés à mettre à jour dynamiquement des informations dans leur zone. Par défaut aucune requête de mise à jour dynamique n'est autorisée.

    	Attention
    	Soyez très prudent lorsque vous autorisez des hôtes à mettre à jour des informations à propos de leur zone. Ne mettez en oeuvre cette option que si vous accordez une confiance absolue à l'hôte. C'est une bien meilleure idée de laisser un administrateur mettre à jour manuellement les enregistrements de la zone et recharger le service named, si possible.

  • file — Spécifie le nom du fichier qui contient les données de configuration de la zone dans le dossier de fonctionnement de named (par défaut /var/named).

  • masters — Utilisée si la zone est définie comme de type esclave. L'option masters indique au named d'un esclave la(les) adresse(s) d'où l'on peut requérir des informations de zone.

  • notify — Fonctionne de manière similaire à l'option notify utilisée avec la déclaration option.

  • type — Définit le type de zone. Les types suivants peuvent être utilisés :

    • forward — Dit au serveur de noms de faire suivre toutes les requêtes d'informations à propos de cette zone vers d'autres serveurs de noms.

    • hint — Un type spécial de zone qui est utilisé pour orienter vers les serveurs de noms racines, servant à résoudre des requêtes lorsqu'une zone n'est pas connue par ailleurs. Normalement vous n'aurez pas besoin de configurer une zone d'indication au-delà du /etc/named.conf par défaut.

    • master — Désigne le serveur de noms présent comme faisant autorité pour cette zone. Une zone devrait être configurée comme de type master si vous possédez les fichiers de configuration de la zone sur le présent système.

    • slave — Désigne le serveur de nomsprésent comme serveur esclave pour cette zone, disant à named de requérir les fichiers de configuration de la zone depuis l'adresse IP du serveur de noms maître pour cette zone.

  • zone-statistics — Dit à named de conserver des statistiques concernant cette zone, en les écrivant soit dans l'emplacement par défaut (/var/named/named.stats), soit à l'emplacement expressément désigné par l'option statistics-file dans la déclaration server, s'il existe.

zone "domain.com" IN {
  type master;
  file "domain.com.zone";
  allow-update { none; };
};

zone "domain.com" {
  type slave;
  file "domain.com.zone";
  masters { 192.168.0.1; };
};

Zone Files

Les fichiers de zone qui contiennent des informations sur un espace de nom particulier sont stockés dans le dossier de fonctionnement de named, qui est par défaut /var/named. Chaque fichier de zone est nommé selon les données d'options de file dans la déclaration zone, généralement d'une manière qui se réfère au domaine en question et identifie le fichier comme contenant des données de zone, comme example.com.zone.

Chaque fichier de zone peut contenir des directives et enregistrements de ressources. Les directives disent au serveur de noms d'effectuer un certain acte ou d'appliquer une configuration spéciale à la zone. Les enregistrements de ressources définissent les paramètres de la zone, assignant une identité à des systèmes à l'intérieur de l'espace de nom de la zone. Les directives sont facultatives, mais les enregistrements de ressources sont requis pour fournir un service de noms à cette zone. Toutes les directives et enregistrements de ressources doivent se situer sur leur propre ligne.

Des commentaires peuvent être placés dans les fichiers de zone après les caractères point-virgules (;).

$ORIGIN domain.com
$TTL 86400
@     IN     SOA    dns1.domain.com.     hostmaster.domain.com. (
                    2001062501 ; serial
                    21600      ; refresh after 6 hours
                    3600       ; retry after 1 hour
                    604800     ; expires after 1 week
                    86400 )    ; minimum TTL of 1 day

      IN     NS     dns1.domain.com.
      IN     NS     dns2.domain.com.

      IN     MX     10     mail.domain.com.
      IN     MX     20     mail2.domain.com.

             IN     A       10.0.1.5

server1      IN     A       10.0.1.5
server2      IN     A       10.0.1.7
dns1         IN     A       10.0.1.2
dns2         IN     A       10.0.1.3

ftp          IN     CNAME   server1
mail         IN     CNAME   server1
mail2        IN     CNAME   server2
www          IN     CNAME   server2

<last-IP-digit>      IN     PTR    <FQDN-of-system>

$ORIGIN 1.0.10.in-addr.arpa
$TTL 86400
@     IN     SOA    dns1.domain.com.     hostmaster.domain.com. (
                    2001062501 ; serial
                    21600      ; refresh after 6 hours
                    3600       ; retry after 1 hour
                    604800     ; expire after 1 week
                    86400 )    ; minimum TTL of 1 day

      IN     NS     dns1.domain.com.
      IN     NS     dns2.domain.com.

20    IN     PTR    alice.domain.com.
21    IN     PTR    betty.domain.com.
22    IN     PTR    charlie.domain.com.
23    IN     PTR    doug.domain.com.
24    IN     PTR    ernest.domain.com.
25    IN     PTR    fanny.domain.com.

zone "1.0.10.in-addr.arpa" IN {
  type master;
  file "domain.com.rr.zone";
  allow-update { none; };
};