Différences

Ci-dessous, les différences entre deux révisions de la page.

--- 090_applicatifs:160dns:30_construire_un_dns [le 17/03/2025 à 17:30] – [Les zones] prof
+++ 090_applicatifs:160dns:30_construire_un_dns [le 18/03/2025 à 18:11] (Version actuelle) – [Les autres zones] prof
@@ Ligne 279: / Ligne 279: @@
 === Les autres zones  ===
 sont destinées à la recherche inverse, ce qui pour l'instant est de peu d'intérêt.
+==== Où est le cache ? ====
+De ce que nous avons vu précédemment, Bind9 conserve dans un cache les recherches qu'il a effectuées, mais comment visualiser son contenu ?
+Bind9 vient avec l'utilitaire ''rndc'' qui sait à peu près tout faire sur Bind. Entre autres choses, la gestion du cache. Ainsi '' rndc dumpdb -cache'' va copier dans le fichier texte ''/var/cache/bind/named_dump.db'' tout le contenu du cache à l'instant «T».
+Montrer l'intégralité de ce fichier serait fastidieux. Mais en effectuant quelques filtrages:
+<html><pre class="code">
+<b>cat named_dump.db | grep education.gouv.fr</b>
+www.education.gouv.fr.	75549	CNAME	education.gouv.fr.cdn.cloudflare.net.
+<b>cat named_dump.db | grep cloudflare.net</b>
+www.education.gouv.fr.	75549	CNAME	education.gouv.fr.cdn.cloudflare.net.
+cloudflare.net.		627	SOA	ns1.cloudflare.net. dns.cloudflare.com. (
+					20250319183342 20250317163342 34505 cloudflare.net.
+	NS	ns1.cloudflare.net.
+	NS	ns2.cloudflare.net.
+	NS	ns3.cloudflare.net.
+	NS	ns4.cloudflare.net.
+	NS	ns5.cloudflare.net.
+					20250516080352 20250316080352 2371 cloudflare.net.
+cdn.cloudflare.net.	627	\-NS	;-$NXRRSET
+; cdn.cloudflare.net. RRSIG NSEC ...
+; cdn.cloudflare.net. NSEC \000.cdn.cloudflare.net. A HINFO MX TXT AAAA LOC SRV NAPTR CERT SSHFP RRSIG NSEC TLSA SMIMEA HIP OPENPGPKEY SVCB HTTPS URI CAA
+; cloudflare.net. SOA ns1.cloudflare.net. dns.cloudflare.com. 2367684337 10000 2400 604800 1800
+; cloudflare.net. RRSIG SOA ...
+ns1.cloudflare.net.	161950	A	173.245.59.31
+ns2.cloudflare.net.	161950	A	198.41.222.131
+ns3.cloudflare.net.	161950	A	198.41.222.31
+ns4.cloudflare.net.	161950	A	198.41.223.131
+ns5.cloudflare.net.	161950	A	198.41.223.31
+</pre></html>
+Les restes de la recherche précédente à propos de ''%%www.education.gouv.fr%%''
+Mais ''rndc'' sait faire d'autres choses comme :
+  * vider le cache: ''rndc flush'';
+  * vider le cache d'une entrée particulière, par exemple: ''rndc flushname www.education.gouv.fr'';
+  * vider le cache d'une arborescence particulière, par exemple: ''rndc flushtree cloudflare.net''
+  * recharger la configuration du serveur: ''rndc reload'', utile surtout si l'on gère des zones dont on est NS ou SOA.
 ===== Créer une zone =====
-Tout ceci est bien, mais nous voudrions maintenant créer une zone pour notre intranet, avec un nom de domaine « en bois » comme par exemple ''maison.mrs''. Le TLD n'existe pas, le domaine ''maison.mrs'' ne peut donc exister sur l'internet, mais il peut parfaitement fonctionner sur notre LAN.
+Nous pouvons à ce niveau créer une zone pour notre LAN. Par exemple, supposons que nous disposons d'un nom de domaine officiel sur l'internet comme ''nain-t.net''. La zone qui définit les hôtes de ce domaine se trouve à priori sur un serveur DNS maintenu par notre «registar», l’organisme auprès duquel le domaine a été déposé. Un ''whois nain-t.net'' va le révéler:
+<html><pre class="code">
+<b>whois nain-t.net</b>
-Pour ce faire, il nous faut tout de même entrer un peu plus dans le détail des informations que peut donner un serveur DNS.
+   Domain Name: NAIN-T.NET
+   ...
+   <span class="hly">Registrar: OVH sas</span>
+   ...
+   <span class="hlg">Name Server: DNS12.OVH.NET</span>
+   <span class="hlg">Name Server: NS12.OVH.NET</span>
+</pre></html>
+Mais nous avons la possibilité en interne, de créer une zone ''home.nain-t.net'', qui permettra de résoudre localement seulement des noms attribués aux hôtes du LAN.
+ Il va falloir commencer par référencer cette zone dans le fichier ''named.conf.local'' en y ajoutant le paragraphe suivant:
+<code>
+zone "home.nain-t.net" {
+        type master;
+        file "/etc/bind/db.home";
+};
+</code>
+Il nous faut maintenant créer ce fichier ''/etc/bind/db.home'' sur le même modèle que le ''db.local''.
 ==== $TTL ====
-Indique en secondes la durée de vie de l'information fournie. Les serveurs DNS récursifs conserveront en cache les informations récoltées pendant la durée indiquée dans ce paramètre. 0 devrait indiquer que les valeurs ne doivent pas être conservées en cache (utile pour les « dyn DNS » mais c'est une autre histoire).
+Indique en secondes la durée de vie de l'information fournie. Les serveurs DNS récursifs conserveront en cache les informations récoltées pendant la durée indiquée avec ce paramètre. 0 devrait indiquer que les valeurs ne doivent pas être conservées en cache (utile pour les « dyn DNS » mais c'est un autre débat).
+==== @ ====
+Ayant créé dans ''named.conf.local'' la zone nommée ''home.nain-t.net'', dans ''db.home'', ''@'' sera identique au nom de la zone.
+Dit simplement dans notre cas : \\ **dans db.home, @ = home.nain-t.net**
+=== IN ===
+Juste pour dire que l'on traite une zone internet. Même dans notre cas de l'intranet.
 ==== SOA ====
