¶ TP DNS
01/12/2022 : la dév est morte il y a quelques mois, et avec elle ce beau TP. N'hésitez pas à le refaire ou à le dockeriser.
Merci à seberus pour ce beau TP !
¶ Introduction
Un DNS (Domain Name System) permet de traduire des noms de domaine en adresse IP. À MiNET, nous avons deux serveurs DNS : NS1 et NS2. Ils travaillent ensemble dans une relation "primaire-secondaire", autrefois appelée "maître–esclave" et nous allons dans ce TP étudier comment monter un serveur DNS avec le package bind9.
Les identifiants de connexion sont les mêmes que pour le TP DHCP.
¶ Configuration d’une zone pour le vlan de développement
La première question que vous vous posez est sûrement « c’est quoi une zone ? ».
Il s’agit d’un lieu où l’on peut voir différents types d’enregistrement dont NS, A, MX, CNAME, AAAA.
En gros :
| Enregistrement | Utilité |
|---|---|
| NS | pointe vers un autre DNS |
| A | lie une IPv4 à un nom de domaine |
| AAAA | lie une IPv6 à un nom de domaine |
| CNAME | lie un nom de domaine à un autre nom de domaine |
| MX | indique le serveur mail à utiliser dans le cas d’envoie d’un mail vers la zone ! |
(par exemple le serveur mail à utiliser pour envoyer un mail à equipe@minet.net est mx1@minet.net)
Cette liste n’est pas exhaustive.
Nous allons utiliser le container « f-dns-server » en faisant un rollback de la snapshot « base ».
Ici bind est déjà installé et le dossier de configuration a été clean pour faire un DNS propre !
La première chose à faire est de définir l’architecture de configuration que l’on va utiliser.
Dans notre cas, en travaillant dans le dossier /etc/bind :
- named.conf rassemble les configurations globales (les vues, redirection vers les configurations plus spécifiques)
- named.conf.options rassemble les variables
- named.conf.<vlan> sera le fichier spécifique pour un vlan indiqué.
Commençons par définir la configuration pour le vlan de développement dans named.conf en créant une vue dédiée : (une vue dans bind9 permet de créer une configuration de serveur dns pour une communauté spécifique)
view "nom" {
match-clients { ipdev ; } ; // les clients autorisés à utiliser cette zone
include "/etc/bind/named.conf.103" ; // on pointe vers un fichier de configuration
spécifique
};
Et là vous vous dites « comment on a défini ip dev ?? » Eh bien on ne l’a pas encore fait !
Pour cela nous allons déclarer une ACL (Access Control List) dans notre fichier de
configuration named.conf.options.
Avant la catégorie options on déclare l’ACL.
acl ipdev { 192.168.103.0/24; }; // vlan de dev
Dans la catégorie options on déclare également :
allow-query { any; };
Cela permet d’accepter les requêtes DNS de n’importe qui de manière générale, vu que l’on
affine plus précisément selon les vues ensuite.
A ce stade la configuration est faite et pointe vers le fichier de configuration spécifique mais
quel fichier ? Créons le !
touch /etc/bind/named.conf.103
On ajoute :
zone "minet.net" { // le nom de zone doit être le nom de domaine
type master ;
file "/etc/bind/zones/minet/db/db.103" ; // on pointe vers le fichier de la zone qui
contiendra les enregistrements dns !
} ;
On crée ensuite le fichier de la zone à l’emplacement qu’on vient de définir !
Le format à utiliser est :
@ IN SOA dns.minet.net. mailduwebmaster@minet.net. (
2007010401 ; Identifiant - date:mois:jour:version
3600 ; Refresh [1h]
600 ; Retry [10m]
86400 ; Expire [1d]
600 ) ; Negative Cache TTL [1h]
;
@ IN NS ns1dev.minet.net.
ns1dev IN A 192.168.103.174
toto IN A 192.168.103.254
On observe dans le SOA un identifiant correspondant à la version de la configuration. À chaque modification il faut mettre à jour cet identifiant ! On observera pourquoi dans la seconde partie du TP.
Tu remarques également qu’on a pas mis le nom de domaine complet dans les entrées mais juste le début de chaque entrée. Cela est dû au fait que l’on a défini le nom de la zone dans /etc/bind/named.conf.103 ! Donc bind9 ajoutera « minet.net » à tous les enregistrements ne se terminant pas par un . donc c’est bien notre cas. dns correspond alors à dns.minet.net
@ signifie que l’on attache à l’espace de nom des caractéristiques. Ici on définit un SOA et un NS à l’espace de nom de la zone.
- Redémarrons le service de DNS.
service bind9 restart
Pour vérifier on prend n’importe quelle machine et on utilise l’utilitaire dig qui permet de connaître l’ip associée à un nom de domaine.
Ici : dig toto.minet.net @ipdudns
L’option @ipdudns permet de forcer l’utilisation d’un DNS en particulier.
Vous devriez obtenir en réponse l’IP que vous avez assignée.
Tentons désormais de modifier l’ACL. Mettez la place "192.168.104.0/24" à la place de cette présente. Retentez la commande DIG. Que remarquez-vous ?
On a donc défini une zone DNS privatisée aux IP du vlan de DEV !
Tips : Pour définir définitivement un DNS sur une machine client on peut la renseigner dans /etc/resolv.conf ou configurer l’IP dans le serveur DHCP s’il existe pour que lorsqu’un client récupère une lease celle-ci contienne également l’IP DNS !
¶ Mise en place d’un lien maître-esclave
Comme tu l’as lu en préambule, à MiNET nos DNS fonctionnent dans un rôle « Maître Esclave ». Cela signifie que les zones sont modifiées sur le DNS maître (ns1) et ns2 prend acte des modifications en updatant les zones qu’il héberge. Ns2 n’a donc pas le droit d’écriture sur les zones mais simplement un droit de lecture.
Nous allons réaliser une liaison master-slave avec :
- master f-dns-server 192.168.103.174
- slave f-dns2-server 192.168.103.175 (MDP : j3 su1s 1 p3t1t 1A !)
Démarre le container f-dns2-server après avoir effectué un rollback de la snapshot
corrigesingledns.
La première étape est de générer des clés TSIG (Transaction SIGnature) afin que le maître et l’esclave communiquent de manière sécurisée via un secret qu’ils partagent.
On va déjà générer le secret que nos machines vont partager. Pour cela on effectue la commande :
ddns-confgen
On copie le secret qui a été généré.
On effectue sur les deux containers dans le fichier named.conf.options au dessus de la section options :
key "dev-key" {
algorithm hmac-sha256;
secret "<secret>";
};
On vient alors de créer la clé dev-key qui sera utilisée dans les communications maîtreesclave. Cela comprend :
- les notifications de mise à jour des zones qui permettront à l’esclave de télécharger la nouvelle version des zones
- les téléchargements des zones vers l’esclave.
Bind nécessite que l’on déclare les serveurs pairs dans la configuration. La syntaxe est la suivante : (dans named.conf.options au dessus de la section options)
server <ipdel’autreserveurdns> {
keys { dev-key; };
};
Pour améliorer la sécurité, on va indiquer sur quelles interfaces les serveurs bind doivent écouter. Ici c’est pas dur il n’y en a que deux possibles : l’adresse de loopback et l’adresse dans le vlan de dév.
Dans la section options du même fichier de configuration à faire sur les deux serveurs :
listen-on { ipduserveurdns; };
Enlève également le listen en ipv6 qui n’est pas utile car on utilise pas d’ipv6 dans ce tp.
On pourrait aussi définir qui a le droit d’envoyer des notifications mais définir un master signifie implicitement que celui-ci a le droit d’envoyer des notifications… donc pas besoin ?
Le slave n’a pas à envoyer de notifications.
Dans named.conf nous allons définir l’interface qui sera utilisée pour envoyer des notifications (surtout du master vers le slave).
On permet aussi aux clients possédant la clé dev-key de matcher la vue bind pour exploiter
la zone !
Pour le master :
view "vlandev" {
match-clients { key dev-key; ipdev; };
include "/etc/bind/named.conf.103";
notify-source 192.168.103.174 port 53;
};
Pour le slave :
view "vlandev" {
match-clients { key dev-key; ipdev; };
include "/etc/bind/named.conf.103";
notify-source 192.168.103.175 port 53;
};
A ce stade nous avons presque terminé, mais nous n’avons toujours pas indiqué quel serveur
est maître et qui est esclave !
Allons dans la configuration spécifique du vlan de développement named.conf.103.
Pour le master :
zone "minet.net" {
type master;
file "/etc/bind/zones/minet/db/db.103";
allow-transfer { 192.168.103.175; };
};
Pour le slave :
zone "minet.net" {
type slave;
masters { 192.168.103.174; };
};
On indique que le slave a le droit de récupérer la zone du master (allow-transfer) et que le maître à contacter par l’esclave a pour ip 192.168.103.174.
Pour rappel on a déjà défini que pour contacter ce serveur on utilise la clé TSIG dev-key donc inutile de le ré-indiquer !
On redémarre bind9.
service bind9 restart
Si on lit les logs de l’esclave (tail -n 200 /var/log/syslog) on observe :
Dec 27 19:23:17 f-dns2-server named[876]: xfer-in: info: zone minet.net/IN/vlandev:
transferred serial 2021122505: TSIG 'dev-key'
Dec 27 19:23:17 f-dns2-server named[876]: xfer-in: info: transfer of 'minet.net/IN/vlandev'
from 192.168.103.174#53: Transfer status: success
Dec 27 19:23:17 f-dns2-server named[876]: xfer-in: info: transfer of 'minet.net/IN/vlandev'
from 192.168.103.174#53: Transfer completed: 1 messages, 7 records, 291 bytes, 0.001 secs
(291000 bytes/sec) (serial 2021122505)
Qu’en déduis-tu ?
Si on laissait le service tourner quelques heures on pourrait répérer les logs suivants :
Dec 27 17:49:13 f-dns2-server named[635]: xfer-in: info: transfer of 'minet.net/IN/vlandev'
from 192.168.103.174#53: connected using 192.168.103.175#52411 TSIG dev-key
Dec 27 17:49:13 f-dns2-server named[635]: xfer-in: info: transfer of 'minet.net/IN/vlandev'
from 192.168.103.174#53: Transfer status: up to date
Comment le slave sait-il que la configuration est à jour ?
Indice : Que doit-on changer à chaque fois que l’on met à jour une configuration DNS ? Relis
plus haut 
Pour vérifier le fonctionnement on peut faire une requête DIG via n’importe quel client sur le vlan de DEV :
dig toto.minet.net @192.168.103.174
dig toto.minet.net @192.168.103.175
Si tu éteins le master et que vous retentez vos requêtes, que remarques-tu ?
Trouves-tu les fichiers de zone dans le slave ? Eh non, car il stocke les entrées dans la mémoire flash étant donné que l’on a pas précisé de fichier dans lequel écrire la zone téléchargée !
Pour vérifier cela, tu peux aller dans /var/cache/bind sur l’esclave
Et effectue :
named-journalprint vlandev.mkeys.jnl
Ceci est le journal de modifications de la zone. Lors d’un crash le serveur peut reconstituer la zone via ce journal si rien n’est écrit dans un fichier.
Tentons de lui demander d’écrire dans un fichier pour la zone !
Dans named.conf.103 :
On ajoute cet argument dans la zone minet.net, comme sur le master :
file "/etc/bind/zones/minet/db/db.103" ;
Crée les dossiers et le fichier à coup de mkdir et de touch. Pense à mettre les droits
d’écriture à bind via :
chown bind:bind -R zones
Modifie le numéro de série dans le SOA du master, redémarre bind sur les deux serveurs.
Lis le fichier de zone du slave, que remarques-tu ? Eh non ce n’est pas lisible car bind
enregistre les données sous format raw mais on peut le décoder :
named-compilezone -f raw -F text -o vlandevreadable minet.net db.103
Lis le nouveau fichier crée, on y est ?
¶ Etablissement d’une zone de résolution inverse
Dans un DNS on peut aussi établir des zones de résolution inverse. C’est-à-dire que vous demandez quels sont les noms de domaine associés à une IP.
Bind9 permet ces résolutions. On utilisera le serveur f-dns-serveur uniquement pour nos cette partie et on n’utilisera plus notre lien master slave.
Déclarons la zone inverse dans le fichier correspond à la vue 103 : named.conf.103
zone "103.168.192.in-addr.arpa" {
type master;
file "/etc/bind/zones/minet/rev/rev.103 ";
};
On peut ensuite créer le fichier de la zone en elle-même. Pense à créer le répertoire
concerné en mettant les bon droits (chown bind:bind -R /etc/bind/zones/minet/rev)
@ IN SOA dns.minet.net. webmaster@minet.net. (
2021122507 ; Serial
3600 ; Refresh [1h]
600 ; Retry [10m]
86400 ; Expire [1d]
600 ) ; Negative Cache TTL [1h]
;
@ IN NS ns1dev.minet.net.
@ IN NS ns2dev.minet.net.
174 IN PTR ns1dev.minet.net.
175 IN PTR ns2dev.minet.net.
254 IN PTR toto.minet.net.
Ici on note comme entrées les associations entre la fin d’une IP et son nom de domaine
(exemple 192.168.103.174 correspond bien à ns1dev.minet.net.)
Pour tester :
dig -x 192.168.103.174 @192.168.103.174
Bravo tu as réussi à créer ton propre serveur DNS sous bind9, ton propre lien master-slave et
tu as également permis la recherche inversée