Administration de Service DNS Sous Linux

IT

NISRO CLUB TUTORIEL INFORMATIQUE

1 Club Tutoriel Informatique

Administration de Service DNS

sous Linux

1. Historique

Comme nous le savons maintenant, l'adressage sur un réseau TCP/IP est basé sur des nombres

de 32 bits. Comme ils sont difficilement mémorisables, les hôtes sont généralement baptisés de façon

plus humaine, par de simples noms comme serveur, Machine1 ou compta. C'est alors au système de

trouver les adresses IP correspondantes : il s'agit de la résolution de noms.

Sur un petit réseau, il n'est pas très difficile de maintenir des tables de correspondances entre

les noms de machines et leurs adresses. Ces informations sont en principe contenues dans un fichier

nommé /etc/hosts. Lors de l'ajout ou la suppression d'hôtes, ou en cas de réassignation d'adresse, il

suffit de mettre à jour le fichier hosts sur toutes les machines. Il est évident que cette opération

devient quasi impossible sur des réseaux composés d'une très grande quantité de systèmes.

NIS, le Network Information System développé par Sun Microsystems, est une solution à ce

problème. NIS conserve le fichier hosts, ainsi que certaines autres informations, dans une base de

données sur une machine maître depuis laquelle des clients peuvent récupérer à tout moment ce dont

ils ont besoin. Mais là encore, cette approche n'est utilisable que sur des réseaux d'importance

moyenne, comme les réseaux locaux, car il faut stocker et maintenir la base de données hosts de

manière centralisée et la Distribuer à tous les serveurs.

Sur l'Internet, ces informations étaient aussi à l'origine stockées dans un unique fichier,

HOSTS.TXT. Il était maintenu au Network Information Center, ou NIC, et devait être téléchargé

puis installé par tous les sites connectés. La croissance du réseau engendra plusieurs problèmes. En

plus du surcroît de travail dû à la nécessité d'installer HOSTS.TXT régulièrement, la charge des

serveurs le diffusant devint vite trop élevée. En plus, tous les noms devaient être enregistrés auprès

du NIC, qui devait s'assurer que tous soient bien uniques.

C'est pourquoi, en 1984, une nouvelle méthode de résolution des noms fut adoptée, le Domain

Name System. Le DNS est l'œuvre de Paul Mockapetris, et règle simultanément les deux problèmes

que nous venons d'évoquer.

2. Introduction à DNS

Le service DNS a plusieurs objectifs :

La résolution des noms de machines en adresses IP (résolution directe). C’est l’objectif

principal

La résolution inverse (Reverse-DNS) des adresses IP en noms de machines

Rechercher l’adresse d’un serveur de messagerie pour l’envoi d’un courrier

IT



DNS organise les noms d'hôtes en une hiérarchie de domaines. Un domaine est un ensemble

de sites qui ont une certaine relation entre eux ; ils peuvent former un réseau particulier (toutes les

machines d'un campus par exemple), ou bien toutes les machines appartenant à une

organisation particulière (comme le Gouvernement) ou encore, être tout simplement proche

géographiquement parlant. Aux USA par exemple, toutes les universités sont regroupées dans le

domaine edu, chacune utilisant un sous-domaine la définissant mieux. L'université Groucho Marx

pourrait ainsi se trouver dans le domaine groucho.edu, et son Département de Mathématiques

pourrait être baptisé maths.groucho.edu. Les hôtes du département verraient alors leur nom ajouté à

tout cela ; ainsi la machine erdos serait connue comme erdos.maths.groucho.edu. C'est ce que l'on

appelle le fully qualified domain name, ou FQDN, qui identifie de manière unique cet hôte aux yeux

du monde entier.

Figure 1. Une partie de l'espace de nommage.

La figure montre une partie de l'espace de nommage. Tout en haut de l’arborescence, l'entrée

dénotée par un simple point, correspond à la racine et est appelé root domain. Pour indiquer qu'un

nom d'hôte est FQDN (c'est-à-dire complètement qualifié, et non pas relatif à un domaine local

implicite), on l'écrit parfois en le terminant par un point. Cela signifie que la dernière composante est

le domaine racine (root domain).

