Aller au contenu principal

5. Master Files (Fichiers maîtres)

Les fichiers maîtres (Master Files) sont des fichiers texte contenant des RR sous forme textuelle. Étant donné que le contenu d'une zone peut être exprimé sous la forme d'une liste de RR, un fichier maître est le plus souvent utilisé pour définir une zone, bien qu'il puisse être utilisé pour lister le contenu d'un cache.

Cette section traite d'abord du format des RR dans un fichier maître, puis des considérations spéciales lorsqu'un fichier maître est utilisé pour créer une zone dans un serveur de noms.

5.1. Format​

Le format des fichiers maîtres est une séquence d'entrées.

Règles générales​

Format orienté lignes :

  • Les entrées sont principalement orientées lignes
  • Les parenthèses peuvent être utilisées pour continuer une liste d'éléments sur plusieurs lignes
  • Les littéraux texte peuvent contenir des CRLF dans le texte

Délimiteurs :

  • Toute combinaison de tabulations et d'espaces agit comme délimiteur entre les éléments séparés

Commentaires :

  • La fin de toute ligne peut se terminer par un commentaire
  • Les commentaires commencent par un ; (point-virgule)
  • Le reste de la ligne après ; est ignoré

Lignes vides :

  • Les lignes vides, avec ou sans commentaires, sont autorisées n'importe où dans le fichier

Types d'entrées​

Les entrées suivantes sont définies :

<blank>[<comment>]

$ORIGIN <domain-name> [<comment>]

$INCLUDE <file-name> [<domain-name>] [<comment>]

<domain-name><rr> [<comment>]

<blank><rr> [<comment>]

Entrées de contrôle​

Deux entrées de contrôle sont définies : $ORIGIN et $INCLUDE.

$ORIGIN :

  • Suivi d'un nom de domaine
  • Réinitialise l'origine actuelle pour les noms de domaine relatifs au nom indiqué
  • Exemple : $ORIGIN example.com.

$INCLUDE :

  • Insère le fichier nommé dans le fichier actuel
  • Peut éventuellement spécifier un nom de domaine qui définit l'origine du nom de domaine relatif pour le fichier inclus
  • Peut également avoir un commentaire
  • Note : Une entrée $INCLUDE ne change jamais l'origine relative du fichier parent, quels que soient les changements apportés à l'origine relative dans le fichier inclus
  • Exemple : $INCLUDE /var/named/example.com.hosts

Entrées de resource records​

Les deux dernières formes d'entrée représentent des RR :

Règles des noms de propriétaire :

  • Si une entrée pour un RR commence par un blanc, alors le RR est supposé appartenir au dernier propriétaire indiqué
  • Si une entrée RR commence par un <domain-name>, alors le nom du propriétaire est réinitialisé

Format RR :

Le contenu de <rr> prend l'une des formes suivantes :

[<TTL>] [<class>] <type> <RDATA>

[<class>] [<TTL>] <type> <RDATA>

Descriptions des champs :

  • TTL : Optionnel, entier décimal représentant la durée de vie en secondes
  • Class : Optionnel, mnémonique standard (par ex., IN)
  • Type : Requis, mnémonique standard (par ex., A, NS, MX)
  • RDATA : Requis, données appropriées au type et à la classe

Valeurs par défaut :

  • Les valeurs de classe et de TTL omises prennent par défaut les dernières valeurs explicitement indiquées
  • Étant donné que les mnémoniques de type et de classe sont disjoints, l'analyse est unique

5.2. Domain Names in Master Files (Noms de domaine dans les fichiers maîtres)​

Les <domain-name> constituent une grande partie des données dans le fichier maître.

Représentation des étiquettes​

Format de base :

  • Les étiquettes dans le nom de domaine sont exprimées sous forme de chaînes de caractères et séparées par des points
  • Les conventions de citation permettent de stocker des caractères arbitraires dans les noms de domaine

