Theodys.org - DNS

Installation et configuration d'un serveur DNS (Bind9) sur Ubuntu

mimi — Mon, 14 May 2007 17:40:00 +0200

Cet article présente l'installation et la configuration d'un serveur DNS.
L'installation est faite sur une distribution Ubuntu (6.06 LTS server dans mon cas)

Installation d'un serveur DNS (Bind9) sur Ubuntu

Cet article présente l'installation et la configuration d'un serveur DNS.
L'installation est faite sur une distribution Ubuntu (6.06 LTS server dans mon cas)

Pré-requis

Savoir ce qu'est le système DNS : Définition wikipedia
Pour l'ensemble du guide, nous partirons du principe, que la configuration réseau de votre serveur est fonctionnelle.
Il est aussi nécessaire d'avoir certaines bases de l'utilisation d'un systeme Linux
Enfin, il est important que votre getionnaire de paquet soit configurer et à jour. Pour cela je vous conseille de lire l'excellent guide sur le site de ubuntu-fr.org :
http://doc.ubuntu-fr.org/gestionnaire_de_paquets

Ma configuration

Adresse IP du serveur : 192.168.1.2
Adresse IP de mon routeur (ou de la "box") : 192.168.1.1
Domaine : mondomaine.local
Les noms des ordinateurs et les ip souhaitées:

server (ubuntu dapper LTS) => 192.168.1.2
mimiz (ubuntu Feisty) => 192.168.1.5
portable (ubuntu Feisty) => 192.168.1.6
poste2 (windows XP) => 192.168.1.10

Installation

La première chose à faire est d'installer le paquet bind sur le serveur :

#sudo apt-get install bind

Configuration du serveur

Dans un premier temps, nous allons jeter un coup d'oeil au fichier de configuration général de bind :

// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the
// structure of BIND configuration files in Debian, *BEFORE* you customize
// this configuration file.
//
// If you are just adding zones, please do that in /etc/bind/named.conf.local

include "/etc/bind/named.conf.options";

// prime the server with knowledge of the root servers
zone "." {
    type hint;
    file "/etc/bind/db.root";
};

// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912

zone "localhost" {
    type master;
    file "/etc/bind/db.local";
};

zone "127.in-addr.arpa" {
    type master;
    file "/etc/bind/db.127";
};

zone "0.in-addr.arpa" {
    type master;
    file "/etc/bind/db.0";
};

zone "255.in-addr.arpa" {
    type master;
    file "/etc/bind/db.255";
};

// zone "com" { type delegation-only; };
// zone "net" { type delegation-only; };

// From the release notes:
// Because many of our users are uncomfortable receiving undelegated answers
// from root or top level domains, other than a few for whom that behaviour
// has been trusted and expected for quite some length of time, we have now
// introduced the "root-delegations-only" feature which applies delegation-only
// logic to all top level domains, and to the root domain. An exception list
// should be specified, including "MUSEUM" and "DE", and any other top level
// domains from whom undelegated responses are expected and trusted.
// root-delegation-only exclude { "DE"; "MUSEUM"; };

include "/etc/bind/named.conf.local";

Vous l'aurez certainement remarqué, plusieurs fichiers sont inclus, du coup je vous invite aussi à regarder à quoi ils ressemblent ne serait-ce que pour savoir ce qui est configuré.
La dernière ligne indique l'inclusion du fichier : /etc/bind/named.conf.local, c'est dans ce fichier que nous allons rajouter les informations de la zone (du domaine) que nous souhaitons configurer.

J'ai, dans le fichier /etc/bind/named.conf.options comme suit :

options {
    directory "/var/cache/bind";
    // If there is a firewall between you and nameservers you want
    // to talk to, you might need to uncomment the query-source
    // directive below. Previous versions of BIND always asked
    // questions using port 53, but BIND 8.1 and later use an unprivileged
    // port by default.

    //query-source address * port 53;

    // If your ISP provided one or more IP addresses for stable
    // nameservers, you probably want to use them as forwarders.
    // Uncomment the following block, and insert the addresses replacing
    // the all-0's placeholder.

    forwarders {
        192.168.1.1;
    };

auth-nxdomain no; # conform to RFC1035

};

