SupportConsoleDéveloppeursCommencer un essaiContact

11.2. BIND

Cette section porte sur le serveur BIND (Berkeley Internet Name Domain), le serveur DNS inclus dans Red Hat Enterprise Linux. Elle est orientée sur la structure de ses fichiers de configuration, et décrit comment les administrer à la fois localement et à distance.

11.2.1. Zones vides

BIND configure un certain nombre de « zones vides » afin d'empêcher des serveurs récursifs d'envoyer des requêtes inutiles vers des serveurs Internet qui ne peuvent pas les gérer (créant ainsi des retards et des réponses SERVFAIL aux clients qui les interrogent). Ces zones vides veillent à ce que les réponses NXDOMAIN immédiates et faisant autorités soient retournées à la place. L' option de configuration vide-zones-enable détermine si oui ou non les zones vides sont créées, tandis que l'option disable-vide-zone peut servir à désactiver une ou plusieurs zones vides dans la liste des préfixes par défaut, qui est utilisée.
Le nombre d'espaces vides créés pour les préfixesRFC 1918 a augmenté, et les utilisateurs de BIND 9.9 et versions ultérieures, verront des espaces vides RFC 1918 à la fois quand empty-zones-enable n'est pas spécifié (valeur par défaut yes), ou quand RFC 1918 est défini à yes.

11.2.2. Configuration du service «named»

Quand le service named démarre, il lit la configuration à partir des fichiers décrits dans Tableau 11.1, « Les fichiers de configuration du service «named» ».
Tableau 11.1. Les fichiers de configuration du service «named»
CheminDescription
/etc/named.confFichier de configuration principal.
/etc/named/Répertoire auxiliaire pour les fichiers de configuration inclus dans le fichier de configuration principal.
Le fichier de configuration consiste en un ensemble d'arguments comprenant des options imbriquées entourées par des crochets courbes ({ et }). Veuillez noter que si vous modifiez le fichier, le service named ne démarrera pas. Un fichier/etc/named.conf se présente ainsi : 
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;
};

Note

Si vous avez installé le paquet bind-chroot, le service de liaison exécutera dans l'environnement chroot. Dans ce cas, le script d'initialisation procédera au montage des fichiers de configuration ci-dessus à l'aide de la commande mount--bind, afin que vous puissiez contrôler la configuration en dehors de cet environnement. Il n'y a pas besoin de copier quoi que ce soit dans le répertoire /var/named/chroot/ parce qu'elle est montée automatiquement. Cela simplifie la maintenance puisque vous n'avez pas besoin de prendre un soin particulier des fichiers de configuration BIND si la commande est exécutée dans un environnement chroot. Vous pouvez tout organiser comme vous le feriez avec BIND si vous n'étiez pas dans un environnement chroot.
Les répertoires suivants sont montés automatiquement sur /var/named/chroot/ si les répertoires de point de montage correspondants qui se trouvent sous /var/named/chroot/ sont vides :
  • /etc/named
  • /etc/pki/dnssec-keys
  • /run/named
  • /var/named
  • /usr/lib64/bind ou /usr/lib/bind (suivant l'architecture).
Les fichiers suivants sont également montés si le fichier cible n'existe pas dans /var/named/chroot/ :
  • /etc/named.conf
  • /etc/rndc.conf
  • /etc/rndc.key
  • /etc/named.rfc1912.zones
  • /etc/named.dnssec.keys
  • /etc/named.iscdlv.key
  • /etc/named.root.key

Important

Pour modifier des fichiers qui ont été montés dans un environnement chroot, vous devrez créer une copie de sauvegarde, puis modifier le fichier d'origine. Sinon, utiliser un éditeur avec le mode « edit-a-copy » désactivé. Ainsi, pour modifier le fichier de configuration de BIND, /etc/named.conf, avec Vim quand il exécute dans un envirionnement chroot, veuillez exécuter la commande suivante en tant qu'utilisateur root : 
~]# vim -c "set backupcopy=yes" /etc/named.conf

11.2.2.1. Installation de BIND dans un envirionnement chroot

Pour installer BIND pour qu'il exécute dans un environnement chroot, veuillez exécuter la commande suivante en tant qu'utilisateur root : 
~]# yum install bind-chroot
Pour activer le service named-chroot, commencez par vérifier que le service named est en cours d'exécution en lançant la commande suivante : 
~]$ systemctl status named
S'il est en cours d'exécution, il doit être désactivé.
Pour déactiver le service chronyd, veuillez exécuter la commande suivante en tant qu'utilisateur root : 
~]# systemctl stop named
~]# systemctl disable named
Puis, pour déactiver le service named-chroot, veuillez exécuter les commandes suivantes en tant qu'utilisateur root : 
~]# systemctl enable named-chroot
~]# systemctl start named-chroot
Pour vérifier le statut du service named-chroot, veuillez exécuter les commandes suivantes en tant qu'utilisateur root : 
~]# systemctl status named-chroot

11.2.2.2. Types d'arguments communs

Les types d'arguments suivants sont souvent utilisés dans /etc/named.conf :
acl
L'argument acl (Access Control List) vous permet de définir des groupes d'hôtes, de façon à ce qu'ils aient accès ou non au serveur de noms. Prend la forme suivante : 
acl acl-name {
  match-element;
  ...
};
Le nom d'argumentacl-name correspond au nom de la liste de contrôle d'accès, et l'option match-element correspond normalement à une adresse IP individuelle (comme 10.0.1.1) ou à une notation de réseau Classless Inter-Domain Routing (CIDR) (par exemple, 10.0.1.0/24). Pour obtenir une liste de mots clés déjà pré-définis, voir Tableau 11.2, « Listes de contrôle d'accès pré-définies ».
Tableau 11.2. Listes de contrôle d'accès pré-définies
Mot-cléDescription
anyFait correspondre chaque adresse IP.
localhostFait correspondre chaque adresse IP utilisée par le système local.
localnetsFait correspondre chaque adresse IP sur n'importe quel réseau connecté au système local.
noneNe correspond à aucune adresse IP.
L'argument acl peut être particulièrement utile s'il est utilisé en conjonction à d'autres arguments tels que options. Exemple 11.2, « Utilisation d'acl en conjonction aux options » définit deux listes de contrôle d'accès, black-hats et red-hats, et ajoute black-hats à la liste noire tout en donnant l'accès normal red-hats.

Exemple 11.2. Utilisation d'acl en conjonction aux options

acl black-hats {
  10.0.2.0/24;
  192.168.0.0/24;
  1234:5678::9abc/24;
};
acl red-hats {
  10.0.1.0/24;
};
options {
  blackhole { black-hats; };
  allow-query { red-hats; };
  allow-query-cache { red-hats; };
};
include
L'argument include vous permet d'inclure des fichiers dans /etc/named.conf, de façon à ce que des données pouvant être sensibles puissent être mises dans un fichier séparé sans limitation de permissions. Prend la forme suivant : 
include "file-name"
L'argument file-name est un nom d'argument qui se trouve dans un chemin d'accès complet de fichier.

