Comment héberger ses propres serveurs DNS sur la zone Internet

ou la recette du pingouin à la sauce argenteuillaise

si tu n'aimes pas Bind, le DNS, Linux ou cette doc, n'hésite pas...clique ICI.
attention: cette documentation (...), a valeur d'information et non de référence (loin de là), car outre une orthographe et une rédaction déficiente, pleins d'informations importantes, voir vitales ! ;-) n'y figurent pas, par manque de temps, de volonté et de connaissances. Cette doc ne couvre pas l'installation du système Bind ni les opérations de base. Une personne réellement interessée par le sujet, devrait plutôt faire l'acquisition du livre DNS and BIND (O'reilly), celui-ci étant LA référence.

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 quelles raisons hébergerai t'on des serveurs DNS à la maison ou ailleurs ?

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.



schema dns

exemple pour faire simple:

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 cela
bobo.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.


Il a donc fallu héberger ses propres serveurs et propres domaines et diminuer les TTL (durée de vie) des enregistrements envoyés aux correspondant (serveurs et clients).

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

  1. 1er problème
  2. 2ème problème
  3. 3ème problème...le bateau coule.

Pour ma recette de cuisine il faut:

  1. Deux machines ayant deux adresse IP différentes.
  2. Une installation de debian correcte sur chacune d'elles.
  3. Une installation de Bind correcte sur chacune d'elles.
  4. Un nom de domaine déjà déclaré.
  5. Un VPN en place entre les deux machines.
  6. Un programme de synchronisation sur chacune d'elles.
  7. Ouvrir et rediriger le port 53 en TCP/UDP sur le routeur.
Personnellement voici nos choix de départ (légèrement imposés parfois, comme la ligne Free). Les processeurs Athlon ne sont ici justifiés que par le fait que d'autres services tournent sur ces serveurs, car Bind n'a pas réellement besoin d'autant de ressources vu la fréquentation des sites hébergés...

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 :-)

Création des hosts

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

dns ovh

déclaration des hosts

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.

hosts 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".


Les fichiers de zone sont placés dans /var/cache/bind, le fichier named.conf.local y fait référence,

named.conf.local

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;
        };
};

Voici la zone verificas.com

fichier /var/cache/bind/db.verificas.com
; 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.

Voici la zone architux.coom

fichier /var/cache/bind/db.architux.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.

info

Pour mémoire voici quelques enregistrements (la classe habituel est IN (internet)).

ANALYSE ET MISE EN ROUTE

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:

résultat d'un netstat -naup

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

Visualisons son status:

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 running
c'est cool !

Activons l'inscription des requètes et définissons son niveau de "verbosité":

akira:~# rndc trace
akira:~# rndc trace
akira:~# rndc trace
akira:~# rndc querylog

Examinons un peu les logs du serveur et les requètes DNS:

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 AAAA
c'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)

Analyse à partir de Windows XP (réseau local)

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.

nslookup

et je tente de lister une zone( option ls -d, comme le LSD ;-) je sais c'est nul, pour le transfert de zone).

transfert de zone

Analyse à partir d'internet

Maintenant tentons d'analyser les zones vu de l'exterieur.

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 :-))

regardons tout d'abord l'enregistrement A de architux.com

enregistrement A

regardons ensuite l'enregistrement NS de architux.com

enregistrement NS

ensuite l'enregistrement MX de architux.com

enregistrement MX

enfin l'enregistrement SOA de architux.com

enregistrement SOA

faisons maintenant un whois d'architux.com

oui, je sais c'est con de barrer les enregistrements, car ils sont publiques, mais bon... whois

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.

En cas de crash, que se passe t'il ?

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 !).

conseil n°1 : respect d'une chronologie de migration

Mettre en services les zones sur ces serveurs, et les tester en local et a partir d'internet, avant de migrer les noms de domaines correspondants, cela ferait mauvais genre et les domaines concernés ne seront plus joignables...

conseil n°2 : organiser avant qu'il ne soit trop tard

Bien réflechir à l'organisation des zones, des noms et aux choix des alias, cela permettra une évolution (future:-)) en douceur.

conseil n°3 : analyser le fonctionnement du serveur sous toutes ses coutures

S'entraîner à utiliser des outils comme nslookup, host et dig, en cas de pépin, ils seront vos outils d'analyse.

conseil n°4 : attention aux commentaires

Si, dans les fichiers contenus dans /etc/bind les commentaires sont des "// ", dans les fichiers de zones, les commentaires sont plutôts des ";".

conseil n°5 : bind est un serveur ayant un accès publique et une configuration complexe

Attention à la directive query-source address * port 53;, qui permet à n'importe quel hosts sur Internet, d'interroger (utiliser) les serveurs DNS. Bind ayant en terme de sécurité, un passé plutôt tumultueux, il est trés conseillé de le faire tourner en mode non privilégié(pas en root quoi...) et/ou de le chrooter et/ou le vserveriser si possible (pach kernel context). Il est aussi conseillé de bien appliquer ces mises à jours et de positionner certaines options restrictives.

conseil n°6 : analyse sans interférence

Pour ne pas fausser les résultats lors d'une analyse, bien penser à vider le cache des résolver présents sur les postes d'analyse, exemple sous windows: C:\ ipconfig /flushdns et sur les serveurs intermédaires: rndc flush.

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.

comment rattacher un domaine quelconque à mes serveurs

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: dns amen

antonin le petit nain