Table des matières

1. Objectifs

Lors du TP précédent, nous avons mis en place une résolution DNS dans un petit réseau.  Ce faisant, nous avons approché le logiciel Bind dans un premier usage, en tant que résolveur.  

Nous allons à présent reprendre ce même réseau, et l’enrichir d’un service supplémentaire : La gestion de la zone interne.  Le serveur qui fera autorité sur la zone sera construit également au départ du logiciel Bind, dans un second usage donc.  Soyez attentif à bien saisir les différences et les nuances entre les deux types de serveurs DNS!

Ce TP comporte 2 étapes : 

  1. L’ajout d’un SOA Bind dans le réseau existant, permettant d’avoir la résolution forward (nom -> IP) pour toutes les machines du réseau 
  2. L’ajout de la zone reverse pour avoir la résolution inverse (IP -> nom)
  3. Pour les plus avancés d’entre vous, vous pourrez également coupler ce SOA au service DHCP, pour que les entrées concernant les machines clientes puissent être intégrées au DNS et mises à jour en fonction des leases DHCP.  

Pour commencer ce TP, il est indispensable que le TP précédent soit finalisé, puisque sans résolution DNS ni DHCP, votre serveur SOA ne servira pas à grand chose. 

A la fin de ce TP, vous devrez : 

  • Savoir utiliser Wireshark et dig à bon escient pour observer le fonctionnement (correct ou non) d’un serveur DNS SOA
  • Etre à l’aise avec les principales directives de Bind en mode SOA
  • Ecrire un fichier de zone correct, en mode forward ou reverse
  • Pouvoir expliquer les opérations effectuées par un serveur SOA lorsqu’il répond à des requêtes DNS
  • Valider le bon fonctionnement d’un SOA

2. Mise en place du SOA et de la zone forward

Pour commencer, lancez votre labo GNS3 et assurez-vous que tout fonctionne, à savoir que les clients DNS (directeur et atelier) doivent avoir une adresse IP dynamique et accéder à Internet en utilisant le résolveur pour sa résolution DNS.  Quant aux serveurs, ils doivent être configurés en IP statiques conformément au schéma ci-dessous.

reseau-woodytoys.png

Les étapes à suivre pour cette partie du TP sont les suivantes : 

2.1. Configuration réseau du serveur SOA

Sur la machine soa, vérifiez la configuration de l’interface réseau de cette machine en IP fixe.  

Faut-il lui configurer un résolveur?

2.2. Configuration du SOA

Nous allons à présent configurer Bind en mode “authoritative” (name server) sur la machine soa.  Pour cela, vous pouvez copier le fichier de configuration utilisé pour le résolveur dans le TP6, puis l’adapter au rôle de SOA.

Réfléchissez : de quels clients notre SOA doit-il accepter les requêtes?  Y a t’il une différence selon qu’il s’agisse d’un SOA interne (comme ici) ou dun SOA public (par exemple ephec.be)?

  • Vérifiez bien que la machine soa accepte les requêtes sur la/les bonnes interfaces
  • Définissez les IPs pour lesquelles le SOA acceptera de répondre aux requêtes. Utilisez pour cela la directive allow-query (même syntaxe que allow-recursion).
  • Contrairement aux résolveurs, un SOA ne doit pas répondre aux requêtes récursives.  Indiquez donc none dans la directive allow-recursion. Ajoutez en outre la directive recursion no : 
	allow-recursion { none; };
	recursion no

2.3. Fichier de zone

Une fois le SOA configuré pour recevoir des requêtes des machines spécifiées, nous allons maintenant nous intéresser aux informations qu’il va fournir à ses clients.

Un SOA répond aux requêtes concernant la zone dont il a la responsabilité. Il s’agit, dans notre cas, de la zone woodytoys.lab. Nous ne nous intéressons pour le moment qu’à la partie interne du réseau, il s’agira donc de la zone privée, donnant les informations concernant les services joignables en interne. Ces services sont typiquement joignable via l’adressage IP interne de l’entreprise. Nous travaillerons sur la zone publique plus tard, au second semestre.

