Le fichier de zone contient un certain nombre de directives qui s'appliquent par défaut à la zone en tant qu'entité ou à ses enregistrements (RR). Ces directives sont appelées directives spéciales. Leur caractéristique est qu'elles commencent toutes par le caractère "$" .

$ORIGIN
Cette directive spécifie le nom de domaine par défaut . Le nom de domaine donné en argument de cette directive est automatiquement suffixé à tout nom de domaine qui n'est pas un FQDN (c.-à-d. non suffixé par un point).

La syntaxe est : $ORIGIN <domaine> [<commentaire>]

Les crochets symbolisent le caractère facultatif de l'argument "commentaire". Les commentaires sont séparés du reste de la directive par un point-virgule (" ; ") ; ceci reste valable pour le reste du cours.

$ORIGIN nic.fr. ... www IN CNAME serveur ...

L'enregistrement CNAME ci-dessus correspond à :
www.nic.fr. IN CNAME serveur.nic.fr.

Il est possible d'utiliser cette directive en cascade pour spécifier des sous-domaines par défaut.

$ORIGIN fr. $ORIGIN nic ... www IN CNAME serveur ...

Cet exemple est équivalent à l'exemple précédent (vous remarquerez l'absence "." après "nic").

Si on donne les noms de domaine en FQDN, ne pas oublier le point " . " à la fin qui symbolise que le nom de domaine est un FQDN et qu'on ne doit pas rajouter l'argument de $ORIGIN en suffixe.

$INCLUDE
Pour une zone assez grande, on peut décider de l'organiser en procédant à une division logique de la zone. Chaque partie sera alors prise en compte dans un fichier de zone séparé qui prend en charge uniquement les domaines appartenant à cette "zone logique". La directive permet alors d'inclure ces fichiers dans le fichier de zone principal.

La syntaxe est : $INCLUDE <fichier> [<origin>] [<commentaire>]

Si <origin> n'est pas spécifié, c'est la valeur en cours qui est utilisée.

... $INCLUDE dom_temporaires ; domaines à supprimer après les opérations de test ...

$TTL
Chaque enregistrement de ressource (RR) a une durée de vie (TTL) qui peut être spécifiée lors de sa déclaration. C'est un temps en secondes qui donne la durée pendant laquelle la valeur donnée pour une ressource reste valide (dans les caches).
Si cette valeur n'est pas spécifiée lors de la déclaration d'un RR, alors celle donnée dans la directive $TTL est appliquée par défaut.

La syntaxe est : $TTL <valeur> [<commentaire>]

L'argument <valeur> doit être comprise entre 0 et 2147483647.

Les enregistrements du fichier de zone (RR : Resource Records) constituent la base de données de la zone. Leur structure est définie dans la RFC 1034 et a le format suivant :

< nom | @ > [] [<classe>] <type> <données> [<commentaire>]

ou

	nom désigne le nom de l'enregistrement ; si le caractère @ est utilisé à la place de nom, alors c'est la valeur de $ORIGIN qui est utilisée comme nom ;
	ttl donne la durée de vie en secondes de l'enregistrement dans les caches ; si elle n'est pas spécifiée, c'est la valeur par défaut définie dans $TTL qui sera appliquée ;
	classe spécifie la classe de l'enregistrement ; en général il s'agit de la classe IN (Internet) ;
	type donne le type d'enregistrement (adresse IP, serveur de nom, nom canonique, etc ...) ;
	données spécifie la valeur de l'enregistrement, c.-à-d. les données qui lui sont associées.

L'enregistrement SOA (Start Of Authority) est le premier RR d'un fichier de zone correctement configuré ; il donne les caractéristiques techniques générales de la zone.
Il a comme structure

zone	IN	SOA	primary	email.	(
				serial
				refresh
				retry
				expire
				ttl	)

avec :

zone
Nom de domaine associé à la zone.

primary
Nom de domaine du serveur primaire de la zone (notez le point apposé à la fin du nom).

