attention: la mise en place du système de résolution de nom sur architux et consorts ayant été faite avant l'écriture de cette page, je ne suis pas certain de respecter l'ordre chronologique des informations décrites ci-dessous, même si j'ai quand même essayé de faire un effort (exemple: ne pas commencer a migrer les domaines, si les serveurs ne sont pas déclarés (hosts) ou si les zones ne sont pas fonctionnelles ou si l'administrateur ne touche pas une bille...;-) ah,ah,ah
Bien entendu, si à la lecture de cette doc, votre voiture explose et/ou que votre(vos) femme(s) vous trompe(nt), l'auteur décline toute reponsabilité !
Pour nous, l'interêt était d'assurer une "bonne" continuité de service, avec en cas de crash serveur, une indisponibilité (théorique) de 10 minutes maximum, une modification DNS nous permettant de rapidement faire repointer l'enregistrement correspondant, vers une autre machine.
J'ai 2 serveurs, bobo et bibi, bobo plante souvent, le service est alors stoppé jusqu'à sa reprise...pas cool !
J'ai donc décidé de créer un enregistrement www qui est un alias, sur lequel pointerait bibi ou bobo, en fonction de leurs disponibilités
bobo.mondomaine. IN A 600 23.56.22.6 bibi.mondomaine. IN A 600 23.56.22.7 www IN CNAME 600 bobo
info: www est l'alias de l'host web du domaine et la présence d'un "." en fin de nom, indique un nom complétement qualifié.
si bobo tombe a l'eau, que reste t'il ? bibi, alors on modifie la zone, et elle devient celabobo.mondomaine. IN A 600 23.56.22.6 bibi.mondomaine. IN A 600 23.56.22.7 www IN CNAME 600 bibi
c'est maintenant "bibi.mondomaine." qui assure le rôle du www du domaine domaine.. Avec le chiffre clé 600 je défini que le temps de vie d'un enregitrement ne peut exceder les 600 secondes. Toute requète sur la zone concernée n'est donc valable que 600 secondes.
Cela génère un rafraîchissement (trop) fréquent, et nous permet des modifications "rapidement" prise en compte...(si tout marche bien :-))
Réaliser cette opération chez un hébergeur de noms (OVH,Gandi,Amen etc...), dans des délais très cours, et en paramètrant ses propres TTL est pratiquement impossible, exemple, Gandi permet de modifier le TTL de chaque RR (ressource record) mais OVH, ne le fait apparement pas. En hébergeant ses propres serveurs DNS ils est possible d'écrire des scripts de bascule ou de la faire à la main dans des délais acceptables.
Tout d'abord, ne mettre qu'un serveur DNS, c'est prendre beaucoup de risques, si celui crash, aucune résolution des noms de domaines hébergés n'est possible (sauf pour les informations mises en cache sur d'autres serveurs DNS ou resolver client, mais le cache à une durée de vie limité). Donc, comme pour d'autres choses dans la vie, mieux vaut en avoir deux...eh,eh
Pour ma recette de cuisine il faut:
Ceci est la partie Logiciel/Matériel, si vous avez un peu de sous, allez acheter le livre DNS and BIND (édition O'reilly) c'est une référence et il est très complet. ca vous evitera de lire la suite :-)
C'est apparemment la première étape, celle qui permettra d'associer un nom de machine à un adresse IP elle est obligatoire, c'est cet enregistrement qui sera plus tard déclaré au serveur racine. Donc on déclare ici au moins deux serveurs DNS (ex:ns1.architux.com et ns2.architux.com).
c'est apparemment la procédure qui permet d'enregistrer officiellement une machine en tant que serveur de noms (je pense qu'un enregistrement est créé sur les serveurs racine). J'ai moi-meme déclaré deux serveurs sur l'interface d'OVH.
Des temps d'attente (propagation ?) interviennent à chaque étape, à l'heure actuelle, même si nos deux serveurs sont déclarés, aucun domaine n'y est encore rattaché.
Il faut maintenant configurer Bind, sous Debian le fichier named.conf.local (situé dans /etc/bind), abrite la déclaration/configuration des fichiers de zones "utilisateur".
Exemple de contenu de named.conf.local, on y trouve entre autres, des directives d'autorisation de transfert de zone, le chemin menant aux fichiers de zones correspondants au domaines hébergés.
zone "verificas.com" in {
type master;
file "/var/cache/bind/db.verificas.com";
allow-transfer {
192.168.3.0/24; 192.168.0/24;
};
};
zone "architux.com" in {
type master;
file "/var/cache/bind/db.architux.com";
allow-transfer {
192.168.3.0/24; 192.168.0/24;
};
};
; zone verificas.com
;
$TTL 600
@ IN SOA ns1.architux.com. hostmaster.architux.com. (
200602083 ; Serial
600 ; Refresh
300 ; Retry
2419200 ; Expire
600) ; Negative Cache TTL
IN NS ns1.architux.com.
IN NS ns2.architux.com.
IN MX 10 mail1.architux.com.
IN MX 20 mail2.architux.com.
@ IN A 82.226.217.242
mir1 IN A 82.239.175.46
www IN CNAME verificas.com.
ftp IN CNAME verificas.com.
; zone architux.com
$TTL 600
@ IN SOA ns1.architux.com. hostmaster.architux.com. (
200602091 ; Serial
600 ; Refresh
300 ; Retry
2419200 ; Expire
600) ; Negative Cache TTL
;
@ IN NS ns1.architux.com.
@ IN NS ns2.architux.com.
IN MX 10 mail1.architux.com.
IN MX 20 mail2.architux.com.
@ IN A 82.226.217.242
ns1 IN A 82.239.175.46
ns2 IN A 82.226.217.242
mir1 IN A 82.239.175.46
www IN CNAME architux.com.
ftp IN CNAME architux.com.
claire IN CNAME architux.com.
antonio IN CNAME architux.com.
archimail IN CNAME architux.com.
mail1 IN A 82.226.217.242
mail2 IN A 82.239.175.46
On remarquera qu'ici, la zone hébergeant les enregistrements (RR: ressource record) des serveurs DNS, je suis obligé de rajouter deux enregistrements A correspondant à ns1 et ns2, chose que je ne fais pas dans les autres zones.
Pour analyser les problèmes, les programmes nslookup,dig et host sont normalement présents sur la Debian Sarge.
Pour le pilotage du daemon Named, la commande rndc permet de faire les actions ci-dessous:
reload Reload configuration file and zones.
reload zone [class [view]]
Reload a single zone.
refresh zone [class [view]]
Schedule immediate maintenance for a zone.
reconfig Reload configuration file and new zones only.
stats Write server statistics to the statistics file.
querylog Toggle query logging.
dumpdb Dump cache(s) to the dump file (named_dump.db).
stop Save pending updates to master files and stop the server.
halt Stop the server without saving pending updates.
trace Increment debugging level by one.
trace level Change the debugging level.
notrace Set debugging level to 0.
flush Flushes all of the server's caches.
flush [view] Flushes the server's cache for a view.
status Display status of the server.
*restart Restart the server.
Attention, un rndc reload, ne vide pas le cache de bind9, alors qu'un rndc restart le fait (je crois !!). L'interêt, une fois le serveur mis en exploitation, est de conserver le cache des requètes, par contre en debuggage, suite à problème ou pour analyse, le cache peut être génant, car faussant la fiabilité des résultats (a mon avis).
Il faut par contre définir la clé d'authentification de rndc: rndc-key.
key "rndc-key" {
algorithm hmac-md5;
secret "ma clef";
};
et donc, dans named.conf, ajouter une ligne include "/etc/bind/rndc.key"; (si elle n'existe pas).
Aprés le lancement du serveur bind9 (/etc/init.d/bind9 start),nous devons vérifier son fonctionnement:
udp 0 0 0.0.0.0:53 0.0.0.0:* 29968/named udp 0 0 192.168.3.3:53 0.0.0.0:* 29968/named udp 0 0 192.168.1.4:53 0.0.0.0:* 29968/named udp 0 0 192.168.2.4:53 0.0.0.0:* 29968/named udp 0 0 192.168.0.4:53 0.0.0.0:* 29968/named udp 0 0 127.0.0.1:53 0.0.0.0:* 29968/named
Nous voyons ici, le daemon named, en écoute sur toutes les interfaces, named, doit aussi être en écoute sur les sockets TCP (netstat -natp).
akira:~# rndc status number of zones: 13 debug level: 3 xfers running: 0 xfers deferred: 0 soa queries in progress: 0 query logging is ON server is up and runningc'est cool !
akira:~# rndc trace akira:~# rndc trace akira:~# rndc trace akira:~# rndc querylog
akira:~# tail -f -n 8 /var/log/daemon.log Feb 17 17:05:30 akira named[29968]: client 192.168.0.4#34775: query: mail2.architux.com IN A Feb 17 17:05:30 akira named[29968]: client 192.168.0.4#34775: query: 1.0.168.192.in-addr.arpa IN PTR Feb 17 17:05:33 akira ntpd[1238]: synchronized to LOCAL(0), stratum 13 Feb 17 17:05:37 akira named[29968]: client 192.168.0.4#34775: query: 4.3.168.192.in-addr.arpa IN PTR Feb 17 17:06:00 192.168.3.4 named[5606]: client 192.168.0.3#35087: query: 3.3.168.192.in-addr.arpa IN PTR Feb 17 17:06:00 akira named[29968]: client 192.168.0.4#34775: query: 4.3.168.192.in-addr.arpa IN PTR Feb 17 17:06:01 akira named[29968]: client 84.100.85.163#33021: query: checkip.dyndns.org IN AAAA Feb 17 17:06:01 akira named[29968]: client 84.100.85.163#33021: query: checkip.dyndns.org IN AAAAc'est a peu prés cool !
La commande rndc stats, nous génère le fichier /var/cache/bind/named.stats, contenant les stats suivantes:
+++ Statistics Dump +++ (1140214836) success 20847 referral 0 nxrrset 5391 nxdomain 32898 recursion 2220 failure 30 --- Statistics Dump --- (1140214836)
Le 1140214836, doit correspondre au temps UNIX (nombres de secondes écoulées depuis 1970... enfin quelque chose comme ça).
ca doit être cool ! (en vérité je sais pas)Maintenant, a partir de mon petit client Windows, je vais utiliser "nslookup" pour analyser mes enregistrements, vu de l'intérieur de mon réseau local.
et je tente de lister une zone( option ls -d, comme le LSD ;-) je sais c'est nul, pour le transfert de zone).
le site http://centralops.net héberge plusieurs outils (whois,nslookup évolué etc...) Nous nous en servirons pour tester les différents enregistrements créés.
(le fait que ce site tourne sur un serveur IIS+ASP, ne doit pas nous empêcher de l'utiliser, car c'est pas sa faute :-))
Nous pouvons voir sur le whois, que les serveurs d'architux sont hébergés eux-même dans la zone du même nom.
info: le site http://www.dnsreport.com/ vous permettra de tester "online" la validité de vos zones.
Ici, comme les serveurs DNS hébergent aussi, les services WEB et MAIL, configurer un des serveurs en principal, et l'autre en esclave, ne nous permettrait pas d'assurer la modification des zones si le serveur principal était indisponible.
La meilleure solution fût donc de placer les deux serveurs dans le rôle de principal, chacun des deux faisant autorité sur l'ensemble des zones hébergées.
La synchronisation des zones et de la configuration est assurée par rsync via un VPN(vpn travaillant sur des adresses IP !).
Voici les options du nslookup disponibles sous Windows.
Commandes : (les identificateurs sont en majuscules, [] signifie en option)
NOM - affiche des infos concernant le NOM d'hôte/de domaine en
utilisant le serveur par défaut
NOM1 NOM2 - comme ci-dessus, en utilisant NOM2 en tant que serveur
help ou ? - affiche des informations sur les commandes communes
set OPTION - paramètre une option
all - affiche les options, le serveur actuel et l'hôte
[no]debug - affiche des informations de débogage
[no]d2 - affiche toutes les informations de débogage
[no]defname - ajoute le nom de domaine à chaque requête
[no]recurse - donne une réponse récursive aux requêtes
[no]search - utilise la liste de recherche du domaine
[no]vc - toujours utiliser un circuit virtuel
domain=NOM - donne le nom NOM au serveur de domaine par défaut
srchlist=N1[/N2/.../N6] - donne au domaine le nom N1 et liste de recherche
N1,N2, etc.
root=NOM - donne au serveur racine le nom NOM
retry=X - effectue X tentatives
timeout=X - fixe la durée d'attente initiale à X secondes
type=X - fixe le type de requête (ex. A,ANY,CNAME,MX,NS,PTR,SRV)
querytype=X - identique à type
class=X - fixe la classe de requête (ex. IN (Internet), ANY)
[no]msxfr - utilise le transfert de zone rapide MS
ixfrver=X - version à utiliser dans les requêtes de transfert IXFR
server NOM - fixe le serveur par défaut en cours à NOM
lserver NOM - fixe le serveur par défaut à NOM, avec le serveur initial
finger [UTIL] - applique finger au NOM optionnel sur l'hôte actuel par défaut
root - fait de la racine le serveur par défaut en cours
ls [opt] DOMAINE [> FIC] - liste les adresses de DOMAINE (option : vers le
fichier FIC)
-a - liste de noms canoniques et d'alias
-d - liste de tous les enregistrements
-t TYPE - liste des enregs. du type donné (ex. A,CNAME,MX,NS,PTR etc.)
view FICHIER - trie un fichier 'ls' en sortie et l'affiche avec pg
exit - quitte le programme
info: sous Debian, nslookup est considerée comme deprecated (en cours d'abandon), il est plutôt conseillé d'utiliser les commandes host et dig, plus efficaces et complètes.
Il suffit de se rendre dans l'interface d'administration de son "registrar" et de rattacher le nom de domaine à ces serveurs, à condition d'avoir déjà parametré les serveurs et d'avoir créé la zone associée au nouveau domaine.
exemple avec l'interface de AMEN, modifiant les serveurs de nom du domaine kartooch.com:
antonin le petit nain