1.5. Configuration des zones sur un serveur DNS BIND

PDF

Une zone DNS est une base de données contenant des enregistrements de ressources pour un sous-arbre spécifique de l'espace de domaine. Par exemple, si vous êtes responsable du domaine example.com, vous pouvez configurer une zone pour celui-ci dans BIND. Par conséquent, les clients peuvent résoudre www.example.com à l'adresse IP configurée dans cette zone.

1.5.1. L'enregistrement SOA dans les fichiers de zone

L'enregistrement de début d'autorité (SOA) est un enregistrement obligatoire dans une zone DNS. Cet enregistrement est important, par exemple, si plusieurs serveurs DNS font autorité pour une zone, mais aussi pour les résolveurs DNS.

Un enregistrement SOA dans BIND a la syntaxe suivante :

name class type mname rname serial refresh retry expire minimum

Pour une meilleure lisibilité, les administrateurs divisent généralement l'enregistrement dans les fichiers de zone en plusieurs lignes avec des commentaires qui commencent par un point-virgule (;). Notez que si vous divisez un enregistrement SOA, les parenthèses maintiennent l'enregistrement ensemble :

@ IN SOA ns1.example.com. hostmaster.example.com. (
                          2022070601 ; serial number
                          1d         ; refresh period
                          3h         ; retry period
                          3d         ; expire time
                          3h )       ; minimum TTL

Important

Notez le point à la fin des noms de domaine pleinement qualifiés (FQDN). Les FQDN sont constitués de plusieurs étiquettes de domaine, séparées par des points. Comme la racine du DNS a une étiquette vide, les FQDNs se terminent par un point. Par conséquent, BIND ajoute le nom de la zone aux noms sans point final. Un nom d'hôte sans point final, par exemple ns1.example.com, sera étendu à ns1.example.com.example.com., ce qui n'est pas l'adresse correcte du serveur de noms primaire.

Il s'agit des champs d'un enregistrement SOA :

name: Le nom de la zone, appelé origin. Si vous attribuez la valeur @ à ce champ, BIND l'étend au nom de la zone défini dans /etc/named.conf.
class: Dans les enregistrements SOA, vous devez toujours définir ce champ sur Internet (IN).
type: Dans les enregistrements SOA, ce champ doit toujours avoir la valeur SOA.
mname (nom principal) : Le nom d'hôte du serveur de noms primaire de cette zone.
rname (nom du responsable) : L'adresse électronique de la personne responsable de cette zone. Notez que le format est différent. Vous devez remplacer le signe at (@) par un point (.).
serial: Le numéro de version de ce fichier de zone. Les serveurs de noms secondaires ne mettent à jour leurs copies de la zone que si le numéro de série du serveur primaire est plus élevé.
Le format peut être n'importe quelle valeur numérique. Un format couramment utilisé est <year><month><day><two-digit-number>. Avec ce format, vous pouvez théoriquement modifier le fichier de zone jusqu'à cent fois par jour.
refresh: Délai pendant lequel les serveurs secondaires doivent attendre avant de vérifier auprès du serveur primaire si la zone a été mise à jour.
retry: Délai pendant lequel un serveur secondaire tente à nouveau d'interroger le serveur primaire après une tentative infructueuse.
expire: Le temps après lequel un serveur secondaire cesse d'interroger le serveur primaire, si toutes les tentatives précédentes ont échoué.
minimum: La RFC 2308 a modifié la signification de ce champ en le remplaçant par le temps de mise en cache négatif. Les résolveurs conformes l'utilisent pour déterminer la durée de mise en cache des erreurs de noms NXDOMAIN.

Note

Une valeur numérique dans les champs refresh, retry, expire, et minimum définit une heure en secondes. Toutefois, pour une meilleure lisibilité, utilisez des suffixes temporels, tels que m pour les minutes, h pour les heures et d pour les jours. Par exemple, 3h correspond à 3 heures.

Ressources supplémentaires

RFC 1035: Noms de domaine - mise en œuvre et spécification
RFC 1034: Noms de domaine - concepts et facilités
RFC 2308: Mise en cache négative des requêtes DNS (cache DNS)

1.5.2. Configuration d'une zone de transfert sur un serveur primaire BIND

Les zones de transfert associent les noms aux adresses IP et à d'autres informations. Par exemple, si vous êtes responsable du domaine example.com, vous pouvez configurer une zone de transfert dans BIND pour résoudre des noms tels que www.example.com.

Conditions préalables

BIND est déjà configuré, par exemple, en tant que serveur de noms avec mise en cache.
Le service named ou named-chroot est en cours d'exécution.

Procédure

