Configuration DNS

Configuration d’un serveur de noms

La configuration d’un serveur de noms est une opération laborieuse la première fois, mais qui va devenir routinière avec un peu d’expérience. Néanmoins, la configuration d’un serveur de noms reste une opération délicate car il y a de pièges, et il n’est pas toujours facile de découvrir ses erreurs.

Types de serveurs

On peut classer les serveurs de noms en plusieurs catégories en fonction de l’usage auquel ils sont destinés. Néanmoins chaque serveur peut remplir simultanément plusieurs fonctions, car tous les serveurs sont cache, et la configuration primaire ou secondaire se fait zone par zone.

Serveur cache

Le but de ce type de serveur est de recevoir les requêtes effectuées à partir d’un certain nombre de machines et de construire au fur et a mesure un cache des réponses. Cela permet de limiter le trafic DNS vers l’extérieur.

Serveur primaire

Le serveur primaire est autoritaire pour un certain nombre de zones. Il obtient le contenu de ces zones à partir de fichiers configurés par l’administrateur système ou par des outils automatiques (exploitant par exemple le fichier /etc/hosts) .

Serveur secondaire

Le serveur secondaire est autoritaire pour un certain nombre de zones. Il obtient le contenu de ces zones à partir des serveurs primaires respectifs pour ces zones.

Fichiers de configuration d’un serveur et leur syntaxe

Ce document décrit les fichiers et la syntaxe de BIND qui est le programme serveur de noms le plus courant. Dans la mesure où BIND se conforme pratiquement complètement à la syntaxe et à l’esprit des RFC 1034 et 1035 cette description doit être réutilisable.

Les fichiers

BIND utilise d’une part un fichier de configuration et d’autre part un fichier de données par zone. De plus un fichier contient aussi la liste des serveurs de noms pour la racine.

Le fichier de configuration: named.conf (named.boot pour la version 4.9.7)

Le fichier named.conf contient la configuration du serveur de noms et en particulier la liste des zones dont le serveur est autoritaire (primaire ou secondaire). La syntaxe complète de ce fichier dépend de la version de BIND. La documentation et les dernieres informations de la version actuelle sont disponibles a l’adresse : http://www.isc.org/downloads/BIND/bind8.html

Liste des zones

Toutes les zones sont énumérées dans le fichier de configuration du serveur de noms en précisant si la zone est primaire, secondaire, ou cache. La syntaxe générale est la suivante :

<type de la zone> <nom de la zone> [source] <fichier>

Les champs sont séparés par des espaces, les tabulations sont plus ou moins bien acceptées suivant les versions. Les lignes vides sont acceptées, des commentaires peuvent figurer par ligne entière commençant par un point-virgule ;.

Les noms de fichiers peuvent être absolus (commençant par un /), ou relatifs. La commande directory peut être utilisée pour changer le répetoire courant du programme.

Zone primaire

Pour une zone primaire, on a :

primary <nom de la zone> <fichier de données>

Le nom de la zones est complètement qualifié, sans point à la fin. Le fichier de données contient les enregistrements de la zone comme décrit ci-dessous.

Dès que le serveur a lu le fichier (sans erreur de syntaxe), le serveur est primaire pour la zone en question. C’est à dire qu’il peut répondre à toutes les requêtes pour des noms dans la zone sans consulter d’autres serveurs. Néanmoins pour que la zone soit connue, il faut que son existence soit déclarée dans la zone parente.

Zone secondaire

Pour une zone secondaire, on a:

secondary <nom de la zone> <liste d’adresses IP> <fichier de données>

Le nom de la zone est complètement qualifié, sans point à la fin. La liste des adresses IP contient une ou plusieurs adresses IP d’où le serveur de nom peut transférer le contenu de la zone. Il faut mettre le(s) adresse(s) du serveur primaire en premier puis ensuite éventuellement les adresses des autres serveurs secondaires si on pense que l’on va avoir des problèmes de connectivité avec le primaire. Les adresses sont séparées par des blancs.

Zone cache

Il n’y a qu’une zone cache contenant la liste des fichiers de la racine. Cette liste est identique sur tous les serveurs et le fichier de zone correspondant s’appelle root.cache ou named.root. Le contenu du fichier est disponible en cliquant sur l’un des deux noms précédents (2 kilo-octets).

cache . root.cache

Il est indispensable d’installer la zone cache sur tous les serveurs, car la liste des serveurs de cette zone sert à amorcer la recherche de tout autre nom.