Tout ce passe au niveau de forwarders {, en effet j'ai mis ici l'adresse IP de mon routeur, cela permet de faire en sorte que si le serveur que nous sommes en train de configurer n'arrive pas à résoudre une adresse donnée il envoie la requete à mon routeur.

Pour chaque domaine, il est nécessaire de configurer deux zones, la zone principale, et la zone de recherche inversée.
Je ne rentrerais pas dans le détails mais en gros,

la zone principale permet de faire pointer un nom de domaine pleinement qualifié (FQDN = Full Qualified Domain Name) sur une adresse IP, pour information un nom de domaine pleinement qualifié est de la forme : hote.domaine.extension.
la zone de recherche inversée, permet de faire, comme son nom l'indique, l'inverse, c'est-à-dire de faire pointer une adresse IP sur un FQDN.

Création de la zone principale

Dans le fichier /etc/bind/named.conf.local nous allons rajouter les informations suivantes :

//
// Do any local configuration here
//
zone "mondomaine.local" {
    type master;
    file "mondomaine.local.hosts";
    allow-update { none; };
};

Ces informations vont créer le domaine : mondoamaine.local, la zone est de type master (c'est-à-dire maitre), le fichier qui contiendra le détails des machines de mon domaine est /etc/bind/mondomaine.local.hosts, et je n'autorise pas de mise à jour.
Pour en savoir plus sur la configuration d'une zone, je vous invite à visiter le site officiel de bind (http://www.isc.org).
La dernière ligne n'est pas indispensable.

Création de la zone de recherche inversée

Toujours dans le fichier /etc/bind/named.conf.local nous allons rajouter les informations suivantes :

zone "1.168.192.in-addr.arpa" {
type master;
file "1.168.192.in-addr.arpa.zone";
};

Là je crois que vous allez me dire, oulala, c'est quoi ce nom ?
C'est en fait assez simple , il s'agit en fait de l'adresse de votre réseau inversé, en gros si les adresses ip de votre réseau sont de la forme, 192.168.1.X, la zone inverse sera : 1.168.192.in-addr.arpa, la fin (in-addr.arpa).
Pour en savoir plus sur l'extension .arpa : http://fr.wikipedia.org/wiki/.arpa

Configuration de la zone principale

Dans la section principale, on a défini que le fichier /etc/bind/mondomaine.local.hosts contiendrait la définition des hôtes de notre réseau.
Il faut donc créer ce fichier, et le remplir.
Mais regardons à quoi ressemble ce fichier, nous le détaillerons plus ensuite :

@    IN     SOA     server.mondomaine.local. webmaster.mondomaine.local. (
            2007051401 ; serial
            21600 ; refresh after 6 hours
            3600 ; retry after 1 hour
            604800 ; expires after 1 week
            86400 ) ; minimum TTL of 1 day
@     IN   NS     server.mondomaine.local.
server   IN     A     192.168.1.2
mimiz     IN     A     192.168.1.5
portable     IN     A     192.168.1.6
poste2     IN     A     192.168.1.10
router     IN     A     192.168.1.1

Voilà, voilà, voilà
Bon ça nous dis quoi tout ça ?
Un fichier de zone DOIT toujours commencer par la définition d'un SOA (Start Of Authority) :
Le "@" spécifie la zone définie dans le fichier configuration
Ensuite "IN" précise qu'il s'adit d'une zone Internet, il s'agit "presque" de la valeur par défaut, j'ai bien dis "presque", en effet, les cas où vous aurez a préciser un autre type de zone sont trés rares ...
Ensuite on précise le mot clé SOA suivi du FQDN du serveur qui héberge la zone (server.mondomaine.local.), puis, sur la meme ligne une adresse email de contact (webmaster.mondomaine.local.).
Dans ce dernier cas, le premier "." est considéré comme un "@" (il s'agit d'une convention), vous auriez pu mettre aussi : moi.fai.com. ...

Attention : Les "." à la fin de server.mondomaine.local. et webmaster.mondomaine.local. sont obligatoires !

Ensuite il faut définir les éléments suivant :

Le numéro de série (serial), généralement la date du jour suivi d'un incrément : YYYYMMDDxx.
Le temps de rafraichissement (refresh), ici 6 heures.
Le temps entre deux essais (retry), ici 1 heures.
Le temps d'expiration (expire) ici 1 semaine.
La valeur TTL minimum (minimum TTL), ici, 1 jour.

Toutes les valeurs de temps sont précisées en secondes ... Je vous rassure, ce n'est pas obligatoire, il est possible de préciser 1W pour une semaine, ou encore 1H pour une heure ...
Tout de suite aprés l'enregistrement SOA, il faut préciser le serveur DNS a consulter :

@ IN NS server.mondomaine.local.

En gros, là on dit : la machine server.mondomaine.local est un serveur de nom (NS = Name server) pour la zone.

Ensuite nous avons la définition des machines de notre réseau :

server IN A 192.168.1.2
mimiz IN A 192.168.1.5
portable IN A 192.168.1.6
poste2 IN A 192.168.1.10
router IN A 192.168.1.1

Chaque ligne Précise :
le nom du pc - le type de zone - le type d'enregistrement - l'adresse IP de la machine
le type d'enregistrement A (A pour Alias) permet donc de pointer, par exemple, server sur l'adresse ip 192.168.1.2).
Bon arretons nous là pour le moment, nous verrons un peu plus loin d'autres type d'enregistrement ...
Mais avant configurons la zone de recherche inversée :

Configuration de la zone de recherche inversée

Comme dans la section précédente, commençonc par regarder le fichier :

@     IN     SOA     server.mondomaine.local. webmaster.mondomaine.local. (
            2007051401 ; serial
            21600 ; refresh after 6 hours
            3600 ; retry after 1 hour
            604800 ; expires after 1 week
            86400 ) ; minimum TTL of 1 day
@     IN     NS     server.mondomaine.local
1     IN     PTR router.mondomaine.local.
2     IN     PTR server.mondomaine.local.
5     IN     PTR mimiz.mondomaine.local.
6     IN     PTR portable.mondomaine.local.
10     IN PTR poste2.mondomaine.local

Je ne vais pas, ici, ré-expliquer le début du fichier ...
Les lignes d'enregistrements de machine sont un peu différentes, en effet, vous remarquerez que toutes les lignes commencent par un nombre, en fait ce nombre est la fin de l'adresse ip de la machine ...
C'est en fait ce qu'il y a aprés : 192.168.1., mon routeur à l'adresse ip 192.168.1.1 alors j'ai mis 1 en face de son FQDN.
Le type d'enregistrement est PTR.
Bon ben voilà, normalement c'est bon ... votre serveur DNS est configuré, et bien alors on va tester.

Configuration des clients

Sous Windows

Je ne détaillerais pas ici la configuration d'un poste client sous Windows (si quelqu'un veut bien le faire ce serait sympa )

