Version brouillon
fabriquée à la va-vite… Quand le texte sera définitif, on passera à du html
propre.
Attention, version en cours de rédaction, rien n’est
définitif, et rien n’est garanti.
Utilisez donc cette page à vos risques et
périls !
Avis, corrections flammes à mailto:named@tranbert.com
I. Un serveur de nom (dns) public pour E-Smith, c'est facile... 1
1. Création de 2 “custom templates” pour les fichiers named.conf et named-ext.conf 2
2. Création des infos de configuration pour le DNS externe : named-ext.conf 3
3. Création des infos de configuration pour le DNS interne : named.conf 4
a) La solution du how-to « officiel » : 4
4. Généreration des fichiers de configuration des 2 named. 4
G. Création du fichier de zone externe appelé par 31tagada : 4
H. Edition d’initab pour démarrer les deux named : 7
1. Création d’un custom template pour /etc/inittab : 7
2. Edition du fichier “50named” pour lancer nos deux copies de named. 7
I. Création de règles ipchains pour permettre l’usage du port 53. 7
2. Création d’un fichier “45AllowDNS”. 8
3. Mise à jour du fichier /etc/masq. 8
K. Modifications des fichiers de zone. 8
L. Tester votre zone en réel 9
Ce document va (tenter de) vous montrer comment
configurer E-Smith (SME server) pour mettre en route un serveur DNS bien à
vous.
Attention, créer et gérer un serveur dns chez soi
est une bonne chose pour apprendre, mais si vous n’avez pas « la
foi », alors achetez un domaine chez http://www.gandi.net/ et gérez votre dns
personnalisé depuis leur site, c’est bien plus simple et plus
sûr !
Tout d’abord deux points de sécurité : Le
serveur de noms (Bind et son daemon Named) intégré à E-Smith existe déjà, mais
il ne répond qu’au demandes venant de l’intérieur de votre réseau local. Il est
tout à fait possible de le configurer pour qu’il réponde aussi aux demandes de
l’extérieur, mais ce serait dangereux. Nous allons donc créer de toute pièce un
deuxième serveur Dns, qui lui ne va répondre qu’aux demandes externes à votre
réseau. C’est plus sûr.
De plus, ces deux serveurs vont être
« chrootés », ce qui veut dire qu’ils ne tourneront pas dans
l’arborescence normale de votre E-Smith, mais dans une arborescence qui leur est
propre. Si une personne arrive à prendre la main sur votre système via le Dns,
elle ne verra que les fichiers de cette arborescence, et rien d’autre. En
anglais c’est la « chroot jail ».
La question qui revient
souvent ; « Dois-je demander à mon FAI de valider le dns secondaire et
le mx secondaire avant ou après avoir créé mon dns »… Hé bien si votre fai
est rapide et réactif, faites vos modifs et demandez à votre Fai ensuite de
configurer son dns. Ca se fait en 2 secondes pour un habitué comme Raphaël, s’il
a le temps J
Si votre Fai est du genre lent, demandez lui avant de commencer, quand vous aurez fini vos bidouilles, tout sera prêt…
Cette partie est reprise du document suivant :
http://www.allenscomputing.com/howto/dual_dns.shtml
attention, leurs informations de zone ne semble pas
valide !)
· mkdir /etc/e-smith/templates/etc/named-ext.conf
· mkdir /etc/e-smith/templates-custom/etc/named.conf
· mkdir /etc/e-smith/templates-custom/etc/named-ext.conf
· cp /etc/e-smith/templates/etc/named.conf/* /etc/e-smith/templates-custom/etc/named.conf
· cp /etc/e-smith/templates/etc/named.conf/* /etc/e-smith/templates-custom/etc/named-ext.conf
On a donc maintenant des fichiers “custom template” modifiables à volonté pour permettre de réaliser nos changement sur le dns local et pour créer la configuration du serveur dns “externe”.
Se
placer dans /etc/e-smith/templates-custom/etc/named-ext.conf
·
mc
/etc/e-smith/templates-custom/etc/named-ext.conf
Changer la ligne "listen on"
dans le fichier "15listenon" de la manière suivante :
· Ligne originale : listen-on \{ 127.0.0.1; { $LocalIP }; \};· A modifier en : listen-on \{ { $ExternalIP }; \};
Modifiez le fichier 30localhost :
#----------------------------------------# localhost PTR record#---------------------------------------- zone "0.0.127.in-addr.arpa" \{ type master; file "named.local.ext";\};
Cela permet la vérification du mapping inverse de 127.0.0.1, testé par http://www.nic.fr/zonecheck/ un outil indispensable pour vérifier sa zone.
Ajouter
le fichier suivant "31tagada" :
*************************************#-----------------------------------------
# Domaine tagada.com
#-----------------------------------------
zone "tagada.com" \{type master;file "tagada.host.ext";allow-transfer \{ ip.du.dns.secondaire/classe; ip.d’un.autre dns/classe; 192.134.4.0/22; 193.0.0.0/23; \};allow-query \{ any; \};\};
*************
En gros, cela dit : Pour la zone tagada.com, dont je suis le « maître » va chercher les infos dans le fichier tagada.host.ext. Puis je dis que j’accepte des transferts de zone demandés par différents serveurs secondaire ou « testeurs » de dns, et qu’ils ont le droit de demander ce qu’il veulent. Vous n’êtes pas obligés de mettre tout ça, demandez à votre fournisseur de Dns secondaire ce qu’il faut indiquer. 192.134.4.0/22 c’est pour autoriser le transfert de zone pour le test de configuration « zonecheck » de l’afnic :-) Si vous êtes chez Nerim et que votre secondaire est metroid, ça donne : ****************************************************
#-----------------------------------------
# tagada.com domain
#-----------------------------------------
zone "tagada.com" \{type master;file "tagada.host.ext";allow-transfer \{ 62.4.16.0/25; 62.4.17.0/24; 192.134.4.0/22; 193.0.0.0/23; \};allow-query \{ any; \};\};
***************************************
Facile. Si vous avez d’autres domaines à ajouter, créez autant de fichiers "31autredomaine" que nécessaire… Effacez le fichier 40localptrs
· rm 40localptrsCe sont des définitions pour les machines du réseau interne, inutile pour la partie publique de notre serveur de noms.Effacez le fichier 60domains
· rm 60domainsNous n’avons pas besoin d’une routine pour ajouter des domaines créés localement (vos Ibays en fait), nous sommes en trains de le faire manuellement pour un domaine extérieur !
Copier les fichiers de définitions de domaines externes vers le répertoire des domaines internes :
Modifier toutes les définitions de domaines :
Dans le fichier “31tagada" ( et les autres fichiers “31
autredomaine " si vous avez
configuré plusieurs domaines), changer la ligne
En gros donc, vous dites au serveur interne que le
domaine tagada a un fichier de définition qui est "
tagada.host.int".
Mon serveur E-Smith a été installé avec un domaine
en dyndns.org, car je n’avais pas avant d’IP fixe, et il ne permet donc pas le
relais des mails qui arrivent à « tagada.com »… C’est bien
dommage ! J’ai donc modifié dans le manager les « virtual
domains » et j’ai crée « tagada.com » en lui affectant une Ibay. Le mail pour
tagada.com est maintenant accepté par E-Smith. Inutile donc d’indiquer à E-Smith
de fichier de configuration pour « tagada.com », de toute manière
tagada.com sera résolu.
Si vous avez installé E-Smith d’origine avec comme
domaine « tagada.com », utilisez la solution du how-to… Vos mails
seront relayés.
Cette liste de commande va générer les fichiers de
configuration des named internes et externes.
·
/sbin/e-smith/expand-template /etc/named.conf
·
/sbin/e-smith/expand-template
/etc/named-ext.conf
·
cp
/etc/named-ext.conf /home/dns/etc
Cette dernière commande est obligatoire, car le
fichier named-ext.conf n’est pas copié dans la chroot-jail par e-smith, l’auteur
du how-to original n’a pas trouvé la solution, et je n’ai pas cherché… Honte à
moi…
C’est la partie la plus délicate, celle où les
erreurs arrivent ! Ici vous allez véritablement créer les informations qui
vont être diffusées vers les autres serveurs de noms, elle doivent être exactes,
et formatées comme il faut, sinon votre domaine ne sera pas
accessible…
Voici un exemple de définition qui est valide,
sauf pour les noms de domaine, évidemment…
$ttl
86400
@
IN
SOA
ns1.tagada.com. moi.free.fr. (
2001092201
86400
3600
604800
86400 )
@
IN
A
80.65.822.10
@
IN
NS
ns1.tagada.com.
@
IN
NS
ns2.monfai.com.
@
IN
MX
10 mail.tagada.com.
@
IN
MX
20 mx2.monfai.com.
mail
IN
A
80.65.822.10
www
IN
A
80.65.822.10
ns1
IN
A
80.65.822.10
ftp
IN
CNAME
tagada.com.
Explication ligne par
ligne :
$ttl 86400 : je veux que le “time to live”, la durée de vie
par défaut de toutes les infos soit de 86400 secondes.
@ : c’est un équivalent du domaine que je
définis, soit celui qui est indiqué dans le named.ext.conf, donc ici
tagada.com.
IN
: Cela veut dire que je
définis ces données pour la classe Internet.
SOA :
Start Of Authority : j’indique ici quel est le domaine sur lequel je suis
autorisé à fournir mes définitions, en gros donc, à partir d’où je suis le
maître du monde !
ns1. tagada.com. : Avec un “.” à la fin !!! C’est le serveur de
nom officiellement enregistré chez NSI, celui que j’ai défini comme étant le
maître du domaine tagada.com, et que je vais référencer chez NSI en modifiant
mes informations de Dns chez mon registrar quand tout sera prêt chez moi sur mon
serveur de nom perso. Clair ?
moi.free.fr. : Adresse mail du gestionnaire du domaine, en
cas de soucis. Attention le « @ » est remplacé par un
« . »
( : début des définitions de durée et des numérotations
de version
·
86400 : REFRESH, nombre de
secondes que doit attendre le DNS secondaire avant de venir voir si les
informations de zone ont été changées
·
86400 : Minimum TTL, nombre de
secondes de validité des informations de zone dans un cache. Une journée ici en
temps normal, peut être plus court si vous êtes en phase de bidouillage de vos
fichiers de zone.
) : Fin des définitions de durée et des numérotations de
version
Et voici les enregistrements des différentes
« machines » qui doivent être connues. Le « @ » est un
raccourci pour le domaine défini dans named.conf.ext, c’est à dire tagada.com.
C’est plus rapide à taper.
La ligne suivante :
@
IN
A
80.65.822.10
Veut dire : Le nom “@” soit tagada.com pour
la classe INternet est un Alias de l’ip
80.65.822.10.
@
IN
NS
ns1.tagada.com.
Le nom “@” soit tagada.com a pour Name Server
ns1.tagada.com
@
IN
NS
ns2.monfai.net.
Le nom “@” soit tagada.com a pour Name Server
secondaire ns2.monfai.net
@ IN MX 10
mail.tagada.com.
tagada.com a pour Mail eXchanger mail.tagada.com,
qui a une priorité de 10 (haute), c’est donc le MX
primaire.
@
IN
MX
20 mx2.monfai.net.
tagada.com a pour Mail eXchanger mx2.monfai.net, qui
a une priorité de 20 (moins haute), c’est donc le MX
secondaire.
mail
IN
A
80.65.822.10
Le nom “Mail” soit mail.tagada.com est un Alias de
l’ip 80.65.822.10
www
IN
A
80.65.822.10
Le nom “www” soit www.tagada.com est un Alias de
l’ip 80.65.822.10
ns1
IN
A
80.65.822.10
Le nom “ ns1” soit ns1.tagada.com est un Alias de
l’ip 80.65.822.10
ftp
IN
CNAME
tagada.com.
Ici j’indique que ftp://ftp.tagada.com/ est un Canonical NAME de
tagada.com. Je l’ai mis pour montrer un autre type d’enregistrement, notez juste
qu’un CNAME associe un nom à un autre nom et pas un nom à une
IP.
Attention : le point « . » à la fin
d’un nom est extrêmement important. Sans lui, le domaine
« tagada.com » serait ajouté à la fin de la définition, par exemple
si
j’écrivais :
ftp
IN
CNAME
tagada.com ß---- Y’a pas de
point !!!
le dns lirait :
ftp
IN
CNAME
tagada.com.tagada.com
Ce qui ne veut rien dire ! Donc n’oubliez pas
le point en fin de définition. Par contre ne le mettez pas après
« ftp » puisque vous voulez que le système ajoute tagada.com pour
fabriquer ftp://ftp.tagada.com/ Ok ???
On a ici créé un custom template, on y a copié l’intégralité du template original, on peut donc maintenant le modifier sans crainte :
Lancez
Et éditez le fichier pour changer les
lignes :
$OUT .= "nd:3457:respawn:/usr/sbin/named
-f";
$OUT .= " -u dns -g dns -t
/home/dns";
en
:
$OUT .= "ni:3457:respawn:/usr/sbin/named -f -u dns -g dns";$OUT .= " -t /home/dns /etc/named.conf\n";$OUT .= "ne:3457:respawn:/usr/sbin/named -f -u dns -g dns";$OUT .= " -t /home/dns /etc/named-ext.conf"; Ce qui veut dire en bon français : lance named et fais en sorte que si il meurt il soit aussitôt relancé (spawn) et lance le sous l’user dns, du groupe dns, et change le répertoire de base en /home/dns (Chroot-jail, c’est ici que ça se passe). Accessoirement, on indique à named de prendre une fois named.conf et l’autre named.ext.conf comme fichier de configuration. Un petit : · /sbin/e-smith/expand-template /etc/inittab
Pour finaliser le fichier de configuration inittab, c’est bon…
Contrairement au how-to, nous allons ouvrir le port
53 en UDP et TCP, pour permettre à notre DNS secondaire de faire tranquillement
ses Zone Transfert, c’est à dire de recopier intégralement les informations de
zone dans sa base. C’est nécessaire.
On crée le répetoire custom pour le template à rajouter à la créationde Masq.
Je crois que cela n’est pas du tout
nécessaire, mais c’est dans le how-to initial (sans l’étoile après masq/ ce
qui est très étonnant !)
Personnellement, je pense qu’il suffit juste d’ignorer cette copie de
tous les fichiers et de passer directement au point
suivant !
entrez le texte suivant (attention si vous
collez directement ce texte, vérifiez bien les retours à la ligne est les
espaces) :
*******************************
{
$OUT
.= <<'HERE'
/sbin/ipchains
--append input -p udp -d $OUTERNET 53 -j ACCEPT
/sbin/ipchains
--append input -p tcp -d $OUTERNET 53 -j ACCEPT
HERE
}
*******************************
Enregistrez le résultat. Le fichier doit appartenir
à root.
Ce fichier veut dire : « ajouter aux règles ipchains existantes la règle suivante : j’accepte sur le port 53 tout ce qui arrive de l’extérieur en UDP et TCP ».
Facile :
Cette commande va générer le fichier /etc/masq qui
contrôle le firewall de E-smith.
Pour mettre à jour le système bien que pas mal des
templates aient déjà été « expandés », envoyez ces deux
commandes :
Normalement tout devrait charger proprement. Vous
pouvez aussi tenter un reboot, mais si vous idolâtrez votre uptime, ce n’est pas
nécessaire…
Ce point est important, car il faut absolument faire
deux choses quand vous modifiez votre zone : augmenter le numéro de série
pour que les autres Dns sachent quelle est la dernière version valide de vos
fichiers et redémarre named pour que votre système relise ses fichiers de
configuration.
Donc, une fois que vous aurez modifié votre fichier
de zone (named-ext.conf par exemple) changez le numéro de
série :
Pour relancer named, vu qu’il a été
« spawné », il va redémarrer tout seuls sans soucis. Donc, sans
crainte, envoyez un
A la suite de ça, si vous regardez les logs, dans /var/log/messages, vous devriez voir votre serveur secondaire demander un transfert de zone :
Oct
1 19:48:33 groumph named[12034]: approved AXFR from [62.4.16.80].10512
for "tagada.com"
Oct
1 19:48:33 groumph named[12034]: zone transfer (AXFR) of "tagada.com"
(IN) to [62.4.16.80].10512
S’il ne le fait pas, méfiance, il y a un
souci : soit votre secondaire n’est pas encore validé, soit votre syntaxe
d’allow-tranfert est bugée, soit votre firewall ne laisse pas passer les
requêtes dns, à vous de choisir...
Pour vérifier que votre zone est bien configurée et
que vos informations de zones sont bien diffusées, en dehors de nslookup ou
host, les commandes linux standard, il existe un outil en ligne très
sévère : Zonecheck, fourni par
l’afnic.
Il se trouve ici : http://www.nic.fr/zonecheck/ et les
sources sont disponibles, si vous le désirez.
Comment ça marche ?
Facile, entrez votre domaine dans la première
fenêtre : tagada.com par exemple
Choisissez dans « Méthode pour obtenir les
informations » le formulaire libre. Cliquez sur
« chercher »
Ensuite, entrez dans les serveurs de noms que vous
avez déclaré dans les cases, c’est expliqué !
Et ensuite, choisissez « vérifiez et
sauvegardez les paramètres » ce qui est bien pratique. Il faut accepter le
cookies, si vous êtes paranos, choissiez juste
« vérifier ».
Ensuite, tout est expliqué, ou en tout cas s’il y a un problème, vous saurez quoi demander. Passez voir le groupe news://news.tranbert.dyndns.org/alt.e-smith.fr (user esmith pass bjmjvcg ); il y aura toujours une bonne âme pour vous répondre…
A
suivre : suivez la propagation des dns, correction et oublis, mise en html,
diffusion.