Exemple 11.3. Inclure un fichier dans /etc/named.conf

inclure "/etc/named.rfc1912.zones";
options
L'argument options vous permet de définir des options de configuration du serveur global, ainsi que de définir les valeurs par défaut d'autres arguments. Il peut être utilisé pour spécifier l'emplacement du répertoire de travail de named, les types de requêtes autorisées et bien plus encore. Il prend la forme suivante : 
options {
  option;
  ...
};
Pour obtenir une liste des possibilités d'option les plus communément utilisées, consulter le tableau ci-dessous Tableau 11.3, « Options de configuration souvent utilisées ».
Tableau 11.3. Options de configuration souvent utilisées
OptionDescription
allow-querySpécifie quels hôtes sont autorisés à interroger le serveur de noms pour les enregistrements de ressources de référence. Il accepte une liste de contrôle d'accès, une collection d'adresses IP, ou des réseaux dans la notation CIDR. Par défaut, tous les hôtes sont autorisés.
allow-query-cacheIndique quels hôtes sont autorisés à interroger le serveur de noms pour des données ne faisant pas autorité, comme les requêtes récursives. Par défaut, seuls les localhost et localnets sont autorisés.
blackholeIndique les hôtes non autorisés à interroger le serveur de noms. Cette option doit être utilisée lorsqu'un hôte particulier ou qu'réseau inonde le serveur de demandes. L'option par défaut est none.
directoryIndique un répertoire de travail pour le service named. L'option par défaut est /var/named/.
disable-empty-zoneUtilisé pour désactiver une ou plusieurs des zones vides de la liste des préfixes par défaut qui pourraient être utilisés. Peut être spécifié dans les arguments d'options et également dans les arguments de vues. Il peut être utilisé à plusieurs reprises.
dnssec-enableIndique si l'on doit retourner aux enregistrements de ressources liées à DNSSEC. L'option par défaut est yes.
dnssec-validationIndique si l'on doit prouver que les enregistrements de ressources sont authentiques via DNSSEC. L'option par défaut est yes.
empty-zones-enableContrôle si les zones vides sont créées ou non. Ne peut être spécifié que dans les arguments d'options.
forwardersIndique une liste d'adresses IP pour les serveurs de noms vers lesquels les requêtes doivent être redirigées pour qu'elles soient résolues.
forward
Indique le comportement de la directive forwarders. Accepte les options suivantes :
  • first — Le serveur va vérifier les serveurs de noms énumérés dans la directive forwarders avant de tenter de résoudre le nom par lui-même.
  • only — Quand on ne peut pas vérifier les serveurs de noms éumérés dans la directive forwarders, le serveur ne tentera pas de résoudre le nom par lui-même.
listen-onIndique l'interface de réseau IPv4 sur lequel écouter les requêtes. Sur un serveur DNS, qui agit aussi comme une passerelle, vous pouvez utiliser cette option pour répondre à des requêtes provenant d'un réseau uniquement. Toutes les interfaces IPv4 sont utilisées par défaut.
listen-on-v6Indique l'interface de réseau IPv6 sur lequel écouter pour les requêtes. Sur un serveur DNS qui agit aussi en tant quepasserelle, vous pouvez utiliser cette option pour répondre à des requêtes provenant d'un seul réseau. Toutes les interfaces IPv6 sont utilisées par défaut.
max-cache-sizeIndique la quantité maximale de mémoire à utiliser pour les caches de serveurs. Lorsque la limite est atteinte, le serveur entraîne l'expiration prémature des enregistrements, alors que la limite n'est pas dépassée. Sur un serveur avec plusieurs vues, la limite s'appliquera séparément dans le cache de chaque vue. L'option par défaut est 32M.
notify
Indique si on doit notifier les serveurs de noms secondaires quand une zone est mise à jour. Accepte les options suivantes :
  • yes — le serveur notifiera tous les serveurs de noms secondaires.
  • no — le serveur ne notifiera aucun serveur de noms secondaire.
  • master-only — le serveur notifiera un serveur primaire pour cette zone uniquement.
  • explicit — le serveur ne notifiera que les serveurs secondaires spécifiés dans la liste also-notify dans un argument de zone.
pid-fileIndique l'emplacement du fichier d'ID de processus créé par le service named.
recursionIndique comportement de serveur récurvif ou non. L'option par défaut est yes.
statistics-fileIndique un emplacement spécifique pour les fichiers de statistiques. Le fichier /var/named/named.stats est utilisé par défaut.

Note

Le répertoire utilisé par named pour les données de runtime a été déplacé de l'emplacement par défaut de BIND, /var/run/nom /, à un nouvel emplacement /run/name/. Ainsi, le fichier PID a été déplacé de l'emplacement par défaut /var/run/named/named.pid au nouvel emplacement /run/named/named.pid. De plus, le fichier de clés de session a été déplacé à /run/named/session.key. Ces emplacements devront être précisés par les arguments de la section options. Voir Exemple 11.4, « Utiliser l'argument « option » ».

Important