Vous allez donc créer le fichier de zone correspondant à la zone woodytoys.lab interne. Pour cela, vous pouvez vous inspirer de l’exemple de la section 12.3.3  du guide de référence Red Hat.

Paramètres de la zone

Pour commencer, remarquez le premier Resource Record du fichier : il s’agit du record SOA

@	IN	SOA	dns1.example.com.	hostmaster.example.com. (
			2001062501 ; serial                     
			21600      ; refresh after 6 hours                     
			3600       ; retry after 1 hour                     
			604800     ; expire after 1 week                     
			86400 )    ; minimum TTL of 1 day

Ce record va définir des informations administratives importantes concernant la zone : son NS primaire, l’adresse de la personne responsable, puis, dans les paramètres :

  • Le Serial Number : ce numéro doit être incrémenté à chaque édition du fichier de zone. En cas d’utilisation d’un serveur secondaire, ce dernier utilise le numéro de série du fichier de zone du serveur primaire pour savoir quand le fichier a été modifié et s’il doit lancer un “transfert de zone” pour se resynchroniser. Une bonne pratique extraite du RFC 1912 consiste à utiliser 10 chiffres : 8 pour la date à l’envers, et 2 pour indiquer le numéro du changement dans ceux effectués ce jour-là. C’est cette syntaxe qui est utilisée dans l’exemple du site Red Hat.
  • Plusieurs valeurs en seconde, définissant différents timers ou TTL pour la gestion des réplications et des caches.

Définition des ressources de la zone

Les machines devant figurer dans ce fichier de zone au stade actuel sont : 

  • Le serveur SOA (appelé soa)
  • Le résolveur (appelé resolv)
  • Le serveur DHCP (appelé dhcp)
  • Le serveur web (appelé www), que vous aurez auparavant configuré en IP statique conformément au schéma ci-dessous.  
  • Et le serveur mail (appelé mail), idem que pour www. 

Complétez le fichier de zone avec les ressources records correspondant à ces cinq serveurs.

2.4. Finalisation et validation de la configuration du SOA

Revenez ensuite dans le fichier named.conf. Définissez la zone woodytoys.lab, en indiquant que le serveur gère cette zone en tant que “master” et en spécifiant le chemin vers le fichier de zone que vous avez créé.  

Vérifier la validité de la syntaxe de votre configuration avec les utilitaires named-checkconf et named-checkzone. Le premier permet de vérifier le fichier de configuration, tandis que le second vérifie la syntaxe de la zone.

Démarrer le serveur avec la commande named.

Pour lancer le serveur en arrière plan, vous pouvez simplement ajouter un & à la fin de la ligne de commande.
Si vous l’avez démarré en avant-plan et souhaitez le basculer en arrière-plan, vous pouvez utilisez ctrl-z pour interrompre le processus, puis la commande bg pour le redémarrer mettre en arrière plan.

Faites les vérifications habituelles, avec ps et netstat -nltpu pour vous assurez que bind est bien démarré.

Vérifiez le fonctionnement du SOA depuis une autre machine (notamment le résolveur) :

  • avec dig @<IP SOA> <query>
  • ou avec un nslookup <query> <IP SOA> depuis une autre machine

2.5. Ajustement du résolveur

Pour le moment, le résolveur effectue des requêtes à la place des clients, en s’adressant au DNS public via les serveurs racines.

Cependant, notre zone interne n’existe pas dans le DNS public. Il faut donc dire au résolveur que pour cette zone en particulier, il ne doit pas faire de la résolution récursive, mais transférer (“forwarder”) les requêtes vers notre serveur SOA.

Pour cela, revenez dans le fichier de configuration du résolveur, et ajoutez-lui ceci :

