Un E-Smith installé et opérationnel... testé avec la 4.1.1, pas avec la 4.1.2 ni la SME V5
Une connexion au net qui fonctionne en IP fixe. Pour une Ip dynamique, allez chez www.dyndns.org c’est plus rapide.
Un serveur dns secondaire, qui peut être fourni par votre FAI (Monfai par exemple) ou par votre registrar (Gandi).
Un Mail eXchanger (MX) secondaire, qui va recevoir vos mails si votre station est « down »…
Un domaine dont vous êtes le propriétaire.
Savoir utiliser la ligne de commande d’E-Smith et comprendre la logique de création/modifications des templates.

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 www.gandi.net et gérez votre dns personnalisé depuis leur site, c’est bien plus simple et plus sûr !

B. Conventions :

Votre domaine sera appelé ici : tagada.com
Votre IP fixe sera : 80.65.822.10
Votre serveur dns secondaire est à l’IP : 82.65.800.10 et il a pour nom : ns2.monfai.com
Votre Fai vous offre un MX secondaire : mx2.monfai.com
Nous utiliserons MC (midnigth commander) pour la navigation et l’édition des fichiers.

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 ».

C. Les difficultés :

Il faut avant toute chose comprendre les différentes informations que vous devrez fournir dans les fichiers de configuration du dns. Pour ça lire http://www.freenix.fr/unix/linux/HOWTO/DNS-HOWTO.html
Toute modification ne sera validée que quand l’ensemble des serveurs Dns du monde auront pris en compte la modification de votre serveur, ce qui peut prendre 48 heures. Ce délai ne permet pas de voir ses erreurs en temps réel.

D. Mode opératoire :

En premier lieu, nous allons créer les templates pour notre nouveau dns en recopiant les templates originaux du premier serveur de noms (named) :
Ensuite nous allons éditer ces templates pour configurer notre dns externe.
Puis nous allons configurer les information de notre domaine et de notre zone.
Enfin, nous allons lancer notre serveur, et diffuser les informations qu’il contient dans le vaste monde…

E. Timing J

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…

F. Création des templates

Cette partie est reprise du document suivant : http://www.allenscomputing.com/howto/dual_dns.shtml attention, leurs informations de zone ne semble pas valide !)

1. Création de 2 “custom templates” pour les fichiers named.conf et named-ext.conf

· 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”.

2. Création des infos de configuration pour le DNS externe : named-ext.conf

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 40localptrs

Ce 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 60domains

Nous 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 !

3. Création des infos de configuration pour le DNS interne : named.conf

a) La solution du how-to « officiel » :

Copier les fichiers de définitions de domaines externes vers le répertoire des domaines internes :

cp /etc/e-smith/templates-custom/etc/named-ext.conf/31* /etc/e-smith/templates-custom/etc/named.conf

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

" tagada.host.ext ";
en " tagada.host.int";

En gros donc, vous dites au serveur interne que le domaine tagada a un fichier de définition qui est " tagada.host.int".

b) Ma solution :

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.

4. Généreration des fichiers de configuration des 2 named

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…

G. Création du fichier de zone externe appelé par 31tagada :

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

2001092201 : Très important, c’est le numéro de série du fichier, à incrémenter à chaque modification pour que les différents serveurs Dns qui vont recopier ce fichier sachent quelle est la version à jour. Se décompose en « 2001 » « 09 » « 22 » « 01 » soit année, mois, jour, numéro de modification du fichier dans la journée…

· 86400 : REFRESH, nombre de secondes que doit attendre le DNS secondaire avant de venir voir si les informations de zone ont été changées

3600 : RETRY, nombre de secondes d’attente pour le rafraîchissement si le « refresh » a échoué.
604800 : EXPIRE, nombre de secondes pendant lesquelles les infos du serveur secondaires sont considérées comme valides en cas de panne du serveur primaire.

· 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.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.tagada.com Ok ???

H. Edition d’initab pour démarrer les deux named :

1. Création d’un custom template pour /etc/inittab :

mkdir /etc/e-smith/templates-custom/etc/inittab
cp /etc/e-smith/templates/etc/inittab/* /etc/e-smith/templates-custom/etc/inittab

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 :

2. Edition du fichier “50named” pour lancer nos deux copies de named

Lancez

mcedit /etc/e-smith/templates-custom/etc/inittab/50named

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…

I. Création de règles ipchains pour permettre l’usage du port 53

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.

1. Création d’un custom template pour /etc/rc.d/init.d/masq attention il y a un changement dans ce chapitre !!!

mkdir /etc/e-smith/templates-custom/etc/rc.d/init.d/masq

On crée le répetoire custom pour le template à rajouter à la créationde Masq.

cp /etc/e-smith/templates/etc/rc.d/init.d/masq/ /etc/e-smith/templates-custom/etc/rc.d/init.d/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 !

2. Création d’un fichier “45AllowDNS”

mcedit /etc/e-smith/templates-custom/etc/rc.d/init.d/masq/45AllowDNS

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 ».

3. Mise à jour du fichier /etc/masq

Facile :