Pour éviter les attaques DDoS (de l'anglais, distributed denial of service), nous vous conseillons d'utiliser l'option allow-query-cache pour limiter l'accès aux services DNS récursifs à quelques groupes de clients particuliers.
Voir le BIND 9 Administrator Reference Manual référencé dans Section 11.2.8.1, « Documentation installée », et la page man named.conf pour obtenir une liste complète des options.

Exemple 11.4. Utiliser l'argument « option »

options {
  allow-query       { localhost; };
  listen-on port    53 { 127.0.0.1; };
  listen-on-v6 port 53 { ::1; };
  max-cache-size    256M;
  directory         "/var/named";
  statistics-file   "/var/named/data/named_stats.txt";

  recursion         yes;
  dnssec-enable     yes;
  dnssec-validation yes;

  pid-file          "/run/named/named.pid";
  session-keyfile   "/run/named/session.key";
};
zone
L'argument zone vous permet de définir les caractéristiques d'une zone, comme l'emplacement de son fichier de configuration et les options spécifiques à la zone, et il peut être utilisé en remplacement aux arguments d'options. Il prend la forme suivante : 
zone zone-name [zone-class] {
  option;
  ...
};
L'attribut zone-name correspond au nom de la zone, zone-class correspond à la classe optionnelle de zone, et option correspond à une option d'argument de zone comme expliqué dans Tableau 11.4, « Options couramment utilisées comme arguments de zone ».
L'attribut zone-name est particulièrement important, car il correspond à la valeur par défaut assignée à la directive $ORIGIN utilisée dans le fichier de zone correspondant qui se trouve dans le répertoire /var/named/. Le démon named ajoute le nom de la zone à n'importe quel nom de domaine incomplet répertorié dans le fichier de zone. Par exemple, si un argument de zone définit l'espace de noms pour example.com, utilisez example.com comme zone-name pour qu'il soit placé à la fin des noms d'hôte dans le fichier de zone example.com.
Pour obtenir plus d'informations sur les fichiers de zone, consulter Section 11.2.3, « Conflits de fichiers ».
Tableau 11.4. Options couramment utilisées comme arguments de zone
OptionDescription
allow-queryIndique quels clients sont autorisés à demander des informations sur cette zone. Cette option prévaut sur l'option globale allow-query. Tous les demandes de requête sont autorisées par défaut.
allow-transferIndique les serveurs secondaires qui sont autorisés à demander un transfert de l'information de zone. Toutes les requêtes de transfert sont autorisées par défaut.
allow-update
Indique quels hôtes sont autorisés à mettre leurs informations à jour de façon dynamique dans leur zone. L'option par défaut est de refuser toutes les demandes de mise à jour dynamiques.
Notez que vous devez être prudents lorsque vous autorisez les clients à mettre à jour des informations sur leur zone. Ne définissez pas les adresses IP dans cette option à moins que le serveur soit dans un réseau fiable. À la place, utiliser la clé TSIG décrite dans Section 11.2.6.3, « TSIG (Transaction SIGnatures) ».
fileIndique le nom du fichier qui se trouve dans le répertoire de travail named qui contient les données de configuration de la zone.
mastersIndique à partir de quelles adresses IP on peut demander des informations de zone autoritatives. Cette option n'est utilisée que si la zone est définie en tant que type slave.
notify
Indique si on doit notifier les serveurs de noms secondaires quand une zone est mise à jour. Accepte les options suivantes :
  • yes — le serveur va notifier tous les serveurs de noms secondaires.
  • no — le serveur ne notifiera aucun serveur de noms secondaires.
  • master-only — le serveur ne notifiera le serveur primaire que pour la zone.
  • explicit — le serveur ne notifiera que les serveurs secondaires spécifiés dans la liste also-notify dans l'argument de zone.
type
Indique le type de zone. Accepte les options suivantes :
  • delegation-only — active le statut de délégation de zones d'infrastructures comme COM, NET, ou ORG. Toute réponse reçue sans délégation implicite ou explicite sera traitée comme NXDOMAIN. Cette option ne s'applique qu'aux niveaux TLDs (Top-Level Domain) ou pour les fichiers de zone racine pour les implémentations en cache ou récursives.
  • forward — transfère toutes les demandes d'informations de cette zone vers d'autres serveurs de noms.
  • hint — un type particulier de zone utilisée pour pointer vers les serveurs de noms racine qui résolvent les requêtes lorsqu'une zone n'est pas connue par ailleurs. Aucune configuration au-delà de la valeur par défaut n'est nécessaire dans une zone hint (astuce).
  • master — indique le serveur de noms comme étant le serveur faisant autorité pour cette zone. Une zone doit être définie comme master si les fichiers de configuration de la zone se trouvent sur le système.
  • slave — désigne le serveur de noms comme serveur esclave de la zone. Le serveur maître est spécifié dans la directive masters.
La plupart des changements au fichier /etc/named.conf d'un serveur de noms primaire ou secondaire consistent à ajouter, modifier ou supprimer des arguments de zone, et seul un petit nombre d'options d'arguments de zone est normalement utile pour qu'un serveur de noms puisse fonctionner efficacement.
Dans Exemple 11.5, « Argument de zone pour un serveur de noms primaire », la zone est identifiée comme example.com, le type est défini sur le master et le service named est chargé de lire le fichier /var/named/example.com.zone. Il permet également à un serveur de noms secondaire (192.168.0.2) uniquement de transférer la zone.

Exemple 11.5. Argument de zone pour un serveur de noms primaire

zone "example.com" IN {
  type master;
  file "example.com.zone";
  allow-transfer { 192.168.0.2; };
};
L'argument de zone d'un serveur secondaire est légèrement différent. Le type est défini sur l'esclave, et la directive du master indique au service named l'adresse IP du serveur maître.
Dans Exemple 11.6, « Un argument de zone pour le serveur de noms secondaire », le service named est configuré pour interroger le serveur principal à l'adresse IP 192.168.0.1 pour obtenir des informations sur la zone example.com. L'information reçue est alors enregistrée dans le fichier /var/named/slaves/example.com.zone. Notez que vous devez mettre toutes les zones esclave dans le répertoire /var/named/esclaves /, sinon le service ne pourra pas transférer la zone.

Exemple 11.6. Un argument de zone pour le serveur de noms secondaire

zone "example.com" {
  type slave;
  file "slaves/example.com.zone";
  masters { 192.168.0.1; };
};

11.2.2.3. Autres types d'arguments

Les types d'arguments suivants sont moins souvent utilisés dans /etc/named.conf :
controls
L'argument controls vous permet de configurer les diverses exigences de sécurité avant d'utiliser la commande rndc qui sert à administrer le service named.
Reportez-vous à Section 11.2.4, « Comment se servir de l'utilitaire rndc » pour obtenir plus d'informations sur l'utilitaire rndc et la façon de l'utiliser.
key
L'argument key vous permet de définir une clé particulière par son nom. Les clés sont utilisées pour authentifier les différentes actions, telles que les mises à jour sécurisées ou l'utilisation de la commande rndc. Deux options sont utilisées avec l'argument key :
  • algorithm algorithm-name — le type d’algorithme à utiliser (par exemple, hmac-md5).
  • secret "key-value" — la clé cryptée.
Reportez-vous à Section 11.2.4, « Comment se servir de l'utilitaire rndc » pour obtenir plus d'informations sur l'utilitaire rndc et la façon de l'utiliser.
logging
L'argument logging vous permet d'utiliser plusieurs types de journaux, appelés canaux. En utilisant l'option channel dans l'argument, vous pouvez construire un type personnalisé du journal avec son propre nom de fichier (file), une limite de taille (taille), un numéro de version (version) et un niveau d'importance (gravité). Une fois qu'un canal (channel) personnalisé est défini, une option catégorie est utilisée pour catégoriser le canal et commencer la journalisation lorsque le service named démarre à nouveau.
Par défaut, le service named envoie des messages standards au démon rsyslog, qui les place dans /var/log/messages. Plusieurs canaux standards sont intégrés dans BIND selon les niveaux de gravité, comme default_syslog (qui gère les messages de journalisation d'information) et default_debug (qui gère spécifiquement les messages de débogage). Une catégorie par défaut, appelée par défaut, utilise les canaux intégrés afin d'effectuer une journalisation normale sans aucune configuration spéciale.
Personnaliser le processus de journalisation peut être un processus très détaillé, qui dépasse le cadre du présent chapitre. Pour obtenir des informations sur la création de journaux BIND personnalisés, consultez le guide BIND 9 Administrator Reference Manual référencé dans Section 11.2.8.1, « Documentation installée ».
server
L'argument server vous permet de spécifier des options qui affectent comment le service named doit répondre à des serveurs de noms éloignés, surtout au niveau notifications et transferts de zones.
L'option transfer-format contrôle le nombre d'enregistrements de ressources qui sont envoyées avec chaque message. Il peut être one-answer (enregistrement d'une seule ressource) ou many-answers (plusieurs enregistrements de ressources). Notez que bien l'option many-answers soit plus efficace, elle n'est pas supportée par les anciennes versions de BIND.
trusted-keys
L'argument trusted-keys vous permet d'indiquer des clés publiques assorties utilisées pour sécuriser le protocole DNS (DNSSEC). Voir Section 11.2.6.4, « DNSSEC (DNS Security Extensions ) » pour obtenir plus d'informations à ce sujet.
view
L'argument view vous permet de créer des affichages spéciaux selon le réseau sur lequel l'hôte qui interroge le serveur se trouve. Cela permet à certains hôtes de recevoir une réponse concernant une zone tandis que les autres hôtes reçoivent des informations totalement différentes. Par ailleurs, certaines zones ne peuvent être rendues disponibles qu'aux hôtes de confiance, tandis que les hôtes non approuvés ne peuvent effectuer des requêtes que pour d'autres zones.
Des vues multiples peuvent être utilisées tant que leurs noms sont uniques. L'option match-clients (correspondance client) vous permet de spécifier les adresses IP qui s'appliquent à une vision particulière. Si l'argument options est utilisé dans une vue, il remplacera les options globales déjà configurées. Enfin, la plupart des arguments de view contiennent plusieurs arguments de zone qui s'appliquent à la liste de match-clients.
Notez que l'ordre dans lequel les arguments de view sont listés est important, car le premier argument qui correspond à une adresse IP de client particulier sera utilisée. Pour plus d'informations sur ce sujet, voir Section 11.2.6.1, « Vues multiples ».

11.2.2.4. Balises de commentaires

En plus des arguments, le fichier /etc/named.conf peut également contenir des commentaires. Les commentaires peuvent être ignorés par le service named, mais peuvent se révéler utiles quand on donne des informations supplémentaires à un utilisateur. Voici des balises de commentaires valides :
//
Tout texte se trouvant après // en fin de ligne est considéré comme un commentaire seulement. Exemple : 
notify yes;  // notifie tous les serveurs de noms secondaires
#
Tout texte se trouvant après # en fin de ligne est considéré comme un commentaire seulement. Exemple : 
notify yes;  # notifie tous les serveurs de noms secondaires
/* et */
Tout bloc de texte se trouvant entre /* et */ est considéré comme un commentaire. Exemple : 
notify yes;  /* notifie tous les serveurs de noms secondaires */

11.2.3. Conflits de fichiers

Comme indiqué dans Section 11.1.1, « Zones de noms de serveurs », les fichiers de zone contiennent des informations sur un espace de noms. Ils sont stockés dans le répertoire de travail named situé dans /var/named/ par défaut. Chaque fichier de zone est nommé selon l'option de fichier dans l'argument zone, habituellement d'une manière qui porte sur le domaine et qui identifie le fichier comme contenant des données de zone, comme example.com.zone.
Tableau 11.5. Les fichiers de zones de service « named »
CheminDescription
/var/named/Le répertoire de travail du service named. Le serveur de noms n'est pas autorisé à écrire dans ce répertoire.
/var/named/slaves/Le répertoire de zones secondaires. Ce répertoire peut contenir des écritures du service named.
/var/named/dynamic/Le répertoire pour les autres fichiers, comme les zones dynamiques DNS (DDNS) ou les clés DNSSEC gérées. Ce répertoire est accessible en écriture par le service named.
/var/named/data/Le répertoire de statistiques variées et de fichiers de débogage. Ce répertoire peut contenir des écritures du service named.
Un fichier de zone se compose d'enregistrements de ressources et de directives. Les directives instruisent le serveur de noms à effectuer des tâches ou à appliquer des paramètres de configuration particuliers à la zone. Les enregistrements de ressources définissent les paramètres de la zone et attribuent des identités aux hôtes individuels. Bien que les directives soient facultatives, les enregistrements de ressources sont utiles pour procurer un service de nommage à une zone.
Toutes les direcives et les enregistrements de noms doivent être saisis sur des lignes individuelles.

11.2.3.1. Directives communes

Les directives commencent par le signe ($) et sont suivies par le nom de la directive, qui apparaît normalement en haut du fichier. Les directives suivantes sont couramment utilisées dans les fichiers de zone :
$INCLUDE
La directive $INCLUDE vous permet d'inclure un autre fichier là où il se trouve, de façon à ce que les autres paramètres de configuration de zone puissent être stockés dans un fichier de zone séparé.

Exemple 11.7. Utilisation de la directive $INCLUDE

$INCLUDE /var/named/penguin.example.com
$ORIGIN
La directive $ORIGIN vous permet d'ajouter le nom de domaine aux enregistrements non qualifiés, comme ceux qui ont un nom d'hôte uniquement. Notez que l'utilisation de cette directive n'est pas nécessaire si la zone est spécifiée dans /etc/named.conf, puisque la zone est utilisée par défaut.
Dans Exemple 11.8, « Utilisation de la directive $ORIGIN », tous les noms utilisés dans les enregistrements de ressources ne se terminant pas par un point final (le signe .) se terminent par example.com.

Exemple 11.8. Utilisation de la directive $ORIGIN

$ORIGIN example.com.
$TTL
La directive $TTL vous permet de définir la valeur par défaut de Time to Live (TTL) pour la zone, autrement dit, combien de temps est un enregistrement de zone est valide. Chaque enregistrement de ressource peut avoir sa propre valeur TTL, qui se substitue à la cette directive.
Augmenter cette valeur permet aux serveurs de noms distants de mettre les informations de zone en cache pour une plus longue période, réduisant le nombre de requêtes pour la zone et allongeant ainsi l'intervalle de temps requis pour propager les modifications d'enregistrements de ressources.

Exemple 11.9. Utilisation de la directive $TTL

$TTL 1D

11.2.3.2. Enregistrements de ressources communs

Les enregistrements de ressources suivants sont couramment utilisés dans les fichiers de zone :
A
L'enregistrement Address indique l'adresse IP à assigner à un nom. Prend la forme suivante : 
hostname IN A IP-address
Si la valeur hostname est omise, l'enregistrement pointera vers le dernier hostname indiqué.
Dans Exemple 11.10, « Utiliser un enregistrement de ressource A », les requêtes de server1.example.com pointent vers 10.0.1.3 ou 10.0.1.5.

Exemple 11.10. Utiliser un enregistrement de ressource A

server1  IN  A  10.0.1.3
         IN  A  10.0.1.5
CNAME
L'enregistrement Canonical Name fait correspondre un nom à un autre. Pour cette raison, ce type d'enregistrement est souvent appelé alias record. Il prend la forme suivante : 
alias-name IN CNAME real-name
Les enregistrements CNAME sont plus couramment utilisés pour pointer vers des services qui utilisent un schéma d'affectation de noms, comme www pour les serveurs Web. Cependant, il existe plusieurs restrictions à leur utilisation :
  • Les enregistrements CNAME ne doivent pas pointer vers d'autres enregistrements CNAME, ceci, afin d'éviter des boucles à l'infini.
  • Les enregistrements CNAME ne doivent pas contenir d'autres types de ressources (comme A, NS, MX, etc.), excepté pour les enregistrements DNSSEC (RRSIG, NSEC, etc.) quand la zone est signée.
  • Les autres enregistrements de ressources qui pointent vers le nom de domaine complet (FQDN) d'un hôte (NS, MX, PTR) ne doivent pas pointer vers un enregistrement CNAME.
Dans Exemple 11.11, « Utiliser l'enregistrement de ressource CNAME », l'enregistrement A relie un nom d'hôte à une adresse IP, tandis que l'enregistrement CNAME y fait pointer le nom d'hôte commun www.

Exemple 11.11. Utiliser l'enregistrement de ressource CNAME

server1  IN  A      10.0.1.5
www      IN  CNAME  server1
MX
Le premier enregistrement Mail Exchange indique où le courrier envoyé à un espace nom particulier contrôlé par cette zone doit aller. Il est sous la forme suivante : 
IN MX preference-value email-server-name
L'email-server-name est un nom de domaine complet (FQDN). La preference-value permet un classement numérique des serveurs e-mail pour un espace de noms, donnant la préférence à certains systèmes de courrier électronique sur d'autres. L'enregistrement de ressource MX avec la plus faible preference-value sera privilégiée au détriment des autres. Toutefois, plusieurs serveurs de messagerie peuvent posséder la même valeur pour distribuer le trafic e-mail équitablement entre eux.
Dans Exemple 11.12, « Utilisation de l'enregistrement de ressource MX », le premier serveur d'emails mail.example.com sera préféré au serveur d'emails mail2.example.com pour recevoir des emails destinés au domaine example.com.

Exemple 11.12. Utilisation de l'enregistrement de ressource MX

example.com.  IN  MX  10  mail.example.com.
              IN  MX  20  mail2.example.com.
NS
L'enregistrement Nameserver indique les serveurs de noms qui font autorité pour une zone particulière. Il est sous la forme suivante : 
ssh username@penguin.example.net
Le nameserver-name doit correspondre à un nom complet (FQDN). Notez que quand deux noms de serveurs sont répertoriés comme étant autoritatifs pour un domaine, le fait qu'ils soient des serveurs de noms secondaires ou si l'un d'entre eux est un serveur primaire n'est pas important. Ils sont tous deux considérés comme faisant référence d'autorité.

Exemple 11.13. Utiliser l'enregistrement de ressource NS

IN  NS  dns1.example.com.
IN  NS  dns2.example.com.
PTR
L'enregistrement Pointer pointe vers une autre partie de l'espace nom. Prend la forme suivante : 
last-IP-digit IN PTR FQDN-of-system
La directive last-IP-digit correspond au dernier numéro d'une adresse IP, et le FQDN-of-system est un nom complet (FQDN).
Les enregistrements PTR sont principalement utilisés pour la résolution de noms inversés, car ils pointent vers des adresses IP qui renvoient à un nom particulier. Voir Section 11.2.3.4.2, « Un fichier de zone de résolution de noms inversés » pour obtenir des enregistrements PTR en cours d'utilisation.
SOA
L'enregistrement Start of Authority donne des informations importantes en matière d'autorité sur un espace nom ou un serveur de noms. Situé juste après la directive, c'est le premier enregistrement de ressource d'un fichier de zone. Prend la forme suivante : 
@  IN  SOA  primary-name-server hostmaster-email (
       serial-number
       time-to-refresh
       time-to-retry
       time-to-expire
       minimum-TTL )
Voici les directives :
  • Le symbole @ met la directive $ORIGIN (ou le nom de zone si la directive $ORIGIN n'est pas définie) comme espace nom défini par cet enregistrement SOA de ressource.
  • La directive primary-name-server est le nom d'hôte du serveur de noms primaire qui fait autorité pour ce domaine.
  • La directive hostmaster-email correspond à l'email de la personne à contacter au sujet de l'espace nom.
  • La directive serial-number est une valeur numérique incrémentée à chaque fois que le fichier de zone est altéré pour indiquer qu'il est temps que le service named charge la zone à nouveau.
  • La directive time-to-refresh est une valeur numérique que les serveurs de noms secondaires utilisent pour déterminer combien de temps il faut attendre avant de demander au serveur de noms primaire si des changements ont été apportés à la zone.
  • La directive time-to-retry est une valeur numérique utilisée par les serveurs de noms secondaires pour déterminer la durée à attendre avant d'émettre une demande d'actualisation, si le serveur de noms primaire ne répond pas. Si le serveur principal n'a pas répondu à une demande de rafraîchissement dans un délai spécifié dans la directive time-to-expire, les serveurs secondaires bloque d'autorité pour les demandes concernant cet espace de noms.
  • Dans BIND 4 et 8, la directive minimum-TTL est la durée pendant laquelle les autres serveurs cachent les informations de la zone. Dans BIND 9, elle définit combien de temps les réponses négatives sont mises en cache. La mise en cache des réponses négatives peut être définie à un maximum de 3 heures (3H).
Lors de la configuration de BIND, toutes les heures sont spécifiées en secondes. Toutefois, il est possible d'utiliser des abréviations lorsque l'on indique des unités de temps autres que des secondes, comme des minutes (M), des heures (H), des jours (D) ou des semaines (W). Tableau 11.6, « Secondes comparées à d'autres unités de temps » affiche une durée en secondes et un temps équivalent dans un autre format.
Tableau 11.6. Secondes comparées à d'autres unités de temps
SecondesAutres unités de temps
601M
180030M
36001H
108003H
216006H
4320012H
864001D
2592003D
6048001W
31536000365D

Exemple 11.14. Utilisation d'un enregistrement de ressource SOA

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

11.2.3.3. Balises de commentaires

En plus des enregistrements de ressources et des directives, un fichier de zone peut également contenir des commentaires. Les commentaires sont ignorés par le service named, mais peuvent s'avérer utiles pour fournir des renseignements supplémentaires à l'utilisateur. N'importe quel texte après le point-virgule, en fin de ligne, est considéré comme un commentaire. Exemple : 
   604800  ; expire après 1 semaine

11.2.3.4. Exemple d'utilisation

Les informations suivantes expliquent l'élément que chaque option configure :
11.2.3.4.1. Fichier de zone simple
Exemple 11.15, « Fichier de zone simple » démontre l'utilisation de directives standards et de valeurs SOA.

Exemple 11.15. Fichier de zone simple

$ORIGIN example.com.
$TTL 86400
@         IN  SOA  dns1.example.com.  hostmaster.example.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.example.com.
          IN  NS     dns2.example.com.
dns1      IN  A      10.0.1.1
          IN  AAAA   aaaa:bbbb::1
dns2      IN  A      10.0.1.2
          IN  AAAA   aaaa:bbbb::2
;
;
@         IN  MX     10  mail.example.com.
          IN  MX     20  mail2.example.com.
mail      IN  A      10.0.1.5
          IN  AAAA   aaaa:bbbb::5
mail2     IN  A      10.0.1.6
          IN  AAAA   aaaa:bbbb::6
;
;
; This sample zone file illustrates sharing the same IP addresses
; for multiple services:
;
services  IN  A      10.0.1.10
          IN  AAAA   aaaa:bbbb::10
          IN  A      10.0.1.11
          IN  AAAA   aaaa:bbbb::11

ftp       IN  CNAME  services.example.com.
www       IN  CNAME  services.example.com.
;
;
Dans cet exemple, les serveurs de noms autoritatifs sont définis en tant que dns1.example.com et dns2.example.com, et sont liés aux adressess 10.0.1.1 et 10.0.1.2 IP respectivement en utilisant l'enregistrement A.
Les serveurs d'email configurés avec les enregistrements MX pointent vers mail et mail2 via les enregistrementsA. Comme ces noms ne se terminent pas par un point final, le domaine $ORIGIN est placé à leur suite, ce qui les étend à mail.example.com et à mail2.example.com.
Les services disponibles en noms standards, comme www.example.com (WWW), pointent vers les serveurs qui conviennent, en utilisant l'enregistrement CNAME.
Ce fichier de zone peut être mis en service avec un argument zone dans /etc/named.conf sous la forme suivante : 
zone "example.com" IN {
  type master;
  file "example.com.zone";
  allow-update { none; };
};
11.2.3.4.2. Un fichier de zone de résolution de noms inversés
Un fichier de zone de résolution de noms inversés est utilisé pour traduire une adresse IP d'espace nom particulier en nom complet (FDNQ). Ce fichier ressemble beaucoup à un fichier de zone standard, sauf que les enregistrements de ressources PTR sont utilisés pour faire correspondre les adresses IP à un nom de domaine complet comme le montre Exemple 11.16, « Un fichier de zone de résolution de noms inversés ».

Exemple 11.16. Un fichier de zone de résolution de noms inversés

$ORIGIN 1.0.10.in-addr.arpa.
$TTL 86400
@  IN  SOA  dns1.example.com.  hostmaster.example.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.example.com.
;
1  IN  PTR  dns1.example.com.
2  IN  PTR  dns2.example.com.
;
5  IN  PTR  server1.example.com.
6  IN  PTR  server2.example.com.
;
3  IN  PTR  ftp.example.com.
4  IN  PTR  ftp.example.com.
Dans cet exemple, les adresses IP qui vont de 10.0.1.1 à 10.0.1.6 pointent vers le nom de domaine complet correspondant.
Ce fichier de zone peut être mis en service avec un argument de zone dans le fichier /etc/named.conf sous la forme suivante : 
zone "1.0.10.in-addr.arpa" IN {
  type master;
  file "example.com.rr.zone";
  allow-update { none; };
};
Il n'y a guère de différence entre cet exemple et un argument de zone standard, à l'exception du nom de zone. Notez qu'une zone de résolution de noms inversés nécessite que les trois premiers blocs de l'adresse IP soient inversés, suivis par .in-addr.arpa. Cela permet à l'unique bloc de numéros IP utilisé dans le fichier de zone de résolution de noms inversés d'être associé à la zone.

11.2.4. Comment se servir de l'utilitaire rndc

L'utilitaire rndc est un outil de ligne de commandes qui vous permet d'administrer le service named, à la fois localement et à partir d'une machine éloignée. Son usage est le suivant : 
rndc [option...] command [command-option]

11.2.4.1. Configuration de l'utilitaire

Pour éviter l'accès non autorisé au service, named doit être configuré pour écouter le port sélectionné (953 par défaut), et une clé identique doit être utilisée par le service et l'utilitaire rndc à la fois.
Tableau 11.7. Fichiers appropriés
CheminDescription
/etc/named.conf Le fichier de configuration par défaut du service named.
/etc/rndc.conf Le fichier de configuration par défaut de l'utilitaire rndc.
/etc/rndc.key L'emplacement de la clé par défaut
La configuration de rndc est située dans /etc/rndc.conf. Si le fichier n'existe pas, l'utilitaire utilisera la clé située dans /etc/rndc.key, qui a été générée automatiquement pendant l'installation par la commande rndc-confgen-a.
Le service named est configuré à l'aide de l'argument controls qui se trouve dans le fichier de configuration /etc/named.conf comme décrit dans Section 11.2.2.3, « Autres types d'arguments ». À moins que cet argument soit présent, seules les connexions de l'adresse de loopback ( 127.0.0.1) seront autorisées, et la clé qui se trouve dans /etc/rndc.key sera utilisée.
Pour plus d'informations à ce sujet, voir les pages man et le guide de référence BIND 9 Administrator Reference Manual qui se trouve dans Section 11.2.8, « Ressources supplémentaires ».

Important

Pour empêcher les utilisateurs non privilégiés d'envoyer des commandes de contrôle au service, veillez à ce que seul l'utilisateur root soit autorisé à lire le fichier /etc/rndc.key : 
~]# chmod o-rwx /etc/rndc.key

11.2.4.2. Vérifier le statut de service

Pour vérifier le statut actuel du service named, utiliser la commande suivante : 
~]# rndc status
version: 9.7.0-P2-RedHat-9.7.0-5.P2.el6
CPUs found: 1
worker threads: 1
number of zones: 16
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
recursive clients: 0/0/1000
tcp clients: 0/100
server is up and running

11.2.4.3. Configuration en ligne de commandes

La mise à jour d'un paquetage est semblable à son installation. Entrez la commande suivante à l'invite du shell : 
~]# rndc reload
server reload successful
Cette commande téléchargera à nouveau les zones tout en conservant toutes les réponses mises en cache, de façon à ce que vous puissiez effectuer des changements à des fichiers de zone sans perdre toutes les résolutions de noms stockées.
Pour télécharger à nouveau une zone particulière, indiquer son nom à la suite de la commande reload, comme par exemple : 
~]# rndc reload localhost
zone reload up-to-date
Enfin, pour charger à nouveau le fichier de configuration et les zones nouvellement ajoutées, saisissez : 
~]# rndc reconfig