Sous Linux

Editez le fichier /etc/resolv.conf, puis reinseignez le comme suit :

domain mondomaine.local
nameserver 192.168.1.2

Test de la configuration

Les outils

Losrque vous avez installé le paquet bind sur votre distribution préférée, certains outils ont été ajoutés :

named-checkconf : Permet de tester si vos fichiers de configurations sont correctement écrits
named-checkzone : permet de tester une zone, syntraxe :
#sudo named-checkzone mondomaine.local /etc/bind/mondomaine.local.hosts
nslookup : permet d'interroger un serveur de nom.
dig : permet aussi d'interroger un serveur de nom.

Si les tests de configuration sont correctement passés , redémarrer votre serveur :

#sudo /etc/init.d/bind9 restart

Interrogation du serveur

remi@portable:~$ nslookup
> server 192.168.1.2
Default server: 192.168.1.2
Address: 192.168.1.2#53
> mimiz.mondomaine.local
Server: 192.168.1.2
Address: 192.168.1.2#53

Name: mimiz.monomaine.local
Address: 192.168.1.5

Ouéé, le serveur à bien résolu mimiz.mondomaine.local en 192.168.1.5 !!
Testons la zone de recher inverse :

remi@portable:~$ nslookup
> server 192.168.1.2
Default server: 192.168.1.2
Address: 192.168.1.2#53
> 192.168.1.6
Server: 192.168.1.2
Address: 192.168.1.2#53

6.1.168.192.in-addr.arpa name = portable.mondomaine.local.

Et bien, c'est pas ty cool tout ça ?
Tout fonctionne comme il faut !

Utilisation des CNAME