email
C'est l'adresse électronique du contact technique de la zone. Cette adresse a un format particulier différent du format habituel utilisé pour le courrier électronique ; le "@" est en effet remplacé par un point (".") . Ainsi, pour une adresse "nom@nom_domaine", on obtient "nom.nom_domaine." (notez encore une fois le point (".") à la fin du nom de domaine.
Si le nom dans l'adresse email contient un point, celui-ci doit être "protégé" en le faisant précéder du caractère "\".
Exemple : on notera philippe\.lubrano.nic.fr. pour philippe.lubrano@nic.fr

serial
Ce paramètre donne le numéro de série du fichier de zone, ce qui correspond à la version du fichier. Le serial est un entier de 32 bits qui doit être augmenté avant chaque enregistrement du fichier de zone après que des modifications y aient été effectuées.

En principe, on peut choisir un numéro de série de départ quelconque et l'incrémenter à chaque modification du fichier de zone. Cependant, il y a un format recommandé, notamment :
YYYYMMDDxx (YYYY : année ; MM :mois ; DD :jour ; xx :énième modification du jour).
Exemple : 2002082903

La procédure de mise à jour du serial est cruciale pour le transfert de zone avec les serveurs secondaires ; si le serial n'est pas incrémenté, les modifications effectuées sur la zone ne seront pas prises en compte par les serveurs secondaires.

refresh
Les serveurs secondaires autoritaires pour la zone procèdent régulièrement à la vérification du numéro de série du fichier de zone du primaire pour décider si la zone doit être transférée ou non. Le paramètre refresh donne l'intervalle de temps en secondes entre deux vérifications du numéro de série. La valeur recommandée est 86400 (c.-à-d. 24 heures); elle devra être réduite si les modifications sont fréquentes pour la zone.

retry
La vérification du numéro de série par un serveur secondaire peut se solder par un échec dû par exemple à des problèmes de connexion. Dans ce cas, la valeur du paramètre retry donne l'intervalle en secondes entre deux tentatives de lecture du serial du fichier de zone. La valeur recommandée est 21400, soit 6 heures ; elle devra être ajustée en fonction de la connectivité entre les serveurs autoritaires de la zone.

expire
Un serveur peut ne pas réussir à vérifier le serial ou à transférer le fichier de zone. Dans ce cas, on considère au bout d'un certain temps que les informations qu'il détient dans la copie du fichier de zone sont "périmées" et qu'il ne faut plus les diffuser. Le paramètre expire donne le temps maximum pendant lequel les données du serveur secondaire peuvent être diffusées, si aucune vérification ni transfert de zone n'ont pu être effectués depuis leur téléchargement. La valeur recommandée pour expire est 3600000, soit 41 jours; au delà de cette période, le serveur ne diffusera plus ces données et répondra d'une manière non autoritaire pour les requêtes concernant cette zone.

En général, on choisit une valeur de expire très grande par rapport à celle de refresh, et celle de refresh très grande par rapport à celle de retry (retry << refresh << expire).

ttl
Cette durée de vie (ttl : time to live) est différente de celle définie plus haut (durée de vie des RR). Ce paramètre définit la durée de vie pour le "negative caching", c'est-à-dire le temps qu'une réponse négative doit rester dans les caches. Il existe deux types de réponse négative qu'un serveur peut renvoyer en réponse à une requête DNS (voir aussi RFC 2308) :

	NXDOMAIN : il n'existe pas d'enregistrement ayant le nom spécifié dans la requête DNS ;
	NODATA : il existe bien un ou des enregistrements portant le nom spécifié dans la requête DNS,

mais ils sont d'un type différent de celui spécifié dans la requête.

L'enregistrement NS est sans aucun doute l'un des RR les plus utiles du fichier de zone; il permet de spécifier un serveur de nom pour le nom de domaine spécifié ; ce nom devient alors une zone dont la délégation est attribuée au serveur. Plusieurs serveurs pouvant être autoritaires pour même une zone, il peut exister plusieurs enregistrements NS pour une zone donnée.
La syntaxe pour les enregistrements NS est de la forme:

...

zone	IN	NS	serveur-nom1.domaine.
	IN	NS	serveur-nom2.domaine.

...

Exemple :

...

nic.fr	IN	NS	ns1.nic.fr.
	IN	NS	ns2.nic.fr.

...

Notez que pour le second enregistrement NS, adjacent au premier, il n'est pas nécessaire de spécifier explicitement la zone; la zone précédente est prise par défaut.

Le DNS a comme principale fonction la mise en correspondance entre adresses IP et noms de machines ; ceci est réalisé avec un enregistrement de type A avec la syntaxe

nom_domaine

IN

A

adresse_IP_machine

"nom_domaine" représentant le FQDN de la machine

Exemple :

...

nic.fr	IN	NS	ns1.nic.fr.
	IN	NS	ns2.nic.fr.
ns1.nic.fr.	IN	A	192.93.0.1

...

Dans un réseau, plusieurs FQDN peuvent correspondre en fait à une seule et même machine ; on considère alors que la machine a un nom et des alias ("pseudonymes"). L'enregistrement CNAME permet d'indiquer que le nom spécifié est en fait un alias vers un autre nom, appelé nom canonique ("véritable" nom de la machine).

Exemple 1 :

$ORIGIN	NIC.fr
ftp		IN	CNAME	serveur5

L'alias hérite de toutes les propriétés du nom canonique. Pour cette raison, il n'est pas permis d'utiliser un nom d'alias pour deux noms canoniques différents. En plus, un alias ne peut être utilisé comme donnée dans un RR, c'est-à-dire qu'il ne peut figurer dans la partie droite d'un enregistrement de fichier de zone.
Les trois exemples suivants illustrent ce qui est permis, et ce qui est interdit dans l'usage de CNAME :

L'enregistrement MX (Mail eXchanger : relais de messagerie) est le lien entre le DNS et SMTP, le protocole de transfert de courrier électronique. Il permet de spécifier le relais de messagerie pour un domaine donné. Pour un domaine donné, les adresses de courrier électronique des personnes de ce domaine sont de la forme personne@nom_domaine . Pour des raisons de continuité de service, il existe souvent plusieurs relais de messagerie pour un même domaine (redondance). Il y a dans ce cas plusieurs enregistrements MX pour ce domaine, et un paramètre précise le poids de l'enregistrement. Lorsqu'un courrier doit être acheminé à une adresse du domaine, le relais de messagerie ayant le poids d'enregistrement MX le plus faible est contacté en premier. En cas d'échec, les autres sont contactés l'un après l'autre dans l'ordre croissant du poids des enregistrements MX.
Les enregistrements MX ont ainsi la structure suivante :

nom	IN	MX	10	relais1.
	IN	MX	20	relais2.
	IN	MX	30	relais3.

Il n'y a pas de contrainte particulière par rapport à la numération choisie pour la préférence ; cependant, on numérote généralement par dizaine afin de pouvoir insérer en cas de nécessité d'autres enregistrement MX avec des niveau de préférence intermédiaires.

Wildcard MX

Le caractère "*" peut être utilisé comme wildcard dans un enregistrement MX.
Son utilisation est expliqué dans l'exemple suivant :

... nic.fr IN MX 10 relais.nic.fr. *.nic.fr. IN MX 10 relais.nic.fr. ...

L'utilisation du wildcard aura comme aura comme effet l'association du relais de messagerie spécifié à tout nom du domaine nic.sn , mais seulement si aucun RR (de quelque type qu'il soit) ne concerne ce nom.

L'exemple suivant illustre ce cas :

nic.fr IN MX 10 relais.nic.fr. *.nic.fr. IN MX 10 relais.nic.fr. nom.nic.fr. IN A adresse_IP

Dans ce cas, nom.nic.fr n'hérite pas du wildcard utilisé pour le domaine nic.fr . Il faut donc associer systématiquement un MX à chaque fois qu'on définit un RR pour un nom donné. Lorsqu'un message doit être délivré à une machine donnée alors qu'aucun MX ne lui est associé, SMTP utilise l'adresse IP associée à cette machine (à partir d'un RR de type A) ; si une telle information n'est pas disponible, alors SMTP utilise l'enregistrement wildcard MX approprié, s'il existe. En l'absence d'un tel enregistrement, SMTP renvoie un message d'erreur.

L'enregistrement PTR sert à associer une adresse IP à un nom de domaine (correspondant à une machine), c'est-à-dire à effectuer une résolution inverse. Cet enregistrement est utilisé dans un fichier de zone de l'arborescence in-addr.arpa (pour les adresses IPv4).

La syntaxe pour ce type d'enregistrement est :

adresse_IP__machine

IN

PTR

nom_domaine

... $ORIGIN 0.134.192.in-addr.arpa. 49                                       IN    PTR    ns3.nic.fr. ...

$ORIGIN 0.0.127.in-addr.arpa. $TTL 86400   @                                          IN      SOA      ns1.nic.fr.     hostmaster.nic.fr.                                                  (                                                                       1997052704           ;serial                                                                       86400                      ;refresh                                                                       21600                      ;retry                                                                       3600000                 ;expire                                                                       3600                       ;negative ttl                                                  )                                                IN        NS ns1.nic.fr. 1                                             IN PTR localhost.nic.fr.