Note

Si vous souhaitez modifier une zone qui utilise un DNS Dynamique (DDNS), veillez à exécuter la commande freeze pour commenncer : 
~]# rndc freeze localhost
Quand vous aurez terminé, exécuter la commande thaw pour autoriser DDNS à nouveau, et charger la zone à nouveau. 
~]# rndc thaw localhost
The zone reload and thaw was successful.

11.2.4.4. Mise à jour des clés de zone

Pour metter à jour les clés DNSSEC et signer la zone, utiliser la commande sign. Exemple : 
~]# rndc sign localhost
Notez que pour signer une zone avec la commande ci-dessus, l'option auto-dnssec doit être définie sur maintain dans l'argument de la zone. Exemple : 
zone "localhost" IN {
  type master;
  file "named.localhost";
  allow-update { none; };
  auto-dnssec maintain;
};

11.2.4.5. Activation de la validation DNSSEC

Pour activer la valisation DNSSEC, veuillez exécuter la commande suivante en tant qu'utilisateur root : 
~]# rndc validation on
De même, pour désactiver cette option, saisissez : 
~]# rndc validation off
Voir l'argument options décrit dans Section 11.2.2.2, « Types d'arguments communs » pour obtenir des informations sur la façon de configurer cette option dans /etc/named.conf.
Le guide Red Hat Enterprise Linux 7 Security Guide a une section bien complète sur DNSSEC.

