S'il n'y a pas de solution c'est qu'il n'y a pas de problème!

Bind

Lors du passage chez Nerim, Linux-sottises a obtenu un ip fixe, et de fil en aiguille, j'ai décidé d'acheter le nom de domaine linux-sottises.net chez Gandi, et comme Gandi ne proposait que d'héberger un DNS secondaire, je me suis lancé dans l'installation de bind8 pour gérer directement le DNS primaire.

Je n'ai pas trouvé ça "immédiat" (la syntaxe des fichiers de configuration de bind fait quand même un peu "âge de pierre"), d'autre part le fonctionnement des DNS semble finalement "assez peu connu", enfin quelques copains de Linux-sottises m'ont "mis la pression" pour écrire un mode d'emploi de bind dans le style du "reste" de Linux-sottises, et bien je m'y suis mis, et voilà le résultat.

Ce document s'inspire naturellement largement du DNS-HOWTO, qui est utile mais que je trouve un peu aride et obscur par endroits. J'ai aussi utilisé le livre DNS et Bind de Paul Albitz & Cricket Liu chez O'Reilly. Cette page n'a évidemment pas l'ambition de remplacer ce bouquin, mais devrait faciliter la mise en place d'un DNS primaire "en comprenant à peu près ce qu'on fait". Arriverai-je à faire mieux que le Howto, c'est à vous de le dire!
Vous trouverez aussi des info sympas sur queret.net

Quelques mots sur le fonctionnement des DNS

Quelques mots pour expliquer brièvement (et donc nécessairement de manière incomplète, voire un peu erronée...) le fonctionnement de la résolution de noms: que se passe-t-il quand vous rentrez www.domain.com dans votre navigateur préféré?

Et bien votre navigateur doit trouver quelle est l'adresse IP qui correspond au nom www.domain.com, car vous savez bien que l'ensemble des machines sur Internet sont repérées par leur adresse IP. Un programme qui cherche à trouver l'adresse IP à partir d'un nom (ou l'inverse, un nom à partir d'un IP) s'appelle un resolver.

L'ensemble de ces informations "nom-adresse" est "distribué" sur Internet sur des serveurs DNS (Domain Name Server). Il n'existe nulle part regroupé l'ensemble de ces informations.

Commence alors une sorte de chasse aux trésors dans laquelle plusieurs machines font donner des indices au resolver pour trouver l'adresse de www.domain.com

Le resolver va d'abord s'adresser au "bon dieu" pour une première indication, il lui pose la question: qui gère les noms qui se terminent par .com? Le "bon dieu" en question, ce sont les serveurs DNS "root" dont les adresses figurent dans /var/named/root.hint (jetez un coup d'oeil à ce fichier, j'indiquerai plus loin comment le tenir à jour)

L'un des serveurs root va indiquer au resolver quels sont les DNS qui gèrent les domaines qui se terminent en .com; Ces serveurs là s'appellent des GTLD (Generic Top Level Domains). Le resolver va ensuite s'adresser à l'un d'eux pour lui demander: qui gère les domaines qui se terminent en domain.com?

Une fois les adresses de ces serveurs connues, le resolver va s'adresser à l'un d'eux pour lui demander: quelle est l'adresse de www.domain.com? Et là, le resolver a fini son travail, il a obtenu l'adresse qu'il cherchait.

Naturellement, il est facile d'imaginer le traffic monstrueux qui serait généré si chaque clic sur votre navigateur déclenchait toutes ces opérations!! Pour pallier cette question de traffic, chaque serveur DNS a un système de cache dans lequel il pioche les adresses qu'il a déjà cherchées... Oui mais si l'adresse a changé?? Et bien chaque DNS, en même temps qu'il donne ses informations (que cela soit un serveur root, gtld ou DNS "final") donne une durée de validité de ces informations. Quand la durée est dépassée, une nouvelle requête n'est pas prise dans le cache, mais provoque une réintérrogation sur les données dont la validité est périmée. Chaque responsable de DNS doit choisir la durée de validité (TTL=Time To Live) des données qu'il envoie: plus elle est courte, plus son serveur sera sollicité et plus le traffic généré sera grand, plus elle est longue, plus longue sera la mise à jour "effective" de ses données.