Que ferait un serveur avec un espace de nommage absolument vide recevant une requête ? C’est pourquoi tous les serveurs de noms de l’Internet doivent pouvoir envoyer des requètes aux serveurs de la racine.

Attention : ne modifiez pas la liste des serveurs de noms du cache, vous vous exposez à des problèmes inextricables.

Autres options

D’autres options dans le fichier de configuration vont changer le comportement du serveur de noms:

directory

directory <repertoire>

Le process serveur de noms effectue un chdir() dans le répertoire spécifié. Les noms de fichiers relatifs dans tout le reste du fichier de configuration deviennent donc relatifs à ce répertoire.

forwarder

slave

Les fichiers de zone

Les fichiers de zones reprennent tous les enregistrements formant le contenu de la zone. L’ordre de ces enregistrements est peu important, néanmoins on respecte en général une logique de parcours d’arbre en commençant par le haut de la zone. Ce qui nous donne au début :

Un enregistrement SOA. Cet enregistrement décrit la zone.

Des enregistrements NS. Ces enregistrements décrivent la liste des serveurs de noms pour la zone.

Eventuellement un ou des enregistrements MX.

Chaque enregistrement est de la forme nom de domaine, type, donnée.

<nom> [TTL] [CLASSE] <TYPE> <valeur>

Les champs sont séparés par des espaces, les tabulations sont plus ou moins bien acceptées suivant les versions. Les lignes vides sont acceptées, des commentaires peuvent figurer par ligne entière commençant par un point-virgule ;.

Il existe un certain nombre de raccourcis pour éviter les répétitions:

Le TTL est par défaut la valeur définie comme default TTL dans l’enregistrement SOA.

La classe est par défaut IN pour Internet.

Le nom, s’il est omis est identique au nom de l’enregistrement précédent. Cela permet de faire apparaitre un nom, puis tous les enregistrements le concernant à la suite sans répéter le nom. On évite ainsi des erreur typographiques dans le nom et on facilite la lecture.

Le caractère @

Il existe un nom spécial « @ » qui remplace dans un fichier de zone le nom de la zone que l’on définit. Cela permet donc de mettre en début de fichier pour l’enregistrement SOA:

@ IN SOA ns.truc.fr. postmaster.truc.fr. (

…

)

IN NS ns.truc.fr.

IN NS ns.secondaire.fr.

IN MX 10 relais.truc.fr.

Noms qualifiés et noms relatifs

Un nom est qualifié s’il se termine par un point, les autres sont relatifs. En anglais, un nom qualifié s’appelle Fully Qualified Domain Name (FQDN).

Si un nom relatif apparaît dans un enregistrement, le nom de la zone en cours (la valeur de @) est concaténée au nom.

Ainsi quand on définit une zone truc.fr dans un fichier truc.zone

primary truc.fr truc.zone

et que dans le fichier on a des enregistrements

@ IN TXT « Foo ! »

toto IN MX 10 titi

IN MX 20 relais.domaine.fr.

ces enregistrements sont modifiés comme suit:

truc.fr. IN TXT « Foo ! »

toto.truc.fr. IN MX 10 titi.truc.fr.

IN MX 20 relais.domaine.fr.

Configuration d’un serveur cache

Choix du répertoire de travail

Tous les fichiers seront stockés dans un répertoire de travail, par exemple dans /var/etc/named, en n’oubliant pas que le contenu de ce répertoire doit être sauvegardé régulièrement.

Le répertoire contient également le répertoire secondary si votre serveur est secondaire pour une ou plusieurs zones.

Fichier named.boot

; Choix du repertoire

; Mettez ici le repertoire dans lequel vous stockez les fichiers

; contenant les enregistrements des zones

directory /var/etc/named

; Les deux lignes suivantes sont obligatoires

cache . root.cache

primary 0.0.127.in-addr.arpa local.rev

; Fin

Fichier root.cache

Le fichier peut être récupéré sur le site web de l’AFNIC ou BIND.

Fichier local.rev

;

; Fichier définissant le nom localhost pour l’adresse 127.0.0.1

;

@ IN SOA <nom de cette machine>. hostmaster.<nom de cette machine>. (

1 ;serial

86400 ;refresh (24 h)

43200 ;retry (12 h)

3600000 ;expire

691200 );minimum (8 j)

IN NS localhost.

1 IN PTR localhost.

Nota : Il existe aussi le choix de mettre localhost.votre.domaine. à la place de localhost. Dans ce cas, il ne faut pas oublier de faire apparaître le nom localhost avec l’adresse 127.0.0.1 dans la définition de votre zone.