11.2.4.6. Activation de la journalisation des requêtes

Pour activer (ou désactiver si elle est déjà activée) la journalisation des requêtes, veuillez exécuter la commande suivante en tant qu'utilisateur root : 
~]# rndc querylog
Pour vérifier la configuration en cours, utilisez la commande status décrite dans Section 11.2.4.2, « Vérifier le statut de service ».

11.2.5. Utilisation de l'utilitaire dig

L'utilitaire dig est un outil de ligne de commandes qui vous permet de faire des consultations DNS et de déboguer une configuration de serveur de noms. Son usage est le suivant : 
dig [@server] [option...] name type
Voir Section 11.2.3.2, « Enregistrements de ressources communs » pour obtenir une liste de valeurs communes à utiliser avec type.

11.2.5.1. Rechercher un serveur de noms

Pour chercher un serveur de noms particulier, utiliser la commande sous la forme suivante : 
dig name NS
Dans Exemple 11.17, « Exemple de recherche de serveur de noms », l'utilitaire dig est utilisé pour afficher les serveurs de noms de example.com.

Exemple 11.17. Exemple de recherche de serveur de noms

~]$ dig example.com NS

; <<>> DiG 9.7.1-P2-RedHat-9.7.1-2.P2.fc13 <<>> example.com NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57883
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;example.com.                   IN      NS

