Chapitre6_admin_linux_p2.doc

1. 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/. 1.1. /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 ; 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.



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



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.



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}; }; Remarque : Plusieurs outils sont disponibles pour réaliser des tests de la configuration du serveur et de ses zones : 

named-checkconf : Pour chercher les erreurs de syntaxe dans les fichiers "named.conf*".



named-checkzone : Similaire à checkconf, mais pour les fichiers de zones. 1.2. 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.  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 (retry) 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.



expiration Si le serveur maître n'a pas répondu à une requête de rafraîchissement avant que la 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

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

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 : Indique les serveurs SMTP à contacter pour envoyer un courriel à un utilisateur d'un domaine donné. ofppt.org. IN MX 10 mai1l.ofppt.org. ofppt.org. IN MX 20 mai1l1.ofppt.org. 10, 20 : Indique la priorité L'enregistrement de ressources MX doté de la priorité la plus basse est préféré aux autres. Toutefois, de multiples serveurs de messagerie peuvent avoir la même valeur pour distribuer uniformément le trafic d'emails entre eux.  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. 1.3. Named.ca Ce fichier n’a pas à être modifier. Il contient les adresses des serveurs dns racine. 1.4. 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. 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.

2. 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/host.conf. 2.1. /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. 2.2. /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 nameserver 205.1.1.5 nameserver 205.1.2.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 ».

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

4. 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 64 bytes from 132.195.99.2: imcp_seq=1 ttl=254 time 5.9 ms 64 bytes from 132.195.99.2: imcp_seq=2 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

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.

5. Mise en place d’un serveur DNS dynamique Un serveur DNS dynamique (DDNS) est un serveur DNS qui sera mis à jour automatiquement par un serveur DHCP. Les clients du réseau qui se connecteront, vont obtenir une adresse IP automatiquement, et feront partit du domaine.

De cette façon, l'administrateur du réseau ne devra plus mettre à jour le nom d'hôtes du client avec son adresse IP dans les fichiers de zones, du serveur DNS, c'est le serveur DHCP qui mettra à jour automatiquement le fichier. Pour configurer un DDNS il faut modifier les fichiers de configuration des deux serveurs. A savoir le fichier dhcpd.conf, et le fichier named.conf. 5.1. Modification du serveur DHCP La modification du serveur DHCP consiste à activer la mise à jours automatique du serveur DNS, d’indiquer pour quelle zone le serveur DHCP doit faire la mise à jour et en fin de sécuriser l’accès au serveur DNS par un e clé cryptée. Code DHCP: include "/etc/rndc.key"; ddns-update-style interim; ddns-updates on; ddns-domainname "ofppt.org"; ddns-rev-domainname "in-addr.arpa"; zone ofppt.org { primary 192.168.0.201; key rndckey; } zone 0.168.192.in-addr.arpa { primary 192.168.0.201; key rndckey; }  include "/etc/rndc.key": Pour que le serveur DHCP, puisse mettre à jour le DNS, une clef cryptée doit être déclaré dans le fichier de configuration du serveur DHCP, pour une question de sécurité. Vérifier que vous avez bien le fichier rndc.key.  ddns-update-style interim: Indique la méthode de mise à jour DNS.  ddns-updates on: active la mise à jours dynamique.  ddns-domainname "ofppt.org": indique la zone qui va être mis à jours dynamiquement.  ddns-rev-domainname "in-addr.arpa": la zone inverse, La valeur "in-addr.arpa" correspond à chaque réseaux/sous réseaux.  Zone : Il faut indiquer dans quelle zone le serveur DHCP peut écrire dans le fichier de configuration du serveur DNS. 5.2. Modification du serveur DNS La modification du serveur DNS consiste à indiquer sur quel port est autorisée la mise à jour ainsi que à partir de quelle machine et de sécuriser l’accès au serveur DNS par une clé cryptée. Code DNS: include "/etc/rndc.key"; controls { inet 127.0.0.1 port 953 allow { 127.0.0.1; 192.168.0.201; } keys { "rndckey"; }; inet 192.168.0.0 port 953 allow { 127.0.0.1; 192.168.0.201; } keys { "rndckey"; }; }; zone " ofppt.org " {

type master; file "db.ofppt.org "; allow-update { key rndckey; }; notify yes; }; zone "0.168.192.in-addr.arpa" { type master; file “db.192.168.0"; allow-update { key rndckey; }; notify yes; }; La clef: Il faut déclarer clef en faisant une inclusion du fichier clef (Comme pour le serveur DHCP). Le port d'écoute (controls): Avec cette ligne, on autorise la mise à jour par une clef sur le port 953. Les zones: On précise les zones qui doivent être mis à jour par le serveur DHCP 5.3. Les droits Pour terminer avec la configuration il ne reste plus qu'à modifier les droits d'accès au dossier: /var/named, par les commandes suivantes: # chmod 2775 /var/named # chown root:named /var/named Maintenant, il ne reste plus qu'à redémarrer les deux serveurs par les commandes suivantes: # service named restart # service dhcpd restart Remarque : si vous éditez vos fichiers de zone, vous n'allez pas voire le nom d'hôtes et l'adresse IP du client qui vient d'être ajouté par le DHCP, c'est pourquoi il y a les deux nouveaux fichiers .jnl. Mais après quelques minutes les fichiers de zone vont être mis à jour automatiquement!