Installation

Une fois les fichiers en place, vous pouvez lancer le serveur de noms et le tester.

Contenu d’une zone

Une zone contient un ensemble de noms de domaines compris dans la zone. Pour chaque nom de domaine, il y a un certain nombre d’enregistrements de données. Ces données peuvent être des adresses, des relais de messagerie, etc.

Dans chaque zone un certain nombre d’enregistrements sont obligatoires. Il s’agit de:

Un enregistrement SOA. Cet enregistrement décrit la zone. Des enregistrements NS. Ces enregistrements décrivent la liste des serveurs de noms pour la zone.

Enregistrements de données

En anglais Resource Record (RR).

Ces enregistrements contiennent les données sur un nom de domaine. Chaque nom de domaine dans une zone peut avoir plusieurs enregistrements, ces enregistrements peuvent être de types différents. Il peut y avoir plus d’un

enregistrement de même type, mais dans ce cas le serveur de noms les envoie au client dans n’importe quel ordre.

Chaque enregistrement est de la forme nom de domaine, type, donnée.

<nom> [TTL] [CLASSE] <TYPE> <valeur>

La classe est toujours IN pour Internet. La liste des types de données figure ci-dessous. Chaque enregistrement a également une durée de vie Time To Live (TTL) qui indique le temps pendant lequel un serveur de noms ayant obtenu l’enregistrement peut le garder dans son cache.

Nota: la syntaxe utilisée pour présenter les types d’enregistrements est celle de RFC1034.

Les types d’enregistrements sont:

A, AAAA, MX, CNAME, NS, SOA, PTR, TXT, HINFO, WKS, RP, MA, MB.

A (Address)

C’est l’enregistrement le plus courant. Il indique une adresse IP associée à un nom (le DNS a été fait pour cela).

Quand une machine dispose de plus d’une adresse IP (un routeur ou une machine avec plusieurs cartes), on doit indiquer plusieurs enregistrements A, un par adresse, mais il faut alors que tous les enregistrements PTR pointent vers

ce nom là.

nom IN A 193.10.20.30

AAAA (Address IPv6)

Le format précis n’est pas encore connu. Si le type d’enregistrement est nommé AAAA, c’est car l’adresse IP version 6 est quatre fois plus longue que pour un enregistrement de type A.

MX (Mail eXchanger)

Cet enregistrement indique pour un nom de domaine quel est la machine à laquelle il faut envoyer le courrier pour ce domaine. Un paramètre précise le poids relatif de cet enregistrement.

Si plusieurs enregistrements MX sont présents, le MTA va essayer d’envoyer le courrier en premier à la machine ayant le poids associé le plus faible, puis ensuite dans l’ordre croissant des poids.

Si la machine qui relaie le courrier est dans la liste des MX pour le domaine, elle envoie le courrier aux machines de poids inférieur au sien.

nom IN MX 10 nom.du.relais.

IN MX 20 nom.du.deuxieme.relais.

CNAME (Cannonical Name)

Cet enregistrement indique que le nom de domaine donné est un alias vers un autre nom (le nom canonique). Il est possible d’avoir une chaîne d’alias, mais la longueur de celle-ci est limitée, en général autour de 10.

Nota: Quand un nom de domaine figure en partie droite d’un enregistrement, ce dernier ne doit pas être une alias. C’est à dire que les noms figurant à droite dans les enregistrements NS, MX, etc. ne doivent pas être des alias, mais les noms canoniques (au bout de la chaîne des alias), l’exception est qu’un CNAME peut pointer vers un autre CNAME, mais attention aux boucles.

Nota: Quand pour un nom on a un enregistrement CNAME, il est interdit de faire figurer d’autres enregistrements. S’il y a à faire figurer des enregistrements, il faut les faire figurer pour le nom canonique.

alias IN CNAME nom.canonique.

SOA (Start Of Authority)

L’enregistrement SOA est l’acte de naissance d’une zone. Il contient un certain nombre de paramètres:

Le nom du primaire

C’est le nom du serveur primaire pour la zone. L’adresse de courrier électronique du responsable technique de la zone (zone-contact). Il faut l’écrire en replaçant le @ par un point. On a alors par exemple: [email protected] qui devient root.inria.fr

Le numéro de série de la zone

Les serveurs secondaires interrogent régulièrement le serveur primaire de chaque zone pour déterminer si la zone a été mise à jour selon le mécanisme décrit ici.

