Pour mettre en place un service DNS, le logiciel recommandé à l'AUF est BIND version 9. Le paquet Debian correspondant est {{{bind9}}}.

/!\ Cette page a été écrite à toute vitesssssse, merci aux DNSmen de la ré-écrire un peu plus proprement et plus en détail.

== Installation ==

L'installation du service se fait simplement avec :
{{{
# aptitude install bind9
}}}

Cependant il est fortement recommandé (voir obligatoire !) de [[/Sécurisation|sécuriser le service DNS]].

{i} Le nom du logiciel effectuant le service DNS (et donc du processus) est `named`, tandis que BIND (''Berkeley Internet Name Daemon'') est le nom du projet.

/!\ Veillez à bien installer `bind9` (avec un 9 à la fin). Le paquet `bind` fournit quant à lui la version 8.x de BIND, ce qui n'est pas la même chose !

== Configuration ==

 * Ajouter une zone : créer le fichier `/etc/bind/db.nom.de.la.zone` puis référencer la zone dans `/etc/bind/named.conf.local`

Quand une zone est ajoutée ou mise à jour, lancez `invoke-rc.d bind9 reload` ou encore `rndc reload`.

{i} L'outil `rndc` (''remote name daemon control'') permet d'être plus fin dans les ordres envoyés à `named`, voir `man rndc`.

== view/recursion ==

Il y a peu, en testant des outils en ligne de vérification de DNS, j'ai remarqué une erreur importante dans mon DNS, j'étais en "Open Server". Autrement dit, n'importe qui, dans le monde, peut utiliser mon DNS pour effectuer des requêtes autre que demander des informations sur mon réseau interne. Au passage, on peut utiliser cette propriété pour fournir de mauvaises informations au cache de Bind. Une documentation était fournit pour éviter d'être en "Open Server" : [[http://www.cymru.com/Documents/secure-bind-template.html]].
Le livre de Bind fournit aussi une bonne documentation : [[http://www.oreillynet.com/pub/a/oreilly/networking/news/views_0501.html]]

 * Les "view" servent a présenter différentes visions de notre réseau, suivant la "personne" qui interroge notre serveur DNS. Par exemple, vous pouvez vouloir réserver certaines machines d'une partie de votre réseau à un usage interne et donc qu'elles ne soient pas visibles de l'extérieur, ou bien vouloir que votre réseau FOAD puissent voir une machine qui ne doit pas être vu de votre réseau grand publique.
 * L'option "recursion", qui porte la valeur yes/no, autorise ou non votre serveur DNS à interroger les autres serveurs DNS. Ce qui fait qu'on est "Open Server" ou non.

De manière basique, on peut donc créer une vue "interne" pour notre réseau, notre dmz, notre vpn, etc... qui autorise les requête récursives, et une vue "externe" qui n'autorise pas ce genre de requête.

{{{
// fichier /etc/bind/named.conf.local

acl "rezointerne" {
   192.168.1.0/24; // notre réseau interne
   10.XX.0.0/24; // notre rpv
   XX.XX.XX.XX/28; // notre plage d'adresse publique
};

view "interne" {
   match-clients { rezointerne; };
   recursion yes;

   zone "refer.ga" {
        type master;
        file "/etc/bind/local/interne.refer.ga.hosts";
   };
};

view "externe" {
   match-clients { any; };
   recursion no;

   zone "refer.ga" {
        type master;
        file "/etc/bind/local/externe.refer.ga.hosts";
   }; 
};
}}}

 * Il est possible que le fichier soit le même, mais il est aussi possible d'avoir deux fichiers différents.

/!\ toutes vos zones doivent être définit dans toutes les vues (pour si vous en avez plus de 2). Donc si vous avez 2 vues, mais 15 zones, par exemple, vous pouvez intégrer vos zones dans un fichier à part utiliser un ''include'' pour que ce soit plus lisible.

== DNSSEC ==
La gestion des noms de domaines est sujette à de nombreux types d'attaques informatiques. A la base, ces attaques consiste à transmettre aux serveurs "slave" ou aux "resolvers" des informations erronées afin de détourner le trafic destiné aux sites cibles de l'attaque.

Afin d'éviter ce problème, une serie de RFC ont permis l'extension du protocole DNS, lui permettant de supporter un certain nom d'opération cryptographique dans le but de:
 * Garantir l' '''authenticité''' des parties impliqués dans des échanges de messages/transactions DNS;
 * Garantir l' '''intégrité''' des données échangées lors de ces transactions ou échanges de messages DNS;
 * Assurer la preuve de non existence lorsqu'une requête aboutie à une réponse de type NXDOMAIN pour une entité.

A l'AUF, DNSSEC pourrait nous intéresser à plus d'un titre. D'abord pour sécuriser nos DNS, mais aussi il pourrait nous servir pour ''publier'' les certificats 

== Pour aller plus loin ==

Quelques liens :
 * le site de BIND : http://www.isc.org/software/bind/ 
 * une documentation pour débuter : http://doc.ubuntu-fr.org/bind9 (j'ai lu en diagonale, ça semble être correct)
 * pour rire, les RFC qui concernent la DNS : http://www.bind9.net/rfc ... quelle horreur !

----
CatégorieEbauche [[CatégorieRecommandationsARI]]