;; ANSWER SECTION:
example.com.            99374   IN      NS      a.iana-servers.net.
example.com.            99374   IN      NS      b.iana-servers.net.

;; Query time: 1 msec
;; SERVER: 10.34.255.7#53(10.34.255.7)
;; WHEN: Wed Aug 18 18:04:06 2010
;; MSG SIZE  rcvd: 77

11.2.5.2. Recherche d'une adresse IP

Pour chercher une adresse IP assignée à un domaine en particulier, utiliser la commande sous la forme suivante : 
dig name A
Dans Exemple 11.18, « Exemple de recherche d'adresse IP », l'utilitaire dig est utilisé pour afficher l'adresse IP de example.com.

Exemple 11.18. Exemple de recherche d'adresse IP

~]$ dig example.com A

; <<>> DiG 9.7.1-P2-RedHat-9.7.1-2.P2.fc13 <<>> example.com A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4849
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;example.com.                   IN      A

;; ANSWER SECTION:
example.com.            155606  IN      A       192.0.32.10

;; AUTHORITY SECTION:
example.com.            99175   IN      NS      a.iana-servers.net.
example.com.            99175   IN      NS      b.iana-servers.net.

;; Query time: 1 msec
;; SERVER: 10.34.255.7#53(10.34.255.7)
;; WHEN: Wed Aug 18 18:07:25 2010
;; MSG SIZE  rcvd: 93

