Pourquoi faire ?
Les raisons sont-elles suffisantes ? Oui, alors allons-y. Nous avons bien un vieux PC qui traine dans un coin et qui ne demande qu'à reprendre du service. Nous y installons une Debian (Lenny dans ce qui suit), sans aucune fioriture, le strict minimum, quoi. Avec bind9 et quelques outils de base, nous ne dépasserons pas les 800 Mo sur le disque et 256 Mo de RAM pourront faire l'affaire, si notre réseau local ne dépasse pas 100 postes…
Ce que nous allons faire ici est destiné à l'usage exclusif de notre LAN. Aucune considération de sécurité ne sera abordée. Si le principe reste le même pour la mise en place d'un serveur DNS public, il faudra prendre en compte tous les risques d'agression et ils sont nombreux.
aptitude install bind9 bind9-host
Qu'avons-nous ajouté sur notre machine ? Le très célèbre serveur DNS de chez ISC, nommé bind, dans sa version 9 et la commande host.
En l'état, notre bind est fonctionnel, c'est un serveur DNS récursif qui sait par lui-même répondre à toutes les demandes de résolution de FQDN de l'internet. La preuve ?
# host -v www.altavista.fr 127.0.0.1 Trying "www.altavista.fr" Using domain server: Name: 127.0.0.1 Address: 127.0.0.1#53 Aliases: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29138 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.altavista.fr. IN A ;; ANSWER SECTION: www.altavista.fr. 7200 IN CNAME rc.yahoo.com. rc.yahoo.com. 1800 IN CNAME rc.fy.b.yahoo.com. rc.fy.b.yahoo.com. 300 IN A 206.190.60.37 ;; AUTHORITY SECTION: fy.b.yahoo.com. 300 IN NS yf1.yahoo.com. fy.b.yahoo.com. 300 IN NS yf2.yahoo.com. Received 134 bytes from 127.0.0.1#53 in 961 ms Trying "rc.fy.b.yahoo.com" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15133 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;rc.fy.b.yahoo.com. IN AAAA ;; AUTHORITY SECTION: fy.b.yahoo.com. 30 IN SOA yf1.yahoo.com. hostmaster.yahoo-inc.com. 1233237548 30 30 86400 1800 Received 96 bytes from 127.0.0.1#53 in 30 ms Trying "rc.fy.b.yahoo.com" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45688 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;rc.fy.b.yahoo.com. IN MX ;; AUTHORITY SECTION: fy.b.yahoo.com. 30 IN SOA yf1.yahoo.com. hostmaster.yahoo-inc.com. 1233237548 30 30 86400 1800 Received 96 bytes from 127.0.0.1#53 in 31 ms
L'emploi de l'option -v rend la réponse un peu indigeste, mais assez instructive.
Nous apprenons que www.altavista.fr. n'est qu'un alias de rc.yahoo.com., lui-même alias de rc.fy.b.yahoo.com. et que son adresse IP est 206.190.60.37.
En prime, nous apprenons que le domaine fy.b.yahoo.com. est géré par les serveurs DNS yf1.yahoo.com. et yf2.yahoo.com., que www.altavista.fr. ne dispose pas d'adresse IP v6, la réponse à la question ;rc.fy.b.yahoo.com. IN AAAA aurait eu une réponse et enfin, que le SOA pour ce domaine est yf1.yahoo.com.. C'est quoi un SOA ? Rappelez-moi d'en parler plus loin dans ce chapitre si jamais j'oubliais.
Toutes ces informations, c'est notre bind à nous qui les a trouvées en se débrouillant tout seul, et en 961 millisecondes seulement ! Nous n'aurions pas fait mieux.
Bien sûr nous pouvons lui poser une question plus simple (sans l'option -v) pour un nœud qui n'a rien à voir :
# host www.google.fr 127.0.0.1 Using domain server: Name: 127.0.0.1 Address: 127.0.0.1#53 Aliases: 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
C'est plus lisible, il y a moins d'informations. Remarquez qu'un seul nom dispose ici de plusieurs adresses IP. C'est du « round-robin » (tourniquet en français). A quoi ça sert ? Rappelez-moi d'en parler plus loin dans ce chapitre si jamais j'oubliais…
Bref, notre bind sait parfaitement effectuer pour nous toute résolution de FQDN, nous pouvons désormais nous passer des serveurs DNS récursifs de notre fournisseur d'accès, à l'exception des clients d'Orange™ qui devront prendre quelques précautions et là encore, nous verrons pourquoi plus tard.
Notre installation de bind9 a produit une configuration par défaut, minimaliste, qui permet au serveur de fonctionner en mode récursif. Sans entrer dans tous les détails, allons y voir de plus près.
Tout se trouve (sur Debian) dans le répertoire /etc/bind.
# cd /etc/bind debvirt:/etc/bind# ls -l total 44 -rw-r--r-- 1 root root 237 jan 2 18:19 db.0 -rw-r--r-- 1 root root 271 jan 2 18:19 db.127 -rw-r--r-- 1 root root 237 jan 2 18:19 db.255 -rw-r--r-- 1 root root 353 jan 2 18:19 db.empty -rw-r--r-- 1 root root 270 jan 2 18:19 db.local -rw-r--r-- 1 root root 2878 jan 2 18:19 db.root -rw-r--r-- 1 root bind 907 jan 2 18:19 named.conf -rw-r--r-- 1 root bind 165 jan 2 18:19 named.conf.local -rw-r--r-- 1 root bind 572 jan 2 18:19 named.conf.options -rw-r----- 1 bind bind 77 jan 29 14:16 rndc.key -rw-r--r-- 1 root root 1317 jan 2 18:19 zones.rfc1918
Nous n'en avons pas parlé jusqu'ici, mais il faut tout de même en dire quelques mots, de la résolution inverse, celle qui consiste à retrouver un nom d'hôte à partir de son adresse IP. Ce service est peu utilisé par le particulier (entendez par là l'internaute en général). Il l'est cependant parfois par des services sur l'internet, comme par exemple SMTP, pour tenter de lutter contre le spam. Pour cette raison, nous n'en dirons pas plus sur la question.
Voyons sans plus tarder le contenu de named.conf qui, de toute évidence, constitue le fichier de configuration principal :
# cat named.conf // This is the primary configuration file for the BIND DNS server named. // // Please read /usr/share/doc/bind9/README.Debian.gz for information on the // structure of BIND configuration files in Debian, *BEFORE* you customize // this configuration file. // // If you are just adding zones, please do that in /etc/bind/named.conf.local include "/etc/bind/named.conf.options"; // prime the server with knowledge of the root servers zone "." { type hint; file "/etc/bind/db.root"; }; // be authoritative for the localhost forward and reverse zones, and for // broadcast zones as per RFC 1912 zone "localhost" { type master; file "/etc/bind/db.local"; }; zone "127.in-addr.arpa" { type master; file "/etc/bind/db.127"; }; zone "0.in-addr.arpa" { type master; file "/etc/bind/db.0"; }; zone "255.in-addr.arpa" { type master; file "/etc/bind/db.255"; }; include "/etc/bind/named.conf.local";
Déjà, nous constatons que ce fichier fait lui-même appel à deux autres fichiers de configuration, named.conf.options et named.conf.local. Nous aurons à modifier au moins l'un d'entre eux. En revanche, named.conf ne devrait (sur Debian) jamais être modifié, sauf par les mises à jour futures de la distribution.
A part ceci, nous observons des déclarations de zones, presques toutes destinées à la résolution inverse, à l'exception de celle qui sont surlignées en vert.
Pas bien utile en général, elle permet de résoudre localhost :
# cat db.local ; ; BIND data file for local loopback interface ; $TTL 604800 @ IN SOA localhost. root.localhost. ( 2 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; @ IN NS localhost. @ IN A 127.0.0.1 @ IN AAAA ::1
Le fichier db.local a une structure que nous aurons besoin de détailler plus tard. Nous y apprenons que localhost dispose des adresses 127.0.0.1 en IPv4 et ::1 en IPv6, ce que nous savions probablement déjà.
Plus intéressant est le fichier db.root :
# cat db.root ; This file holds the information on root name servers needed to ; initialize cache of Internet domain name servers ; (e.g. reference this file in the "cache . <file>" ; configuration file of BIND domain name servers). ; ; This file is made available by InterNIC ; under anonymous FTP as ; file /domain/named.root ; on server FTP.INTERNIC.NET ; -OR- RS.INTERNIC.NET ; ; last update: Feb 04, 2008 ; related version of root zone: 2008020400 ; ; formerly NS.INTERNIC.NET ; . 3600000 IN NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4 A.ROOT-SERVERS.NET. 3600000 AAAA 2001:503:BA3E::2:30 ; ; formerly NS1.ISI.EDU ; . 3600000 NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. 3600000 A 192.228.79.201 ; ; formerly C.PSI.NET ; . 3600000 NS C.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12 ; ; formerly TERP.UMD.EDU ; . 3600000 NS D.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90 ; ; formerly NS.NASA.GOV ; . 3600000 NS E.ROOT-SERVERS.NET. E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10 ; ; formerly NS.ISC.ORG ; . 3600000 NS F.ROOT-SERVERS.NET. F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241 F.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:2f::f ; ; formerly NS.NIC.DDN.MIL ; . 3600000 NS G.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4 ; ; formerly AOS.ARL.ARMY.MIL ; . 3600000 NS H.ROOT-SERVERS.NET. H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53 H.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:1::803f:235 ; ; formerly NIC.NORDU.NET ; . 3600000 NS I.ROOT-SERVERS.NET. I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17 ; ; operated by VeriSign, Inc. ; . 3600000 NS J.ROOT-SERVERS.NET. J.ROOT-SERVERS.NET. 3600000 A 192.58.128.30 J.ROOT-SERVERS.NET. 3600000 AAAA 2001:503:C27::2:30 ; ; operated by RIPE NCC ; . 3600000 NS K.ROOT-SERVERS.NET. K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129 K.ROOT-SERVERS.NET. 3600000 AAAA 2001:7fd::1 ; ; operated by ICANN ; . 3600000 NS L.ROOT-SERVERS.NET. L.ROOT-SERVERS.NET. 3600000 A 199.7.83.42 ; ; operated by WIDE ; . 3600000 NS M.ROOT-SERVERS.NET. M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33 M.ROOT-SERVERS.NET. 3600000 AAAA 2001:dc3::35 ; End of File
Il contient en effet toutes les informations sur les root-servers, sans quoi, notre bind n'aurait rien pu faire. Notez que le ; est un signe de commentaire.
Le contenu de ce fichier évolue peu dans le temps et les mises à jour de la distribution suffisent normalement à le maintenir dans un état satisfaisant. Notez que certains (mais peu encore) des root-servers disposent d'une adresse IPv6.
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.
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.
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).
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 ».
Nous pouvons d'ailleurs, au moyen de la commande host savoir rapidement toutes ces choses :
# 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.
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.
Mais quel est dans cette liste le serveur « maitre » ?
# host -t soa yahoo.com yahoo.com has SOA record ns1.yahoo.com. hostmaster.yahoo-inc.com. 2009012906 3600 300 1814400 600
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.
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.
Indique en seconde le temps au bout duquel les serveurs « esclaves », aussi appelés secondaires, devront demander à rafraichir leur données pour cette zone. 3600 secondes dans l'exemple, soit une heure.
Indique en secondes au bout de combien de temps un serveur esclave doit ré-essayer de se synchroniser si la tentative a échoué après le temps refresh. Ici toutes les 300 secondes, soit toutes les 5 minutes.
Si toutes les tentatives de synchronisation échouent, indique le temps (en secondes) au bout duquel les serveurs secondaires devront considérer qu'ils ne savent plus répondre aux requêtes concernant cette zone. Ici 1814400 secondes, soit 21 jours ! Mieux vaut donner une réponse peut-être fausse que de ne pas en donner du tout ?
Paramètre dont la signification est assez floue. Pour bind9, indique le temps pendant lequel les caches (DNS récursifs) conserverait l'information NXDOMAIN, « le domaine n'existe pas », lorsqu'un incident s'est produit.
Le champ NS (Name Server) indique le nom d'un serveur de noms. Pour une zone donnée, s'il y a plusieurs serveurs de noms, il y aura plusieurs champs NS.
Le champ A (Address) fait correspondre un nom à une adresse IPv4, alors que le champ AAAA fera correspondre un nom à une adresse IPv6.
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).
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 ...
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 :
Créons d'abord dans /etc/bind/ un fichier nommé par exemple : db.maison.mrs qui contiendrait ceci :
$TTL 1600
@ IN SOA debvirt.maison.mrs. root.debvirt.maison.mrs. (
2009012901 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
1600 ) ; Negative Cache TTL
;
@ IN NS debvirt.maison.mrs.
@ IN A 192.168.0.254
debvirt IN A 192.168.0.254
test1 IN A 192.168.0.1
test2 IN CNAME test1
test3 IN CNAME irp.nain-t.net.
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.
Il nous faut maintenant indiquer à bind que cette zone existe. Nous allons le faire dans le fichier /etc/bind/named.conf.local :
zone "maison.mrs" {
type master;
file "/etc/bind/db.maison.mrs";
};
Enfin, nous redémarrons bind avec un /etc/init.d/bind9 restart et nous contrôlons
# 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: ;maison.mrs. IN ANY ;; ANSWER SECTION: 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 # host test1.maison.mrs test1.maison.mrs has address 192.168.0.1 # host test2.maison.mrs test2.maison.mrs is an alias for test1.maison.mrs. test1.maison.mrs has address 192.168.0.1 # host test3.maison.mrs test3.maison.mrs is an alias for irp.nain-t.net. irp.nain-t.net has address 213.186.40.149
Tout va bien, notre serveur DNS fonctionne parfaitement.
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.
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 :
# 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
Voyons maintenant depuis une connexion Orange™, qui utilise les serveurs DNS renseignés par la connexion PPPoE :
# 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
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 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.
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 :
d# 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.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
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.