zone "woodytoys.lab" IN {  
    type forward;  
    forwarders { 192.168.0.3; };  
	forward only;  
};

Pour que cela fonctionne, nous devons en outre (malheureusement) désactiver le DNSSEC sur le résolveur. Le DNSSEC est un système permettant de vérifier l’authenticité des ressources records. Nous ne l’exploiterons pas dans le cadre de ce cours-ci, et laissons donc de coté pour le moment cette étape de sécurisation importante.

Pour désactivez le DNSSEC, ajoutez la ligne suivante dans la section “options” du fichier named.conf :

dnssec-validation no;

Retenez bien que désactiver le DNSSec est une mauvaise idée en production! Au second semestre, vous devrez l’activer et le configurer dans vos réseaux.

Testez à présent que n’importe quel poste client peut joindre les autres machines à partir des noms DNS (par ex : ping www.woodytoys.lab)

3. Mise en place de la zone inverse

Si votre zone woodytoys.lab fonctionne, vous pouvez à présent configurer votre zone inverse.

3.1. Rappels sur le DNS inverse et mise en pratique

La zone inverse (ou reverse) contiendra les ressources records de type PTR, qui permettent, à l’inverse des records A ou AAAA, de récupérer le nom d’une machine au départ de son adresse IP. Pour cela, il faut transformer l’adresse IPv4 sur laquelle porte la requête en un nom DNS particulier : il se construit en inversant les octets de l’adresse IPv4, et en ajoutant le domaine spécial in-addr.arpa.

Dans notre cas, nous utilisons le préfixe 192.168.0.0/24. Nos machines différeront au niveau du dernier octet. Le nom de domaine de la zone inverse sera alors constitué des trois premiers octets inversés, suivi du nom de domaine générique, ce qui donne : 0.168.192.in-addr.arpa.

De la même manière, le nom DNS inverse de la machine dhcp dont l’IP est 192.168.0.1 sera 1.0.168.192.in-addr.arpa.

3.2. Configuration de la zone inverse

Pour configurer la zone inverse, le principe est similaire à ce qui a été effectué pour la zone dite “directe” (forward) :

  1. Créez le fichier de zone concernant la zone reverse 0.168.192.in-addr.arpa.  Ajoutez-y tous les records inverses (PTR) correspondant aux IPs des serveurs.
  2. Vérifiez que la configuration est correcte avec named-checkconf et named-checkzone.  N’oubliez pas de redémarrer le serveur, et de valider le fonctionnement avec dig/nslookup. 
  3. Modifiez le fichier de configuration du résolveur pour qu’il forwarde les requêtes pour la zone reverse au SOA.

Les PTR doivent pointer vers les FQDN des machines concernées, et non vers des noms relatifs ! Par ex : 1 IN PTR ns.woodytoys.lab. et non 1 IN PTR ns

Savez-vous expliquer pourquoi il faut mettre ici des FQDNs, alors que des noms relatifs peuvent être utilisés dans le fichier de zone directe ? 

4. DNS dynamique (bonus)

Dans les étapes précédentes de ce TP, nous avons mis en place la résolution DNS directe et inverse des noms des serveurs de la zone interne woodytoys.lab.  
Malheureusement, cette résolution via un fichier de zone statique ne fonctionne pas pour les adresses des postes client, car ces derniers obtiennent leurs adresses IP de manière dynamique.  

Il est possible d’intégrer les clients DHCP à une zone interne, en couplant le serveur DNS SOA et le serveur DHCP.  De la sorte, lorsqu’une entrée DHCP est ajoutée ou modifiée dans le serveur DHCP, ce dernier notifie le serveur SOA afin que le fichier de zone soit mis à jour en fonction.   C’est possible dans notre cas, notamment car les deux serveurs sont édités par le même organisme (l’ISC), et leurs configurations s’intègrent donc facilement.

Nous allons voir ici la procédure à suivre pour construire un tel scénario.  