Ajouter une définition de zone au fichier /etc/named.conf:
```
zone "example.com" {
    type master;
    file "example.com.zone";
    allow-query { any; };
    allow-transfer { none; };
};
```
Ces paramètres définissent
- Ce serveur est le serveur primaire (type master) pour la zone example.com.
- Le fichier /var/named/example.com.zone est le fichier de zone. Si vous définissez un chemin d'accès relatif, comme dans cet exemple, ce chemin d'accès est relatif au répertoire que vous avez défini dans directory dans la déclaration options.
- Tout hôte peut interroger cette zone. Il est également possible de spécifier des plages d'adresses IP ou des surnoms de liste de contrôle d'accès (ACL) BIND pour limiter l'accès.
- Aucun hôte ne peut transférer la zone. N'autorisez les transferts de zone que lorsque vous configurez des serveurs secondaires et uniquement pour les adresses IP des serveurs secondaires.
Vérifier la syntaxe du fichier /etc/named.conf:
```
# named-checkconf
```
Si la commande n'affiche aucune sortie, la syntaxe est correcte.

Créez le fichier /var/named/example.com.zone, par exemple, avec le contenu suivant :

$TTL 8h
@ IN SOA ns1.example.com. hostmaster.example.com. (
                          2022070601 ; serial number
                          1d         ; refresh period
                          3h         ; retry period
                          3d         ; expire time
                          3h )       ; minimum TTL

                  IN NS   ns1.example.com.
                  IN MX   10 mail.example.com.

www               IN A    192.0.2.30
www               IN AAAA 2001:db8:1::30
ns1               IN A    192.0.2.1
ns1               IN AAAA 2001:db8:1::1
mail              IN A    192.0.2.20
mail              IN AAAA 2001:db8:1::20

Ce fichier de zone :

Définit la valeur par défaut du time-to-live (TTL) pour les enregistrements de ressources à 8 heures. Sans suffixe temporel, tel que h pour heure, BIND interprète la valeur en secondes.
Contient l'enregistrement de ressource SOA requis avec des détails sur la zone.
Définit ns1.example.com comme serveur DNS faisant autorité pour cette zone. Pour être fonctionnelle, une zone nécessite au moins un enregistrement de serveur de noms (NS). Toutefois, pour être conforme à la RFC 1912, il faut au moins deux serveurs de noms.
Définit mail.example.com comme l'échangeur de courrier (MX) du domaine example.com. La valeur numérique devant le nom d'hôte est la priorité de l'enregistrement. Les entrées ayant une valeur inférieure ont une priorité plus élevée.
Définit les adresses IPv4 et IPv6 de www.example.com, mail.example.com, et ns1.example.com.

Définissez des autorisations sécurisées sur le fichier de zone qui permettent uniquement au groupe named de le lire :
```
# chown root:named /var/named/example.com.zone
# chmod 640 /var/named/example.com.zone
```

Vérifier la syntaxe du fichier /var/named/example.com.zone:

# named-checkzone example.com /var/named/example.com.zone
zone example.com/IN: loaded serial 2022070601
OK

Recharger BIND :
```
# systemctl reload named
```
Si vous exécutez BIND dans un environnement change-root, utilisez la commande systemctl reload named-chroot pour recharger le service.

Vérification

Interrogez différents enregistrements de la zone example.com et vérifiez que le résultat correspond aux enregistrements que vous avez configurés dans le fichier de zone :
```
# dig +short @localhost AAAA www.example.com
2001:db8:1::30

# dig +short @localhost NS example.com
ns1.example.com.

# dig +short @localhost A ns1.example.com
192.0.2.1
```
Cet exemple suppose que BIND fonctionne sur le même hôte et répond aux requêtes sur l'interface localhost.

Ressources supplémentaires

1.5.3. Mise en place d'une zone inverse sur un serveur primaire BIND

Les zones inversées transforment les adresses IP en noms. Par exemple, si vous êtes responsable de la plage d'adresses IP 192.0.2.0/24, vous pouvez configurer une zone inverse dans BIND pour résoudre les adresses IP de cette plage en noms d'hôtes.

Note

Si vous créez une zone inversée pour des réseaux de classe entière, nommez la zone en conséquence. Par exemple, pour le réseau de classe C 192.0.2.0/24, le nom de la zone est 2.0.192.in-addr.arpa. Si vous souhaitez créer une zone inverse pour un réseau de taille différente, par exemple 192.0.2.0/28, le nom de la zone est 28-2.0.192.in-addr.arpa.

Conditions préalables

BIND est déjà configuré, par exemple, en tant que serveur de noms avec mise en cache.
Le service named ou named-chroot est en cours d'exécution.

Procédure