Noms absolus vs. relatifs :

  • Noms absolus (Absolute Names) : Les noms de domaine se terminant par un point sont appelés absolus et sont considérés comme complets

    • Exemple : www.example.com.

  • Noms relatifs (Relative Names) : Les noms de domaine ne se terminant pas par un point sont appelés relatifs

    • Le nom de domaine réel est la concaténation de la partie relative avec une origine spécifiée dans un $ORIGIN, $INCLUDE, ou comme argument à la routine de chargement du fichier maître
    • Un nom relatif est une erreur lorsqu'aucune origine n'est disponible
    • Exemple : www avec l'origine example.com. devient www.example.com.

Chaînes de caractères​

<character-string> est exprimé de l'une des deux manières suivantes :

  1. Non quoté : Un ensemble contigu de caractères sans espaces intérieurs
  2. Quoté : Une chaîne commençant par " et se terminant par "
    • À l'intérieur d'une chaîne délimitée par ", n'importe quel caractère peut apparaître sauf un " lui-même
    • Un " doit être quoté en utilisant \ (barre oblique inverse)

5.3. Special Encodings (Encodages spéciaux)​

Étant donné que les fichiers maîtres sont des fichiers texte, plusieurs encodages spéciaux sont nécessaires pour permettre le chargement de données arbitraires.

Caractères et séquences spéciaux​

. (point) :

  • Un . isolé désigne la racine
  • Exemple : Dans example.com., le . final désigne la racine

@ (arobase) :

  • Un @ isolé est utilisé pour désigner l'origine actuelle
  • Exemple : @ IN SOA ... fait référence à l'origine de la zone

\X (échappement par barre oblique inverse) :

  • Où X est n'importe quel caractère autre qu'un chiffre (0-9)
  • Utilisé pour quoter ce caractère afin que sa signification spéciale ne s'applique pas
  • Exemples :
    • \. peut être utilisé pour placer un point dans une étiquette
    • \; peut être utilisé pour inclure un point-virgule dans une chaîne (pas comme commentaire)
    • \\ représente un caractère barre oblique inverse

\DDD (échappement décimal) :

  • Où chaque D est un chiffre
  • Représente l'octet correspondant au nombre décimal décrit par DDD
  • L'octet résultant est supposé être du texte et n'est pas vérifié pour une signification spéciale
  • Exemple : \065 représente le caractère 'A' (ASCII 65)

( ) (parenthèses) :

  • Les parenthèses sont utilisées pour grouper des données qui franchissent une limite de ligne
  • En effet, les terminaisons de ligne ne sont pas reconnues à l'intérieur des parenthèses
  • Utile pour les enregistrements SOA et autres entrées multi-lignes

; (point-virgule) :

  • Le point-virgule est utilisé pour commencer un commentaire
  • Le reste de la ligne est ignoré

5.4. Use of Master Files to Define Zones (Utilisation des fichiers maîtres pour définir des zones)​

Lorsqu'un fichier maître est utilisé pour charger une zone, l'opération devrait (SHOULD) être supprimée si des erreurs sont rencontrées dans le fichier maître.

Justification​

La raison en est qu'une seule erreur peut avoir des conséquences généralisées. Par exemple :

  • Supposons que les RR définissant une délégation aient des erreurs de syntaxe
  • Alors le serveur renverra des erreurs de nom autoritaires pour tous les noms dans la sous-zone
  • (sauf dans le cas où la sous-zone est également présente sur le serveur)

Vérifications de validité​

Plusieurs vérifications de validité devraient (SHOULD) être effectuées en plus de s'assurer que le fichier est syntaxiquement correct :

  1. Cohérence de classe : Tous les RR dans le fichier devraient (SHOULD) avoir la même classe

  2. Exigence SOA : Exactement un RR SOA devrait (SHOULD) être présent au sommet de la zone

  3. Informations de colle : Si des délégations sont présentes et que des informations de colle sont requises, elles devraient (SHOULD) être présentes

  4. Données autoritaires : Les informations présentes en dehors des nœuds autoritaires dans la zone devraient (SHOULD) être des informations de colle, plutôt que le résultat d'une origine ou d'une erreur similaire

5.5. Master File Example (Exemple de fichier maître)​

Voici un exemple de fichier qui pourrait être utilisé pour définir la zone ISI.EDU et est chargé avec une origine de ISI.EDU :

