FreeBSD utilise, par défaut, BIND (Berkeley Internet
Name Domain), qui est l'implémentation la plus courante
du protocole DNS. Le DNS est le protocole qui effectue la
correspondance entre noms et adresses IP, et inversement. Par
exemple une requête pour www.FreeBSD.org
aura pour réponse
l'adresse IP du serveur Web du projet FreeBSD, et une
requête pour ftp.FreeBSD.org
renverra l'adresse IP de
la machine FTP correspondante. De même, l'opposé
est possible. Une requête pour une adresse IP retourne
son nom de machine. Il n'est pas nécessaire de faire
tourner un serveur DNS pour effectuer des requêtes DNS
sur un système.
FreeBSD est actuellement fourni par défaut avec le serveur DNS BIND9. Notre installation est dotée de fonctionnalités étendues au niveau de la sécurité, d'une nouvelle organisation du système de fichiers et d'une configuration en environnement chroot(8) automatisée.
Le DNS est coordonné sur l'Internet à travers un système complexe de serveurs de noms racines faisant autorité, de domaines de premier niveau (« Top Level Domain », TLD), et d'autres serveurs de noms de plus petites tailles qui hébergent, directement ou font office de “cache”, l'information pour des domaines individuels.
Actuellement, BIND est maintenu par l'Internet Software Consortium http://www.isc.org/.
Pour comprendre ce document, certains termes relatifs au DNS doivent être maîtrisés.
Terme | Definition |
---|---|
“Forward“ DNS | Correspondance noms de machine vers adresses IP. |
Origine | Fait référence au domaine couvert par un fichier de zone particulier. |
named, BIND, serveur de noms | Noms courants pour le serveur de noms BIND de FreeBSD |
Resolveur | Un processus système par l'intermédiaire duquel une machine contacte un serveur de noms pour obtenir des informations sur une zone. |
DNS inverse | C'est l'inverse du DNS “classique” (“Forward“ DNS). C'est la correspondance adresses IP vers noms de machine. |
Zone racine | Début de la hiérarchie de la zone Internet. Toutes les zones sont rattachées à la zone racine, de la même manière qu'un système de fichier est rattaché au répertoire racine. |
Zone | Un domaine individuel, un sous-domaine, ou une partie des noms administrés par un même serveur faisant autorité. |
Exemples de zones:
.
est la zone racine
org.
est un domaine de premier niveau
(TLD) sous la
zone racine
example.org.
est une
zone sous le TLD
org.
1.168.192.in-addr.arpa
est une zone faisant
référence à toutes les adresses IP
qui appartiennent l'espace d'adresse 192.168.1.*
.
Comme on peut le remarquer, la partie la plus
significative d'un nom de machine est à sa gauche. Par
exemple, example.org.
est
plus spécifique que org.
, comme
org.
est à son tour plus
spécifique que la zone racine. La constitution de
chaque partie d'un nom de machine est proche de celle d'un
système de fichiers: le répertoire /dev
se trouve sous la racine, et
ainsi de suite.
Les serveurs de noms se présentent généralement sous deux formes: un serveur de noms faisant autorité, et un serveur de noms cache.
Un serveur de noms faisant autorité est nécessaire quand:
on désire fournir des informations DNS au reste du monde, être le serveur faisant autorité lors des réponses aux requêtes.
un domaine, comme par exemple
example.org
, est
enregistré et des adresses IP doivent être
assignées à des noms de machine appartenant
à ce domaine.
un bloc d'adresses IP nécessite des entrées DNS inverses (IP vers nom de machine).
un second serveur de noms ou de secours, appelé esclave, qui répondra aux requêtes.
Un serveur de noms cache est nécessaire quand:
un serveur de noms local peut faire office de cache et répondre plus rapidement que l'interrogation d'un serveur de noms extérieur.
Quand on émet des requêtes pour www.FreeBSD.org
, le résolveur
interroge généralement le serveur de noms du
fournisseur d'accès, et récupère la
réponse. Avec un serveur DNS cache local, la
requête doit être effectuée qu'une seule
fois vers le monde extérieur par le serveur DNS cache.
Chaque interrogation suivante n'aura pas à être
transmise en dehors du réseau local, puisque
l'information est désormais disponible localement dans
le cache.
Sous FreeBSD le “daemon” BIND est appelé named pour des raisons évidentes.
Fichier | Description |
---|---|
named(8) | le “daemon” BIND |
rndc(8) | le programme de contrôle du serveur de noms |
/etc/namedb | répertoire où se trouvent les informations sur les zones de BIND |
/etc/namedb/named.conf | le fichier de configuration du “daemon” |
En fonction de la manière dont est
configurée sur le serveur une zone donnée, les
fichiers relatifs à cette zone pourront être
trouvés dans les sous-répertoires master
, slave
, ou dynamic
du répertoire
/etc/namedb
. Ces
fichiers contiennent les informations DNS
qui seront données par le serveur de noms en
réponse aux requêtes.
Puisque BIND est installé par défaut, sa configuration est relativement simple.
La configuration par défaut de named est un serveur de noms résolveur basique, tournant dans un environnement chroot(8). Pour lancer le serveur avec cette configuration, utilisez la commande suivante:
#
/etc/rc.d/named forcestart
Pour s'assurer que le “daemon”
named est lancé à chaque
démarrage, ajoutez la ligne suivante dans
/etc/rc.conf
:
Il existe, bien évidemment, de nombreuses options de
configuration pour /etc/namedb/named.conf
qui dépassent le cadre de ce document. Si vous êtes intéressé
par les options de démarrage de
named sous FreeBSD, jetez un oeil aux
paramètres
named_
dans
*
/etc/defaults/rc.conf
et consultez la
page de manuel rc.conf(5). La section Section 11.7, « Utilisation du système rc sous FreeBSD » constitue également une bonne
lecture.
Les fichiers de configuration pour
named se trouvent dans le
répertoire /etc/namedb
et devront être
adaptés avant toute utilisation, à moins que
l'on ait besoin que d'un simple résolveur. C'est dans
ce répertoire où la majeure partie de la
configuration se fera.
Pour configurer une zone maître, il faut se rendre
dans le répertoire /etc/namedb/
et exécuter
la commande suivante:
#
sh make-localhost
Si tout s'est bien passé, un nouveau fichier
devrait apparaître dans le sous-répertoire
master
. Les noms de
fichiers devraient être
localhost.rev
pour le nom de domaine
local et localhost-v6.rev
pour les
configurations IPv6. Tout comme le
fichier de configuration par défaut, les informations
nécessaires seront présentes dans le fichier
named.conf
.
Comme les commentaires le précisent, pour
bénéficier d'un cache en amont de votre
connexion, le paramètre forwarders
peut être activé. Dans des circonstances
normales, un serveur de noms interrogera de façon
récursive certains serveurs de noms jusqu'à
obtenir la réponse à sa requête. Avec
ce paramètre activé, votre serveur interrogera
le serveur de noms en amont (ou le serveur de noms fourni)
en premier, en bénéficiant alors de son cache.
Si le serveur en question gère beaucoup de trafic, et
est un serveur rapide, activer cette option peut en valoir
la peine.
127.0.0.1
ne fonctionnera pas ici. Remplacez
cette adresse IP par un serveur de noms en amont de votre
connexion.
Dans named.conf
, ce sont des
exemples d'entrées d'un serveur esclave.
Pour chaque nouvelle zone gérée, une
nouvelle entrée de zone doit être
ajoutée au fichier
named.conf
.
Par exemple, l'entrée de zone la plus simple
possible pour example.org
serait:
Ce sera un serveur maître pour la zone, comme
indiqué par l'option type
,
concervant ses informations de zone dans le fichier
/etc/namedb/master/example.org
comme
précisé par l'option
file
.
Dans le cas d'un esclave, les informations concernant la zone seront transférées à partir du serveur maître pour la zone en question, et sauvegardées dans le fichier indiqué. Si ou lorsque le serveur maître tombe ou est inaccessible, le serveur esclave disposera des informations de la zone transférée et sera capable de les diffuser.
Un exemple de fichier de zone maître pour example.org
(défini dans
/etc/namedb/master/example.org
) suit:
Notez que chaque nom de machine se terminant par un
“.” est un nom de machine complet, alors que
tout ce qui se termine pas par un “.” est
référencé par rapport à une
origine. Par exemple, www
sera traduit
en
www.
.
Dans notre fichier de zone fictif, notre origine est
origine
example.org.
, donc www
sera traduit en www.example.org.
Le format d'un fichier de zone est le suivant:
Les enregistrements DNS les plus couramment utilisés:
début des données de zone
serveur de noms faisant autorité
adresse d'une machine
alias d'un nom de machine
serveur de messagerie recevant le courrier pour le domaine
un pointeur sur un nom de domaine (utilisé dans le DNS inverse)
example.org.
le nom de domaine, également l'origine pour ce fichier de zone.
ns1.example.org.
le serveur de noms primaire/faisant autorité pour cette zone.
admin.example.org.
la personne responsable pour cette zone avec
le caractère “@” remplacé.
(<admin@example.org>
devient
admin.example.org
)
2006051501
le numéro de série de ce fichier.
Celui-ci doit être incrémenté
à chaque modification du fichier de zone. De nos
jours, de nombreux administrateurs
préfèrent un format du type
aaaammjjrr
pour le numéro de
série. 2006051501
signifierait dernière modification le 15/05/2006,
le 01
indiquant que c'est la seconde
fois que ce fichier a été
révisé ce jour. Le numéro de
série est important puisqu'il indique aux
serveurs de noms esclaves pour la zone une modification
de celle-ci.
C'est une entrée de type NS. Tous les serveurs de noms qui doivent faire autorité pour la zone devront inclure une de ces entrées.
Un enregistrement de type A indique des noms de machine.
Comme présenté ci-dessus ns1.example.org
sera résolu en
192.168.1.2
.
Cette ligne assigne l'adresse IP 192.168.1.1
à l'origine, dans
cet exemple example.org
.
L'enregistrement de type CNAME est
généralement utilisé pour créer
des alias à une machine. Dans l'exemple,
www
est un alias de la machine
connue sous le nom localhost.example.org
(127.0.0.1
). Les enregistrements CNAME
peuvent être utilisés pour fournir des alias
à des noms de machines, ou permettre la rotation
(“round robin”) d'un nom de machine entre
plusieurs machines.
L'enregistrement MX indique quels serveurs de messagerie
sont responsables de la gestion du courrier entrant pour la
zone. mail.example.org
est le
nom de machine du serveur de messagerie, et 10 étant
la priorité du serveur de messagerie.
On peut avoir plusieurs serveurs de messagerie, avec des
priorités de 10, 20, etc. Un serveur de messagerie
tentant de transmettre du courrier au domaine example.org
essaiera en premier
le MX avec la plus haute priorité (l'enregistrement
avec le numéro de priorité le plus bas), puis
celui venant
en second, etc, jusqu'à ce que le courrier puisse
être correctement délivré.
Pour les fichiers de zone in-addr.arpa (DNS inverse), le même format est utilisé, à l'exception du fait que des entrées PTR seront utilisées en place de A ou CNAME.
Ce fichier donne la correspondance entre adresses IP et noms de machines de notre domaine fictif.
Un serveur de noms cache est un serveur de noms qui ne fait autorité pour aucune zone. Il émet simplement des requêtes, et se souvient du résultat pour une utilisation ultérieure. Pour mettre en place un tel serveur, configurez le serveur de noms comme à l'accoutumé, en prenant bien soin de n'inclure aucune zone.
Bien que BIND soit l'implémentation la plus courante du DNS, le problème de la sécurité subsiste toujours. De possibles problèmes de sécurité exploitables sont parfois découvert.
Bien que FreeBSD enferme automatiquement named dans un environnement chroot(8), il existe plusieurs autres mécanismes de sécurité qui pourraient aider à se prémunir contre de possibles attaques DNS.
C'est une bonne idée de lire les avis de sécurité du CERT et de s'inscrire à la liste de diffusion des avis de sécurité pour FreeBSD pour se maintenir au courant des problèmes de sécurité actuels de l'Internet et de FreeBSD.
Si un problème surgit, conserver les sources à jour et disposer d'une version compilée de named récente ne seront pas de trop.
Les pages de manuel de BIND/named: rndc(8) named(8) named.conf(5).
Ce document, ainsi que d'autres peut être téléchargé sur ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/
Pour toutes questions à propos de FreeBSD, lisez la
documentation avant de contacter
<questions@FreeBSD.org>.
Pour les questions sur cette documentation, contactez
<doc@FreeBSD.org>.