L'internet rapide et permanent

Outils pour utilisateurs

Outils du site

Vous êtes ici : L'internet rapide et permanent » Les protocoles applicatifs » DNS » Construire un serveur DNS

Différences

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

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision		Révision précédente
090_applicatifs:160dns:30_construire_un_dns [le 17/03/2025 à 18:19] – [SOA] prof090_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  === === Les autres zones  ===
 sont destinées à la recherche inverse, ce qui pour l'instant est de peu d'intérêt. 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.
 + 161950 NS ns1.cloudflare.net.
 + 161950 NS ns2.cloudflare.net.
 + 161950 NS ns3.cloudflare.net.
 + 161950 NS ns4.cloudflare.net.
 + 161950 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 ===== ===== Créer une zone =====
Ligne 336: Ligne 376:
  
 === Serial === === 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 === === Refresh ===
Ligne 357: 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%%''). 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> <code>
 $TTL    1600 $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
                          604800         ; Refresh                          604800         ; Refresh
                           86400         ; Retry                           86400         ; Retry
Ligne 378: Ligne 413:
                           1600 )        ; Negative Cache TTL                           1600 )        ; 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> </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. Tout va bien, notre serveur DNS fonctionne parfaitement.
 ===== Conclusion ===== ===== 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. 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».
  
Construire un serveur DNS: Dernière modification le: 17/03/2025 à 18:19 par prof