Ajouter une définition de zone au fichier /etc/named.conf:
```
zone "2.0.192.in-addr.arpa" {
    type master;
    file "2.0.192.in-addr.arpa.zone";
    allow-query { any; };
    allow-transfer { none; };
};
```
Ces paramètres définissent
- Ce serveur est le serveur primaire (type master) pour la zone inversée 2.0.192.in-addr.arpa.
- Le fichier /var/named/2.0.192.in-addr.arpa.zone est le fichier de zone. Si vous définissez un chemin d'accès relatif, comme dans cet exemple, ce chemin d'accès est relatif au répertoire que vous avez défini dans directory dans la déclaration options.
- Tout hôte peut interroger cette zone. Il est également possible de spécifier des plages d'adresses IP ou des surnoms de liste de contrôle d'accès (ACL) BIND pour limiter l'accès.
- Aucun hôte ne peut transférer la zone. N'autorisez les transferts de zone que lorsque vous configurez des serveurs secondaires et uniquement pour les adresses IP des serveurs secondaires.
Vérifier la syntaxe du fichier /etc/named.conf:
```
# named-checkconf
```
Si la commande n'affiche aucune sortie, la syntaxe est correcte.
Créez le fichier /var/named/2.0.192.in-addr.arpa.zone, par exemple, avec le contenu suivant :
```
$TTL 8h
@ IN SOA ns1.example.com. hostmaster.example.com. (
                          2022070601 ; serial number
                          1d         ; refresh period
                          3h         ; retry period
                          3d         ; expire time
                          3h )       ; minimum TTL

                  IN NS   ns1.example.com.

1                 IN PTR  ns1.example.com.
30                IN PTR  www.example.com.
```
Ce fichier de zone :
- Définit la valeur par défaut du time-to-live (TTL) pour les enregistrements de ressources à 8 heures. Sans suffixe temporel, tel que h pour heure, BIND interprète la valeur en secondes.
- Contient l'enregistrement de ressource SOA requis avec des détails sur la zone.
- Définit ns1.example.com comme serveur DNS faisant autorité pour cette zone inversée. Pour être fonctionnelle, une zone nécessite au moins un enregistrement de serveur de noms (NS). Toutefois, pour être conforme à la RFC 1912, il faut au moins deux serveurs de noms.
- Définit l'enregistrement du pointeur (PTR) pour les adresses 192.0.2.1 et 192.0.2.30.
Définissez des autorisations sécurisées sur le fichier de zone qui n'autorisent que le groupe named à le lire :
```
# chown root:named /var/named/2.0.192.in-addr.arpa.zone
# chmod 640 /var/named/2.0.192.in-addr.arpa.zone
```

Vérifier la syntaxe du fichier /var/named/2.0.192.in-addr.arpa.zone:

# named-checkzone 2.0.192.in-addr.arpa /var/named/2.0.192.in-addr.arpa.zone
zone 2.0.192.in-addr.arpa/IN: loaded serial 2022070601
OK

Recharger BIND :
```
# systemctl reload named
```
Si vous exécutez BIND dans un environnement change-root, utilisez la commande systemctl reload named-chroot pour recharger le service.

Vérification

Interrogez différents enregistrements de la zone inversée et vérifiez que les résultats correspondent aux enregistrements configurés dans le fichier de zone :
```
# dig +short @localhost -x 192.0.2.1
ns1.example.com.

# dig +short @localhost -x 192.0.2.30
www.example.com.
```
Cet exemple suppose que BIND fonctionne sur le même hôte et répond aux requêtes sur l'interface localhost.

Ressources supplémentaires

1.5.4. Mise à jour d'un fichier de zone BIND

Dans certaines situations, par exemple si l'adresse IP d'un serveur change, vous devez mettre à jour un fichier de zone. Si plusieurs serveurs DNS sont responsables d'une zone, n'effectuez cette procédure que sur le serveur principal. Les autres serveurs DNS qui stockent une copie de la zone recevront la mise à jour par le biais d'un transfert de zone.

Conditions préalables

La zone est configurée.
Le service named ou named-chroot est en cours d'exécution.

Procédure

Facultatif : indiquez le chemin d'accès au fichier de zone dans le fichier /etc/named.conf:
```
options {
    ...
    directory       "/var/named";
}

zone "example.com" {
    ...
    file "example.com.zone";
};
```
Le chemin d'accès au fichier de la zone est indiqué dans la déclaration file de la définition de la zone. Un chemin relatif est relatif au répertoire défini dans directory dans la déclaration options.
Modifier le fichier de zone :
1. Effectuez les modifications nécessaires.
2. Incrémenter le numéro de série dans l'enregistrement de début d'autorité (SOA).
  Important
  Si le numéro de série est égal ou inférieur à la valeur précédente, les serveurs secondaires ne mettront pas à jour leur copie de la zone.

Vérifier la syntaxe du fichier de zone :

# named-checkzone example.com /var/named/example.com.zone
zone example.com/IN: loaded serial 2022062802
OK

Recharger BIND :
```
# systemctl reload named
```
Si vous exécutez BIND dans un environnement change-root, utilisez la commande systemctl reload named-chroot pour recharger le service.