4.1. Couplage du DHCP et du SOA

Pour que les deux serveurs acceptent de communiquer, et pour que le SOA accepte de modifier son fichier de zone sur demande du DHCP, il faut qu’ils partagent une clé servant d’authentification. Nous allons générer cette clé sur le SOA puis la copieront dans la configuration du DHCP :

  1. Sur le serveur soa, générez une clé via l’utilitaire rndc, installé par défaut avec bind :  
    rndc-confgen
  2. Dans l’output de cette commande, récupérez la clé, que vous reconnaitrez car elle aura un format similaire à ceci : 
    key "rndc-key" {  
 algorithm hmac-md5;  
 secret "something long";  
};
  3. Copiez/collez cette clé dans le fichier named.conf du SOA, et ajoutez la directive suivante dans chacune des deux zones pour indiquer qu’on autorise les mises à jour si la clé indiquée figure dans la requête :  
    allow-update { 
 key rndc-key; 
};

  4. Validez cette configuration avec les outils adéquat, puis redémarrer le serveur SOA pour prendre en compte cette nouvelle configuration.  

  5. Sur le serveur DHCP, ajoutez la clé en mettant à jour le fichier dhcp.conf (à adapter en fonction de votre clé) , et ajoutez également les directives correspondant au “ddns” (DNS dynamique). Configurez les deux zones en indiquant le serveur à contacter et la clé à utiliser. 
    ddns-updates on;
ddns-update-style standard;   
authoritative;
default-lease-time 7200;
max-lease-time 7200;
key "rndc-key" {
 algorithm hmac-sha256;
 secret "Something long";
};

zone woodytoys.lab. {
    primary 192.168.0.3;
    key rndc-key;
}
zone 0.168.192.in-addr.arpa.{
    primary 192.168.0.3;
    key rndc-key;
}
    
subnet 192.168.0.0 netmask 255.255.255.0 {
    option routers 192.168.0.254;     
    option subnet-mask 255.255.255.0; 
    range 192.168.0.10 192.168.0.100; 
    option domain-name-servers 192.168.0.2;
    option domain-name "woodytoys.lab";    
}
  1. Redémarrez le serveur DHCP et validez-en le fonctionnement.  Vous pouvez pour cela changer le hostname d’un des postes client dans GNS3 et relancer un lease DHCP depuis sa console :  
    dhclient -r // Renoncement au "lease actuel"
dhclient    // relance d'un échange DHCP DORA pour obtenir un nouveau lease
  2. Vérifiez les logs dans /var/log/named/misc.log (si vous utilisez bind en arrière-plan) : Normalement, vous devriez avoir des indications comme quoi les fichiers de zone ont été mis à jour.  Si les logs indiquent des problèmes de permissions : Vérifiez que les deux fichiers de logs appartiennent bien à l’utilisateur bind. 
  3. Testez avec un ping depuis l’autre poste client : 
    ping mynewclientname.woodytoys.lab
  4.  Idem pour tester le reverse : Faites un dig @192.168.0.3 -x <IP> pour vérifier que les adresses IP attribuées par DHCP sont bien associées aux noms d’hôte des postes clients

Si votre DNS dynamique n’a pas l’air de se mettre à jour de manière adéquate, n’oubliez pas que trois serveurs interagissent : le DHCP et le SOA pour la mise à jour des adresses, mais également le résolveur comme “relais” des requêtes provenant des clients.  Chacun d’eux peut être source de dysfonctionnement.  Pour résoudre les problèmes éventuels, vous pouvez : 

  • Tout d’abord et comme toujours : utiliser Wireshark pour comprendre les échanges et identifier le serveur responsable du problèmen
  • Vider la cache du résolveur avec la commande rndc flush,
  • Réinitialiser les zone DNS dynamiques dans le SOA en effaçant les fichiers <zone>.jnl,
  • Et surtout, surveiller les logs pour comprendre quel serveur effectue quelle opération !