@   IN  SOA     VENERA      Action\.domains (
                                 20     ; SERIAL
                                 7200   ; REFRESH
                                 600    ; RETRY
                                 3600000; EXPIRE
                                 60)    ; MINIMUM

        NS      A.ISI.EDU.
        NS      VENERA
        NS      VAXA
        MX      10      VENERA
        MX      20      VAXA

A       A       26.3.0.103

VENERA  A       10.1.0.52
        A       128.9.0.32

VAXA    A       10.2.0.27
        A       128.9.0.33


$INCLUDE <SUBSYS>ISI-MAILBOXES.TXT

Analyse de l'exemple​

Enregistrement SOA :

  • @ représente l'origine de la zone (ISI.EDU.)
  • VENERA est le serveur de noms primaire (nom relatif, devient VENERA.ISI.EDU.)
  • Action\.domains est la boîte aux lettres de la personne responsable ([email protected])
    • Notez l'utilisation de \ pour échapper le point dans l'adresse e-mail
  • Numéro de série : 20
  • Rafraîchissement : 7200 secondes (2 heures)
  • Nouvelle tentative : 600 secondes (10 minutes)
  • Expiration : 3600000 secondes (environ 41,67 jours)
  • Minimum : 60 secondes

Enregistrements NS :

  • Trois serveurs de noms : A.ISI.EDU. (absolu), VENERA (relatif), VAXA (relatif)

Enregistrements MX :

  • Échangeur de courrier primaire : VENERA avec préférence 10
  • Échangeur de courrier secondaire : VAXA avec préférence 20

Enregistrements A :

  • A.ISI.EDU. a une adresse IPv4
  • VENERA.ISI.EDU. a deux adresses IPv4 (multihébergé)
  • VAXA.ISI.EDU. a deux adresses IPv4 (multihébergé)

Directive $INCLUDE :

  • Inclut un fichier externe contenant des enregistrements de boîtes aux lettres

5.6. Common Master File Patterns (Modèles de fichiers maîtres courants)​

Modèle 1 : Fichier de zone simple​

$ORIGIN example.com.
$TTL 86400

@   IN  SOA ns1.example.com. admin.example.com. (
            2024010101  ; Serial
            3600        ; Refresh
            1800        ; Retry
            604800      ; Expire
            86400 )     ; Minimum

    IN  NS  ns1.example.com.
    IN  NS  ns2.example.com.

ns1 IN  A   192.0.2.1
ns2 IN  A   192.0.2.2
www IN  A   192.0.2.10

Modèle 2 : Sous-domaine délégué​

; Délégation à un sous-domaine
subdomain       IN  NS  ns1.subdomain.example.com.
                IN  NS  ns2.subdomain.example.com.

; Enregistrements de colle (requis si les serveurs de noms sont dans le sous-domaine)
ns1.subdomain   IN  A   192.0.2.20
ns2.subdomain   IN  A   192.0.2.21

Modèle 3 : Multiples enregistrements A (équilibrage de charge)​

; DNS round-robin pour l'équilibrage de charge
www     IN  A   192.0.2.10
        IN  A   192.0.2.11
        IN  A   192.0.2.12

5.7. Best Practices (Meilleures pratiques)​

  1. Toujours utiliser des noms absolus pour les références externes : Les noms en dehors de votre zone devraient se terminer par un point

  2. Utiliser $ORIGIN avec précaution : Le définir au début et éviter de le changer inutilement

  3. Inclure les numéros de série : Toujours incrémenter le numéro de série lors des modifications

  4. Utiliser des commentaires : Documenter votre fichier de zone avec des commentaires

  5. Tester avant le déploiement : Utiliser des outils comme named-checkzone pour valider la syntaxe

  6. Maintenir la cohérence : Conserver un formatage cohérent pour la lisibilité

  7. Sauvegarder : Toujours maintenir des sauvegardes des fichiers de zone fonctionnels avant d'apporter des modifications

Suivant : 6. Name Server Implementation (Implémentation du serveur de noms)

Dernière mise à jour le