Par Serge.
Configuration de base d'un serveur named : serveur cache
Ce document est sous licence Licence pour Documents Libres de la guilde des doctorants.
Cet article est le 1er d'une série sur les serveurs DNS. Nous étudions dans ce premier article la configuration permettant de faire un serveur DNS dit "de cache", qui est en fait la configuration de base de n'importe quel serveur DNS. Nous voyons aussi à la fin de cet article comment se servir en plus des serveurs DNS de notre fournisseur d'accès, c'est à dire comment faire du "forward".
Un serveur DNS est le programme qui permet de traduire le nom d'un serveur, ou équipement IP, relié au réseau en adresse IP. Par exemple, lorsque dans votre navigateur vous tapez l'adresse du site web http://slackware-fr.org, votre navigateur va tout d'abord faire une requête DNS pour traduire le nom slackware-fr.org en une adresse IP, puis se connecter à cette adresse IP pour afficher le site web.
En réalité, les machines entre elles ne savent dialoguer qu'avec des adresses IPs. Les noms sont fait pour nous, les humains. Il faut donc des programmes pour résoudre les noms en adresses IP : c'est le rôle des serveurs DNS.
Une requête DNS consiste à demander à un serveur DNS la correspondance entre un nom et une adresse IP.
On a donc vu qu'un serveur DNS permet de traduire un nom en une adresse IP, mais comment fait-il ?
Tout d'abord il faut savoir que chaque requête DNS est découpée en plusieurs sous requêtes. Si on reprend notre exemple de site web www.slackware-fr.org, les étapes vont être les suivantes:
DNS de premier niveau Top Level Domain, ou encore TLD (.org, .com, .fr, ...) et sont connus de tous les autres serveurs DNS du monde.DNS qui gère la zone slackware-fr.org ?".DNS qui gère la zone slackware-fr.org en lui demandant "quelle est l'adresse de www.slackware-fr.org ?" et stocke la réponse en mémoire un certain temps, afin d'éviter de devoir reposer les même questions si on lui demande à nouveau la même requête DNS.Dans le processus que nous venons de décrire, nous pouvons distinguer deux principaux rôles pour un serveur DNS:
En terme de serveur DNS on distingue alors deux modes de fonctionnement:
Pour faire simple, le mode authoritative est le mode de fonctionnement d'un serveur DNS quand il répond à une requête DNS dont il sert la zone. C'est pour cela que quand vous enregistrez un domaine chez un registar (gandi, namebay, ovh, ...) celui-ci vous demande le serveur DNS primaire du domaine (et secondaire aussi), c'est à dire les serveurs qui vont être déclarés pour tout Internet comme étant les serveurs qui vont servir cette zone et à qui les autres serveurs vont poser, envoyer, les requêtes concernant cette zone. Ces serveurs sont les serveurs authoritative (autoritaire en français) de cette zone.
Le mode cache lui est le mode de fonctionnement inverse, c'est à dire quand il répond à une requête dont il ne sert pas la zone. Un serveur DNS cache permet aussi de conserver (de cacher) les réponses de requêtes DNS dont il n'est pas le serveur autoritative. Ceci permet de désengorger le réseau et d'accélérer les réponses DNS en évitant de demander à chaque fois à l'autre bout du monde une correspondance entre un nom et une adresse IP.
A savoir aussi que les modes de fonctionnement sont souvent mélangés : un même serveur DNS peut être serveur autoritaire pour une zone donnée, et faire serveur cache pour le reste des requêtes qui lui sont adressées.
Pour faire serveur DNS, la Slackware à besoin du paquet bind d'installé. Pour cela, vérifiez qu'il existe un fichier bind-???? dans /var/log/packages. Dans le cas contraire, vous trouverez ce paquet dans la série N des paquets Slackware.
La Slackware a la très bonne idée de configurer par défaut le serveur bind en tant que serveur cache. En fait il n'y a rien de surprenant à cela car, comme nous avons vu précédemment, tout serveur DNS fait serveur cache pour les zones qu'il ne sert pas.
Passons en revu sa configuration.
Voici le fichier par défaut lors de l'installation du paquet bind :
options {
directory "/var/named";
/*
* If there is a firewall between you and nameservers you want
* to talk to, you might need to uncomment the query-source
* directive below. Previous versions of BIND always asked
* questions using port 53, but BIND 8.1 uses an unprivileged
* port by default.
*/
// query-source address * port 53;
};
//
// a caching only nameserver config
//
zone "." IN {
type hint;
file "caching-example/named.ca";
};
zone "localhost" IN {
type master;
file "caching-example/localhost.zone";
allow-update { none; };
};
zone "0.0.127.in-addr.arpa" IN {
type master;
file "caching-example/named.local";
allow-update { none; };
};
Toutes les lignes qui débutent par 2 / sont des lignes de commentaires, elles ne sont là que pour documenter le fichier et n'ont aucune influence sur la configuration.
On remarque deux types de sections dans ce fichier: options et zone. Détaillons ces sections.
Cette section contient la configuration du serveur DNS lui-même. Voyons les options utilisées dans notre exemple, les autres options possibles seront vues plus tard.
directory: désigne le répertoire de travail du serveur. Tout chemin de fichier qui n'a pas un chemin absolu sera alors considéré comme relatif au chemin déclaré ici. Ce chemin est /var/named dans notre exemple.Nous voyons dans ce fichier plusieurs déclarations de zone.
Nous avons vu précédemment qu'une requête DNS était en fait découpée en plusieurs sous-requêtes, de manière hiérarchisée :
org dans la hiérarchie .?"slackware-fr dans la hiérarchie org?"www dans la hiérarchie slackware-fr.org?"Vous comprenez alors pourquoi, nous voyons comme première zone déclarée dans le fichier /etc/named.conf la zone .:
zone "." IN {
type hint;
file "caching-example/named.ca";
};
C'est dans ce fichier named.ca que nous allons retrouver la liste des serveurs racines (root).
Nous voyons aussi deux autres zones de déclarées dans ce fichier, localhost et 0.0.127.in-addr.arpa. Détaillons et expliquons ces fichiers.
Regardons plus en détails le fichier de zone ., c'est à dire le fichier de zone racine qui, comme nous avons vu, doit nous indiquer quels sont les serveurs qui gèrent les TLD.
/var/named/caching-example/named.ca:
; 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: Jan 29, 2004 ; related version of root zone: 2004012900 ; ; ; formerly NS.INTERNIC.NET ; . 3600000 IN NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4 ; ; formerly NS1.ISI.EDU ; . 3600000 IN NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. 3600000 A 192.228.79.201 ; ; formerly C.PSI.NET ; . 3600000 IN NS C.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12 ; ; formerly TERP.UMD.EDU ; . 3600000 IN NS D.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90 ; ; formerly NS.NASA.GOV ; . 3600000 IN NS E.ROOT-SERVERS.NET. E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10 ; ; formerly NS.ISC.ORG ; . 3600000 IN NS F.ROOT-SERVERS.NET. F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241 ; ; formerly NS.NIC.DDN.MIL ; . 3600000 IN NS G.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4 ; ; formerly AOS.ARL.ARMY.MIL ; . 3600000 IN NS H.ROOT-SERVERS.NET. H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53 ; ; formerly NIC.NORDU.NET ; . 3600000 IN NS I.ROOT-SERVERS.NET. I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17 ; ; operated by VeriSign, Inc. ; . 3600000 IN NS J.ROOT-SERVERS.NET. J.ROOT-SERVERS.NET. 3600000 A 192.58.128.30 ; ; operated by RIPE NCC ; . 3600000 IN NS K.ROOT-SERVERS.NET. K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129 ; ; operated by ICANN ; . 3600000 IN NS L.ROOT-SERVERS.NET. L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12 ; ; operated by WIDE ; . 3600000 IN NS M.ROOT-SERVERS.NET. M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33 ; End of File
Voila donc la liste des root servers de l'Internet, c'est à dire la liste des serveurs qui gère tout les TLD mondiaux. Pour plus d'informations sur ces serveurs, vous pouvez consulter: root-servers.org.
Grâce à ce fichier de zone votre serveur DNS peu résoudre n'importe quel domaine internet et en cacher les réponses. Les deux autres fichiers de zones sont pour une utilisation locale, ils permettent de résoudre l'adresse de loopback localhost et son reverse (inverse).
Fichier de zone localhost /var/named/caching-example/localhost.zone:
$TTL 86400
$ORIGIN localhost.
@ 1D IN SOA @ root (
42 ; serial (d. adams)
3H ; refresh
15M ; retry
1W ; expiry
1D ) ; minimum
1D IN NS @
1D IN A 127.0.0.1
Cela permet au serveur DNS de résoudre l'adresse locale 127.0.0.1. Comme cette adresse est une adresse locale, c'est au serveur lui-même de la résoudre et de la gérer: il est donc autoritaire pour cette zone et c'est pourquoi cette zone est déclarée dans le fichier de configuration du serveur.
Le fichier suivant est pour le reverse de la zone localhost.
Nous employons un nouveau terme, reverse, qu'est-ce donc? Un reverse (ou plus exactement une requête inverse) permet comme son nom l'indique de résoudre "en inverse", c'est à dire obtenir cette fois-ci le nom correspondant à une IP.
Bien que cela ne soit pas indispensable pour le fonctionnement du réseau, on associe fréquemment un nom à chaque adresse IP pour savoir à qui elle appartient, ou pour représenter le service associé à l'équipement qui possède cette IP ou bien encore pour vérifier que l'on usurpe pas une identité.
Par exemple l'IP 127.0.0.1 a pour nom localhost.
Fichier /var/named/caching-example/named.local:
$TTL 86400
@ IN SOA localhost. root.localhost. (
1997022700 ; Serial
28800 ; Refresh
14400 ; Retry
3600000 ; Expire
86400 ) ; Minimum
IN NS localhost.
1 IN PTR localhost.
Et voila ! Notre serveur DNS à tout ce qu'il faut pour être opérationnel.
Donc, dés que que nous faisons une requête DNS autre que "localhost" (ou son reverse 127.0.0.1) nous allons demander aux serveurs roots de nous donner la réponse. Nous avons l'avantage d'être sur de la réponse (les serveurs sont des serveurs de confiance) mais cela a l'inconvénient d'utiliser des serveurs déjà beaucoup chargés (ils s'occupent de tout l'Internet !!) et très loin de chez vous.
Sachant qu'il y a 13 serveurs root dans le monde, que 10 sont aux USA, 2 en Europe et 1 au Japon.
Votre fournisseur d'accès proposes des serveurs DNS pour tous ses abonnés, c'est à dire des serveurs caches. Autant s'en servir. Au lieu de demander aux serveurs root de l'autre coté de la planète, nous allons demander aux serveurs de notre fournisseur d'accès, qui de plus a surement déjà la réponse dans son cache car il y a de trés grande chance qu'un autre abonné ait déjà fait la même requête DNS que vous.
Nous allons donc faire notre cache non plus vis-à-vis des serveurs root, mais vis-à-vis du (ou des) serveur(s) Internet de notre fournisseur d'accés. Et si jamais ces derniers tombent en panne, la requête sera alors transmise aux serveurs roots. Pour cela il suffit simplement d'ajouter les directives de configuration dans le fichier /etc/named.conf comme ci-dessous :
options {
directory "/var/named";
/*
* If there is a firewall between you and nameservers you want
* to talk to, you might need to uncomment the query-source
* directive below. Previous versions of BIND always asked
* questions using port 53, but BIND 8.1 uses an unprivileged
* port by default.
*/
// query-source address * port 53;
forwarders
{
ip_dns1;
ip_dns2;
};
};
//
// a caching only nameserver config
//
zone "." IN {
type hint;
file "caching-example/named.ca";
};
zone "localhost" IN {
type master;
file "caching-example/localhost.zone";
allow-update { none; };
};
zone "0.0.127.in-addr.arpa" IN {
type master;
file "caching-example/named.local";
allow-update { none; };
};
Donc, si vous ne souhaitez faire qu'un serveur de cache vis-à-vis des serveurs DNS de votre fournisseur d'accés, voici les quelques lignes à ajouter dans la partie Options du fichier /etc/named.conf fournit, en standard, par la Slackware :
forwarders
{
ip_dns1;
ip_dns2;
};
Remplacez bien sûr ip_dns1 et ip_dns2 par les adresses IPs des serveurs DNS de votre fournisseur d'accés, par exemple chez moi 80.10.246.3 et 80.10.246.130. Ces adresses IPs vous sont fournit par votre FAI (au cas ou, demandez-les lui).
Votre serveur est désormais opérationel. Mais pour qu'il soit utile et utilisé il faut le spécifier à chaque machine et même à la machine qui le serveur DNS elle-même.
Pour la machine ayant le serveur DNS, il suffit de mettre une seule ligne nameserver dans le ficher /etc/resolv.conf pour spécifier à votre machine d'utiliser son propre serveur DNS :
nameserver 127.0.0.1
Si vous avez un réseau local et que vous voulez que vos autres postes profitent du serveur DNS, modifiez alors aussi leur resolv.conf en spécifiant l'IP locale de la machine ayant le serveur DNS, par exemple :
nameserver 192.168.0.1
Sachez que vous pouvez mettre plusieurs lignes nameserver, lors d'une requête DNS votre machine essayera les serveurs DNS un à un jusqu'à ce qu'il obtienne une réponse.
Le serveur DNS de cache enregistrant les requêtes déjà effectuées en mémoire, cela signifie que si vous arrêtez la machine sur laquelle tourne votre DNS, il perdra tout son cache et devra donc le reconstituer.
C'est donc pour cela qu'il est conseillé d'utiliser les DNS de votre FAI, et non les serveurs root, et d'installer votre serveur sur une passerelle, ou un serveur, qui est rarement arrêté.
Comme pour tous services sur la Slackware, vérifier que le script d'initialisation est bien exécutable pour un lancement automatique au boot :
chmod +x /etc/rc.d/rc.bind
Voici quelques commandes pour vérifier le bon fonctionement de votre serveur DNS.
Requête DNS simple:
host www.slackware-fr.org
vous allez avoir une réponse :
www.slackware-fr.org is an alias for ema.slackfr.org. ema.slackfr.org has address 213.186.60.118
où l'on apprend que www.slackware-fr.org est un alias de ema.slackfr.org qui a pour adresse 213.186.60.118 (les alias sont expliqués dans le second article DNS de ce site).
Et si nous regardons une requête complète, avec les sous-requêtes vers les serveurs root ?
Tapez cette commande :
dig @localhost www.toto.fr +trace
Et la réponse:
; <<>> DiG 9.4.3-P1 <<>> @localhost www.toto.fr +trace ; (1 server found) ;; global options: printcmd . 99837 IN NS M.ROOT-SERVERS.NET. . 99837 IN NS A.ROOT-SERVERS.NET. . 99837 IN NS D.ROOT-SERVERS.NET. . 99837 IN NS B.ROOT-SERVERS.NET. . 99837 IN NS J.ROOT-SERVERS.NET. . 99837 IN NS C.ROOT-SERVERS.NET. . 99837 IN NS L.ROOT-SERVERS.NET. . 99837 IN NS E.ROOT-SERVERS.NET. . 99837 IN NS G.ROOT-SERVERS.NET. . 99837 IN NS I.ROOT-SERVERS.NET. . 99837 IN NS F.ROOT-SERVERS.NET. . 99837 IN NS K.ROOT-SERVERS.NET. . 99837 IN NS H.ROOT-SERVERS.NET. ;; Received 304 bytes from 127.0.0.1#53(127.0.0.1) in 1 ms fr. 172800 IN NS E.EXT.NIC.fr. fr. 172800 IN NS G.EXT.NIC.fr. fr. 172800 IN NS A.NIC.fr. fr. 172800 IN NS F.EXT.NIC.fr. fr. 172800 IN NS D.EXT.NIC.fr. fr. 172800 IN NS E.NIC.fr. fr. 172800 IN NS B.EXT.NIC.fr. fr. 172800 IN NS C.NIC.fr. ;; Received 405 bytes from 192.33.4.12#53(C.ROOT-SERVERS.NET) in 97 ms toto.fr. 172800 IN NS dns.ovh.net. toto.fr. 172800 IN NS ns.ovh.net. ;; Received 71 bytes from 194.146.106.46#53(F.EXT.NIC.fr) in 7 ms www.toto.fr. 86400 IN CNAME toto.fr. toto.fr. 86400 IN A 193.251.93.237 toto.fr. 86400 IN NS ns.ovh.net. toto.fr. 86400 IN NS dns.ovh.net. ;; Received 133 bytes from 212.27.32.132#53(ns.ovh.net) in 1 ms
Où nous voyons que pour demander www.toto.fr nous avons tout d'abord demandé à 127.0.0.1 la liste des serveurs root et nous avons eu comme réponse :
. 99837 IN NS M.ROOT-SERVERS.NET. . 99837 IN NS A.ROOT-SERVERS.NET. . 99837 IN NS D.ROOT-SERVERS.NET. . 99837 IN NS B.ROOT-SERVERS.NET. . 99837 IN NS J.ROOT-SERVERS.NET. . 99837 IN NS C.ROOT-SERVERS.NET. . 99837 IN NS L.ROOT-SERVERS.NET. . 99837 IN NS E.ROOT-SERVERS.NET. . 99837 IN NS G.ROOT-SERVERS.NET. . 99837 IN NS I.ROOT-SERVERS.NET. . 99837 IN NS F.ROOT-SERVERS.NET. . 99837 IN NS K.ROOT-SERVERS.NET. . 99837 IN NS H.ROOT-SERVERS.NET.
Puis nous avons demandé au serveur root C.ROOT-SERVERS.NET les serveurs qui gérent la zone .fr et nous avons eu comme réponse :
fr. 172800 IN NS E.EXT.NIC.fr. fr. 172800 IN NS G.EXT.NIC.fr. fr. 172800 IN NS A.NIC.fr. fr. 172800 IN NS F.EXT.NIC.fr. fr. 172800 IN NS D.EXT.NIC.fr. fr. 172800 IN NS E.NIC.fr. fr. 172800 IN NS B.EXT.NIC.fr. fr. 172800 IN NS C.NIC.fr.
Puis nous avons demandé au serveur F.EXT.NIC.fr les serveurs qui gérent la zone toto.fr et nous avons eu comme réponse :
toto.fr. 172800 IN NS dns.ovh.net. toto.fr. 172800 IN NS ns.ovh.net.
Et enfin nous avons demandé au serveur ns.ovh.net l'adresse de www.toto.fr et nous avons eu comme réponse :
www.toto.fr. 86400 IN CNAME toto.fr. toto.fr. 86400 IN A 193.251.93.237
et donc www.toto.fr a pour adresse IP 193.251.93.237.
On vérifie que l'on est bien autoritaire sur la zone localhost. Tapez cette commande:
nslookup
Vous allez avoir un shell :
>
Tapez alors :
localhost
Et vous allez avoir comme réponse :
Server: 127.0.0.1 Address: 127.0.0.1#53 Name: localhost Address: 127.0.0.1
Tapez cette commande:
nslookup
Vous aurez un shell :
>
Tapez alors:
www.toto.fr
et vous aurez comme réponse:
toto.fr Server: 127.0.0.1 Address: 127.0.0.1#53
Non-authoritative answer: Name: toto.fr Address: 193.251.93.237
Le Non-authoritative answer prouve bien que votre serveur n'est pas autoritaire pour cette zone et a du demander la réponse à d'autres serveurs DNS.
Thèmes : #articles #bind #dns #local #logiciels #named #reseau #serge
Sauf indication contraire, ce document est placé sous licence CC-BY-SA 3.0.