L’intervalle entre les rafraîchissements (refresh)

Temps en secondes entre les vérifications du numéro de série par les secondaires. La valeur conseillée est 24heures, soit 86400 secondes.

L’intervalle entre les rafraîchissements (retry)

Temps en secondes entre les vérifications du numéro de série par les secondaires si la première vérification a échouée. La valeur conseillée est 6 heures, soit 21600 secondes.

La durée d’expiration des enregistrements d’un secondaire

Si un secondaire n’arrive pas à contacter le serveur primaire de la zone, il continue à répondre aux requêtes pendant la durée donnée. La valeur conseillée est de 41 jours, soit 3600000 secondes.

La durée de vie par défaut des enregistrements (default TTL)

Quand le TTL d’un enregistrement n’est pas spécifiée, cette valeur est utilisée. La valeur conseillée est de 24 heures, soit 86400 secondes.

Les différentes valeurs sont toujours telles que l’inégalité suivante est vérifiée (avec un rapport au moins 10 entre les

termes):

retry << refresh << expire

zone IN SOA nom.du.primaire. adresse.du.hostmaster. (

95021502 ; numero de serie

86400 ; refresh

21600 ; retry

3600000 ; expire

86400 ) ; default TTL

Dans la syntaxe bind, le symbole @ représente le nom de la zone courante, donc nous avons souvent au début du fichier pour une zone:

@ IN SOA …

IN NS …

IN NS …

IN MX 10 …

NS (Name Server)

Cet enregistrement indique une délégation pour la gestion du nom donné. C’est à dire que le nom donné devient une

zone, dont la gestion est déléguée au serveur indiqué en partie droite.

L’enregistrement donne le nom d’un des serveurs de noms autoritaire pour la zone, comme il y a toujours plus d’un serveur de noms pour une zone, on répète l’enregistrement NS autant de fois qu’il y a de serveurs pour la zone.

Quand pour un nom, on a des enregistrements NS, il est interdit de faire figurer dans la zone parente (celle là) d’autres enregistrements. S’il y a à faire figurer des enregistrements, il faut les mettre dans la zone fille.

zone IN NS serveur.nom.de.domaine.

IN NS autreServeur.nom.de.domaine.

IN NS encoreUn.autreNom.de.domaine.

TXT (Text)

Cet enregistrement permet de stocker une chaîne de caractères.

nom IN TXT « Bonjour ! »

PTR (Pointer)

Les enregistrements PTR permettent d’indiquer une correspondance vers un autre nom dans l’abre de nommage. Il sont discutés dans la section sur le domaine in-addr.arpa.

10.20.30.192.in-addr.arpa. IN PTR ma.machine.fr.

HINFO (Host Info)

L’enregistrement HINFO permet de préciser pour une machine quel est son système d’exploitation et le matériel. Cet enregistrement est peu utilisé.

serveur IN HINFO « ZX81 » « BASIC »

Nota: Il existe un certain nombre de valeurs légales pour l’enregistrement HINFO.

Si vous utilisez l’enregistrement HINFO, n’oubliez pas de mettre les deux valeurs car c’est une cause importante d’erreur de syntaxe qui apparaît dans les fichiers de zone. Suivant la version de votre serveur de nom, cela cause des messages d’insulte, des plantages, ou cela empêche le transfert de la zone du primaire vers les secondaires.

RP (Responsible Person)

Cet enregistrement permet de donner les noms des responsables d’un nom de domaine. Le nom de domaine en question peut être une zone, ou simplement un nom de machine. Ce type d’enregistrement n’étant pas encore répandu, il faut vérifier que votre serveur de nom ainsi que tous les secondaires de la zone le supportent. Les deux paramètres sont d’une part une adresse de courrier électronique formatée de manière similaire à celle de l’enregistrement SOA, et d’autre part un autre nom de domaine. Pour cet autre nom de domaine, on fait figurer un enregistrement TXT donnant plus d’informations (téléphone, numéro de beep, etc.).

zone.fr. IN RP postmaster.zone.fr. sysadmins.zone.fr.

sysadmins.zone.fr. IN TXT « Telephone d’urgence: +33 (1) 99 99 99 99 »

Le déverminage des serveurs de noms

Analyse des messages d’erreur (UNIX)

Les versions récentes de BIND génèrent beaucoup plus de messages d’erreurs et vérifient plus en détail les configurations et le fonctionnement du serveur. Les messages sont envoyés au système à l’aide de la routine syslog() qui envoie les messages au processus syslog. Les messages sont envoyés avec comme identifiant daemon et une priorité variable en fonction du niveau de gravité du message.