-Start Of Authority. Si nous avons plusieurs serveurs DNS qui servent la même zone, nous avons vu l'exemple pour ''yahoo.com'' qui en a deux, mais il pourrait y en avoir plus, il y en a un qui est le serveur « maitre », les autres n'étant que des « escalves », c'est à dire de simples répliquas. L'administrateur met à jour le maitre, qui notifiera ses esclaves (l'informaticien a une tendance à la paresse). Le champ SOA indique donc quel est le serveur « maitre ».
+Start Of Authority. Si nous avons plusieurs serveurs DNS qui servent la même zone, comme le ''whois nain-t.net'' le laisse supposer, c'est qu'il y a un maître et un esclave. Le maître, c'est le SOA et il ne peut y en avoir qu'un seul dans une zone.
+Nous pouvons d'ailleurs, au moyen de la commande ''host'' savoir rapidement toutes ces choses. Exemple avez la zone ''yahoo.com'' :
+<html><pre class="code">
+<b>host -t NS yahoo.com</b>
-Nous pouvons d'ailleurs, au moyen de la commande ''host'' savoir rapidement toutes ces choses :
-<code>
-# host -t ns yahoo.com
 yahoo.com name server ns4.yahoo.com.
-yahoo.com name server ns6.yahoo.com.
 yahoo.com name server ns1.yahoo.com.
 yahoo.com name server ns3.yahoo.com.
 yahoo.com name server ns5.yahoo.com.
-yahoo.com name server ns8.yahoo.com.
 yahoo.com name server ns2.yahoo.com.
-</code>
+</pre></html>
-Tiens, il y a bien plus de deux Name Servers pour le domaine Yahoo.com, finalement... Mais tous n'ont pas forcément besoin d'être référencés sur les serveurs du TLD ''com'', deux suffisent.
+Cinq Name Servers pour le domaine Yahoo.com. Mais quel est dans cette liste le serveur « maitre » ?
+<html><pre class="code">
+<b>host -t SOA yahoo.com</b>
-Mais quel est dans cette liste le serveur « maitre » ?
+yahoo.com has SOA record ns1.yahoo.com. hostmaster.yahoo-inc.com. 2025031706 3600 300 1814400 600
-<code>
+</pre></html>
-# host -t soa yahoo.com
-yahoo.com has SOA record ns1.yahoo.com. hostmaster.yahoo-inc.com. 2009012906 3600 300 1814400 600
-</code>
 C'est ''ns1.yahoo.com.'' et nous disposons également d'autres informations, que nous allons retrouver lors de la construction de notre zone « maison ». Nous avons l'assurance que ce serveur fournira toujours la bonne information (sauf erreur de l'administrateur).
