Ceci est une ancienne révision du document !
Table des matières
Construire un serveur DNS
Pourquoi faire ?
- pour comprendre mieux comment ça fonctionne ;
- pour disposer d'une solution de secours si le(s) serveur(s) DNS de notre fournisseur d'accès montre(nt) des signes de faiblesse ;
- pour se créer un petit intranet sympa, même avec un nom de domaine « en bois » qui ne sera fonctionnel que sur notre LAN.
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…
Bon gros avertissement
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.
apt 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.
Un simple cache
Une simple question
Par défaut, le cache devrait répondre aux requêtes issues de toutes les stations du réseau local.
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 www.debian.org ::1
Using domain server:
Name: ::1
Address: ::1#53
Aliases:
www.debian.org has address 194.177.211.216
www.debian.org has address 130.89.148.77
www.debian.org has IPv6 address 2001:648:2ffc:deb:216:61ff:fe2b:6138
www.debian.org has IPv6 address 2001:67c:2564:a119::77
Notons que la réponse contient 2 adresses IPv4 et 2 adresses IPv6. Il faudra revenir sur cette curiosité.
Par quel prodige ?
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.
ls -l /etc/bind/ total 48 -rw-r--r-- 1 root root 2928 25 janv. 11:14 bind.keys -rw-r--r-- 1 root root 255 25 janv. 11:14 db.0 -rw-r--r-- 1 root root 271 25 janv. 11:14 db.127 -rw-r--r-- 1 root root 237 25 janv. 11:14 db.255 -rw-r--r-- 1 root root 353 25 janv. 11:14 db.empty -rw-r--r-- 1 root root 270 25 janv. 11:14 db.local -rw-r--r-- 1 root bind 458 25 janv. 11:14 named.conf -rw-r--r-- 1 root bind 498 25 janv. 11:14 named.conf.default-zones -rw-r--r-- 1 root bind 165 25 janv. 11:14 named.conf.local -rw-r--r-- 1 root bind 846 25 janv. 11:14 named.conf.options -rw-r----- 1 bind bind 100 17 mars 16:22 rndc.key -rw-r--r-- 1 root root 1317 25 janv. 11:14 zones.rfc1918Nous n'en avons pas parlé jusqu'ici, mais il faut tout de même 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. 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 /etc/bind/named.conf // This is the primary configuration file for the BIND DNS server named. // // Please read /usr/share/doc/bind9/README.Debian 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"; include "/etc/bind/named.conf.local"; include "/etc/bind/named.conf.default-zones";
Bien. Un fichier qui dit qu'il faut en regarder d'autres…
Les options
cat /etc/bind/named.conf.options
options {
directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://www.kb.cert.org/vuls/id/800113
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
// forwarders {
// 0.0.0.0;
// };
//========================================================================
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See https://www.isc.org/bind-keys
//========================================================================
dnssec-validation auto;
listen-on-v6 { any; };
};
Une fois enlevé les commentaires, il ne reste pas grand chose, mais c'est ici qu'il faudra agir si ce serveur doit fonctionner sur l'internet.
Localement...
cat /etc/bind/named.conf.local // // Do any local configuration here // // Consider adding the 1918 zones here, if they are not used in your // organization //include "/etc/bind/zones.rfc1918";Simple, pour l'instant il n'y a rien.
Les zones par défaut
Les zones, ce sont les espaces qui correspondent à un niveau du FQDN que l'on veut renseigner pour ce serveur.. Pratiquement, elles sont définies dans des fichiers que le serveur va lire et mettre en cache lors de son démarrage, puis relire périodiquement d'un TTL indiqué dans le fichier de la zone.
cat /etc/bind/named.conf.default-zones // prime the server with knowledge of the root servers zone "." { type hint; file "/usr/share/dns/root.hints"; }; // 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"; };La zone
. de type «hint», la seule de ce type, c'est la zone qui renseigne tous les «root servers». Le fichier est placé dans un répertoire particulier: /usr/share/dns/ car le fichier root.hints peut être mis à jour avec les mises à jour du système. C'est rarement le cas, mais ça peut arriver. Ce fichier contient donc:
; 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.cache ; on server FTP.INTERNIC.NET ; -OR- RS.INTERNIC.NET ; ; last update: April 18, 2024 ; related version of root zone: 2024041801 ; ; FORMERLY NS.INTERNIC.NET ; . 3600000 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 170.247.170.2 B.ROOT-SERVERS.NET. 3600000 AAAA 2801:1b8:10::b ; ; FORMERLY C.PSI.NET ; . 3600000 NS C.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12 C.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:2::c ; ; FORMERLY TERP.UMD.EDU ; . 3600000 NS D.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET. 3600000 A 199.7.91.13 D.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:2d::d ; ; FORMERLY NS.NASA.GOV ; . 3600000 NS E.ROOT-SERVERS.NET. E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10 E.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:a8::e ; ; 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 G.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:12::d0d ; ; FORMERLY AOS.ARL.ARMY.MIL ; . 3600000 NS H.ROOT-SERVERS.NET. H.ROOT-SERVERS.NET. 3600000 A 198.97.190.53 H.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:1::53 ; ; FORMERLY NIC.NORDU.NET ; . 3600000 NS I.ROOT-SERVERS.NET. I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17 I.ROOT-SERVERS.NET. 3600000 AAAA 2001:7fe::53 ; ; 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 L.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:9f::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 fileroot@demoserver1:/usr/share/dns#
La liste des root-servers, leurs FQDN, le TTL de l'information qui suit à savoir leur adresse IPv4 et IPv6 car nous pouvons constater qu'ils ont désormais tous une adresse IPv6.
La zone "localhost"
Pas bien utile en général, elle permet de résoudre localhost :
cat /etc/bind/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 ::1Le fichier
db.local a une structure que nous aurons besoin de détailler plus tard, car c'est la structure typique de toute zone définie dans notre serveur. Nous y apprenons que localhost dispose des adresses 127.0.0.1 en IPv4 et ::1 en IPv6, ce que nous savions déjà.
Les autres zones
sont destinées à la recherche inverse, ce qui pour l'instant est de peu d'intérêt.
Créer une zone
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:
whois nain-t.net Domain Name: NAIN-T.NET ... Registrar: OVH sas ... Name Server: DNS12.OVH.NET Name Server: NS12.OVH.NETMais 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:
zone "home.nain-t.net" {
type master;
file "/etc/bind/db.home";
};
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 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, 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 :
host -t NS yahoo.com yahoo.com name server ns4.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 ns2.yahoo.com.Cinq Name Servers pour le domaine Yahoo.com. 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. 2025031706 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).
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.
Refresh
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.
Retry
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.
Expire
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 ?
Negative Cache TTL
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.
NS, A, AAAA, CNAME et les autres
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).
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
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.
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 :
# 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.
psst ! le round-robin ?...
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.