En fonction de sa position dans la hiérarchie, un domaine peut être appelé de premier niveau

(top-level), second niveau ou troisième niveau….

Voici plusieurs domaines américains de premier niveau que vous rencontrerez très souvent :

IT



edu Sites en rapport avec l'éducation (collèges, universités...).

com Entreprises commerciales.

org Organisations privées non commerciales.

net Passerelles et autres machines administratives d'un réseau.

mil Institutions militaires américaines.

gov Institutions gouvernementales américaines.

Techniquement, les quatre premiers appartiennent aux Etats-Unis, mais vous pourrez quand

même rencontrer des sites d'autres pays dans ces domaines ; en particulier dans net. En revanche, mil

et gov sont exclusivement américains.

En dehors des USA, chaque état utilise généralement un domaine de premier niveau bien

à lui, constitue d'après les deux lettres définissant le code pays ISO-3166. La Maroc, par exemple,

utilise le domaine ma ; la France fr, l'Allemagne de, et l'Australie au. En dessous, chaque NIC est

libre d'organiser les noms comme il l'entend. L'Australie, par exemple, utilise des domaines de

second niveau identiques aux niveaux internationaux supérieurs : com.au, edu.au, et ainsi de suite.

3. Présentation des concepts

Notion de domaine

Un "domaine" est un sous-arbre de l'espace de nommage. Par exemple ".com" est un domaine,

il contient toute la partie hiérarchique inférieure de l'arbre sous jacente au nœud ".com".

Un domaine peut être organisé en sous domaines. ".sysco.com" est un sous domaine du domaine

".com". Un domaine peut être assimilé à une partie ou sous-partie de l'organisation de l'espace de

nommage.

Figure 2. Les domaines

IT



Notion de zone

Une "zone" est une organisation logique (ou pour être plus précis, une organisation

administrative) des domaines. Le rôle d'une zone est principalement de simplifier l'administration des

domaines. Le domaine ".com" peut être découpé en plusieurs zones, z1.com, z2.com...zn.com.

L'administration des zones sera déléguée afin de simplifier la gestion globale du domaine.

Figure 3. Les zones

Notion de délégation

La délégation consiste à déléguer l'administration d'une partie du domaine (zone ou sous-zone)

aux administrateurs de cette zone. Il y a transfert de responsabilité pour l'administration de cette zone.

Les serveurs de la zone auront autorité sur la zone et auront en charge la responsabilité de la

résolution de nom sur la zone. Les serveurs ayant autorité sur le domaine auront des pointeurs vers

les serveurs de noms ayant autorité sur chaque zone du domaine.

IT



Figure 4. La délégation

Remarque :

Un domaine est une organisation de l'espace de nommage. Il peut être attaché à un domaine

parent, et/ou peut avoir un ou plusieurs sous-domaines enfants.

Les zones correspondent à des organisations administratives des domaines. Un domaine peut

être administré par plusieurs zones administratives, mais il est possible aussi qu'une zone

serve à l'administration de plusieurs domaines. Prenons l'exemple d'un domaine "sysco.ma",

membre de ".ma". Il peut être composé de trois sous-domaines maroc.sysco.ma,

france.sysco.ma, espagne.sysco.ma et de deux zones d'administration. Une au Maroc pour les

