DNS : principe et fonctionnement    Enregistrer au format PDF

Les ordinateurs connectés à un réseau IP, par exemple Internet, possèdent tous une adresse IP. Ces adresses sont numériques afin d’être plus facilement traitées par une machine . Selon IPv4, elles prennent la forme xxx.yyy.zzz.aaa, où xxx, yyy, zzz et aaa sont quatre nombres variant entre 0 et 255 (en système décimal).


par Sphix

Il n’est évidemment pas simple pour un humain de retenir ce numéro lorsque l’on désire accéder à un ordinateur d’Internet. C’est pourquoi le Domain Name System (ou DNS, système de noms de domaine) fut inventé en 1983 par Paul Mockapetris. Il permet d’associer à une adresse IP, un nom intelligible, humainement plus simple à retenir, appelé nom de domaine. fr.nom_domaine.org, par exemple, est composé du domaine générique org, du domaine déposé mon_domaine et du nom d’hôte fr.

Quand un utilisateur souhaite accéder à un site, comme par exemple www.free.fr, son ordinateur émet une requête spéciale à un serveur DNS, demandant ’Quelle est l’adresse de www.free.fr ?’. Le serveur répond en retournant l’adresse IP du serveur, qui est dans ce cas-ci, 213.228.0.42.

Il est également possible de poser la question inverse, à savoir ’Quel est le nom de domaine de telle adresse IP ?’. On parle alors de résolution inverse.

Plusieurs noms de domaine peuvent pointer vers une même adresse IP. Mais une adresse IP ne peut pointer que sur un unique nom de domaine.

Lorsqu’un service génère un trafic important, celui-ci peut faire appel à la technique du DNS Round-Robin, qui consiste à associer plusieurs adresses IP à un nom de domaine.

Configurer un serveur indépendant

Par défaut, Bind est configuré en tant que serveur DNS "indépendant", qui n’est primaire ou secondaire pour aucun domaine. Quel est l’intérêt d’un tel serveur ? Faire office de cache DNS. En effet, le serveur DNS va retenir dans son cache les correspondances IP-DNS demandées par les clients, et ne sera pas obligé d’aller chercher à chaque fois auprès des autres serveurs DNS la réponse aux requêtes.

Par exemple, si vous trouvez que le serveur DNS de votre fournisseur d’accès est trop long à répondre, vous aurez intérêt à installer un serveur DNS sur votre ordinateur et configurer votre système pour qu’il interroge en priorité le serveur local. Pour optimizer les temps de requêtes, configurez votre serveur DNS pour qu’il demande les enregistrements qu’il n’a pas dans son cache aux serveurs DNS de votre fournisseur d’accès au lieu d’aller les demander lui-même auprès des autres serveurs DNS.

Pour cela, éditez le fichier named.conf et décommentez les lignes de la sous-section forwarders de la section options en y inscrivant les adresses IPs des serveurs DNS de votre fournisseur d’accès. Le début du fichier named.conf ressemble alors à cela :

options {
        directory "/var/cache/bind";

        forwarders {
                48.128.12.41;
                48.128.12.42;
         };

        auth-nxdomain no;
};

où 48.128.12.41 et 48.128.12.42 sont les adresses IPs des serveurs DNS de votre fournisseur d’accès.

Enfin, modifiez le fichier /etc/resolv.conf et mettez votre serveur en première position dans la liste des serveurs DNS :

search liste_de_domaines_pour_les_noms_DNS_dont_le_domaine_n'est_pas_précisé
nameserver 127.0.0.1
nameserver 48.128.12.41
nameserver 48.128.12.42

Configurer un serveur DNS primaire pour une zone

Vous avez acheté un nom de domaine et vous souhaitez héberger votre DNS primaire ? Il vous faut configurer votre Bind comme autoritaire (ou master) pour votre domaine et donner à l’organisme auquel vous avez acheté votre domaine l’adresse IP de votre serveur.

Dans named.conf

Ajoutez à la fin du fichier named.conf les lignes suivantes :

zone "mondomaine.org" {
        type master;
        file "mondomaine.org.zone";
};

mondomaine.org est le nom de domaine pour lequel votre serveur sera primaire,
mondomaine.org.zone désigne le fichier /var/cache/bind/mondomaine.org.zone où seront stockés les enregistrements de la zone.

Fichier zone

Voici un exemple de fichier zone pour bind. On y retrouve toutes les informations sur le domaine concerné (ici mailfr.com) : TTL (durée de mise en cache maximale des informations), Serveur primaire (SOA primary.heberge.info), Serveurs de nom du domaine (NS primary et secondary), Serveur de courrier du domaine (MX = Mail Exchanger), et l’adresse IP du domaine vide (IN A) et de tous les sous-domaines (* IN A) :

$TTL 1D
; BIND data file for domain mailfr.com
@       IN SOA primary.heberge.info. root.brassens.heberge.info. (
               2003082602      ; serial
               21600           ; refresh (6h)
               3600            ; retry (1h)
               604800          ; expiry (7d)
               86400 ) ; RR TTL (24h)

               IN      NS      primary.heberge.info.
               IN      NS      secondary.heberge.info.
               IN      MX 5    mx.heberge.info.
               IN      A       80.67.172.60
*               IN      A       80.67.172.60

Les principaux enregistrements définis par un DNS sont :


A
record ou address record qui fait correspondre un nom d’hôte à une adresse IPv4 de 32 bits.

AAAA record ou IPv6 address record qui fait correspondre un nom d’hôte à une adresse IPv6 de 128 bits.

CNAME record ou canonical name record qui permet de faire d’un domaine un alias vers un autre. Cet alias hérite de tous les sous-domaines de l’original.


MX
record ou mail exchange record qui définit les serveurs de mail pour ce domaine.

PTR record ou pointer record qui définit un nom domaine pour une adresse IP.

NS record ou name server record qui définit les serveurs DNS de ce domaine.

SOA record ou start of authority record qui définit le serveur DNS fournissant l’information faisant autorité sur un domaine Internet.

SRV record qui généralise la notion de MX record, standardisé dans la RFC 2782.


NAPTR
record qui donne accès à des règles de réécriture de l’information, permettant des correspondances assez lâches entre un nom de domaine et une ressource. Il est spécifié dans la RFC 3403.



Sécurité

Comme beaucoup de protocoles Internet, le DNS a été conçu sans se préoccuper de la sécurité. Il ne faut donc pas se fier au DNS pour arriver sur le bon serveur et c’est pour cela que des protocoles comme SSH font leur propre vérification (via la cryptographie). Les principales failles du DNS (décrites dans le RFC 3833) sont :

Interception du paquet (requête ou réponse) et émission d’un autre paquet à sa place,

Fabrication d’une réponse (les serveurs DNS acceptent trop facilement des réponses puisque seul un numéro de requête, très petit, sert d’authentification),

Trahison par un serveur (le secondaire hors-site d’un domaine peut par exemple passer sous le contrôle de personnes malintentionnées),

et le traditionnel déni de service.

Documentations publiées dans cette rubrique