-Comme nous allons le voir, le symbole ''@'' n'a pas ici la signification habituelle ''at''. Aussi, l'adresse e-mail du responsable de la zone est marquée : ''hostmaster.yahoo-inc.com.''. Si nous avons une remarque à faire au responsable de la zone, nous adresserons le message à ''%%hostmaster@yahoo-inc.com%%''.
 === Serial ===
-Numéro de série qu'il faut incrémenter à chaque modification de la zone. Il est d'usage de le construire à partir de la date de modification. Ainsi, dans l'exemple précédent, nous pouvons imaginer que le serveur a été mis à jour le 29 janvier 2009, peut être à 6h GMT, ou alors ce serait la sixième modification opérée ce jour. Cette façon de faire est une recommandation, mais pas une obligation. Un simple incrément suffit. Ce numéro de série permet aux serveurs « esclaves » de savoir s'il y a eu ou non une modification de la zone depuis leur dernière synchronisation.
+Numéro de série qu'il faut incrémenter à chaque modification de la zone. Il est d'usage de le construire à partir de la date de modification. Ainsi, dans l'exemple précédent, nous pouvons imaginer que le serveur a été mis à jour le 17 mars 2025, peut être à 6h GMT, ou alors ce serait la sixième modification opérée ce jour. Cette façon de faire est une recommandation, mais pas une obligation. Un simple incrément suffit. Ce numéro de série permet aux serveurs « esclaves » de savoir s'il y a eu ou non une modification de la zone depuis leur dernière synchronisation.
 === Refresh ===
@@ Ligne 336: / Ligne 397: @@
 Le champ CNAME (Common Name) fait correspondre un alias à un « vrai nom ». Le « vrai nom » doit disposer par ailleurs d'un champ A, dans la même zone ou dans une autre, sur le même serveur ou sur un autre (nous en avons vu un exemple avec ''%%www.education.gouv.fr%%'').
-Il existe encore d'autres champs comme MX (Mail eXchanger), utile pour le protocole SMTP ou TXT, (utile surtout, hélas, pour « tunnelliser » n'importe quoi dans du protocole DNS, mais c'est une autre affaire).
+Il existe encore d'autres champs comme MX (Mail eXchanger), utile pour le protocole SMTP ou TXT.
-==== Le symbole « @ » ====
-Dans un fichier de configuration de zone, ce symbole représente exactement le nom de domaine de la zone. Par exemple, lorsque nous allons créer notre zone ''maison.mrs'', écrire :
-  maison.mrs.  IN SOA ...
-Nous pourrons écrire :
-  @            IN SOA ...
-==== La zone maison.mrs ====
+==== La zone home.nain-t.net. ====
-Nous en savons assez pour créer notre zone « maison ». Notre serveur va s'appeler ''debvirt.maison.mrs'' et dispose de l'adresse IP 192.168.0.254 :
+Nous en savons assez pour créer notre zone « maison ». Notre serveur va s'appeler ''demoserver1.home.nain-t.net'' et dispose de l'adresse IP 192.168.60.200 :
-Créons d'abord dans ''/etc/bind/'' un fichier nommé par exemple : ''db.maison.mrs'' qui contiendrait ceci :
+Créons d'abord dans ''/etc/bind/'' un fichier nommé  : ''db.home'' qui contiendrait ceci :
 <code>
 $TTL    1600
