Christophe : /* Principe général et Organisation */

2007-04-20T22:01:13Z

Principe général et Organisation

Nouvelle page

[[Category:Applications]]

=Principe général et Organisation=
http://www.linux-sottises.net/bind.php

http://fr.wikipedia.org/wiki/Domain_Name_System

http://fr.wikipedia.org/wiki/Serveurs_DNS_Racine

http://www.opendns.com/
==Le principe général==

Le [http://fr.wikipedia.org/wiki/Domain_Name_System 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 [http://en.wikipedia.org/wiki/Root_nameserver 13 serveurs racines] connus du monde entier. Ces serveurs contiennent la liste des serveurs des tld ([http://en.wikipedia.org/wiki/Top-level_domain top level domains]) qui correspondent aux extensions bien connues (org, com, fr...).

[[Image:Dns.png|center|La structure du DNS]]

L'espace des noms de domaines est divisé en <tt>"zones"</tt>. 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 <tt>"Transfert de zone"</tt> 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 <tt>"requête"</tt> 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 [http://www.bind9.net/manual/bind/9.3.0/Bv9ARM.html|BIND 9 Administrator Reference Manual] de Nominum, Inc.

La configuration d'un serveur BIND se fait par l'intermédiaire de trois types de fichiers:
* <tt>/etc/named.conf</tt> 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 <tt>named.conf</tt>==
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:
* <tt>dig @nom_serveur txt chaos version.bind</tt> (linux uniquement)
* <tt>nslookup -ip_serv_dns, puis /> set class=chaos /> set type=txt /> version.bind </tt>

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

====directory====
L'option '''directory''' précise l'adresse du répertoire contenant les autres fichiers du DNS.

====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 <tt>allow-transfer{none;};</tt>
Il existe plusieurs moyens pour tester un transfert de zone:
* <tt>host -l nom_zone nom_serveur</tt> (linux uniquement)
* <tt>nslookup</tt> (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 <tt>/etc/bind/pri/exemple.com</tt> 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 <tt>rndc</tt>.
<licode file=/etc/named.conf>
controls
{
inet 127.0.0.1 allow { localhost; } keys { "key";};
};
</licode>

L'utilisation de la commande <tt>rndc</tt> 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 <tt>/etc/rndc.conf</tt>.

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 <tt>/etc/rndc.key</tt>, il suffit d'exécuter la commande <tt>rndc-confgen -a</tt>.

===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 <tt>/etc/rndc.conf</tt> et <tt>/etc/named.conf</tt> 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)===
<licode file=/var/bind/named/pri/exemple.com.zone>
$TTL 3h
</licode>

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.

<blockquote class=note>
'''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.
</blockquote>

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. (
2006042501
8H
2H
1W
1D)
</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.

<blockquote class=note>
'''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.
</blockquote>

===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.

<blockquote class=note>
'''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.
</blockquote>

===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.

<blockquote class=note>
'''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.
</blockquote>

<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. (
2002041514
8H
2H
1W
1D )

@ 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).

<blockquote class=note>
'''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>
</blockquote>

=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

<blockquote class=note>
'''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.
</blockquote>

=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 <tt>/etc/resolv.conf</tt> 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 -> -> ->.

<blockquote class=note>
'''Remarque :''' les paramètres DNS et WINS se trouvent dans la base de registre. Voici son contenu pour une machine à Toulouse:

<pre>
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"
</pre>
</blockquote>

=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 <tt>/etc/init.d/named reload</tt>
* 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. (
2006050211
8H
2H
1W
1D)

@ 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

{{Copy|2006|Christophe de Livois|FDL}}

DNS - Historique des versions

Christophe : 1 version

Christophe : /* Principe général et Organisation */

← Version précédente	Version du 28 mai 2012 à 20:31
(Aucune différence)

DNS - Historique des versions

Christophe : 1 version

Christophe : /* Principe général et Organisation */

Christophe : 1 version

Christophe : /* Principe général et Organisation */