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
:
named_enable="YES"
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.6, « Utilisation du système rc(8) 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
.
// $FreeBSD$ // // Reportez-vous aux pages de manuel named.conf(5) et named(8), et à // la documentation se trouvant dans /usr/share/doc/bind9 pour plus de // détails. // // Si vous devez configurer un serveur primaire, assurez-vous d'avoir // compris les détails épineux du fonctionnement du DNS. Même avec de // simples erreurs, vous pouvez rompre la connexion entre les parties // affectées, ou causer un important et inutile trafic Internet. options { directory "/etc/namedb"; pid-file "/var/run/named/pid"; dump-file "/var/dump/named_dump.db"; statistics-file "/var/stats/named.stats"; // Si named est utilisé uniquement en tant que résolveur local, ceci // est un bon réglage par défaut. Pour un named qui doit être // accessible à l'ensemble du réseau, commentez cette option, précisez // l'adresse IP correcte, ou supprimez cette option. listen-on { 127.0.0.1; }; // Si l'IPv6 est activé sur le système, décommentez cette option pour // une utilisation en résolveur local. Pour donner l'accès au réseau, // précisez une adresse IPv6, ou le mot-clé "any". // listen-on-v6 { ::1; }; // En plus de la clause "forwarders", vous pouvez forcer votre serveur // de noms à ne jamais être à l'origine de // requêtes, mais plutôt faire suivre les demandes en // activant la ligne suivante: // // forward only; // Si vous avez accès à un serveur de noms au niveau de // votre fournisseur d'accès, ajoutez ici son adresse IP, et // activez la ligne ci-dessous. Cela vous permettra de // bénéficier de son cache, réduisant ainsi le // trafic Internet. /* forwarders { 127.0.0.1; }; */
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.
/* * S'il y a un coupe-feu entre vous et les serveurs de noms * avec lesquels vous voulez communiquer, vous aurez * peut-être besoin de décommenter la directive * query-source ci-dessous. Les versions * précédentes de BIND lançaient des * requêtes à partir du port 53, mais depuis la * version 8, BIND utilise * par défaut un port pseudo-aléatoire quelconque non * réservé. */ // query-source address * port 53; }; // Si vous activez un serveur de noms local, n'oubliez pas d'entrer // 127.0.0.1 dans votre fichier /etc/resolv.conf de sorte que ce // serveur soit interrogé le premier. Assurez-vous // également de l'activer dans /etc/rc.conf. zone "." { type hint; file "named.root"; }; zone "0.0.127.IN-ADDR.ARPA" { type master; file "master/localhost.rev"; }; // RFC 3152 zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA" { type master; file "master/localhost-v6.rev"; }; // NB: N'utilisez pas les adresses IP ci-dessous, elles sont factices, // et ne servent que pour des besoins de // démonstration/documentation! // // Exemple d'entrées de configuration de zone esclave. // Il peut être pratique de devenir serveur esclave pour la // zone à laquelle appartient votre domaine. Demandez à // votre administrateur réseau l'adresse IP du serveur primaire // responsable de la zone. // // N'oubliez jamais d'inclure la résolution de la zone inverse // (IN-ADDR.ARPA)! // (Ce sont les premiers octets de l'adresse IP, en ordre inverse, // auxquels ont a ajouté ".IN-ADDR.ARPA".) // // Avant de commencer à configurer une zone primaire, il faut // être sûr que vous avez parfaitement compris comment le // DNS et BIND fonctionnent. Il apparaît parfois des pièges // peu évidents à saisir. En comparaison, configurer une // zone esclave est plus simple. // // NB: N'activez pas aveuglément les exemples ci-dessous. :-) // Utilisez des noms et des adresses réelles. /* Un exemple de zone maître zone "example.net" { type master; file "master/example.net"; }; */ /* Un exemple de zone dynamique key "exampleorgkey" { algorithm hmac-md5; secret "sf87HJqjkqh8ac87a02lla=="; }; zone "example.org" { type master; allow-update { key "exampleorgkey"; }; file "dynamic/example.org"; }; */ /* Exemple de zones esclaves directes et inverses zone "example.com" { type slave; file "slave/example.com"; masters { 192.168.1.1; }; }; zone "1.168.192.in-addr.arpa" { type slave; file "slave/1.168.192.in-addr.arpa"; masters { 192.168.1.1; }; }; */
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:
zone "example.org" { type master; file "master/example.org"; };
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
.
zone "example.org" { type slave; file "slave/example.org"; };
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:
$TTL 3600 ; 1 hour example.org. IN SOA ns1.example.org. admin.example.org. ( 2006051501 ; Serial 10800 ; Refresh 3600 ; Retry 604800 ; Expire 86400 ; Minimum TTL ) ; Serveurs DNS IN NS ns1.example.org. IN NS ns2.example.org. ; Enregistrements MX IN MX 10 mx.example.org. IN MX 20 mail.example.org. IN A 192.168.1.1 ; Noms de machine localhost IN A 127.0.0.1 ns1 IN A 192.168.1.2 ns2 IN A 192.168.1.3 mx IN A 192.168.1.4 mail IN A 192.168.1.5 ; Alias www IN CNAME @
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.origine
.
Dans notre fichier de zone fictif, notre origine est
example.org.
, donc www
sera traduit en www.example.org.
Le format d'un fichier de zone est le suivant:
nom-enregistrement IN type-enregistrement valeur
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. IN SOA ns1.example.org. admin.example.org. ( 2006051501 ; Serial 10800 ; Refresh after 3 hours 3600 ; Retry after 1 hour 604800 ; Expire after 1 week 86400 ) ; Minimum TTL of 1 day
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.
IN NS ns1.example.org.
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.
localhost IN A 127.0.0.1 ns1 IN A 192.168.1.2 ns2 IN A 192.168.1.3 mx IN A 192.168.1.4 mail IN A 192.168.1.5
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
.
IN A 192.168.1.1
Cette ligne assigne l'adresse IP 192.168.1.1
à l'origine, dans
cet exemple example.org
.
www IN CNAME @
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.
IN MX 10 mail.example.org.
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.
$TTL 3600 1.168.192.in-addr.arpa. IN SOA ns1.example.org. admin.example.org. ( 2006051501 ; Serial 10800 ; Refresh 3600 ; Retry 604800 ; Expire 3600 ) ; Minimum IN NS ns1.example.org. IN NS ns2.example.org. 1 IN PTR example.org. 2 IN PTR ns1.example.org. 3 IN PTR ns2.example.org. 4 IN PTR mx.example.org. 5 IN PTR mail.example.org.
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>.