Principe général et Organisation

Le principe général

Le DNS ou "Domain Name System" est le système au sens large qui permet d'associer un nom de machine à son adresse IP et vice-versa. C'est le DNS qui permet de savoir que l'adresse IP de monserveur.livois.com est 192.168.0.5.

Le DNS est un système distribué. Sur Internet, un grand nombre de serveurs DNS contiennent chacun une petite partie de l'information associant un nom de machine à son adresse IP. Ces serveurs communiquent entre eux pour que chaque personne connectée à Internet puisse avoir accès à l'ensemble de cette information.

Le DNS a une structure d'arbre. A la racine (.) se trouvent 13 serveurs racines connus du monde entier. Ces serveurs contiennent la liste des serveurs des tld (top level domains) qui correspondent aux extensions bien connues (org, com, fr...).

L'espace des noms de domaines est divisé en "zones". Chaque zone dépend d'un serveur DNS primaire qui a autorité sur elle. Pour assurer une redondance, on lui associe souvent un ou plusieurs serveurs DNS secondaires pour la zone. Ainsi, si un serveur tombe en panne, les autres serveurs assurent la relève.

On appelle "Transfert de zone" le transfert des données du primaire vers un secondaire pour le mettre le jour. Ce transfert de zone s'effectue aujourd'hui rapidement après le changement des données du primaire.

On appelle "requête" la demande DNS d'un client. Ainsi, si je veux récupérer l'adresse IP du serveur monserveur.livois.com, j'envoie une requête à un serveur DNS de la zone livois.com.

Les serveurs DNS peuvent aussi transférer certaines requêtes vers un autre serveur. Ainsi, toutes les requêtes qui ne concernent pas la zone livois.com sont transférées au serveur DNS groupe.

Explication des fichiers de configuration d'un serveur BINDv9

Les paramètres présentés ici ne concernent qu'une petite partie des fonctionnalités de BIND. L'explication de tous les paramètres se trouve dans le chapitre 6 du 9 Administrator Reference Manual de Nominum, Inc.

La configuration d'un serveur BIND se fait par l'intermédiaire de trois types de fichiers:

/etc/named.conf qui donne la configuration générale et le nom des zones
les fichiers de zones qui donnent la correspondance nom -> ip pour la zone
les fichiers de zones inverses qui donnent la correspondance ip -> nom pour un réseau

La configuration de `named.conf`

Ce fichier comporte 5 types de champs disctincts :

les options générales
les définitions de zones
les définitions de zones inverses
le champ "controls"
le champ "key"

options générales

Ce fichier commence par une partie "options" qui définit les options générales, communes à chaque zone. <licode file /etc/named.conf> options {

 version "";
 directory "/var/bind";
 forward first;
 forwarders 
 {
   ip_du_dns_FAI;
 };
 allow-transfer {none;};

}; </licode>

version