sous-domaines maroc.sysco.ma, espagne.sysco.ma (il n'y a pas de délégation), et une pour

france.sysco.ma, il y a délégation.

L'adressage IP correspond à une organisation physique des nœuds sur un réseau ip.

L'organisation de l'espace de nommage est complètement indépendante de l'implantation

géographique d'un réseau ou de son organisation physique.

Les seules machines connues au niveau de l'espace de nommage, sont les serveurs de nom

"déclarés".

La cohérence (le service de résolution de nom) entre l'organisation de l'espace de nommage et

les organisations physiques des réseaux sur internet et réalisées par les serveurs de noms.

Le domaine in-addr.arpa

Le principe de la résolution de nom, consiste à affecter un nom d'hôte à une adresse IP. On parle

de résolution de nom directe. Le processus inverse doit pouvoir également être mis en ouvre. On

parle de résolution de nom inverse ou reverse. Le processus doit fournir, pour une adresse IP, le nom

correspondant. Pour cela il y a une zone particulière, in-addr.arpa, qui permet la résolution inverse

d'adresse IP.

IT



Figure 5. La résolution inverse

Par exemple, pour le réseau 192.68.1.0, on créera une zone inverse dans le domaine in-addr.arpa.

La zone de recherche inverse dans le domaine deviendra : 1.68.192.in-addr.arpa. Cette zone devra

répondre pour toutes les adresses déclarées dans la tranche 192.168.1.0 à 192.168.1.254.

On inscrira dans cette zone tous les nœuds du réseau pour lesquels on désire que la résolution

inverse fonctionne. Un serveur de nom peut, pratiquement, fonctionner sans la définition de cette

zone tant que le réseau n'est pas relié à l'internet. Si cela était le cas, il faudrait déclarer cette zone,

sans quoi, des services comme la messagerie électronique, ne pourrait fonctionner correctement.

4. Type de serveur DNS

Un serveur DNS peut être configuré pour fonctionner de différentes manières, soit en serveur :

Serveur de noms primaire : Un serveur de noms primaire contient toutes les données de la

zone ou du domaine. Toutes les modifications concernant ces données sont réalisés sur ce

serveur.

Serveur de nom secondaire : Le serveur de noms secondaire reçoit les données nécessaires

pour gérer sa zone d’autorité à partir du serveur de nom maître (master). Ce serveur peut être

un serveur de noms primaire ou un autre serveur de nom secondaire. La transmission des

informations de zone est définie par le terme de « transfert de zone ». Lors du démarrage d’un

serveur de noms secondaire, celui-ci établit une connexion vers son serveur de nom maître et

démarre le transfert de zone.

IT



Serveur cache : Les fonctions d’un serveur cache ne consistent qu’à prendre en compte et à

exécuter des requêtes, à assurer l’enregistrement intermédiaire des réponses et à renvoyer les

résultats. Un serveur cache ne dispose d’aucune autorité de domaine, c’est-à-dire que les

informations de zone n’y sont pas enregistrées. Au démarrage, un serveur cache ne peut

fournir aucune information, car elles ne seront construites qu’au cours du fonctionnement,

lors du traitement des réponses aux requêtes.

5. Fonctionnement

Le DNS fonctionne suivant le modèle client/serveur, ces composants principaux sont les clients

DNS, les serveurs DNS et les enregistrements de ressources DNS. Les enregistrements de

ressources se trouvent dans la base de données du serveur DNS. Si votre solution DNS est

connectée à Internet, les serveurs DNS situés sur Internet peuvent être utilisés

Le client lance des requêtes DNS (demandes de résolution) à travers une application spécialisée

appelée resolver. Ces requêtes sont généralement adressées à un serveur de noms par défaut (par

exemple le serveur de noms d'entreprise) ; sous UNIX, ce serveur est spécifié dans le fichier

/etc/resolv.conf.

Il existe deux types de requêtes : requêtes récursives et requêtes itératives.

IT



Requête récursive

Une requête récursive est une requête envoyée à un serveur DNS dans laquelle le client DNS

demande au serveur de fournir une réponse complète. En retour, le serveur peut uniquement renvoyer

une réponse complète ou indiquer qu’il ne sait pas résoudre le nom. Une requête récursive ne peut

pas être redirigée vers un autre serveur DNS.

Les requêtes récursives sont lancées par un client DNS ou par un serveur DNS configuré pour

utiliser des redirecteurs. Une requête récursive place toute la responsabilité de la réponse finale sur le

serveur interrogé.

Les données demandées.

Un message d’erreur indiquant que les données du type demandé n’existent pas.

Un message indiquant que le nom de domaine spécifié n’existe pas.

Requêtes itératives (non récursives)

Une requête itérative est une requête envoyée à un serveur DNS dans laquelle le client DNS

demande la meilleure réponse. Le résultat d’une requête itérative est souvent une référence à un autre

serveur DNS situé plus bas dans l’arborescence DNS.

Une requête itérative vise à ce que le serveur DNS, désormais en mesure d’utiliser la requête

récursive du client, soit chargé de trouver une réponse à la question de ce dernier. Le serveur DNS

interroge alors sa propre base de données ou s’adresse à d’autres serveurs DNS, situés à différents

niveaux de l’espace de noms de domaines, afin de trouver le serveur DNS qui fait autorité pour la

requête d’origine.

En règle générale, un serveur DNS envoie une requête itérative à d’autres serveurs DNS après

avoir reçu d’un client une requête récursive. Dans une requête itérative, le serveur de noms interrogé

renvoie au demandeur la meilleure réponse qu’il possède. La réponse à une requête itérative peut être

:

une réponse positive ;

une réponse négative ;

une référence à un autre serveur.

IT



Fonctionnement d’une requête itérative

Dans l’illustration, le serveur DNS local n’a pas réussi à résoudre le nom demandé en utilisant sa

mémoire cache et il ne fait pas autorité pour le domaine.

Il commence donc à rechercher le serveur DNS qui fait autorité en interrogeant d’autres serveurs

DNS. Pour trouver le serveur DNS qui fait autorité pour le domaine, le serveur DNS résout le nom de

domaine pleinement qualifié, de la racine jusqu’à l’hôte, en utilisant des requêtes itératives. Le

traitement de cet exemple se déroule comme suit :

1. Le serveur DNS local reçoit une requête récursive d’un client DNS. Par exemple : Le

serveur DNS local reçoit une requête récursive de Computer1 concernant

mail1.nwtraders.com.

2. Le serveur DNS local envoie une requête itérative au serveur racine pour obtenir un

serveur de noms faisant autorité.

3. Le serveur Racine répond par une référence à un serveur DNS plus proche du nom de

domaine demandé.

Par exemple : Le serveur racine répond par une référence au serveur DNS associé au domaine

.com.

4. Le serveur DNS local envoie ensuite une requête itérative au serveur DNS plus proche du

nom de domaine demandé.

Par exemple : Le serveur DNS local envoie une requête itérative au serveur DNS de .com.

IT



5. Le processus continue jusqu’à ce que le serveur DNS local reçoive une réponse faisant

autorité.

6. Configuration d’un serveur DNS sous unix

BIND (Berkeley Internet Name Domain), précédemment appelé: Berkeley Internet Name

Daemon est le serveur DNS le plus utilisé sur Internet, spécialement sur les systèmes de type UNIX

et est devenu de facto un standard.

La configuration de bind ce fait en modifiant le fichier :

/etc/named.conf : Contient les paramètres généraux.

/var/named/named.ca : Indique les serveurs dns racines.

/var/named/named.local : résolution locale des adresses loopback

et en créant des fichiers de zone dans le répertoire /var/named/.

/etc/named.conf

Le fichier racine pour la configuration du serveur de nom est le fichier "/etc/named.conf". Ce

fichier est lu au démarrage du service et donne la liste des fichiers qui définissent la base de données

pour la zone.

Déclaration options

La déclaration options permet de paramétrer des options globales du serveur de noms. Une seule

déclaration options peut être utilisée dans le fichier /etc/named.conf. Voici un exemple de déclaration

options avec les options les plus utilisés :

options {

Directory chemin ;

};

directory : spécifie le répertoire de travail du serveur de noms. Par défaut, le répertoire

/var/named est utilisé

Déclaration de zone

Une déclaration de zone définit les caractéristiques particulières d’une zone, tel que le nom de

son fichier de configuration … :

Zone nom_domaine in {

Type master ;

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

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

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

http://fr.wikipedia.org/wiki/Normalisation_(industrie_et_service)

IT



File nom ;

} ;

zone nom_domaine in {

type slave ;

masters {adr_ip ; [adr_ip ; ]} ;

file nom ;

} ;

zone «.» in {

type hint ;

file nom;

};

Dans la déclaration, nom-domaine correspond au nom de la zone. Cet attribut est particulièrement

important, puisqu'il représente la valeur par défaut assignée à la directive $ORIGIN utilisés au sein

du fichier de zone correspondant.

Parmi les options les plus courantes de la déclaration de zone figurent:

type : définit le type de zone. Ci-après figure une liste des types valides:

hint : un type spécial de zone utilisé pour diriger des transactions vers les serveurs de

noms racines qui résolvent des requêtes lorsqu'une zone n'est pas connue autrement.

Aucune configuration au-delà de la valeur par défaut n'est nécessaire avec une zone hint.

master : désigne le serveur de noms faisant autorité pour cette zone. Une zone devrait

être configurée comme de type master (maître) si les fichiers de configuration de la zone

se trouvent sur le système.

slave : désigne le serveur de noms comme serveur esclave pour cette zone. Cette option

spécifie également l'adresse IP du serveur de noms maître pour cette zone.

masters : l'option masters établit une liste des adresses IP à partir desquelles demander des

informations sur la zone faisant autorité. Cette option ne doit être utilisée que si la zone est

définie comme de type slave.

allow-transfer : spécifie les serveurs esclaves qui sont autorisés à requérir un transfert des

informations de la zone. Par défaut toutes les requêtes de transfert sont autorisées.

notify : informe les serveurs esclaves lorsqu'une zone est mise à jour. Les options suivantes

sont acceptées:

yes : informe les serveurs esclaves.

no : n’informe pas les serveurs esclaves.

file : spécifie le nom du fichier qui contient les données de configuration de la zone, dans le

répertoire de travail named.

allow-query : spécifie les clients qui sont autorisés à requérir des informations à propos de

cette zone. Par défaut toutes les requêtes d'informations sont autorisées.

IT



allow-update : spécifie les hôtes qui sont autorisés à mettre à jour dynamiquement des

informations dans leur zone. Par défaut aucune requête de mise à jour dynamique n'est

autorisée.

Ci-dessous se trouve un exemple de déclaration de zone pour le serveur de nom primaire

hébergeant ofppt.org :

Zone ofppt.org IN {

type master;

file db.ofppt;

allow-update {none};

};

La déclaration de zone pour le serveur esclave de ofppt.org ressemble à l’extrait ci-dessous :

Zone ofppt.org IN {

type slave;

file db.ofppt.org;

masters {192.168.0.1};

};

Fichiers de zone

Il existe deux fichiers de configuration pour chaque zone. L’un est nécessaire pour trouver

l’adresse IP d’après le nom de l’hôte (résolution directe) et l’autre pour trouver le nom d’hôte d’après

l’adresse IP (résolution inverse). Chaque fichier de zone est nommé selon le paramètre fourni à

l’option file dans la déclaration zone (/etc/named.conf).

Directive de fichier de zone

Les directives sont identifiées par le symbole ($) suivit du nom de la directive. Elles apparaissent au

haut du fichier de zone. Les directives les plus couramment utilisées sont les suivantes:

$TTL : règle la valeur par défaut de Time to Live (TTL) (ou temps de vie) pour la zone. Cette

valeur exprimée en secondes, correspond à la durée pendant laquelle les enregistrements de

ressources de la zone resteront valides. Chaque enregistrement de ressources peut contenir

sa propre valeur TTL, qui remplace alors cette directive. En accroissant cette valeur, les

serveurs de noms distants peuvent mettre en cache ces informations de zone pendant plus

longtemps. Cela réduit le nombre de requêtes effectuées au sujet de cette zone, mais rallonge

également le temps nécessaire pour la prolifération des changements des enregistrements de

ressources.

$ORIGIN : attache le nom de domaine à tout enregistrement non-qualifié. L'utilisation de la

directive $ORIGIN n'est pas nécessaire si l'on nomme la zone dans /etc/named.conf parce que

le nom de la zone est utilisé par défaut, comme la valeur de la directive $ORIGIN

Enregistrement de ressources

Les enregistrements de ressources représentent les premiers composants d’un fichier de zone. Il

existe de nombreux types différents d’enregistrements de ressources, les plus fréquemment utilisé

sont énumérés ci-dessous.

IT



SOA (Start of Authority) : L’enregistrement SOA (ou Origine d’autorité) indique l’origine

de la zone. Voici la syntaxe de cet enregistrement :

@ IN SOA nom_serveur. email_contact. (

numero_serie ; Serial

rafraichissement ; Refreah

nombre_essais ; Retry

expiration ; Expire

ttl_minimum) ; Minimum

Le symbole @ place la directive $ORIGIN (ou le nom de domaine). Le serveur de noms

primaire faisant autorité pour ce domaine est utilisé pour le nom_serveur et l'adresse email de la

personne à contacter à propos de cet espace de nom est remplacée par email_contact.

Voici la description des paramètres d’un enregistrement SOA :

numéro_série est incrémentée chaque fois que vous changez le fichier de zone afin que

named sache qu'il doit recharger cette zone. La valeur numéro_série est utilisée par le serveur

esclave pour déterminer s'il est en train d'utiliser des données de zone périmées et doit donc

les rafraîchir.

rafraîchissement indique à tout serveur esclave combien de temps il doit attendre avant de

demander au serveur de noms maître si des changements ont été effectués dans la zone.

nombre_essai précise au serveur de noms esclave l'intervalle pendant lequel il doit attendre

avant d'émettre une autre requête de rafraîchissement, au cas où le serveur de noms maître ne

répondrait pas.

durée

indiquée dans expiration ne se soit écoulée, le serveur esclave cesse de répondre en tant

qu'autorité pour les requêtes au sujet de cet espace de nom.

ttl_minimum demande que d'autres serveurs de noms placent en cache les informations

pour cette zone pendant au moins cette durée (en secondes).

NS : Name Server

L’enregistrement NS indique le serveur de noms responsable d’un domaine. Sa syntaxe est la

suivante :

IN NS seveur.

A : Address

L’enregistrement A indique l’adresse d’un hôte. Voici la syntaxe de cet enregistrement :

nom_hôte_complet IN A adresse_IP

Par exemple, la ligne :

www.ofppt.org. IN A 10.73.127.132

IT



Indique l’adresse IP du serveur Web www.ofppt.org. Le fichier de zone doit contenir au moins un

enregistrement A par hôte. Il est possible d’indiquer uniquement le nom de l’hôte, comme dans

l’exemple suivant :

www IN A 10.73.127.132

Le nom de domaine sera automatiquement ajouté au nom de l’hôte.

PTR : Domain Name Pointer

Cet enregistrement transforme une adresse IP en nom d’hôte. C’est le service des noms de

domaine inverse. Voici la syntaxe d’un enregistrement PTR :

adresse_IP IN PTR nom_hôte.

Par exemple, l’enregistrement

10.73.127.132 IN PTR www.ofppt.org.

associe l’adresse IP 10.73.127.132 à l’hôte www.ofppt.org.

CNAME : Canonical Name

L’enregistrement CNAME indique l’alias d’un hôte officiel. Voici la syntaxe d’un enregistrement

CNAME :

nom_alias IN CNAME nom_hote.

Par exemple, l’enregistrement

ftp.ofppt.org. IN CNAME www.ofppt.org.

indique que le nom ftp.ofppt.org. est associé à www.ofppt.org. . Il est aussi possible d’utiliser

uniquement les noms d’hôtes comme dans l’exemple suivant :

ftp IN CNAME www

MX :

Named.ca Ce fichier n’a pas à être modifier. Il contient les adresses des serveurs dns racine.

named.local @ IN SOA linux.ofppt.org. root. ofppt.org .(

2000101500 ; numéro de série

28800 ; rafraîchissement toutes les 8 heures

14400 ; nouvel essai toutes les 4 heures

604800 ; expiration dans 7 jours

86400 ) ; temps de vie minimal 24 heures

NS linux.ofppt.org.

1 PTR localhost.

IT



Normalement, les valeurs de ce fichier ne doivent pas être modifiées. Si une modification doit être

faite dans ce fichier vous devez modifier le numéro de série doit être modifié afin de faire connaître

cette modification aux autres serveurs dns.

7. Configuration d’un client DNS

Pour accéder aux différents serveurs de l’Internet, il est nécessaire de configurer le client DNS.

La partie cliente d’un DNS s’appelle un « resolver ». Il s'agit d'un ensemble de fonctions écrites en C

permettant aux différents programmes de lancer une requête de résolution de nom. Les fichiers de

configuration du « resolver » s'appellent /etc/resolv.conf et /etc/hosts.conf.

/etc/host.conf

Ce fichier permet de spécifier au système la manière de résoudre les adresses IP en fonction des

noms. Si vous utilisez les services d'un serveur de noms, il doit contenir ces deux lignes:

order hosts, bind

multi on

La première ligne des fichiers définit l’ordre dans lequel les services de résolution de noms

doivent être interrogés. Dans notre exemple, c’est d’abord le fichier local /etc/hosts qui est parcouru.

Si aucune correspondance n’est trouvée, le programme interroge le serveur de noms.

La deuxième ligne indique, par le terme « multi on », permet d'avoir plusieurs adresses IP pour un

même nom de machine dans /etc/hosts.

/etc/resolv.conf

Permet d'affecter les serveurs de noms à interroger pour faire la résolution des noms.

search microapp.fr

# Adresse du serveur de noms

nameserver 205.1.1.1



L’entrée « search » impose au programme de tenter de résoudre un nom incomplet. Ce nom

de domaine est ajouté après les noms incomplets. Cette entrée s’appelait précédemment « domain »,

pour ce fichier. Conformément à la demande RFC1535 (Request For Comment 1535), il est

fortement recommandé de ne plus utiliser l’entrée « domain ».

8. Démarrage du serveur DNS

Il est possible de démarrer le serveur de nom manuellement à l’aide de la commande suivante :

#service named restart / start / stop

IT



9. teste du serveur DNS

Les commandes ping nslookup, host et dig permettent de tester le serveur DNS, elles sont décrites

dans les sections suivantes.

- Ping

Le programme ping permet de vérifier si une connexion fonctionne en affichant de l’information

semblable à celle ci-dessous :

# ping shuttle.mike.fr

PING shuttle.mike.fr (132.195.99.2): 56 data bytes

64 bytes from 132.195.99.2: imcp_seq=0 ttl=254 time 5.9 ms



- dig

L'utilitaire dig permet de faire des requêtes DNS évoluées et fournit un maximum d'informations sur

la requête. Il est très utile pour vérifier la bonne configuration d'un serveur DNS.

Exemples d'utilisation de dig :

Requête sur le champ "A" du nom www.mondomaine.org auprès du serveur DNS 12.42.112.242 :

% dig @12.42.112.242 www.mondomaine.org A

Requête sur la champ "MX" du nom mondomaine.org auprès du serveur DNS 12.42.112.242 :

% dig @12.42.112.242 mondomaine.org MX

Requête sur tous les champs du nom mondomaine.org auprès du serveur DNS 12.42.112.242 :

% dig @12.42.112.242 mondomaine.org ANY

Requête inverse (i.e. reverse DNS) sur l'IP 12.42.111.242 auprès du serveur DNS

12.42.112.242 :

% dig @12.42.112.242 -x 12.42.111.242

Exemple de configuration :

foo.org. IN SOA ns1.foo.org. hostmaster.foo.org. (

20001210011 ; numéro de série

10800 ; rafraîchissement

3600 ; nouvel essai

604800 ; Obsolescence après une semaine

IT



86400 ) ; TTL minimal de 1 jour

# Enregistrement de type NS pour le domaine foo.org:

foo.org. IN NS ns1.foo.org.

foo.org. IN NS ns2.foo.org.

# Enregistrements de type A : Nous devons décrire la correspondance Nom / Adresse

ns1.foo.org. IN A 192.168.0.1

ns2.foo.org. IN A 192.168.0.2

localhost.foo.org. IN A 127.0.0.1

# Enregistrements de type CNAME : Ce sont les alias (Canonical Name). Une requête du type

http://www.foo.org sera adressée à ns1.foo.org, puisque www est un alias de ns1.

ns1.foo.org. IN CNAME www.foo.org.

ns2.foo.org. IN CNAME ftp.foo.org.

# Enregistrement de type PTR : Ils serviront à la résolution de nom inverse.

1.0.168.192.in-addr.arpa. IN PTR ns1.foo.org.

2.0.168.192.in-addr.arpa. IN PTR ns2.foo.org.

ftp://ftp.foo.org/

Documents

Administration de Service DNS Sous Linux