Comme je l'ai promis un peu plus haut, nous allons voir un autre type d'enregistrement utile : le type : CNAME (pour Canonical Name).
Ce type d'enregistrement permet de faire pointer un nom différent sur une machine précise et sans passer par l'adresse ip ...
Le meilleur exemple pour ce type d'enregistrement est le nom d'hôte : www
On va dire par exemple que votre serveur contient aussi un serveur web, alors dans ce cas ce serait bien d'avoir www.mondomaine.local qui pointe sur votre serveur.
Reprenons le fichier de zone principal :

@     IN     SOA     server.mondomaine.local. webmaster.mondomaine.local. (
            2007051401 ; serial
            21600 ; refresh after 6 hours
            3600 ; retry after 1 hour
            604800 ; expires after 1 week
            86400 ) ; minimum TTL of 1 day
@     IN     NS     server.mondomaine.local.
server     IN     A     192.168.1.2
mimiz     IN     A     192.168.1.5
portable IN     A     192.168.1.6
poste2     IN     A     192.168.1.10
router     IN     A     192.168.1.1
www     IN     CNAME     server

J'ai donc simplement rajouté une ligne assez parlante il me semble, faisons un ch'ti test :

ping www.mondomaine.local
PING server.mondomaine.local (192.168.1.2) 56(84) bytes of data.
64 bytes from server.theodys.net (192.168.1.2): icmp_seq=1 ttl=64 time=0.110 ms
64 bytes from server.theodys.net (192.168.1.2): icmp_seq=2 ttl=64 time=0.109 ms
64 bytes from server.theodys.net (192.168.1.2): icmp_seq=3 ttl=64 time=0.105 ms
64 bytes from server.theodys.net (192.168.1.2): icmp_seq=4 ttl=64 time=0.116 ms

--- mimiz.theodys.net ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2997ms
rtt min/avg/max/mdev = 0.105/0.110/0.116/0.004 ms

Vous remarquerez que l'adresse ip (et le nom réel) de server ont été renvoyés comme il faut. Amusez vous à faire la même chose avec www.google.com par exemple, et Ô surprise, ca pointe vers une autre machine ...

Conclusion

Voilà, c'est fini ...
A bientôt pour un autre piti tuto ...

mimiz

Mise en place d'un serveur DNS dynamique

mimi — Sun, 27 Aug 2006 17:49:00 +0200

Tutorial sur la mise en oeuvre d'un serveur DNS (BIND) Dynamique sous linux.

BIND (Berkeley Internet Name Domain) est surement un des serveurs les plus utilisés pour le bon fonctionnement d'Internet. C'est ce logiciel qui gère la plupart des noms de domaine sur Internet, il permet entre autre de gérer la correspondance entre adresses IP et nom de domaine.

Je ne reviendrais pas dans cet article sur le fonctionnement de DNS ni sur l'installation ni sur la configuration du systeme, je partirais donc du principe que vous avez déjà installé un serveur DNS, qu'au moins un nom de domaine est configuré, et que jusqu'ici tout fonctionne correctement.

Pourquoi un DNS dynamique ?

Si vous avez configuré un serveur DNS vous avez du remarqué que si l'adresse IP d'une machine change, il faudra aller modififier le fichier des enregistrements du domaine pour que la nouvelle adresse IP soit prise en compte. Souvent l'exemple donné est une machine qui reçoit une adresse IP via DHCP, et qui change à chaque redémarrage, par défaut DNS ne le sait pas, il faut donc faire la mise à jour à la main !

Vous me direz, pourquoi ne pas utilisé un service de type DynDNS ? Ben simplement parce que je souhaite utiliser mon propre nom de domaine, et que ce dernier est hébergé sur un serveur Dédié ...

Mettre en place un DNS dynamique permettra donc de s'affranchir de la mise à jour de DNS, elle se fera toute seule !
La mise à jour automatique via DHCP est possible, mais n'est pour le moment pas l'objet de ce guide. Voyons la configuration de test ainsi que les objectifs à atteindre

Configuration et Objectifs

Configuration :

Serveur DNS : NS.domaine.com
Zone : domaine.net
Logiciels : BIND ... et ... c'est tout

Objectifs :

J'ai une machine (monpc) connecté à Internet via mon FAI avec une adresse IP dynamique (a peu prés comme tout le mode quoi ...), j'aimerais mettre en place certains services sur cette machine et y acceder de n'importe où. Je pourrais utiliser un service de type DynDNS, mais j'ai envie d'utiliser mon propre nom de domaine, qui, comme je l'ai déjà dit, est hébergé sur un serveur Dédié.