11.2.5.3. Recherche d'un nom d'hôte

Pour rechercher un nom d'hôte pour une adresse IP particulière, utiliser la commande sous la forme suivante : 
dig -x address
Dans Exemple 11.19, « Exemple de recherche de nom d'hôte », l'utilitaire dig est utilisé pour afficher le nom d'hôte assigné à 192.0.32.10.

Exemple 11.19. Exemple de recherche de nom d'hôte

~]$ dig -x 192.0.32.10

; <<>> DiG 9.7.1-P2-RedHat-9.7.1-2.P2.fc13 <<>> -x 192.0.32.10
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29683
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 6

;; QUESTION SECTION:
;10.32.0.192.in-addr.arpa.      IN      PTR

;; ANSWER SECTION:
10.32.0.192.in-addr.arpa. 21600 IN      PTR     www.example.com.

;; AUTHORITY SECTION:
32.0.192.in-addr.arpa.  21600   IN      NS      b.iana-servers.org.
32.0.192.in-addr.arpa.  21600   IN      NS      c.iana-servers.net.
32.0.192.in-addr.arpa.  21600   IN      NS      d.iana-servers.net.
32.0.192.in-addr.arpa.  21600   IN      NS      ns.icann.org.
32.0.192.in-addr.arpa.  21600   IN      NS      a.iana-servers.net.

;; ADDITIONAL SECTION:
a.iana-servers.net.     13688   IN      A       192.0.34.43
b.iana-servers.org.     5844    IN      A       193.0.0.236
b.iana-servers.org.     5844    IN      AAAA    2001:610:240:2::c100:ec
c.iana-servers.net.     12173   IN      A       139.91.1.10
c.iana-servers.net.     12173   IN      AAAA    2001:648:2c30::1:10
ns.icann.org.           12884   IN      A       192.0.34.126

;; Query time: 156 msec
;; SERVER: 10.34.255.7#53(10.34.255.7)
;; WHEN: Wed Aug 18 18:25:15 2010
;; MSG SIZE  rcvd: 310

11.2.6. Fonctionnalités avancées de BIND

La plupart des implémentations de BIND utilisent seulement le service named pour fournir des services de résolution de nom ou pour agir comme autorité pour un domaine particulier. Cependant, la version BIND 9 a un certain nombre de fonctionnalités avancées qui permettent un service DNS plus sûr et plus efficace.

Important

Avant d'utiliser des fonctionnalités avancées comme DNSSEC, TSIG ou IXFR (transfert de zone incrémentiel), assurez-vous que la fonctionnalité en question est prise en charge par tous les serveurs de noms dans l'environnement réseau, surtout lorsque vous utilisez des versions plus anciennes de serveurs de liaison (BIND) ou des serveurs non-BIND.
Toutes les fonctionnalités mentionnées sont expliquées en détails dans le manuel BIND 9 Administrator Reference Manual qui se trouve dans Section 11.2.8.1, « Documentation installée ».