Exemple pratique
Lancez

nslookup

puis

server a.root-servers.net

(on va utiliser le serveur root a.root-servers.net). Entrez:

net.

(avec le . à la fin, cela signifie qui gère la branche .net?) . Arrive la liste des serveurs GTLD qui gèrent les domaines en .net; Choississez en un, par exemple entrez:

server k.gtld-servers.net

Demandez lui qui gère linux-sottises.net, entrez (n'oubliez pas le . à la fin):

linux-sottises.net.

vous allez avoir l'info des serveurs qui gèrent linux-sottises.net. Vous devriez avoir 3 serveurs: yoda.linux-sottises.net, ns6.gandi.net et metroid.nerim.net. Choississez en un, par exemple entrez:

server yoda.linux-sottises.net

demandez lui maintenant quelle est l'adresse de www.linux-sottises.net (avec ou sans point à la fin, à ce niveau c'est identique):

www.linux-sottises.net

Vous obtenez l'adresse 62.4.22.49

Configuration

Tout d'abord, tout ce qui suit concerne la version 8.2.3 de bind. Installer le soit à partir des paquetages de votre distribution favorite soit depuis le site d'Internet Software Consortium.

Vous êtes propriétaire d'un nom de domaine, vous avez un IP fixe , et vous avez choisi un nom pour votre serveur DNS. Vous connaissez aussi le nom de la machine qui vous servira de DNS secondaire.
Je prendrai comme exemple celui que je connais le mieux (8-D) linux-sottises, donc domaine=linux-sottises.net, IP=62.4.22.49, DNS1=yoda.linux-sottises.net, DNS2=metroid.nerim.net (en fait j'ai aussi un DNS3=ns6.gandi.net).

Il y a deux types de fichiers de configuration: le fichier de configuration générale de bind (en général /etc/named.conf) et les fichiers de description de "zones" (placés dans /var/named) . Quand vous installez bind, vous avez aussi un fichier /var/named/root.hint (ou /var/named.root si vous utilisez un paquetage d'une distribution) qui contient les adresses des serveurs root (ou vous le récupérez par ftp à ftp.rs.internic.net, répertoire /domain, fichier named.root)

Le fichier /etc/named.conf comporte des sections qui décrivent les options utilisées, le logging et la déclaration des zones dont on est maitre. Un exemple étant plus parlant, téléchargez ou visualisez celui que j'utilise, et commentons le.

La partie entre { }; contient toutes les options.

• directory indique le répertoire où devront être cherchés les fichiers de zone
• pid-file est le fichier où est stocké le numéro de process
• forwarders indique que les demandes qui seront adressées à bind seront transférées aux ip correspondants (les dns de mon FAI Nerim) et que bind ne fera la requête lui même que si ces dns ne répondent pas. Cette option n'est naturellement pas obligatoire.
• forward first; demande le comportement précédemment décrit (d'abord demander aux serveurs forwarders, l'autre option est only: on n'utilise que les serveurs forwarders)
• query-source indique le port sur lequel écouter les requêtes (derrière un firewall, port * est recommandé)
• allow-query indique les ip qui peuvent interroger le serveur. N'indiquez que des adresses locales (réseau local, boucle locale, ip public internet) si vous ne voulez pas que votre serveur soit utilisé par la terre entière... (vous autoriserez toutes les demandes externes mais uniquement pour votre zone!)
• allow-recursion indique les interfaces pour lesquelles bind fait "tout le travail" (et pas uniquement indiquer l'adresse où trouver l'info)
• listen-on indique quelles interfaces sont "écoutées"? Cla peut paraitre faire double emploi, mais sans cela bind écoute toutes les interfaces (y compris l'interface connéctée au modem ;-)

Voilà pour les options. Faites man named.conf pour plus d'options et plus d'informations.

La partie logging que j'utilise est simple et standard, reportez vous aussi à man named.conf pour plus d'informations.

Figurent ensuite les caractéristiques générales des zones de votre serveur. Le premier ordre "zone" concerne la racine des serveurs de nom "." et fait appel au fichier root.hint (tous les fichiers se trouvent par défaut dans le répertoire indiqué dans l'ordre "directory"). IN indique une classe Internet (en fait c'est la seule classe réellement utilisée). Vous pouvez voir ici mon fichier root.hint

Viennent ensuite les caractéristiques de la zone "linux-sottises.net" dont bind est maître

• type master; indique que bind est maître du domaine (c'est lui qui est responsable de la validité des informations sur tout internet)
• file "zone/linux-sottises.net"; indique l'emplacement du fichier de configuration de la zone (chemin relatif au répertoire déclaré plus haut, et donc ici /var/named/zone/linux-sottises.net)
• allow-transfer{}; donne la liste des IP vers lesquels les transferts d'information de la zone sont autorisés, c'est à dire les IP des dns "secondaires".
• allow-query{}; indique qui a le droit de faire des requêtes sur votre serveur, any indique "tout le monde", c'est naturellement indispensable ici, votre serveur sera interrogé pour votre domaine.

La zone suivante est une zone "reverse" (ip vers nom) et concerne la boucle locale (relation de la machine avec elle même). La partie du nom xxx.xxx avant .in-addr.arpa pourra être utilisée dans le fichier de la zone lui même. Ainsi 0.0.127.in-addr.arpa permettra de décrire les adresses de la forme 127.0.0.x

Remarque. Si vous enlevez la zone master du fichier de configuration et gardez la partie 0.0.127.in-addr.arpa et le fichier correspondant (voir plus loin), vous disposez d'un serveur de nom sur votre machine qui vous rendra bien service si les dns de votre FAI sont en rade!

J'ai ensuite configuré la zone reverse pour mon réseau local. 0.168.192.in-addr.arpa permet de décrire les adresses locales de la forme 192.168.0.x.

Passons aux fichiers de zone. Téléchargez ou visualisez ici le fichier linux-sottises.net que je stocke dans /var/named/zone comme indiqué dans le fichier de configuration de bind.

• $TTL 86400 indique une durée de vie (Time To Live) par défaut de 86400 secondes (une journée) pour les enregistrements où cela n'est pas précisé
• @ est un raccourci pour le nom de la zone indiquée dans le fichier named.conf suivi d'un point. C'est à dire que si vous n'utilisez pas @, vous DEVEZ mettre votre nom de domaine (linux-sottises.net. pour moi)
• SOA désigne l'enregistrement de "début d'autorité" (Start Of Authority), il est suivi du nom du serveur DNS primaire et de l'adresse du responsable où @ est remplacé par un "." et l'adresse elle même terminée aussi par un "." (je sais c'est bizarre, mais c'est comme ça)
• viennent ensuite entre ( ) des informations sur la durée de validité de l'enregistrement:
  • pour commencer, indiquez un numéro de série de l'enregistrement. Quand vous changerez votre configuration, n'oubliez pas d'updater ce numéro, cela permettra aux serveurs esclaves de mettre à jours leurs données quand cela est nécessaire. Utilisez un numéro de série de la forme AAAAMMJJXX où AAAA et l'année, MM le mois sur deux chiffres, JJ le jour sur deux chiffres et XX un numéro à deux chiffres (vous pouvez commencez à 00 et augmenter de 1 à chaque changement dans la même journée).
  • viennent ensuite 4 durées:
    • le rafraichissement correspond à l'intervalle entre deux vérifications des serveurs esclaves
    • reessai est l'intervalle de nouvelle tentative de vérification en cas de non réponse de votre serveur
    • l'obsolescence correspond à la durée maximale pendant laquelle les esclaves répondront aux requêtes sans avoir pu contacter le serveur maitre
    • durée de vie est la durée de validité des données communiquée par votre serveur pour toute requête.
  • Figurent ensuite les enregistrements NS (name server) qui indique quels sont les serveurs de noms de votre domaine (maitre et esclaves)
  • MX désigne les serveurs de mail (MX= Mail EXchanger), le numéro qui figure indique l'ordre de priorité des serveurs de mail, plus le numéro est petit, plus la priorité est grande. Ainsi, si votre machine est arrêtée, les mails qui lui sont destinés sont récupérés par le mail exchanger de priorité immédiatement inférieur qui vous les retransmettra quand votre machine sera de nouveau connectée. Naturellement, les enregistrements MX ne sont utiles que si vous hébergez un serveur de mail!
  • TXT est un commentaire
• Sont indiquées ensuite les informations des machines de votre domaine. Au nom qui est est indiqué est implicitement rajouté votre-domaine suivi d'un point. Par exemple, dans mon fichier de configuration, yoda est équivalent à yoda.linux-sottises.net. (avec le point à la fin).
  • L'enregistrement A donne l'adresse de la machine
  • Hinfo est constitué de deux chaînes de caractères, la première donne le processeur, la seconde l'OS
  • TXT est un commentaire
• Il est nécessaire de systématiquement configurer localhost avec l'adresse 127.0.0.1
• Vous serez peut-être "étonnés" de voir une adresse locale 192.168.0.6 pour la machine pluto, mais cela est tout à fait correct! Cela permet non seulement de nommer et configurer proprement un réseau local, mais cela permet aussi d'adresser du courrier depuis l'extérieur à des adresses de la forme nom@pluto.linux-sottises.net avec les ordres MX indiqués. Le courrier adressé aux adresses de cette forme sont envoyés à yoda.linux-sottises.net et c'est le serveur de mail sur yoda qui est configuré pour rediriger ces courriers vers pluto en local.

Enfin pour terminer les fichiers de configuration, il reste le fichier reverse de la boucle locale zone/127.0.0 et le fichier reverse de réseau local (non obligatoire!!) zone/192.168.0

Un nouveau type d'enregistrement y apparait, C'est PTR pour pointeur. Le 1 en début de ligne dans le reverse de la boucle locale indique que l'on fait référence à 127.0.0."1", mais vous aviez saisi.

SI vous souhaitez voir ce que donne ces enregistrements "en ligne", lancez:

nslookup
server yoda.linux-sottises.net
set q=any
linux-sottises.net.

sans oublier le dernier point

Pour votre propre serveur, il ne vous reste plus qu'à lancer le daemon named depuis votre script d'initialisation (ou en suivant les "règles" de votre distribution)

Si vous voulez vérifier la configuration de votre DNS, plusieurs outils en ligne existent, ils m'ont été suggérés par Jérôme Alet.
www.dnsreport.com
www.domtools.com
www.checkdns.net

Maintenance du fichier root.hint

Il vous est possible de maintenir à jour le fichier root.hint (qui ne varie quand même pas tant que ça au cours de l'année!) par le script hintupdate que vous lancerez dans un cron tous les mois (ou toutes les semaines si vous êtes autant parano que moi!).

Lisez les commentaires au début de ce script. Vous avez besoin de:

• hosmaster dans /etc/aliases (ou modifiez le script)
• un nom dns1 et son ip dans /etc/hosts (ou modifiez le script)
• remplacer "rcnamed restart" par l'ordre de redémarrage de bind si vous n'êtes pas sous Suse avec le package Suse de bind
• sendmail (pour prévenir root de l'état de la mise à jour) (ou modifiez le script)

Naturellement, les commentaires ou suggestions sur cette page sont les bienvenus à tnka at linux-sottises.net