L'option version permet de cacher la version du serveur BIND utilisé. Pour des raisons de sécurité, il est important de cacher le numéro de version qui donne des indication sur les failles de vulnérabilités de l'application. (cf http://www.isc.org/products/BIND/bind-security.html).

Il existe plusieurs moyens pour récupérer le numéro de version d'un serveur BIND à distance:

dig @nom_serveur txt chaos version.bind (linux uniquement)
nslookup -ip_serv_dns, puis /> set class=chaos /> set type=txt /> version.bind

Sur le serveur, la commande "named -v" donne toujours le vrai numéro de version de l'application.

recursion

If yes, and a DNS query requests recursion, then the server will attempt to do all the work required to answer the query. If recursion is off and the server does not already know the answer, it will return a referral response. The default is yes. Note that setting recursion no does not prevent clients from getting data from the server's cache; it only prevents new data from being cached as an effect of client queries. Caching may still occur as an effect the server's internal operation, such as NOTIFY address lookups. See also fetch-glue above.

forward

Cette option n'a un intérêt que si un "forwarder" est renseigné. Il existe deux paramètres options forward :

forward only implique que le serveur ne fait que transférer les requêtes sauf s'il a lui même la réponse!
forward first est l'option par défaut. Elle autorise le serveur à chercher une réponse ailleurs (via les serveurs root ou tld) si le forwarder n'a rien trouvé.

L'option forwarders donne la liste des serveurs DNS à qui transférer les requêtes auxquelles le serveur n'arrive pas lui même à répondre.

Les forwarders peuvent être les serveurs de opendns (cf http://guide.opendns.com/).

allow-transfer

Ces options de transfert de requêtes peuvent être redéfinies pour chaque zone.

L'option allow-transfer autorise les transferts de zone pour les serveurs listés. Cette option existe aussi comme paramètre de zone. Elle est alors prioritaire. Par défaut, les transferts sont autorisés à tout le monde. Pour les interdire, il suffit d'écrire allow-transfer{none;}; Il existe plusieurs moyens pour tester un transfert de zone:

host -l nom_zone nom_serveur (linux uniquement)
nslookup (FIXME)

A noter que l'on peut commenter une ligne de trois façons. On peut mettre un #, ou // en début de ligne. La troisième façon est d'entourer le paragraphe à commenter d'un /* */, comme en langage c.

définitions de zones

<licode file=/etc/named.conf> zone "exemple.com" {

 type master;
 notify yes;
 allow-transfer {192.168.100.11;};
 file "pri/exemple.com";

}; </licode>

Il faut toujours commencer par définir le "type" du serveur pour chaque zone:

master si c'est un serveur primaire pour la zone
slave si c'est un serveur secondaire
hint est un type particulier qui indique l'adresse des 13 serveurs racines (.)

Les paramètres notify et allow-transfer précisent les transferts de zone.

L'option notify permet au serveur d'envoyer un message NOTIFY aux autres serveurs de la zone quand l'information qu'il contient a changé.

L'option allow-transfer donne une liste des serveurs qui peuvent demander un transfert de zone (après avoir reçu un message NOTIFY par exemple!). Pour des raisons de sécurité, il est important de limiter cette liste. En effet, un transfert de zone donne des informations importantes (la correspondance ip/nom de machine!) sur le réseau.

Le paramètre file donne l'adresse du fichier définissant la zone. Ce paramère tient compte de l'option directory. Ainsi, l'exemple précédent indique que le fichier /etc/bind/pri/exemple.com contient les informations de la zone exemple.com. Le répertoire "pri" (primary zone) est en général créé sur le serveur primaire d'une zone. Le secondaire se voit octroyé le répertoire "sec" (secondary zone).

définitions des zones inverses

<licode file=/etc/named.conf> zone "100.168.192.in-addr.arpa" {

 type master;
 notify yes;
 allow-transfer {192.168.100.11;};
 file "pri/192.168.100";

}; </licode>

Les paramètre d'une zone inverse sont les même que ceux d'une zone. Seulement le nom de la zone commence par le début inversé de l'adresse ip , suivi du suffix "in-addr.arpa". Une zone inverse "168.192.in-addr.arpa" aurait été envisageable. Cependant, elle n'est pas nécessaire dans la mesure où les parisiens n'ont pas besoin du dns inverse pour les serveurs de régions.

Le champ controls

Il permet de définir les canaux de communication utilisés par les administrateurs avec la commande rndc. <licode file=/etc/named.conf> controls {

 inet 127.0.0.1 allow { localhost; } keys { "key";};

}; </licode>

L'utilisation de la commande rndc est limitée par les paramètres allow et keys. Allow limite l'accès par adresse IP alors que keys limite l'accès par clé d'authentification. "key" doit être le même paramètre que dans /etc/rndc.conf.

En pratique, la commande rndc est utilisée quand on remet à jour les fichiers de zone du serveur (/etc/init.d/named reload).

Pour créer une clé rndc dans /etc/rndc.key, il suffit d'exécuter la commande rndc-confgen -a.

Les paramètres TSIG (Transaction Signatures)

Une clé TSIG fournit les moyens d'authentifier et de vérifier la validité des données échangées, en utilisant une clé secrète entre un client et un serveur ou entre deux serveurs.

Le champ "key" comporte :

l'algorithme de cryptage de la clé. Le seul utilisé pour l'instant est hmac-md5.
la clé secrète utilisée pour les échanges cryptés TSIG

La clé peut être utilisée dans un paramètre server pour assurer un cryptage des communications avec ce serveur. Ce niveau de sécurité n'est sans doute pas nécessaire dans un réseau local. Par contre, il peut être intéressant de le mettre en place pour les régions.

<licode file=/etc/named.conf> key "key" {

       algorithm       hmac-md5;
       secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";

}; </licode>

La clé est secrète, par conséquent tous ceux qui la possèdent peuvent s'authentifier ou décrypter la communication. Il est donc primordial de la préserver en n'autorisant l'accès en lecture au fichiers /etc/rndc.conf et /etc/named.conf qu'aux l'utilisateurs utilisant rndc et named.

La configuration des fichiers de zone

Les fichiers de zones primaires ou secondaires sont quasi-identiques. Par convention, il sont placés dans des répertoires différents (pri pour les primaires, sec pour les secondaires). En pratique, les fichiers de zones secondaires sont automatiquement remplis par transfert de zone. On ne remplit donc que les premières lignes (TTL, SOA et NS) en prenant soin d'indiquer l'adresse ip du serveur primaire de la zone.

Les commentaires sont introduits par un ";" et s'étendent jusqu'à la fin de la ligne.

Time To Live (TTL)

Chaque fichier de zone commence par une directive $TTL qui indique la durée de vie (time to live) des informations de cette zone lorsqu'elles seront dans le cache d'un autre serveur DNS.

Remarque : Lorsqu'un changement de paramétrage de DNS est prévu, il est intéressant de diminuer ce paramètre (par exemple à 1h) suffisament de temps avant le changement. Ainsi, ce changement se diffusera plus rapidement auprès des différents serveurs DNS.

Le reste du fichier de zone contient des définitions de Ressource Records (RR). Un RR est une ligne d'information DNS. Les plus utilisés (SOA, NS, MX, A et CNAME) sont décrits dans les paragraphes qui suivent.

Start Of Authority (SOA)

<licode file=/var/bind/pri/exemple.com.zone> @ IN SOA ns.exemple.com. hostmaster.exemple.com. (

</licode>

Le premier RR du fichier de zone est le SOA. La ligne indique:

le nom de la zone ou @ pour utiliser le nom indiqué dans named.conf
la classe INternet (il existe d'autres classes qui ne sont pas utilisées en pratique).
le type du RR (SOA)
le nom du serveur maître de la zone (ns.exemple.com)
l'adresse électronique du responsable de la zone. (La RFC 2142 demande que cette adresse soit "hostmaster").

Il est important de noter les points (.) terminaux qui indiquent la racine du DNS.

Suivent 5 paramètres:

le numéro de série qui doit être IMPERATIVEMENT augmenté à chaque changement de zone. Sinon les transferts de zone vers les secondaires n'auront pas lieu. Par convention (et parce que ça tient dans un entier de 32 bits) , on utilise un format AAAAMMJJNN où AAAAMMJJ correspond à la date et NN au numéro de modification.
la durée de rafraîchissement qui était utilisée par les secondaires pour savoir à quel intervalle ils devaient interroger le primaire pour savoir si une zone avait été modifiée. Maintenant, le primaire avertit (notify) immédiatement les secondaires de toute modification et ce paramètre n'est plus utilisé.
la durée de nouvelle tentative qui indique aux secondaires le temps d'attente avant de redemander un transfert de zone qui a échoué.
la durée d'expiration qui indiquent aux secondaires le temps au bout duquel il doivent effacer leurs données après une période de transferts de zone infructueux.
le TTL négatif qui indique aux caches combien de temps ils doivent conserver les réponses négatives.

Les serveurs de noms d'une zone (NS)

<licode file=/var/bind/pri/exemple.com.zone> @ NS ns.exemple.com. </licode>

Les RR NS indiquent les serveurs de noms de la zone.

Remarques : Il aurait été syntaxiquement correct de remplacer les @ par du vide. En effet, la valeur de la première colonne est alors la même que celle de la première colonne de la ligne précédente. La classe (IN) n'est pas mentionnée car elle est par défaut celle de la ligne (RR) précédente.

Les serveurs de messagerie (MX)

<licode file=/var/bind/pri/exemple.com.zone> exemple.com. MX 10 mail.exemple.com. </licode>

Le RR MX (Mail eXchanger) indique quel est le serveur de messagerie associé à une zone. Le nom de la machine est précédé d'un entier. Quand la zone dispose de plusieurs serveurs de messagerie, cet entier indique la priorité relative du serveur correspondant au RR. Plus l'entier (ou poids) est petit, plus le serveur est prioritaire. Ainsi, si le serveur de poids le plus faible ne répond pas, le courier sera envoyé au deuxième, puis au troisième et ainsi de suite. Il est possible de mettre le même poids à plusieurs serveurs pour faire de la répartition de charge.

Remarque : Le nom de machine du serveur de messagerie doit être associé à un RR A. Un RR CNAME n'est pas suffisant et invaliderait la ligne MX.

Les (A)

<licode file=/var/bind/pri/exemple.com.zone> localhost A 127.0.0.1

dns A 192.168.100.10 dns2 A 192.168.100.11 </licode>

Le RR A est le RR de base. C'est lui qui associe un nom de machine à une adresse IP.

Remarque : Dans l'exemple, l'absence de point après les noms de machine indiquent que leur FQDN (Fully Qualified Domain Name) est nom.domaine_de_la zone. En l'occurence, le FQDN de dns2 est dns2.exemple.com. On pourrait ainsi rajouter le site www.exemple.net dans le fichier de zone. En pratique cela fonctionne, seulement la réponse des serveurs exemple.net ne fait pas autorité pour cette zone.

<licode file=/var/bind/pri/exemple.com.zone> www.exemple.net. A 69.xxx.xxx.xxx </licode>

Les noms canoniques (CNAME)

<licode file=/var/bind/pri/exemple.com.zone> www CNAME dns </licode>

Le RR CNAME permet d'associer plusieurs noms de machine à une même adresse IP. Quand on lui demandera l'adresse IP de www.exemple.com., le serveur DNS lui renverra celle de dns.exemple.com.

La configuration des fichiers de zone "inverse"

<licode file=/var/bind/pri/192.168.100.zone> @ IN SOA ns.exemple.com. hostmaster.exemple.com. (

@ NS ns.exemple.com.

10 PTR dns1.exemple.com. 11 PTR dns2.exemple.com. </licode> Les zones inverses dépendent du domaine in-addr.arpa. Comme la hiérarchie des domaines se lit de droite à gauche, les adresses IP sont écrites à l'envers du sens habituel. Pour le reste, le fichier de zone est très semblable à un fichier de zone directe, sauf qu'on utilise des RR de type PTR. En première colonne, on écrit que le dernier octet de l'adresse IP ( la suite étant complétée par 100.168.192.in-addr.arpa en l'absence du point final).

Remarque : si la zone inverse avait été 168.192.in-addr.arpa (possibilité mentionnée en 2.1.3), les RR PTR auraient eu la forme suivante: <licode file=/var/bind/pri/192.168.zone> 100.10 PTR dns.exemple.com. </licode>

La configuration des serveurs NT

Configuration d'un serveur DNS (NT4)

Pour installer un serveur DNS, il faut:

ajouter et exécuter le composant "Service DNS"
créer et paramétrer les zones

Lors du paramétrage des zones, on indique:

le serveur maître (ou primaire) : dns1.exemple.com (192.168.100.10)
le redirecteur : ip_du_dns_FAI
les zones secondaires

Les zones secondaires définies sont :

exemple.com
100.168.192.In-addr.arpa (à Lyon et Toulouse); intégration WINS
101.168.192.In-addr.arpa (à Lyon); intégration WINS-R
102.168.192.In-addr.arpa (à Toulouse); intégration WINS-R

Configuration d'un serveur WINS

Pour installer un serveur WINS, il faut:

ajouter et exécuter le composant "Service de nom Internet Windows"
paramétrer la duplication entre les serveurs

Il existe deux modes de réplication:

la réplication tirée (pull) ne demande que les changements pour la base de référence ou primaire.
la réplication poussée (push) transmet l'intégralité de la base, ce qui sollicite plus la bande passante.

Exemple de paramétrage: FIXME : Explication schéma 0,5,15,20...

Intervalle de réplication tirée: 30mn
Seuil de réplication poussée: 5000

Remarque : Il peut être utile de faire un "push", soit pour initialiser une base, soit parce que le nombre de changements est trop élevé. Il ne faut donc pas désactiver le "push" mais placer son seuil à une valeur importante. Dès cet instant, les "pull" seront quasiment les uniques modes d'échange réalisés.

Configuration des clients

La configuration des clients est très simple. Il suffit d'indiquer deux adresses de serveur DNS. Pour les stations NT, on rajoute aussi les adresses des serveurs WINS.

Pour Paris, les DNS à donner sont, sans aucun ordre, 192.168.100.10 et 192.168.100.11.

Pour Lyon, il faut donner en premier 192.168.101.11 et un des DNS de Paris en second.

Pour Toulouse, il faut donner en premier 192.168.102.20 et un des DNS de Paris en second.

Les clients Linux

Le fichier à configurer est /etc/resolv.conf qui contient trois lignes: <licode file=/etc/resolv.conf> search exemple.com nameserver 192.168.100.10 nameserver 192.168.100.11 </licode>

L'option search précise le nom de domaine par défaut à accoler au nom de machine.

L'option nameserver définit les deux serveurs DNS utilisés.

Les clients NT

La configuration du client NT se fait à partir de la configuration IP:

Pour configuer le DNS:

FIXME -> -> ->.

Pour configurer le WINS:

FIXME -> -> ->.

Remarque : les paramètres DNS et WINS se trouvent dans la base de registre. Voici son contenu pour une machine à Toulouse:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\
Clé: Parameters
Valeur: NameServer
Type: REG_SZ
Données: "192.168.102.20 192.168.100.10" 

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Adapters\
Clé: <nom du pilote de carte réseau>
Valeur: NameServer
Type: REG_SZ
Données: "192.168.102.20"

Les opérations de maintenance

Vérification du fonctionnement du DNS

Avant de vérifier le fonctionnement du DNS, il faut se rappeler que le DNS sert juste à faire la transposition adress IP / nom de machine. Le DNS ne peut être mis en cause que si cette transposition n'est pas faite.

A partir du serveur DNS Linux

vérifier que le service named tourne (ps aux|grep named)
vérifier que le port udp 53 est ouvert (netstat -una)

Si le serveur ne tourne pas, il faut le relancer:

#/etc/init.d/named start

En cas de problèmes vérifier les logs :

#grep named /var/log/messages

Utiliser l'outil rndc (remote name domain control)

http://www.isc.org/sw/bind/arm93/Bv9ARM.ch03.html#rndc

dumpdb [-all|-cache|-zone] [view ...]

Dump the server's caches (default) and / or zones to the dump file for the specified views. If no view is specified all views are dumped.

status

Display status of the server. Note the number of zones includes the internal bind/CH zone and the default ./IN hint zone if there is not a explicit root zone configured.

A partir d'un client Linux

La commande host permet d'interroger un serveur DNS distant.

Pour vérifier le DNS interne:

#host nom_interne ip_du_serveur_dns

Exemple:

#host www 192.168.100.10
#host www.exemple.com 192.168.100.11

Pour vérifier le DNS externe:

#host nom_externe ip_du_serveur_dns

Exemple:

#host www.yahoo.com 192.168.100.10

La page de man (man host) donne plus de précision sur les fonctionnalités de la commande host.

A partir d'un client Windows

Sous Windows, on utilise nslookup en ligne de commande

#nslookup nom_machine ip_du_serveur_dns

Changer les données d'une zone

En pratique, le seul serveur primaire est dns (192.168.100.10). Il est serveur primaire pour 4 zones:

la zone exemple.com
la zone inverse 100.168.192
la zone inverse 101.168.192
la zone inverse 102.168.192

La procédure à suivre pour bind est la suivante:

se connecter à dns
prendre l'identité root
ajouter ou retirer l'adresse voulue dans /etc/bind/pri/nom_zone
NE PAS OUBLIER d'AUGMENTER le numéro de série (ex date du changement)
reloader le serveur /etc/init.d/named reload
vérifier que les changements ont été pris en compte (sur un secondaire au moins!)
se déconnecter

Lire les listes de sécurité

Il faut reconnaître que BIND a un passé chargé en failles de vulnérabilité. (cf http://www.isc.org/products/BIND/bind-security.html). Il est donc impératif de s'abonner à une liste de sécurité comme bugtraq chez http://www.securityfocus.com. Il faut en outre la consulter régulièrement!

Annexes

Fichiers de configuration de dns

named.conf

<licode file=/etc/bind/named.conf > /* Fichier de conf du DNS primaire de l'intranet*/ /* Le DNS pour sortir est 212.27.39.135 */ /* Les DNS secondaire sont 192.168.100.11 192.168.101.11 (Lyon) 192.168.102.20 (Toulouse)*/

options {

 version "";
 directory "/var/bind";
 forward only;
 forwarders{212.27.39.135;};

};

zone "exemple.com" {

 type master;
 notify yes;
 allow-transfer {192.168.100.11; 192.168.101.11; 192.168.102.20; localhost;};
 file "pri/exemple.com";

};

zone "100.168.192.in-addr.arpa" {

 type master;
 notify yes;
 allow-transfer {192.168.100.11; 192.168.101.11; 192.168.102.20; localhost;};
 file "pri/192.168.100";

};

zone "100.168.192.in-addr.arpa" {

 type master;
 notify yes;
 allow-transfer {192.168.100.11; 192.168.101.11; localhost;};
 file "pri/192.168.101";

};

zone "102.168.192.in-addr.arpa" {

 type master;
 notify yes;
 allow-transfer {192.168.100.11; 192.168.102.20; localhost;};
 file "pri/192.168.102";

};

zone "0.0.127.in-addr.arpa" {

 type master;
 file "pri/127.0.0";

};

key "key" {

       algorithm       hmac-md5;
       secret "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx";

};

controls {

 inet 127.0.0.1 allow { localhost; } keys { "key";};

}; </licode>

/var/bind/pri/exemple.com

<licode file=/var/bind/pri/exemple.com> $TTL 3h

@ correspond à la zone décrite par le fichier

@ IN SOA ns.exemple.com. hostmaster.exemple.com. (

@ IN NS ns.exemple.com. @ IN NS dns2.exemple.com. @ IN NS dns-lyon.exemple.com. @ IN NS dns-tlse.exemple.com.

Serveurs Linux

dns A 192.168.100.10 dns2 A 192.168.100.11

CNAME - Noms canoniques ou lien

linuxweb

www CNAME dns </licode>

/var/bind/pri/192.168.100

<licode file=/var/bind/pri/192.168.100> $TTL 3h @ SOA ns.exemple.com. hostmaster.exemple.com. (

                       2006050211
                       8H      ;refresh
                       2H      ;retry
                       1W      ;expire
                       1D )    ;default_ttl

@ NS ns.exemple.com. @ NS dns2.exemple.com. @ NS dns-lyon.exemple.com. @ NS dns-tlse.exemple.com.

1 PTR gw.exemple.com.

10 PTR dns.exemple.com. 11 PTR dns2.exemple.com. </licode>

Fichiers de configuration de dns2

/etc/bind/named.conf

<licode file=/etc/bind/named.conf> /* Fichier de configuration du DNS secondaire*/ /* Le DNS du FAI 212.27.39.135 */ /* Le DNS primaire est 192.168.100.10*/

options {

 version "";
 directory "/var/bind";
 forward only;
 forwarders {212.27.39.135;};
 allow-transfer {none;};

};

zone "exemple.com" {

 type slave;
 file "sec/exemple.com";
 masters {192.168.100.10; };

};

zone "100.168.192.in-addr.arpa" {

 type slave;
 file "sec/192.168.100";
 masters {192.168.100.10; };

};

zone "0.0.127.in-addr.arpa" {

 type master;
 file "pri/127.0.0";

};

key "key" {

       algorithm       hmac-md5;
       secret "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx";

};

controls {

 inet 127.0.0.1 allow { localhost; } keys { "key";};

}; </licode>

/var/bind/sec/exemple.com

<licode file= /var/bind/sec/exemple.com> $TTL 3h exemple.com IN SOA ns.exemple.com. hostmaster.exemple.com. (

                               2006050211 ; serial
                               28800      ; refresh (8 hours)
                               7200       ; retry (2 hours)
                               604800     ; expire (1 week)
                               86400      ; minimum (1 day)
                               )
                       NS      dns-lyon.exemple.com.
                       NS      dns-tlse.exemple.com.
                       NS      dns2.exemple.com.
                       NS      ns.exemple.com.

</licode>

/var/bind/sec/192.168.100

<licode file=/var/bind/sec/192.168.100> $ORIGIN . $TTL 3h 100.168.192.in-addr.arpa IN SOA ns.exemple.com. hostmaster.exemple.com. (

                               2006050211 ; serial
                               28800      ; refresh (8 hours)
                               7200       ; retry (2 hours)
                               604800     ; expire (1 week)
                               86400      ; minimum (1 day)
                               )
                       NS      dns-lyon.exemple.com.
                       NS      dns-tlse.exemple.com.
                       NS      dns2.exemple.com.
                       NS      ns.exemple.com.

</licode>

Tester son serveur DNS

http://www.DNSreport.com

http://www.dnsdoctor.org/

Ressources

DNS HOWTO

BIND White Paper - Nominum, Inc

BIND 9 Administrator Reference Manual

Frequently Asked Questions about BIND (nominum.com)

Administration de Réseaux - ENSTA

Copyright

Vous avez l'autorisation de copier, distribuer et/ou modifier ce document suivant les termes de la GNU Free Documentation License, Version 1.2 ou n'importe quelle version ultérieure publiée par la Free Software Foundation; sans section invariante, sans page de garde, sans entête et sans page finale. Pour plus d'informations consulter le site de l'APRIL.

DNS

Principe général et Organisation

Le principe général

Explication des fichiers de configuration d'un serveur BINDv9

La configuration de named.conf

options générales

version

directory

recursion

forward

allow-transfer

définitions de zones

définitions des zones inverses

Le champ controls

Les paramètres TSIG (Transaction Signatures)

La configuration des fichiers de zone

Time To Live (TTL)

Start Of Authority (SOA)

Les serveurs de noms d'une zone (NS)

Les serveurs de messagerie (MX)

Les (A)

Les noms canoniques (CNAME)

La configuration des fichiers de zone "inverse"

La configuration des serveurs NT

Configuration d'un serveur DNS (NT4)

Configuration d'un serveur WINS

Configuration des clients

Les clients Linux

Les clients NT

Les opérations de maintenance

Vérification du fonctionnement du DNS

A partir du serveur DNS Linux

Utiliser l'outil rndc (remote name domain control)

A partir d'un client Linux

A partir d'un client Windows

Changer les données d'une zone

Lire les listes de sécurité

Annexes

Fichiers de configuration de dns

named.conf

/var/bind/pri/exemple.com

/var/bind/pri/192.168.100

Fichiers de configuration de dns2

/etc/bind/named.conf

/var/bind/sec/exemple.com

/var/bind/sec/192.168.100

Tester son serveur DNS

Ressources

Copyright

Menu de navigation

Rechercher

La configuration de `named.conf`