Vérification

Interroger l'enregistrement que vous avez ajouté, modifié ou supprimé, par exemple :
```
# dig +short @localhost A ns2.example.com
192.0.2.2
```
Cet exemple suppose que BIND fonctionne sur le même hôte et répond aux requêtes sur l'interface localhost.

Ressources supplémentaires

1.5.5. Signature de la zone DNSSEC à l'aide des fonctions de génération automatique de clés et de maintenance de la zone

Vous pouvez signer les zones avec des extensions de sécurité du système de noms de domaine (DNSSEC) pour garantir l'authentification et l'intégrité des données. Ces zones contiennent des enregistrements de ressources supplémentaires. Les clients peuvent les utiliser pour vérifier l'authenticité des informations de la zone.

Si vous activez la fonctionnalité de politique DNSSEC pour une zone, BIND effectue automatiquement les actions suivantes :

Crée les clés
Signes de la zone
Entretient la zone, y compris la re-signature et le remplacement périodique des clés.

Important

Pour permettre aux serveurs DNS externes de vérifier l'authenticité d'une zone, vous devez ajouter la clé publique de la zone à la zone mère. Contactez votre fournisseur de domaine ou votre bureau d'enregistrement pour plus de détails sur la manière de procéder.

Cette procédure utilise la politique DNSSEC intégrée à default dans BIND. Cette politique utilise des signatures de clés uniques ECDSAP256SHA. Vous pouvez également créer votre propre politique pour utiliser des clés, des algorithmes et des délais personnalisés.

Conditions préalables

La zone pour laquelle vous souhaitez activer DNSSEC est configurée.
Le service named ou named-chroot est en cours d'exécution.
Le serveur synchronise l'heure avec un serveur de temps. Une heure système précise est importante pour la validation DNSSEC.

Procédure

Modifiez le fichier /etc/named.conf et ajoutez dnssec-policy default; à la zone pour laquelle vous souhaitez activer le DNSSEC :
```
zone "example.com" {
    ...
    dnssec-policy default;
};
```
Recharger BIND :
```
# systemctl reload named
```
Si vous exécutez BIND dans un environnement change-root, utilisez la commande systemctl reload named-chroot pour recharger le service.

BIND stocke la clé publique dans le fichier /var/named/K<zone_name>. <algorithm> <key_ID>.key dans le fichier Ce fichier permet d'afficher la clé publique de la zone dans le format requis par la zone mère :

Format d'enregistrement DS :

# dnssec-dsfromkey /var/named/Kexample.com.+013+61141.key
example.com. IN DS 61141 13 2 3E184188CF6D2521EDFDC3F07CFEE8D0195AACBD85E68BAE0620F638B4B1B027

Format DNSKEY :

# grep DNSKEY /var/named/Kexample.com.+013+61141.key
example.com. 3600 IN DNSKEY 257 3 13 sjzT3jNEp120aSO4mPEHHSkReHUf7AABNnT8hNRTzD5cKMQSjDJin2I3 5CaKVcWO1pm+HltxUEt+X9dfp8OZkg==

Demande d'ajout de la clé publique de la zone à la zone parente. Contactez votre fournisseur de domaine ou votre bureau d'enregistrement pour plus de détails sur la manière de procéder.

Vérification

Interrogez votre propre serveur DNS pour obtenir un enregistrement de la zone pour laquelle vous avez activé la signature DNSSEC :
```
# dig +dnssec +short @localhost A www.example.com
192.0.2.30
A 13 3 28800 20220718081258 20220705120353 61141 example.com. e7Cfh6GuOBMAWsgsHSVTPh+JJSOI/Y6zctzIuqIU1JqEgOOAfL/Qz474 M0sgi54m1Kmnr2ANBKJN9uvOs5eXYw==
```
Cet exemple suppose que BIND fonctionne sur le même hôte et répond aux requêtes sur l'interface localhost.
Une fois que la clé publique a été ajoutée à la zone parentale et propagée à d'autres serveurs, vérifiez que le serveur active l'indicateur de données authentifiées (ad) lors des requêtes adressées à la zone signée :
```
#  dig @localhost example.com +dnssec
...
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
...
```

Ressources supplémentaires

1.5. Configuration des zones sur un serveur DNS BIND

1.5.1. L'enregistrement SOA dans les fichiers de zone

1.5.2. Configuration d'une zone de transfert sur un serveur primaire BIND

1.5.3. Mise en place d'une zone inverse sur un serveur primaire BIND

1.5.4. Mise à jour d'un fichier de zone BIND

1.5.5. Signature de la zone DNSSEC à l'aide des fonctions de génération automatique de clés et de maintenance de la zone

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Rendre l’open source plus inclusif

À propos de Red Hat

Red Hat legal and privacy links

Red Hat legal and privacy links