-@       IN      SOA     debvirt.maison.mrs. root.debvirt.maison.mrs. (
+@       IN      SOA     demoserver1.home.nain-t.net. root.demoserver1.home.nain-t.net. (
-                        2009012901      ; Serial
+                        2025031701      ; Serial
          ; Refresh
          ; Retry
@@ Ligne 357: / Ligne 413: @@
 )        ; Negative Cache TTL
 ;
-@         IN    NS      debvirt.maison.mrs.
+@             IN    NS      demoserver1.home.nain-t.net.
-@         IN    A       192.168.0.254
+@             IN    A       192.168.60.200
-debvirt   IN    A       192.168.0.254
+demoserver1   IN    A       192.168.60.200
-test1     IN    A       192.168.0.1
+test1         IN    A       192.168.60.47
-test2     IN    CNAME   test1
+test2         IN    CNAME   test1
-test3     IN    CNAME   irp.nain-t.net.
+test3         IN    CNAME   irp.nain-t.net.
 </code>
-Ceci devrait permettre de répondre aux requêtes de type NS pour le domaine ''maison.mrs'', de répondre aussi aux requêtes de type A pour debvirt.maison.mrs et pour test1.maison.mrs, constater aussi que les alias fonctionnent dans et hors du domaine.
+Ceci devrait permettre de répondre aux requêtes de type NS pour le domaine ''home.nain-t.net'', de répondre aussi aux requêtes de type A pour demoserver1.home.nain-t.net et pour test1.home.nain-t.net, constater aussi que les alias fonctionnent dans et hors du domaine.
-Il nous faut maintenant indiquer à bind que cette zone existe. Nous allons le faire dans le fichier /etc/bind/named.conf.local :
+Il nous reste à forcer bind9 à relire sa configuration avec un ''rndc reload'' et nous contrôlons
-<code>
+<html><pre class="code">
-zone "maison.mrs" {
+<b>host -t NS home.nain-t.net ::1</b>
-	type master;
+Using domain server:
-	file "/etc/bind/db.maison.mrs";
+Name: ::1
-};
+Address: ::1#53
-</code>
+Aliases:
-Enfin, nous redémarrons bind avec un ''/etc/init.d/bind9 restart'' et nous contrôlons
-<code>
+<span class="bhly">home.nain-t.net name server demoserver1.home.nain-t.net.</span>
-# host -a maison.mrs
-Trying "maison.mrs"
-;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59474
-;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
-;; QUESTION SECTION:
+<b>host -t SOA home.nain-t.net ::1</b>
-;maison.mrs.			IN	ANY
+Using domain server:
+Name: ::1
+Address: ::1#53
+Aliases:
-;; ANSWER SECTION:
+<span class="bhly">home.nain-t.net has SOA record demoserver1.home.nain-t.net. root.demoserver1.home.nain-t.net. 2025031701 604800 86400 2419200 1600</span>
-maison.mrs.		1600	IN	SOA	debvirt.maison.mrs. root.debvirt.maison.mrs. 2009012901 604800 86400 2419200 1600
-maison.mrs.		1600	IN	NS	debvirt.maison.mrs.
-maison.mrs.		1600	IN	A	192.168.0.254
-;; ADDITIONAL SECTION:
-debvirt.maison.mrs.	1600	IN	A	192.168.0.254
-Received 123 bytes from 127.0.0.1#53 in 1 ms
+<b>host demoserver1.home.nain-t.net ::1</b>
+Using domain server:
+Name: ::1
+Address: ::1#53
+Aliases:
+<span class="bhly">demoserver1.home.nain-t.net has address 192.168.60.200</span>
-# host test1.maison.mrs
+<b>host test1.home.nain-t.net ::1</b>
-test1.maison.mrs has address 192.168.0.1
+Using domain server:
+Name: ::1
+Address: ::1#53
+Aliases:
+<span class="bhly">test1.home.nain-t.net has address 192.168.60.47</span>
-# host test2.maison.mrs
+<b>host test2.home.nain-t.net ::1</b>
-test2.maison.mrs is an alias for test1.maison.mrs.
+Using domain server:
-test1.maison.mrs has address 192.168.0.1
+Name: ::1
+Address: ::1#53
+Aliases:
+<span class="bhly">test2.home.nain-t.net is an alias for test1.home.nain-t.net.
+test1.home.nain-t.net has address 192.168.60.47</span>
-# host test3.maison.mrs
+<b>host test3.home.nain-t.net ::1</b>
-test3.maison.mrs is an alias for irp.nain-t.net.
+Using domain server:
-irp.nain-t.net has address 213.186.40.149
+Name: ::1
-</code>
+Address: ::1#53
+Aliases:
+<span class="bhly">test3.home.nain-t.net is an alias for irp.nain-t.net.
+irp.nain-t.net is an alias for vps.nain-t.net.
+vps.nain-t.net has address 51.68.121.59
+vps.nain-t.net has IPv6 address 2001:41d0:305:2100::2cd5</span>
+</pre></html>
 Tout va bien, notre serveur DNS fonctionne parfaitement.
 ===== Conclusion =====
 Encore une fois, cette configuration ne tient compte d'aucune considération sécuritaire. Cependant, nous avons un service récursif pour les résolutions sur l'internet et qui pourra gérer les noms dans notre intranet.
-==== Note pour Orange™ ====
-De longue date, ce petit problème existe. De nombreux clients utilisent les services de ''smtp.wanadoo.fr'' pour envoyer leurs e-mails. Faisons avec notre beau bind une résolution de ''smtp.wanadoo.fr'' :
-<code>
-# host smtp.wanadoo.fr
-smtp.wanadoo.fr has address 80.12.242.148
-smtp.wanadoo.fr has address 193.252.22.65
-smtp.wanadoo.fr has address 193.252.22.78
-smtp.wanadoo.fr has address 193.252.22.92
-smtp.wanadoo.fr has address 193.252.23.67
-smtp.wanadoo.fr has address 80.12.242.9
-smtp.wanadoo.fr has address 80.12.242.15
-smtp.wanadoo.fr has address 80.12.242.53
-smtp.wanadoo.fr has address 80.12.242.62
-smtp.wanadoo.fr has address 80.12.242.82
-smtp.wanadoo.fr has address 80.12.242.142
-</code>
-Voyons maintenant depuis une connexion Orange™, qui utilise les serveurs DNS renseignés par la connexion PPPoE :
-<code>
-# host  smtp.wanadoo.fr
-smtp.wanadoo.fr has address 193.252.22.74
-smtp.wanadoo.fr has address 193.252.22.91
-smtp.wanadoo.fr has address 193.252.23.66
-smtp.wanadoo.fr has address 80.12.242.10
-smtp.wanadoo.fr has address 80.12.242.16
-smtp.wanadoo.fr has address 80.12.242.52
-smtp.wanadoo.fr has address 80.12.242.61
-smtp.wanadoo.fr has address 80.12.242.86
-smtp.wanadoo.fr has address 80.12.242.141
-smtp.wanadoo.fr has address 193.252.22.64
-</code>
-Ce ne sont pas les mêmes... Pourquoi ?
-Il faut le demander aux administrateurs de wanadoo.fr. Toujours est-il que votre vaillant Firefox (ou équivalent), si vous êtes usagers de smtp.wanadoo.fr, ne parviendra pas à poster vos messages, la résolution faite par notre cache personnel ne donnant pas les bons serveurs. La solution est de créer sur notre bind une zone wanadoo.fr de type « forward » et d'y indiquer les adresses IP des serveurs DNS fournis par la connexion Orange™. La documentation de bind indique comment réaliser cette opération. Cette documentation complète se trouve sur [[https://www.isc.org/software/bind/documentation|le site d'ISC]] (124 pages en anglais, pour la version 9.4, fournie avec Lenny) dont la lecture est indispensable si l'on souhaite réaliser un serveur public ou simplement découvrir toutes les possibilités de l'outil.
+En toute rigueur, sur une installation professionnelle, il est vivement conseillé d'ajouter au moins un serveur esclave, de manière à assurer de la tolérance de panne.
+===== Et le round-robin ? =====
+Comme nous l'avons vu, il arrive parfois qu'à un FQDN corresponde plusieurs adresses IP. Posons deux fois la même question:
+<html><pre class="code">
+<b>host www.debian.org</b>
+<span class="hly">www.debian.org has address 194.177.211.216</span>
+<span class="hlo">www.debian.org has address 130.89.148.77</span>
+<span class="hly">www.debian.org has IPv6 address 2001:67c:2564:a119::77</span>
+<span class="hlo">www.debian.org has IPv6 address 2001:648:2ffc:deb:216:61ff:fe2b:6138</span>
-===== psst ! le round-robin ?... =====
+<b>host www.debian.org</b>
-Comme nous l'avons vu, il arrive parfois qu'à un FQDN corresponde plusieurs adresses IP (parfois nombreuses, comme dans le cas de ''smtp.wanadoo.fr''). Reprenons l'exemple plus simple de ''%%www.google.fr%%'', en posant trois fois de suite la même question à notre serveur :
+<span class="hlo">www.debian.org has address 130.89.148.77</span>
-<code>
+<span class="hly">www.debian.org has address 194.177.211.216</span>
-d# host www.google.fr
+<span class="hlo">www.debian.org has IPv6 address 2001:67c:2564:a119::77</span>
-www.google.fr is an alias for www.google.com.
+<span class="hly">www.debian.org has IPv6 address 2001:648:2ffc:deb:216:61ff:fe2b:6138</span>
-www.google.com is an alias for www.l.google.com.
+</pre></html>
-www.l.google.com has address 209.85.129.104
-www.l.google.com has address 209.85.129.147
-www.l.google.com has address 209.85.129.99
-# host www.google.fr
-www.google.fr is an alias for www.google.com.
-www.google.com is an alias for www.l.google.com.
-www.l.google.com has address 209.85.129.99
-www.l.google.com has address 209.85.129.104
-www.l.google.com has address 209.85.129.147
-# host www.google.fr
-www.google.fr is an alias for www.google.com.
-www.google.com is an alias for www.l.google.com.
-www.l.google.com has address 209.85.129.147
-www.l.google.com has address 209.85.129.99
-www.l.google.com has address 209.85.129.104
-</code>
-Nous observons une permutation circulaire dans l'ordre des réponses (tourniquet). Comme l'application demandeuse prendra la première réponse servie, si trois clients de notre serveur veulent accéder tour à tour à ''%%www.google.fr%%'', ils utiliseront chacun une adresse IP différente et donc probablement aboutiront à un serveur différent. Ce système est très souvent utilisé pour répartir simplement la charge sur plusieurs hôtes.
+Nous observons une permutation circulaire dans l'ordre des réponses (tourniquet). Comme l'application demandeuse prendra la première réponse servie, si deux clients de notre serveur veulent accéder tour à tour à ''%%www.debian.org%%'', ils utiliseront chacun une adresse IP différente et donc probablement aboutiront à un serveur différent. Ce système fut très souvent utilisé pour répartir simplement la charge sur plusieurs hôtes. On lui préfère aujourd'hui d'autres méthodes de répartition de charge, mais il est encore possible de trouver quelques exemples de «round-robin».