11.2.6.1. Vues multiples

Éventuellement, des informations différentes peuvent être présentées à un client selon le réseau de provenance de la demande. Ceci est principalement utilisé pour refuser l'accès à des données sensibles DNS de la part de clients se trouvant à l'extérieur du réseau local, tout en permettant aux requêtes des clients à l'intérieur du réseau local.
Pour configurer plusieurs affichages, ajoutez l'argument view dans le fichier de configuration /etc/named.conf. Utilisez l'option de match-clients pour faire correspondre les adresses IP ou des réseaux dans leur ensemble et leur donner des options spéciales et les données de zone.

11.2.6.2. IXFR (Incremental Zone Transfers)

Incremental Zone Transfers (IXFR) permet à un serveur de noms secondaire de télécharger les portions mises à jour d'une zone modifiée sur un serveur de noms primaire. Par rapport à un processus de transfert standard, cela rend le processus de notification et de mise à jour bien plus efficace.
Veuillez noter qu'IXFR n'est disponible qu'en utilisant la mise à jour dynamique pour effectuer des changements dans les enregistrements de zones du master. Pour modifier des fichiers de zone manuellement, Automatic Zone Transfer (AXFR) est utilisé.

11.2.6.3. TSIG (Transaction SIGnatures)

Transaction SIGnatures (TSIG) veille à ce qu'une clé secrète partagée existe à la fois sur des serveurs de noms primaires et secondaires avant d'autoriser un transfert. Cela renforce la méthode axée sur l'adresse IP standard d'autorisation de transfert, dans la mesure où les attaquants auraient non seulement besoin d'avoir accès à l'adresse IP de la zone de transfert, mais il faudrait aussi qu'ils connaissent la clé secrète.
Depuis la version 9, BIND prend également TKEY en charge, une autre méthode de clés secrêtes partagées pour autoriser les transferts de zone.

Important

Quand on communique sur réseau non sécurisé, ne pas se fier à l'authentification IP basée adresse uniquement.

11.2.6.4. DNSSEC (DNS Security Extensions )

Domain Name System Security Extensions (DNSSEC) fournit une authentification d'origine aux données DNS, le déni d'existence authentifié, et l'intégrité des données. Quand un domaine particulier est marqué comme sécurisé, la réponse SERVFAIL est retournée pour chaque enregistrement de ressource qui échoue au niveau validation.
Notez que pour déboguer un domaine de signature DNSSEC ou un résolveur DNSSEC-aware, vous pouvez utiliser l'utilitaire de dig comme décrit dans Section 11.2.5, « Utilisation de l'utilitaire dig ». Options utiles : + dnssec (demande d'enregistrements de ressources liées à DNSSEC en définissant le DNSSEC OK bit), + cd (indique au serveur de noms récursif de ne pas valider la réponse), et + bufsize = 512 (modifie la taille du paquet à 512 octets pour pouvoir passer à travers certains pare-feux).

11.2.6.5. IPv6 (Internet Protocol version 6)

Internet Protocol version 6 (IPv6) est pris en charge par l'utilisation des enregistrements de ressources AAAA, et la directive listen-on-v6 décrite dans Tableau 11.3, « Options de configuration souvent utilisées ».

11.2.7. Erreurs communes à éviter

Voici une liste des recommandations pour éviter les erreurs que les utilisateurs font souvent quand ils configurent un serveur de noms :
Utiliser les points virgule et les crochets courbes correctement
Un point virgule ou un crochet courbe qui ne correspond pas, dans le fichier /etc/named.conf, peut empêcher le démarrage du service named.
Utiliser le point final (le signe .) correctement.
Dans les fichiers de zone, un point virgule en fin de nom de domaine indique un nom de domaine complet. Si vous l'omettez, le service named ajoutera le nom de la zone ou la valeur correspondant à $ORIGIN pour compléter le nom de domaine.
Incrémenter le numéro de série lorsque vous modifiez un fichier de zone
Si le numéro de série n'est pas incrémenté, le serveur de noms primaire aura la nouvelle information correcte, mais les noms de serveurs ne seront jamais notifiés du changement, et ne tenteront pas de réactualiser leurs données dans cette zone.
Fichier de configuration
Si un parefeu bloque des connexions d'un service named à d'autres serveurs de noms, la pratique conseillée est de modifier les paramètres de configuration du parefeu.

Avertissement

L'utlisation d'un port source UDP pour les recherches DNS représente un danger potentiel de sécurité car cela permettrait à un attaquant de conduire des attaques d'empoisonnement de cache plus facilement. Pour éviter cela, par défaut, DNS envoie un port éphémère. Configurer votre parefeu pour autoriser les demandes aléatoires sortantes de ports source UDP. Une plage de 1024 à 65535 est utilisée par défaut.

11.2.8. Ressources supplémentaires

Les sources d'informations suivantes fournissent des ressources supplémentaires à propos de BIND.

11.2.8.1. Documentation installée

BIND comprend un grand nombre de documentations installées couvrant plusieurs sujets, chaque sujet étant placé dans son propre répertoire de sujet. Pour chaque élément ci-dessous, remplacer la version par la version du package bind installée sur le système :
/usr/share/doc/bind-version/
Le répertoire principal contenant la documentation la plus récente. Le répertoire contient le manuel BIND 9 Administrator Reference Manual au format HTML et PDF, qui détaille les ressources BIND nécessaires, comment configurer différents types de serveurs de noms, comment effectuer l'équilibrage des charges et autres sujets avancés.
/usr/share/doc/bind-version/sample/etc/
Le répertoire contient des exemples de fichiers de configuration named.
rndc(8)
La page man de l'utilitaire de contrôle de serveur de noms rndc contient une documentation sur son utilisation.
named(8)
La page man du serveur de noms de domaine Internet named qui contient une documentation sur un assortiement d'arguments pouvant être utilisés pour contrôler le démon du serveur de noms BIND.
lwresd(8)
Page man pour le démon du programme de résolution léger lwresd (de l'anglais lightweight resolver daemon), qui contient la documentation sur le démon et sur son utilisation.
named.conf(5)
Page man avec une liste complète d'options disponibles dans le fichier de configuration de named.
rndc.conf(5)
Page man comprenant une liste d'options disponibles pour le fichier de configuration de rndc.

11.2.8.2. Ressources en ligne

https://access.redhat.com/site/articles/770133
Un article de la base de connaissances de Red Hat sur l'exécution de BIND dans un environnement chroot, comprenant les différences par rapport à Red Hat Enterprise Linux 6.
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/
Le guide Red Hat Enterprise Linux 7 Security Guide a une bonne section sur DNSSEC.
https://www.icann.org/namecollision
ICANN FAQ on domain name collision.
Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.