Vous devez configurer votre syslog (généralement en modifiant le fichier /etc/syslog.conf) de manière à envoyer les messages daemon d’une priorité info ou supérieure dans un fichier. N’oubliez pas de signaler au processus syslog que le fichier a changé en lui envoyant un signal SIGHUP à l’aide de la commande kill.

Pour visualiser les messages envoyés au fur et à mesure, vous pouvez utiliser la commande tail en faisant : tail -f fichier.

Si la quantité de messages est trop importante, vous pouvez enregistrer les messages de priorité notice.

Dump du cache

A tout moment vous pouvez demander au serveur le contenu de son cache en mémoire. Il faut pour cela lui envoyer le signal SIGINT (3). Le serveur écrit alors son cache dans le fichier /usr/tmp/named_dump.db.

Ce fichier contient tous les enregistrements que le serveur a chargé en tant que primaire et secondaire, ainsi que les enregistrements obtenus au fur et a mesure de l’utilisation de celui-ci.

Le fichier peut être assez gros (quelques méga-octets) et pendant que le serveur écrit celui-ci, il ne réponds pas aux requêtes.

Interrogation du serveur

Pour déterminer si votre serveur de noms fonctionne bien, vous pouvez utiliser un certain nombre d’outils qui vont envoyer une requète et vous afficher la réponse. Plusieurs outils permettent de faire cela, les plus courants sont nslookup et dig. Ces deux programmes sont distribués avec BIND.

nslookup

nslookup est une sorte de Shell que vous lancez et avec lequel vous allez pouvoir effectuer des requêtes vers des serveurs de noms. Le manuel complet est disponible ici.

Pour utiliser nslookup, il faut exécuter à partir d’un Shell la commande nslookup. Une requête est envoyée à chaque fois que vous tapez un nom de domaine. Pour terminer, tapez contrôle-D.

Le type d’enregistrement demandé est par défaut A, mais peut être changé avec la commande set type=<type>. Un type particulier, ANY permet d’obtenir tous les enregistrements pour un nom donné dans le cache du serveur de noms interrogé. C’est à dire que si le serveur de noms à dans son cache uniquement des enregistrements NS pour une zone, vous n’obtiendrez pas l’ enregistrement SOA avec une requête de type ANY.

La commande server <serveur> permet de fixer le serveur auquel sera envoyé les requêtes. Par défaut,

nslookup utilise le premier serveur de la liste du fichier /etc/resolv.conf, ou localhost.

Interprétation des résultats

Les erreurs sont préfixées par trois étoiles. Les erreurs envoyées par nslookup sont celles définies par le protocole DNS.

Non-existent host/domain indique que le domaine demandé n’existe pas. No <type> records available for <domaine> indique que le domaine existe mais aucun enregistrement de ce type n’est enregistré pour ce domaine. Request to <serveur> timed-out indique que le serveur n’a pas répondu. Plusieurs causes sont possibles:

Le serveur désigné n’est pas atteignable (tester avec ping).

Le serveur désigné n’a pas pu joindre les serveurs nécessaires pour obtenir l’information.

Le serveur désigné est mal configuré, en particulier il est probable que le serveur se pose des questions à lui même. Cela arrive souvent quand un serveur devrait être primaire ou secondaire pour une zone mais ne l’est pas.

Server failure indique que la base de donnée d’un serveur interrogé est inconsistante, souvent quand un serveur devrait être primaire ou secondaire pour une zone mais ne l’est pas.

Un autre message important est: Non-authoritative answer. Ce message indique que le serveur interrogé n’est pas autoritaire pour le domaine demandé et vous renvoie les informations de son cache. Ces informations peuvent déjà avoir un certain age (l’age maximum est fixé par l’enregistrement SOA de la zone).

Exemple: Obtenir la liste des serveurs pour une zone

$ nslookup

> set type=NS

> inserm.fr

Server: ns1.nic.fr

Address: 192.93.2.1

Non-authoritative answer:

inserm.fr nameserver = mercure.tolbiac.inserm.fr

inserm.fr nameserver = isis.vjf.inserm.fr

inserm.fr nameserver = dpx.nancy.inserm.fr

Authoritative answers can be found from:

inserm.fr nameserver = mercure.tolbiac.inserm.fr

inserm.fr nameserver = isis.vjf.inserm.fr

inserm.fr nameserver = dpx.nancy.inserm.fr