L'objectif est donc d'arriver à mettre à jour un hôte de ma zone : domaine.net. De façon a pouvoir acceder à ma machine en utilisant l'URL suivante : monpc.mondomaine.net.

Je voudrais aussi que la transaction soit assez sécurisée (un peu plus qu'avec un login/password quoi !)

Je voudrais aussi que certains de mes amis puissent utiliser le système pour leurs machines

Enfin ma machine connectée à Internet tourne sous la distribution IPCOP, et donc je souhaiterais automatisée la mise a jour de ma zone à chaque changement d'IP

Etape 1 : Génération de la clé

Comme je l'ai précisé plus haut, je souhaiterais que la mise à jour de mla zone se fasse de manière sécurisée. Nous allons donc utilisée une clé de cryptage générée à l'aide de la commande dnssec-keygen fournie avec BIND, la clé générée sera au format TSIG on parle d'ailleur de clé TSIG.
Je me place donc dans le répertoire de mon choix et je génére la clé ... Comme les zones gérées par mon serveur sont stockées dans le répertoire /var/named/zones/, j'ai créé le dossier /var/named/keys/ dans lequel je sotckerais mes clés générées.
Voyons donc la génération des clés :

Création d'une clé de cryptage [root@monsrv ~]# cd /var/named/keys/ // Je me place dans le bon repertoire
[root@monsrv keys]# /usr/sbin/dnssec-keygen -a HMAC-MD5 -b 512 -n HOST macle1 // Je génére ma clé
Kmacle1.+157+30505 // La réponse : le nom de ma clé
[root@monsrv keys]# chown named.named ./Kmacle1.+157+30505.* // Je rend l'utilisateur named propriétaire de ma clé

Explications :

Vous l'aurez compris, c'est la deuxième ligne qui est la plus intéressante, en effet, c'est cette ligne qui permet de créer la clé ...
Une info, quand meme, chez moi l'utilitaire dnssec-keygen se trouve dans le répetoire /usr/sbin/, il pourra se trouver ailleurs sur votre machine en fonction de votre installation de BIND, uiliser find ou locate pour le trouver ...
Revenons sur la deuxième ligne de notre exemple, on comprendra aisément que -a HMAC-MD5 détermine le protocole de cryptage utilisé, le parametre -b 512 détermine la longueur de la clé, le parametre -n HOST détermine le type d'enregistrement, il peut avoir les valeurs : ZONE | HOST | ENTITY | USER, et enfin macle1 est le nom de ma clé.

Pour en savoir plus sur les paramètres de dnssec-keygen, utilsé l'argument -?

Si on regarde le contenu de notre répertoire /var/named/keys/ on verra 2 fichiers qui ont le même nom, et qui finissent par .private et .key soit : Kmacle1.+157+30505.private et Kmacle1.+157+30505.key

Voyons à quoi ressemble la clé générée :

Contenu du fichier .key vi Kmacle1.+157+30505.key

macle1. IN KEY 512 3 157 Zwc51Lxzt6ggjmrVRZuoBqKg/Y3S8ulAsrCNMRY+2dgQdwWwCaElBHnGYHoWdewF59w58YfEP/xUbgKDYPSUNg==
~
~
~
"./keys/Kmacle1.+157+30505.key" 1L, 115C

La clé macle1 est donc : Zwc51Lxzt6ggjmrVRZuoBqKg/Y3S8ulAsrCNMRY+2dgQdwWwCaElBHnGYHoWdewF59w58YfEP/xUbgKDYPSUNg==

Maintenant voyons comment configurer notre zone DNS

Etape 2 : Configuration de la zone

Création d'un fichier de clés

Maintenant que la clé est définie, nous allons créer un fichier qui contiendra toutes les clés définies, et ce pour faciliter l'administration de votre serveur et donc ne pas surcharger le fichier de configuratiion de BIND (/etc/named.conf chez moi ...).

On va donc créer un fichier : /var/named/theokeys.conf, bien sur le nom du fichier importe peu ...

/var/named/theokeys.conf vi /var/named/theokeys.conf

key macle1 {
algorithm HMAC-MD5;
secret "Zwc51Lxzt6ggjmrVRZuoBqKg/Y3S8ulAsrCNMRY+2dgQdwWwCaElBHnGYHoWdewF59w58YfEP/xUbgKDYPSUNg==";
};
~
~
~
"/var/named/theokeys.conf" 14L, 438C

On remarquera, que le nom de la clé "macle1" est celui chosi lors de la génération, de la même maniere, l'algorithme de cryptage HDMA-MD5, est l'algorithme choisi, et enfin la valeur de secret est la clé propement dite !

Modification du fichier de configuration

Donc on a créer un fichier de clé, maintenant il va falloir configurer named, pour qu'il le prenne en compte, et il faudra ensuite définir les "droits des clés", c'est-à-dire ce que le proprietaire de la clé à le droit de mettre à jour dans notre configuration

Dans un premier temps on va insérer le fichier de clés à la configuration de named

/etc/named.conf vi /etc/named.conf

options {
        directory "/var/named";
};
//
// a caching only nameserver config
//
controls {
        inet 127.0.0.1 allow { localhost; } keys { rndckey; };
};
zone "." IN {
        type hint;
        file "named.ca";
};

zone "localhost" IN {
        type master;
        file "localhost.zone";
        allow-update { none; };
};

zone "0.0.127.in-addr.arpa" IN {
        type master;
        file "named.local";
        allow-update { none; };
};

include "/etc/rndc.key";

/*
* Cles pour Dynamique DNS
*/
include "/var/named/theokeys.conf"; // Inclusion du fichier de clés
// Configuration des zones
zone "domaine.net" {
        type master;
        file "/var/named/domaine.net.hosts";
};

Si on redemarre named notre fichier de clés sera donc pris en compte, par contre pour le moment nous n'avons défini aucun droit pour notre clé

Dans mon exemple, je souhaiterais que l'hôte : mimi.domaine.net puisse être mis à jour à l'aide de la clé macle1, on va donc rajouter une ligne à configuration de la zone domaine.net

Modification de la zone domaine.net ---
zone "domaine.net" {
        type master;
        file "/var/named/domaine.net.hosts";
        update-policy {
                grant macle1. name mimi.domaine.net. A TXT;
        };
};
---

Dans cet exemple, j'ai donné l'autorisation à la clé macle1 de modifié l'enregistrement DNS de mimi.domaine.net, et ce uniquement pour les type d'enregistrement A et TXT
J'aurais aussi pu autoriser la clé macle1 a modifier la zone dans son intégralité en insérant (à la place de la section update-policy) la valeur suivante :

Exemple 2 : macle1 allow-update ---
zone "domaine.net" {
        type master;
        file "/var/named/domaine.net.hosts";
        allow-update {
                key macle1;
        };
};
---

Mais pour des raisons de sécurité et d'intégrité de ma zone, je préfere utilisé l'instruction update-policy.

La syntaxe des lignes de cette instruction est la suivante :

Exemple 2 : syntaxe de update-policy ...
        update-policy {
                grant <key> <type> <zone> <record-types>;
        };
...

Explications :

<key> : Doit correspondre à une clé du fichier /var/named/theokeys.conf
<type> : Correspond au type de l'autorisation, peut prendre name ou subdomain
<zone> : Indique la zone ou le sous-domaine à mettre à jour
<record-type> : Précise le type d'enregistrement qui peuvent être mis à jour

Maintenant que la mise à jour dynamique est mise en place voyons comment cela fonctionne coté client !

Etape 3 : Mise à jour des enregistrements (nsupdate)

Récupération des clés

Comme nous avons créer des clés pour autoriser les mises à jour, il faut que les clients les récupèrent pour pouvoir mettre à jour leurs enregistrements, je ne détaillerais pas ce point, car c'est assez facile, personnellement j'ai crée un fichier .tar.gz contenant les fichiers .key et .private de ma clé et que j'ai ensuite placé dans un répertoire accessible via FTP, j'ai récupéré ce fichier via FTP, puis je l'ai supprimé pour des raisons de sécurité.

Ce n'est certainement pas la meilleure solution, mais s'en ai une !

Aprés avoir décompressé le fichier dans un dossier de mon choix sur mon poste client, je me suis penché sur l'utilisation de nsupdate

Utilisation de nsupdate

L'utilitaire nsupdate est fourni avec BIND aussi bien pour Linux que pour Windows je vais donc expliquer comment mettre à jour l'enregistrement mimi.domaine.net à l'aide de cet utilitaire, pour avoir plus d'information sur nsupdate consultez l'aide en ligne ou utilisez man nsupdate

La syntaxe de nsupdate est identique sous Windows ou sous Linux, la seule différence réelle va résider dans les chemins d'accés aux fichiers de clé.

L'utilisation de nsupdate fonctionne à peu prés comme un shell (ou une invite de commande, pour les utilisateurs de Windows), voyons un exemple :

Utilisation de nsupdate nsupdate -k /chemin/de/la/clé/Kmacle1.+157+30505.key > _

Je préfére utilsé le paramètre -k , mais c'est un choisx personnel, reportez vous à la documentation de nsupdate pour en savoir plus

Une fois sur le prompt de nsupdate, vous pouvez envoyer des requetes au serveur pour qu'il fasse les mises à jour souhaitées :

Requêtes nsupdate 1 nsupdate -k /chemin/de/la/clé/Kmacle1.+157+30505.key >server NS.domaine.com // Je me place sur mon serveur DNS
>zone domaine.net // Je précise la zone
> update add mimi.domaine.net 86400 IN A www.xxx.yyy.zzz // Details plus bas
> // Appuyer encore sur [ENTREE] pour que nsupdate excute la commande

Explcations :

La ligne update add mimi.domaine.net 86400 IN A www.xxx.yyy.zzz, vous l'aurez compris est la requête à proprement parlé, en gros là je dis à named Ajoute l'hôte mimi.domaine.net pour une durée de 86400 secondes (soit 1 jour), le type d'enregistrement est A, et l'adresse IP est www.xxx.yyy.zzz.

On notera, que pour que le serveur prenne en compte les requêtes, il faut valider une ligne vide !

Vous remarquerez que c'est assez simple d'utilisation, une chose quand même, si vous aviez déjà ajouté l'hôte, il faudra le supprimer avant de le rajouter afin de le mettre à jour ! exemple :

Requêtes nsupdate 2 nsupdate -k /chemin/de/la/clé/Kmacle1.+157+30505.key > server NS.domaine.com // Je me place sur mon serveur DNS
> zone domaine.net // Je précise la zone
> update delete mimi.domaine.net A // On supprime l'enregistrement
> update add mimi.domaine.net 86400 IN A www.xxx.yyy.zzz // On ajoute l'enregistrement
> // Appuyer encore sur [ENTREE] pour que nsupdate excute la commande

Voilà maintenant vous pouvez tester la configuration, avec des utilisaires systèmes comme ping, dig ou encore nslookup, à vous de choisir !

Bon, la mise à jour de notre serveur DNS fonctionne, c'est bien, mais ce serait encore mieux si la mise à jour se faisait de façon automatique à chaque fois que l'adresse IP de ma machine change ...

Automatisation de la mise à jour

Sous Linux

J'ai crée un petit script bash permettant de mettre à jour le serveur DNS de façon automatique (à savoir sans interaction avec l'utilisateur). Vous pouvez utiliser ce script pour vos besoins ... Et si vous prenez l'envie de l'améliorer, j'espere que vous penserez à me le faire savoir ...

Voici le script :

Script : nsupdte.sh #!/bin/bash
#
# Auteur : Rémi Goyard
# version 1.0
# LICENCE : Faites en ce que vous voulez...

### Parametres à modifier
IPADDR=`cat /chemin/de/local-ipaddress`
KEY="/chemin/de/la/clé/Kmacle1.+157+30505.key"
SERVER="ns.domaine.com"
ZONE="domaine.net"
HOTE2="hote2.domaine.net"
MIMI="mimi.domaine.net"

LOGFILE="/var/log/nsupdate.log"

cat <<eof | nsupdate -k $KEY
server $SERVER
zone $ZONE
update delete $HOTE2
update delete $MIMI
update add $HOTE2 84600 IN A $IPADDR
update add $MIMI 84600 IN A $IPADDR
send
EOF
>>$LOGFILE 2>&1

Bientôt la suite ...

Sous Windows

Bientôt ...

Liens et autres documents utiles

nsupdate(8) - Linux man page
A DDNS Server Using BIND and Nsupdate
Painless DDNS part 2: configuring the server
Secure dynamic DNS howto
RFC 2136 - Dynamic Updates in the Domain Name System (DNS UPDATE)

Problemes et solutions

A venir ....