mercure.tolbiac.inserm.fr internet address = 193.55.93.18

isis.vjf.inserm.fr internet address = 192.134.32.10

dpx.nancy.inserm.fr internet address = 193.55.2.1

Exemple: Vérification de la configuration d’une zone

> server ns1.nic.fr

Default Server: ns1.nic.fr

Address: 192.93.2.1

> nic.fr

Server: ns1.nic.fr

Address: 192.93.2.1

nic.fr nameserver = ns1.nic.fr

nic.fr nameserver = ns2.nic.fr

nic.fr nameserver = ns.oleane.net

nic.fr nameserver = ns.pipex.net

nic.fr preference = 100, mail exchanger = sagres.inria.fr

nic.fr preference = 200, mail exchanger = concorde.inria.fr

nic.fr

origin = ns1.nic.fr

mail addr = hostmaster.nic.fr

serial = 95021502

refresh = 21600 (6 hours)

retry = 3600 (1 hour)

expire = 3600000 (41 days 16 hours)

minimum ttl = 86400 (1 day)

ns1.nic.fr internet address = 192.93.2.1

ns2.nic.fr internet address = 192.93.2.4

ns.oleane.net internet address = 194.2.1.1

ns.pipex.net internet address = 158.43.128.1

sagres.inria.fr internet address = 128.93.2.26

concorde.inria.fr internet address = 192.93.2.39

dig

La commande dig fonctionne de manière identique a nslookup, mais avec une syntaxe différente. La présentation des résultats est différente, probablement plus proche du protocole DNS. Le manuel complet est disponible a l’adresse : https://www.afnic.fr/ext/dns/html/cours247.html

Trace des requêtes reçues

Le serveur peut envoyer à syslog une ligne par requête reçue. Pour mettre en route ou arrêter la capture, il faut envoyer à named le signal SIGWINCH.

Les lignes se présentent de la manière suivante :

XX /<source>/<nom de domaine>/<type>

Ou la source est l’adresse IP de la machine ayant envoyé la requête, le nom de domaine est le nom demandé, et le type est le type d’enregistrement demandé.

Malheureusement avec cette méthode, on ne connaît pas la réponse du serveur.

Trace de l’activité du serveur (debug)

Un certain nombre de routines du programme BIND peuvent écrire dans un fichier les actions effectuées. Le niveau de détail est variable. Par défaut (niveau de debug 0) aucune écriture est réalisée, plus le niveau de debug est élevé, plus les messages sont détaillés.

Le fichier de log des messages est /usr/tmp/named.run, on peut le visualiser avec tail -f

/usr/tmp/named.run. Si le niveau de debug est élevé, ce fichier peut grandir de plusieurs dizaine de kilo-octets par seconde…

Le niveau de debug est compris entre 0 et 10. On peut le fixer au démarrage de named avec l’option -d, ou l’augmenter de un en envoyant le signal SIGUSR1 et le remettre à zéro en envoyant le signal SIGUSR2.

Comprendre ce qui est écrit dans ce fichier est relativement ardu et dépasse largement le cadre de ce document. Néanmoins un coup d’œil de temps en temps permet de s’y habituer.

Exemple concret

Voici un exemple de configuration réel d’une machine et de différentes zones : /etc/name.conf (bind8.x)

options {

directory « /var/named »;

allow-transfer {

195.154.222.6;

195.154.101.73;

194.149.160.1;

};

multiple-cnames yes;

};

logging{

category lame-servers {

null;

};

category cname {

null;

};

};

server 194.149.160.1 {

bogus yes;

};

server 195.154.101.73 {

bogus yes;

};

server 195.154.222.6 {

bogus yes;

};

zone « . » {

type hint;

file « named.ca »;

};

zone « supersonique.net »{

type master;

file « supersonique.net.hosts »;

notify yes;

};

Fichier de zone : /var/named/supersonique.net.hosts

@ IN SOA host.supersonique.net. hostmaster.supersonique.net. (

2000051206

21600

3600

604800

86400

)

IN NS ns.supersonique.net.

IN NS ns7w.7ways.net.

IN NS ns.isdnet.net.

IN MX 0 mail

IN A 194.149.168.60

host IN A 194.149.168.60

ns IN A 194.149.168.60

www IN A 194.149.168.60

mail IN A 194.149.168.60

support IN A 194.149.168.60

admin IN A 194.149.168.60

news IN A 194.149.168.60

ftp IN CNAME www

smtp IN CNAME mail

pop IN CNAME mail

imap IN CNAME mail