Serveur DNSChaque utilisateur est connecté par une adresse IP, et lorsque l'on se connecte à un site, on envoie des mails on sollicite en fait une IP. Pourquoi les utilisateurs ne voient pas les IP ? Car pour accéder à Internet, un PC a besoin de l'IP d'un serveur DNS. Ce serveur DNS va faire pour lui les résolutions DNS, c'est-à-dire convertir les noms en IP (et les IP en nom si necessaire). Par exemple, lorsque vous ouvrez un navigateur et pointez sur http://www.google.fr, votre PC envoie une requête à votre serveur DNS qui lui dit www.google.com = 216.239.37.99 et votre navigateur sollicite en réalité http://216.239.37.99
Lorsque vous vous abonnez à un FAI, celui-ci vous fournit les IP des serveurs DNS de votre FAI. Par exemple pour wanadoo, il s'agit de 193.252.19.3 et 193.252.19.4 ou pour nerim 62.4.16.70 et 62.4.17.69
Si vous avez un réseau informatique, il est intéressant d'installer son propre serveur DNS. Celui-ci gèrera non seulement les résolutions DNS du web mais aussi les resolutions de votre réseau local, c'est-à-dire convertir les noms de vos machines et leur IP (locales si vous n'avez pas acheté d'IP fixes). Celui-ci agira donc comme serveur DNS de cache. Les machines du réseau n'iront donc plus chercher les services DNS chez votre FAI mais ils iront sur votre serveur.
On peut aussi configurer le serveur DNS en tant que que serveur DNS primaire pour gérer un (ou plusieurs) noms de domaines.
Les adresses des serveurs DNS sont stockées dans le fichier /etc/resolv.conf qui contient une ou plusieurs adresses IP (il peut être utile d'avoir un serveur DNS secondaire prêt à pallier le premier en cas de pépin).
Voici le serveur DNS que nous allons installer : Bind
Sous Debian, faire simplement apt-get install bind9
Les fichiers de configuration sont dans le répertoire /etc/bind9/
Il existe également d'autres serveurs dns tels que djbdns.
Les tests se font à l'aide des commandes nslookup, host et dig (du paquet dnsutils).
Principe de fonctionnement détaillé du service DNS
Le service DNS signifiant Domain Name Services est né de la volonté de faciliter et de standardiser le processus d’identification des ressources connectées aux réseaux informatiques tels que l’Internet. Les machines ne sachant communiquer qu’à travers l’échange d’adresses IP difficiles à mémoriser pour l’homme, le DNS agit comme un annuaire téléphonique en fournissant la correspondance entre le nom de la machine et son adresse IP. Ainsi, lorsque l’on veut se connecter à un ordinateur dont on connaît le nom d’hôte, on interroge un serveur DNS qui nous renvoie l’adresse IP correspondant à ce nom.
Le DNS est un modèle réparti hiérarchisé, sa mise en œuvre requiert plusieurs serveurs qui prennent en charge individuellement la traduction de parties complémentaires de l’espace des noms afin de rendre plus souple le traitement des sollicitations. Ces parties appelées zones sont en fait des domaines de noms dont l’administration est définie et attribuée à un ou plusieurs serveurs.
Le domaine source d’où découlent les domaines de noms est appelé domaine Racine. Le domaine Racine est géré par les 13 serveurs DNS nommés « <x>.root-servers.net », où <x> est une lettre comprise entre ‘a’ à ‘m’. Ces serveurs racines sont gérés par des organisations différentes nommées par l’ICANN (VeriSign, USC-ISI, Cogent, UMD, NASA-ARC, ISC, DOD-NIC, ARL, Autonomica, RIPE, ICANN et WIDE). Afin d’assurer le bon maintien du service, ces serveurs sont en réalité redondés, soit localement, soit de manière répartie. Dans ce dernier cas, la technique de routage Anycast est utilisée afin d’associer l’adresse IP d’un serveur racine à plusieurs machines éloignées géographiquement permettant de répartir la charge des requêtes en toute transparence. Par exemple, le serveur racine « c.root-servers.org » est géré par la société Cogent et est en réalité composé de 6 serveurs répartis sur la planète. Pour plus d’information sur les serveurs roots vous pouvez consulter le site http://root-servers.org/
Les domaines adjacents au domaine racine sont les domaines dits de premier niveau ou TLD (Top Level Domain). Ils définissent la nature des organisations et leur provenance géographique. Le TLD ‘com’, le plus répandu, est géré par la société Vérisign sur 13 serveurs DNS. L’AFNIC gère actuellement 3 TLD : ‘fr’, ‘re’ et ‘tf’. La liste des 295 TLD existants est connue de tous les serveurs racines.
Enfin, les domaines de second niveau (SLD) décrivent plus précisément leur nom ou leur titre. Au niveau des domaines de second niveau, des milliers d’autres serveurs sont sollicités pour répondre aux besoins de traduction en adresse IP.
Le niveau terminal (le plus éloigné de la racine) désigne le nom d’hôte de la machine. Ainsi, une machine sur Internet est facilement repérable grâce à son nom d’hôte et à la chaîne d’appartenance à laquelle elle est reliée. La concaténation de la racine, du TLD, du SLD, des sous-domaines et du nom d’hôte séparés par un point est appelée nom FQDN (Fully Qualified Domain Name). La taille limite d’un FQDN est de 255 caractères. Par exemple : la machine qui sert de serveur mail dans l’entreprise Oktey s’appelle mail au sein d’Oktey et « mail.oktey.fr. » sur Internet.
L’ICANN justifie la limitation du nombre des serveurs racines à 13 par un argument technique : utiliser plus de 13 serveurs racines entraînerait des réponses à certaines requêtes DNS de plus de 512 octets. Or le protocole applicatif DNS fonctionne au-dessus du protocole de transport UDP limité à 512 octets de données. La généralisation de l’utilisation de TCP au lieu d’UDP, utilisé pour la synchronisation entre serveurs DNS, entrainerait une surcharge des serveurs DNS.
Pour bien comprendre le mécanisme présenté, la figure suivante décrit le principe d’une requête DNS. Dans l’exemple, l’utilisateur symbolisé en haut à gauche, souhaite accéder au serveur web présent sur la machine : « mail.oktey.fr ». Nous n’analyserons que le trafic DNS dans cet exemple et considérons que le serveur DNS local, n’a pas l’information requise en cache (en mémoire), sans quoi ce dernier répond directement à la demande.
Les commandes utilisées pour requêter le service DNS sont ‘nslookup’ sous Windows et ‘dig’ ou ‘host’ sous Linux. A défaut de connaitre l’IP de la machine contactée via le fichier de nom « /etc/hosts », le resolver DNS utilise le ou les serveurs DNS mentionnés dans « /etc/resolv.conf » (ou la configuration réseau sous Windows) pour effectuer ses requêtes. Pour chacune des étapes, nous allons détailler les commandes sous Linux de la forme : #commande et l’équivalent sous Windows avec le formalisme : >commande. Les réponses seront produites pour les commandes sous Windows, pour éviter d’alourdir l’article inutilement.
1) Le poste de l’utilisateur est configuré pour utiliser le resolver qui orientera sa requête vers le « Serveur DNS local », correspondant généralement à l’IP du serveur DNS de l’entreprise.
# dig mail.oktey.com
> nslookup
> mail.oktey.com
Si le serveur DNS local, possède la réponse en cache, il répondra immédiatement le résultat, sinon il se chargera de poursuivre en interrogeant successivement tous les serveurs DNS, les phases décrites ci-dessous : (2) Racine, (3) DNS de FR, puis (4) DNS de oktey.fr.
2) Le serveur DNS local n’a pas la connaissance sur l’IP affecté au serveur « mail.oktey.fr ». Il doit donc retrouver l’information auprès des serveurs de « oktey.fr. ». Pour cela, il va d’abord contacter les serveurs racine pour savoir qui gère « fr ». La liste des serveurs racine est connue de tous les serveurs DNS, c’est la seule information configurée en dur sur les serveurs DNS.
Pour avoir la liste des serveurs racines :
# dig . NS
> nslookup
> set q=NS
> .
(root) nameserver = g.root-servers.net
(root) nameserver = l.root-servers.net
(root) nameserver = b.root-servers.net
(root) nameserver = c.root-servers.net
(root) nameserver = j.root-servers.net
(root) nameserver = h.root-servers.net
(root) nameserver = a.root-servers.net
(root) nameserver = f.root-servers.net
(root) nameserver = d.root-servers.net
(root) nameserver = e.root-servers.net
(root) nameserver = m.root-servers.net
(root) nameserver = k.root-servers.net
(root) nameserver = i.root-servers.net
a.root-servers.net internet address = 198.41.0.4
a.root-servers.net AAAA IPv6 address = 2001:503:ba3e::2:30
b.root-servers.net internet address = 192.228.79.201
c.root-servers.net internet address = 192.33.4.12
d.root-servers.net internet address = 128.8.10.90
e.root-servers.net internet address = 192.203.230.10
f.root-servers.net internet address = 192.5.5.241
f.root-servers.net AAAA IPv6 address = 2001:500:2f::f
g.root-servers.net internet address = 192.112.36.4
h.root-servers.net internet address = 128.63.2.53
h.root-servers.net AAAA IPv6 address = 2001:500:1::803f:235
i.root-servers.net internet address = 192.36.148.17
i.root-servers.net AAAA IPv6 address = 2001:7fe::53
j.root-servers.net internet address = 192.58.128.30
Pour information, on voit apparaitre dans la réponse que 4 serveurs root sur 13 possèdent un adressage IPv6. Pour la prochaine requête un serveur root sera utilisé au hasard parmi les 13 disponibles, dans notre exemple nous utiliserons c.root-servers.net [192.33.4.12].
Requête auprès d’un serveur racine pour savoir qui gère ‘fr’ :
# dig @192.33.4.12 fr NS
> nslookup
> set q=NS
> server 192.33.4.12
> fr
fr nameserver = d.ext.nic.fr
fr nameserver = f.ext.nic.fr
fr nameserver = e.ext.nic.fr
fr nameserver = d.nic.fr
fr nameserver = a.nic.fr
fr nameserver = g.ext.nic.fr
fr nameserver = c.nic.fr
a.nic.fr internet address = 192.93.0.129
a.nic.fr AAAA IPv6 address = 2001:660:3005:3::1:1
c.nic.fr internet address = 192.134.0.129
c.nic.fr AAAA IPv6 address = 2001:660:3006:4::1:1
d.ext.nic.fr internet address = 192.5.4.2
d.ext.nic.fr AAAA IPv6 address = 2001:500:2e::2
d.nic.fr internet address = 194.0.9.1
d.nic.fr AAAA IPv6 address = 2001:678:c:1::1
e.ext.nic.fr internet address = 193.176.144.6
e.ext.nic.fr AAAA IPv6 address = 2a00:d78:0:102:193:176:144:6
f.ext.nic.fr internet address = 194.146.106.46
f.ext.nic.fr AAAA IPv6 address = 2001:67c:1010:11::53
g.ext.nic.fr internet address = 204.61.216.39
g.ext.nic.fr AAAA IPv6 address = 2001:500:14:6039:ad::1
L’AFNIC utilise 7 serveurs DNS, 3 sont physiquement sur les réseaux de l’AFNIC en France, et 4 (les sous-domaine en ‘ext’) se trouvent à l’extérieur du réseau de l’AFNIC.
3) Une requête est ensuite envoyée auprès des serveurs DNS de l’AFNIC pour savoir quels sont les DNS de la zone : ‘oktey.fr’. Dans l’exemple, nous utiliserons au hasard le serveur d.nic.fr [194.0.9.1].
# dig @194.0.9.1 oktey.fr NS
> nslookup
> set q=ns
> server 194.0.9.1
> oktey.fr
oktey.fr nameserver = dns.oktey.net
oktey.fr nameserver = ns.oktey.net
4) Pour finir, la requête DNS finale est effectuée directement auprès d’un des serveurs DNS gérant le domaine ‘oktey.fr’, les DNS « faisant autorité ». Le type d’enregistrement qui nous intéresse n’est plus NS mais A (ou CNAME). L’adresse IP de : ‘dns.oktey.net’ est 213.251.128.136, d’où la requête ci-dessous.
# dig @213.251.128.136 mail.oktey.fr A
> nslookup
> set q=A
> server 213.251.128.136
> mail.oktey.fr
Nom : mail.oktey.fr
Address: 87.248.120.148
Pour effectuer cette dernière requête, il a été nécessaire de retrouver l’IP du serveur ‘dns.oktey.net’, si l’information n’était pas dans le cache cela a nécessité de contacter les DNS, racine pour savoir qui gère .net, puis oktey.net, puis dns.oktey.net soit 3 requêtes supplémentaires.
A chaque étape, un des serveurs DNS retourné était pris au hasard afin d’effectuer la requête suivante. Il est donc vital que tous les serveurs DNS renvoient systématiquement la même réponse à une requête identique. Les serveurs DNS d’une même zone doivent donc impérativement être synchronisés entre eux.
Le découpage en étapes que nous venons de décomposer peut être affiché directement via la commande dig suivante : #dig +trace +all mail.oktey.fr
Nous vous avons présenté le fonctionnement du service DNS dans cet article, car la messagerie (tout comme le web) utilise comme fondation le service DNS. Nous remarquons que très souvent les problèmes de messagerie électronique proviennent en réalité de soucis DNS. Une bonne compréhension du fonctionnement des DNS permet bien souvent d’appréhender un grand nombre de soucis de messagerie électronique.
Serveurs DNS racine[modifier]
Les serveurs racine sont gérés par douze organisations différentes : deux sont européennes, une japonaise et les neuf autres sont américaines. Sept de ces serveurs sont en réalité distribués dans le monde grâce à la technique anycast et neuf disposent d'une adresse IPv64. Grâce à anycast, plus de 200 serveurs répartis dans 50 pays du monde assurent ce service5. Il existe 13 autorités de nom appelées de a à m.root-servers.net6. Le serveur k reçoit par exemple de l'ordre de 20 000 requêtes par seconde7.
Le DNS ne fournit pas de mécanisme pour découvrir la liste des serveurs racine, chacun des serveurs doit donc connaître cette liste au démarrage grâce à un encodage explicite. Cette liste est ensuite mise à jour en consultant l'un des serveurs indiqués. La mise à jour de cette liste est peu fréquente de façon à ce que les serveurs anciens continuent à fonctionner.
Fully Qualified Domain Name[modifier]
On entend par Fully qualified domain name (FQDN), ou Nom de domaine pleinement qualifié un nom de domaine écrit de façon absolue, y compris tous les domaines jusqu'au domaine de premier niveau (TLD), il est ponctué par un point final, par exemple fr.wikipedia.org.
La norme prévoit qu'un élément d'un nom de domaine (appelé label) ne peut dépasser 63 caractères, un FQDN ne pouvant dépasser 253 caractères.
Nom de domaine internationalisé[modifier]
Dans leur définition initiale, les noms de domaines sont constitués des caractères de A à Z (sans casse : les lettres capitales ne sont pas différenciées), de chiffres et du trait d'union.
La RFC 3490 définit un format appelé Punycode qui permet l'encodage d'un jeu de caractère plus étendu.
Technique du Round-Robin pour la distribution de la charge[modifier]
Lorsqu'un service génère un trafic important, celui-ci peut faire appel à la technique du DNS Round-Robin (en français tourniquet), qui consiste à associer plusieurs adresses IP à un nom de domaine. Les différentes versions de Wikipedia, comme fr.wikipedia.org par exemple, sont associées à plusieurs adresses IP : 207.142.131.235, 207.142.131.236, 207.142.131.245, 207.142.131.246, 207.142.131.247 et 207.142.131.248. L'ordre dans lequel ces adresses sont renvoyées sera modifié d'une requête à la suivante. Une rotation circulaire entre ces différentes adresses permet ainsi de répartir la charge générée par ce trafic important entre les différentes machines ayant ces adresses IP. Il faut cependant nuancer cette répartition car elle n'a lieu qu'à la résolution du nom d'hôte et reste par la suite en cache sur les différents resolvers (client DNS).
Principaux enregistrements DNS[modifier]
Le type de RR est codé sur 8 bits, l'IANA conserve le registre des codes assignés8. Les principaux enregistrements définis sont les suivants :
- A record ou address record qui fait correspondre un nom d'hôte à une adresse IPv4 de 32 bits distribués sur quatre octets ex: 123.234.1.2 ;
- AAAA record ou IPv6 address record qui fait correspondre un nom d'hôte à une adresse IPv6 de 128 bits distribués sur seize octets ;
- 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 courriel pour ce domaine ;
- PTR record ou pointer record qui associe une adresse IP à un enregistrement de nom de domaine, aussi dit « reverse » puisqu'il fait exactement le contraire du A record ;
- NS record ou name server record qui définit les serveurs DNS de ce domaine ;
- SOA record ou Start Of Authority record qui donne les informations générales de la zone : serveur principal, courriel de contact, différentes durées dont celle d'expiration, numéro de série de la zone ;
- SRV record qui généralise la notion de MX record, mais qui propose aussi des fonctionnalités avancées comme le taux de répartition de charge pour un service donné, standardisé dans la RFC 2782 ;
- NAPTR record ou Name Authority Pointer 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 ;
- TXT record permet à un administrateur d'insérer un texte quelconque dans un enregistrement DNS (par exemple, cet enregistrement était utilisé pour implémenter la spécificationSender Policy Framework) ;
- d'autres types d'enregistrements sont utilisés occasionnellement, ils servent simplement à donner des informations (par exemple, un enregistrement de type LOC indique l'emplacement physique d'un hôte, c'est-à-dire sa latitude et sa longitude). Cet enregistrement aurait un intérêt majeur mais n'est malheureusement que très rarement utilisé sur le monde Internet.
NS record[modifier]
Le record NS crée une délégation d'un sous-domaine vers une liste de serveurs.
Dans la zone org, les record NS suivants créent le sous-domaine wikipedia et délèguent celui-ci vers les serveurs indiqués. L'ordre des serveurs est quelconque. Tous les serveurs indiqués doivent faire autorité pour le domaine.
wikipedia NS ns1.wikimedia.org.
wikipedia NS ns2.wikimedia.org.
wikipedia NS ns0.wikimedia.org.
PTR record[modifier]
À l'inverse d'une entrée de type A, une entrée PTR indique à quel nom d'hôte correspond une adresse IPv4. Si elle est spécifiée, elle doit contenir l'enregistrement inverse d'une entrée DNS A. Par exemple, cet enregistrement PTR :
232.174.198.91.in-addr.arpa. IN PTR text.esams.wikimedia.org.
correspond à cette entrée A :
text.esams.wikimedia.org. IN A 91.198.174.232
Les enregistrements PTR sont aussi utilisés pour spécifier le nom d'hôte correspondant à une adresse IPv6. Ces entrées de type PTR sont enregistrées dans la zone ip6.arpa., pendant de la zone in-addr.arpa. des adresses IPv4.
La règle permettant de retrouver l'entrée correspondant à une adresse IPv6 est similaire à celle pour les adresses IPv4 (renversement de l'adresse et recherche dans un sous-domaine dédié de la zone arpa.), mais diffère au niveau du nombre de bits de l'adresse utilisés pour rédiger le nom du domaine où rechercher le champ PTR : là où pour IPv4 le découpage de l'adresse se fait par octet, pour IPv6 c'est un découpage par quartet qui est utilisé.
Par exemple à l'adresse IPv6 :
2001:610:240:22::c100:68b
correspond le nom de domaine :
b.8.6.0.0.0.1.c.0.0.0.0.0.0.0.0.2.2.0.0.0.4.2.0.0.1.6.0.1.0.0.2.ip6.arpa. PTR www.ipv6.ripe.net.
MX record[modifier]
Une entrée DNS MX indique les serveurs SMTP à contacter pour envoyer un courriel à un utilisateur d'un domaine donné. Par exemple :
wikimedia.org. IN MX 10 mchenry.wikimedia.org.
wikimedia.org. IN MX 50 lists.wikimedia.org.
On voit que les courriels envoyés à une adresse en @wikimedia.org sont en fait envoyés au serveur mchenry.wikimedia.org. ou lists.wikimedia.org. Le nombre précédant le serveur représente la priorité. Le serveur avec la priorité numérique la plus petite est employé en priorité. Ici, c'est donc mchenry.wikimedia.org. qui doit être utilisé en premier, avec une valeur de 10.
Les serveurs indiqués doivent avoir été configurés pour accepter de relayer les courriers pour le nom de domaine indiqué. Une erreur courante consiste à indiquer des serveurs quelconques comme serveurs secondaires, ce qui aboutit au rejet des courriers quand le serveur primaire devient inaccessible. Il n'est pas indispensable de disposer de serveurs secondaires, les serveurs émetteurs conservant les messages pendant un temps déterminé (typiquement, plusieurs jours) jusqu'à ce que le serveur primaire soit à nouveau disponible.
Les entrées MX sont généralisées par les entrées SRV qui permettent de faire la même chose mais pour tous les services, pas seulement SMTP (le courriel). L'avantage des entrées SRV par rapport aux entrées MX est aussi qu'elles permettent de choisir un port arbitraire pour chaque service ainsi que de faire de la répartition de charge plus efficacement. L'inconvénient c'est qu'il existe encore peu de programmes clients qui gèrent les entrées SRV. Cependant, depuis 2009, avec l'augmentation de l'utilisation du protocole SIP sur les services de VoIP, les enregistrements SRV deviennent plus fréquents dans les zones DNS.
CNAME record[modifier]
L'enregistrement CNAME permet de créer un alias.
Par exemple :
fr.wikipedia.org. IN CNAME text.wikimedia.org.
text.wikimedia.org. IN CNAME text.esams.wikimedia.org.
text.esams.wikimedia.org. IN A 91.198.174.232
Celui-ci exclut tout autre enregistrement (RFC 1034 section 3.6.2, RFC 1912 section 2.4), c'est-à-dire qu'on ne peut avoir à la fois un CNAME et un A record pour le même nom de domaine.
Par exemple, ceci est interdit :
fr.wikipedia.org. IN CNAME text.wikimedia.org.
fr.wikipedia.org. IN A 91.198.174.232
Par ailleurs, pour des raisons de performance, et pour éviter les boucles infinies du type
fr.wikipedia.org. IN CNAME text.wikimedia.org.
text.wikipedia.org. IN CNAME fr.wikimedia.org.
les spécifications (RFC 1034 section 3.6.2, RFC 1912 section 2.4) recommandent de ne pas faire pointer un CNAME sur un autre CNAME ni sur un DNAME.
Ainsi, le premier exemple serait préférablement enregistré de la façon suivante :
fr.wikipedia.org. IN CNAME text.esams.wikimedia.org.
text.wikimedia.org. IN CNAME text.esams.wikimedia.org.
text.esams.wikimedia.org. IN A 91.198.174.232
NAPTR record[modifier]
Peu répandus à l'heure actuelle (ils sont surtout utilisés par ENUM), ils décrivent une réécriture d'une clé (un nom de domaine) en URI. Par exemple, dans ENUM, des enregistrements NAPTR peuvent être utilisés pour trouver l'adresse de courrier électronique d'une personne, connaissant son numéro de téléphone (qui sert de clé à ENUM).
Ses paramètres sont dans l'ordre :
- Order : indique dans quel ordre évaluer les enregistrements NAPTR ; tant qu'il reste des enregistrements d'une certaine valeur de order à examiner, les enregistrements des valeurs suivantes de order n'entrent pas en considération ;
- Preference : donne une indication de priorité relative entre plusieurs enregistrements NAPTR qui ont la même valeur de order ;
- Flags : indique par exemple si l'enregistrement décrit une réécriture transitoire (dont le résultat est un nom de domaine pointant sur un autre enregistrement NAPTR) ou une réécriture finale ; la sémantique précise du paramètre flags dépend de l'application DDDS ('Dynamic Delegation Discovery System', RFC 3401) employée (ENUM en est une parmi d'autres) ;
- Services : décrit le service de réécriture ; par exemple dans ENUM, la valeur de services spécifie le type de l'URI résultante ; la sémantique précise de ce paramètre dépend également de l'application DDDS employée ;
- Regexp : l'opération de réécriture elle-même, formalisée en une expression rationnelle ; cette expression rationnelle est à appliquer à la clé ; ne peut être fourni en même temps que replacement ;
- Replacement : nom de domaine pointant sur un autre enregistrement NAPTR, permettant par exemple une réécriture transitoire par délégation ; ne peut être fourni en même temps que regexp.
L'enregistrement NAPTR est défini par la RFC 3403.
SOA record[modifier]
Cet enregistrement permet d'indiquer le serveur de nom maître (primaire), l'adresse e-mail d'un contact technique (avec @ remplacé par un point) et des paramètres d'expiration.
Il désigne l'autorité (start of authority) ou le responsable de la zone dans la hiérarchie DNS.
Ces paramètres sont dans l'ordre :
wikipedia.org. IN SOA ns0.wikimedia.org. hostmaster.wikimedia.org. 2010060311 43200 7200 1209600 3600
- Serial : indique un numéro de version pour la zone (32 bits non signé). Ce nombre doit être incrémenté à chaque modification du fichier zone ; on utilise par convention une date au format « yyyymmddnn » (« yyyy » pour l'année sur 4 chiffres, « mm » pour le mois sur 2 chiffres, « dd » pour le jour sur 2 chiffres, « nn » pour un compteur de révision si le numéro de série est modifié plusieurs fois dans un même jour. Cette convention évite tout débordement du 32 bits non signé jusqu'en l'an 4294) ;
- Refresh : l'écart en secondes entre les demandes successives de mise à jour réalisées depuis le serveur secondaire ou les serveurs esclaves ;
- Retry : le délai en secondes que doivent attendre le serveur secondaire ou les serveurs esclaves lorsque leur précédente requête a échoué ;
- Expire : le délai en secondes au terme duquel la zone est considérée comme invalide si le secondaire ou les esclaves ne peuvent joindre le serveur primaire ;
- Minimum ou negative TTL : utilisé pour spécifier, en secondes, la durée de vie pendant laquelle sont conservées en cache les réponses qui correspondent à des demandes d'enregistrements inexistants.
Les versions récentes de BIND (named) acceptent les suffixes M, H, D ou W pour indiquer un intervalle de temps en minutes, heures, jours ou semaines respectivement.
Time to live[modifier]
Chaque record est associé à un Time to live (TTL) qui détermine combien de temps il peut être conservé dans un serveur cache. Ce temps est typiquement d'un jour (86400 s) mais peut être plus élevé pour des informations qui changent rarement, comme des records NS. Il est également possible d'indiquer que des informations ne doivent pas être mises en cache en spécifiant un TTL de zéro.
Certaines applications, comme des navigateurs web disposent également d'un cache DNS, mais qui ne respecte pas nécessairement le TTL du DNS. Ce cache applicatif est généralement de l'ordre de la minute, mais Internet Explorer par exemple conserve les informations jusqu'à 30 minutes9, indépendamment du TTL configuré.
Glue records[modifier]
Quand un domaine est délégué à un serveur de noms qui appartient à ce sous-domaine, il est nécessaire de fournir également l'adresse IP de ce serveur pour éviter les références circulaires. Ceci déroge au principe général selon lequel l'information d'un domaine n'est pas dupliquée ailleurs dans le DNS.
Par exemple, dans la réponse suivante au sujet des NS pour le domaine wikimedia.org :
wikimedia.org. IN NS ns2.wikimedia.org.
wikimedia.org. IN NS ns1.wikimedia.org.
wikimedia.org. IN NS ns0.wikimedia.org.
Il est nécessaire de fournir également les adresses IP des serveurs indiqués dans la réponse, car ils font partie du domaine en question :
ns0.wikimedia.org. IN A 208.80.152.130
ns1.wikimedia.org. IN A 208.80.152.142
ns2.wikimedia.org. IN A 91.198.174.4
Mise à jour dynamique[modifier]
Une extension du DNS nommée DNS dynamique (en) (DDNS) permet à un client de mettre à jour une zone avec des informations qui le concernent (RFC 2136). Ceci est utile quand des clients obtiennent une adresse IP par DHCP et qu'ils souhaitent que le DNS reflète le nom réel de la machine.
Considérations opérationnelles[modifier]
Mise à jour du DNS[modifier]
Les mises à jour se font sur le serveur primaire du domaine, les serveurs secondaires recopiant les informations du serveur primaire dans un mécanisme appelé transfert de zone. Pour déterminer si un transfert de zone doit avoir lieu, le serveur secondaire consulte le numéro de version de la zone et le compare à la version qu'il possède. Le serveur primaire détermine à quelle fréquence le numéro de version est consulté. Quand un changement est effectué, les serveurs envoient des messages de notification aux serveurs secondaires pour accélérer le processus.
Il se peut que des informations qui ne sont plus à jour soient cependant conservées dans des serveurs cache. Il faut alors attendre l'expiration de leur Time to live pour que ces informations cachées disparaissent et donc que la mise à jour soit pleinement effective. On peut minimiser le temps nécessaire en diminuant le TTL associé aux noms de domaines qui vont être modifiées préalablement à une opération de changement.
Cohérence du DNS[modifier]
Quand la liste des serveurs de noms change, ou quand une adresse IP qui fait l'objet d'un Glue Record est modifiée, le gestionnaire du domaine de niveau supérieur doit effectuer la mise à jour correspondante.
Robustesse du DNS[modifier]
Pour éviter les points individuels de défaillance, on évite de partager l'infrastructure entre les serveurs qui font autorité. Un serveur secondaire sera de préférence délocalisé et routé différemment que le serveur primaire.
Bien que cela soit techniquement possible, on évite de mêler sur un même serveur le rôle de DNS récursif et celui de serveur qui fait autorité.
De même, un hôte sera configuré avec plusieurs serveurs récursifs, de sorte que si le premier ne répond pas à la requête, le suivant sera employé. En général, les serveurs récursifs fournis par les FAI refusent les requêtes émanant d'adresses IP appartenant à d'autres FAI.
Il existe des services de DNS récursifs ouverts, c'est-à-dire qu'ils acceptent les requêtes de tous les clients. Il est donc possible à un utilisateur de configurer ceux-ci en lieu et place de ceux fournis par le FAI. Ceci pose cependant les problèmes suivants :
- il n'y a pas de garantie que les réponses fournies seront les mêmes qu'avec des serveurs récursifs habituels. Un tel service pourrait en effet faire référence à une autre hiérarchie depuis la racine, disposer de TLD additionnels non standard, restreindre l'accès à certains domaines, voire altérer certains records avant leur transmission au client.
- il n'y a pas de garantie de confidentialité, c'est-à-dire que ce service pourrait déterminer à quels domaines un utilisateur à accès en conservant des traces des requêtes DNS.
Sécurité du DNS[modifier]
Le protocole DNS a été conçu avec un souci minimum de la sécurité. Plusieurs failles de sécurité du protocole DNS ont été identifiées depuis. Les principales failles du DNS ont été décrites dans le RFC 3833 publié en août 2004.
Interception des paquets[modifier]
Une des failles mises en avant est la possibilité d'intercepter les paquets transmis. Les serveurs DNS communiquent au moyen de paquets uniques et non signés. Ces deux spécificités rendent l'interception très aisée. L'interception peut se concrétiser de différentes manières, notamment via une attaque de type « man in the middle », de l'écoute des données transférées et de l'envoi de réponse falsifiée (voir paragraphe ci-dessous).
Fabrication d'une réponse[modifier]
Les paquets des serveurs DNS étant faiblement sécurisés, authentifiés par un numéro de requête, il est possible de fabriquer de faux paquets. Par exemple, un utilisateur qui souhaite accéder au site http://mabanque.example.com fait une demande au site DNS. Il suffit, à ce moment, qu'un pirate informatique réponde à la requête de l'utilisateur avant le serveur DNS pour que l'utilisateur se retrouve sur un site d'hameçonnage.
Corruption des données[modifier]
La trahison par un serveur, ou corruption de données, est, techniquement, identique à une interception des paquets. La seule différence venant du fait que l'utilisateur envoie volontairement sa requête au serveur. Cette situation peut arriver lorsque, par exemple, l'opérateur du serveur DNS souhaite mettre en avant un partenaire commercial.
Empoisonnement du cache DNS[modifier]
L'empoisonnement du cache DNS ou pollution de cache DNS (DNS cache poisoning ou DNS cache pollution en français) est une technique permettant de leurrer les serveurs DNS afin de leur faire croire qu'ils reçoivent une requête valide tandis qu'elle est frauduleuse10.
Déni de service[modifier]
Une attaque par déni de service (ou attaque par saturation ; en anglais, Denial of Service attack ou DoS attack) est une attaque sur un serveur informatique qui résulte en l'incapacité pour le serveur de répondre aux requêtes de ses clients.
DNSSEC[modifier]
Pour contrer ces vulnérabilités, le protocole DNSSEC a été développé.
Exemple d'attaques majeures contre des serveurs DNS[modifier]
En juillet 2008, quelques jours après la publication du rapport de la United States Computer Emergency Readiness Team concernant la faille de sécurité des serveurs DNS permettant d'empoisonner leur cache, plusieurs serveurs DNS majeurs ont subi des attaques. Une des plus importantes fut celle menée contre les serveurs de AT&T. L'attaque empoisonnant le cache des serveurs DNS de AT&T a permis au pirate informatique de rediriger toutes les requêtes à Google vers un site d'hameçonnage11.
Détails du protocole[modifier]
DNS utilise en général UDP et le port 53. La taille maximale des paquets utilisée est de 512 octets. Si une réponse dépasse cette taille, la norme prévoit que la requête doit être renvoyée sur le port TCP 53. Ce cas est cependant rare et évité, et les firewalls bloquent souvent le port TCP 53. Les transferts de zone s'effectuent par TCP sur le même numéro de port. Pour des raisons de sécurité, les serveurs restreignent généralement la possibilité de transférer des zones.
L'extension EDNS0 (RFC 2671) permet d'utiliser une taille de paquets plus élevée, sa prise en charge est recommandée pour IPv6 comme pour DNSSEC.
La norme prévoit qu'il existe une classe associée aux requêtes. Les classes IN (Internet), CH (Chaos) et HS (Hesiod (en)) sont définies, seule la classe IN étant réellement utilisée en pratique. La classe chaos est utilisée par BIND pour révéler le numéro de version12.
Exemples de consultation DNS[modifier]
Pour vérifier l'association entre un nom et une adresse IP, plusieurs commandes sont disponibles suivant les systèmes d'exploitation utilisés. Pour exemple sur Windows la commandenslookup est disponible via l'invite de commande :
C:\>nslookup www.google.fr
Serveur : Livebox-6370
Address: 192.168.1.1
Réponse ne faisant pas autorité :
Nom : www.l.google.com
Addresses:
209.85.229.104
209.85.229.106
209.85.229.103
209.85.229.147
209.85.229.105
209.85.229.99
Aliases: www.google.fr
www.google.com
dig www.google.com aaaa
; <<>> DiG 9.7.0-P1 <<>> www.google.com aaaa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47055
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 4, ADDITIONAL: 0
;; QUESTION SECTION:
;www.google.com. IN AAAA
;; ANSWER SECTION:
www.google.com. 422901 IN CNAME www.l.google.com.
www.l.google.com. 77 IN AAAA 2a00:1450:8004::67
www.l.google.com. 77 IN AAAA 2a00:1450:8004::68
www.l.google.com. 77 IN AAAA 2a00:1450:8004::69
www.l.google.com. 77 IN AAAA 2a00:1450:8004::6a
www.l.google.com. 77 IN AAAA 2a00:1450:8004::93
www.l.google.com. 77 IN AAAA 2a00:1450:8004::63
;; AUTHORITY SECTION:
google.com. 155633 IN NS ns2.google.com.
google.com. 155633 IN NS ns1.google.com.
google.com. 155633 IN NS ns3.google.com.
google.com. 155633 IN NS ns4.google.com.
;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Sun May 23 16:23:49 2010
;; MSG SIZE rcvd: 292
Serveurs DNS racine[modifier]
Les serveurs racine sont gérés par douze organisations différentes : deux sont européennes, une japonaise et les neuf autres sont américaines. Sept de ces serveurs sont en réalité distribués dans le monde grâce à la technique anycast et neuf disposent d'une adresse IPv64. Grâce à anycast, plus de 200 serveurs répartis dans 50 pays du monde assurent ce service5. Il existe 13 autorités de nom appelées de a à m.root-servers.net6. Le serveur k reçoit par exemple de l'ordre de 20 000 requêtes par seconde7.
Le DNS ne fournit pas de mécanisme pour découvrir la liste des serveurs racine, chacun des serveurs doit donc connaître cette liste au démarrage grâce à un encodage explicite. Cette liste est ensuite mise à jour en consultant l'un des serveurs indiqués. La mise à jour de cette liste est peu fréquente de façon à ce que les serveurs anciens continuent à fonctionner.
Fully Qualified Domain Name[modifier]
On entend par Fully qualified domain name (FQDN), ou Nom de domaine pleinement qualifié un nom de domaine écrit de façon absolue, y compris tous les domaines jusqu'au domaine de premier niveau (TLD), il est ponctué par un point final, par exemple fr.wikipedia.org.
La norme prévoit qu'un élément d'un nom de domaine (appelé label) ne peut dépasser 63 caractères, un FQDN ne pouvant dépasser 253 caractères.
Nom de domaine internationalisé[modifier]
Dans leur définition initiale, les noms de domaines sont constitués des caractères de A à Z (sans casse : les lettres capitales ne sont pas différenciées), de chiffres et du trait d'union.
La RFC 3490 définit un format appelé Punycode qui permet l'encodage d'un jeu de caractère plus étendu.
Technique du Round-Robin pour la distribution de la charge[modifier]
Lorsqu'un service génère un trafic important, celui-ci peut faire appel à la technique du DNS Round-Robin (en français tourniquet), qui consiste à associer plusieurs adresses IP à un nom de domaine. Les différentes versions de Wikipedia, comme fr.wikipedia.org par exemple, sont associées à plusieurs adresses IP : 207.142.131.235, 207.142.131.236, 207.142.131.245, 207.142.131.246, 207.142.131.247 et 207.142.131.248. L'ordre dans lequel ces adresses sont renvoyées sera modifié d'une requête à la suivante. Une rotation circulaire entre ces différentes adresses permet ainsi de répartir la charge générée par ce trafic important entre les différentes machines ayant ces adresses IP. Il faut cependant nuancer cette répartition car elle n'a lieu qu'à la résolution du nom d'hôte et reste par la suite en cache sur les différents resolvers (client DNS).
Principaux enregistrements DNS[modifier]
Le type de RR est codé sur 8 bits, l'IANA conserve le registre des codes assignés8. Les principaux enregistrements définis sont les suivants :
- A record ou address record qui fait correspondre un nom d'hôte à une adresse IPv4 de 32 bits distribués sur quatre octets ex: 123.234.1.2 ;
- AAAA record ou IPv6 address record qui fait correspondre un nom d'hôte à une adresse IPv6 de 128 bits distribués sur seize octets ;
- 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 courriel pour ce domaine ;
- PTR record ou pointer record qui associe une adresse IP à un enregistrement de nom de domaine, aussi dit « reverse » puisqu'il fait exactement le contraire du A record ;
- NS record ou name server record qui définit les serveurs DNS de ce domaine ;
- SOA record ou Start Of Authority record qui donne les informations générales de la zone : serveur principal, courriel de contact, différentes durées dont celle d'expiration, numéro de série de la zone ;
- SRV record qui généralise la notion de MX record, mais qui propose aussi des fonctionnalités avancées comme le taux de répartition de charge pour un service donné, standardisé dans la RFC 2782 ;
- NAPTR record ou Name Authority Pointer 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 ;
- TXT record permet à un administrateur d'insérer un texte quelconque dans un enregistrement DNS (par exemple, cet enregistrement était utilisé pour implémenter la spécificationSender Policy Framework) ;
- d'autres types d'enregistrements sont utilisés occasionnellement, ils servent simplement à donner des informations (par exemple, un enregistrement de type LOC indique l'emplacement physique d'un hôte, c'est-à-dire sa latitude et sa longitude). Cet enregistrement aurait un intérêt majeur mais n'est malheureusement que très rarement utilisé sur le monde Internet.
NS record[modifier]
Le record NS crée une délégation d'un sous-domaine vers une liste de serveurs.
Dans la zone org, les record NS suivants créent le sous-domaine wikipedia et délèguent celui-ci vers les serveurs indiqués. L'ordre des serveurs est quelconque. Tous les serveurs indiqués doivent faire autorité pour le domaine.
wikipedia NS ns1.wikimedia.org. wikipedia NS ns2.wikimedia.org. wikipedia NS ns0.wikimedia.org.
PTR record[modifier]
À l'inverse d'une entrée de type A, une entrée PTR indique à quel nom d'hôte correspond une adresse IPv4. Si elle est spécifiée, elle doit contenir l'enregistrement inverse d'une entrée DNS A. Par exemple, cet enregistrement PTR :
232.174.198.91.in-addr.arpa. IN PTR text.esams.wikimedia.org.
correspond à cette entrée A :
text.esams.wikimedia.org. IN A 91.198.174.232
Les enregistrements PTR sont aussi utilisés pour spécifier le nom d'hôte correspondant à une adresse IPv6. Ces entrées de type PTR sont enregistrées dans la zone ip6.arpa., pendant de la zone in-addr.arpa. des adresses IPv4.
La règle permettant de retrouver l'entrée correspondant à une adresse IPv6 est similaire à celle pour les adresses IPv4 (renversement de l'adresse et recherche dans un sous-domaine dédié de la zone arpa.), mais diffère au niveau du nombre de bits de l'adresse utilisés pour rédiger le nom du domaine où rechercher le champ PTR : là où pour IPv4 le découpage de l'adresse se fait par octet, pour IPv6 c'est un découpage par quartet qui est utilisé.
Par exemple à l'adresse IPv6 :
2001:610:240:22::c100:68b
correspond le nom de domaine :
b.8.6.0.0.0.1.c.0.0.0.0.0.0.0.0.2.2.0.0.0.4.2.0.0.1.6.0.1.0.0.2.ip6.arpa. PTR www.ipv6.ripe.net.
MX record[modifier]
Une entrée DNS MX indique les serveurs SMTP à contacter pour envoyer un courriel à un utilisateur d'un domaine donné. Par exemple :
wikimedia.org. IN MX 10 mchenry.wikimedia.org. wikimedia.org. IN MX 50 lists.wikimedia.org.
On voit que les courriels envoyés à une adresse en @wikimedia.org sont en fait envoyés au serveur mchenry.wikimedia.org. ou lists.wikimedia.org. Le nombre précédant le serveur représente la priorité. Le serveur avec la priorité numérique la plus petite est employé en priorité. Ici, c'est donc mchenry.wikimedia.org. qui doit être utilisé en premier, avec une valeur de 10.
Les serveurs indiqués doivent avoir été configurés pour accepter de relayer les courriers pour le nom de domaine indiqué. Une erreur courante consiste à indiquer des serveurs quelconques comme serveurs secondaires, ce qui aboutit au rejet des courriers quand le serveur primaire devient inaccessible. Il n'est pas indispensable de disposer de serveurs secondaires, les serveurs émetteurs conservant les messages pendant un temps déterminé (typiquement, plusieurs jours) jusqu'à ce que le serveur primaire soit à nouveau disponible.
Les entrées MX sont généralisées par les entrées SRV qui permettent de faire la même chose mais pour tous les services, pas seulement SMTP (le courriel). L'avantage des entrées SRV par rapport aux entrées MX est aussi qu'elles permettent de choisir un port arbitraire pour chaque service ainsi que de faire de la répartition de charge plus efficacement. L'inconvénient c'est qu'il existe encore peu de programmes clients qui gèrent les entrées SRV. Cependant, depuis 2009, avec l'augmentation de l'utilisation du protocole SIP sur les services de VoIP, les enregistrements SRV deviennent plus fréquents dans les zones DNS.
CNAME record[modifier]
L'enregistrement CNAME permet de créer un alias.
Par exemple :
fr.wikipedia.org. IN CNAME text.wikimedia.org. text.wikimedia.org. IN CNAME text.esams.wikimedia.org. text.esams.wikimedia.org. IN A 91.198.174.232
Celui-ci exclut tout autre enregistrement (RFC 1034 section 3.6.2, RFC 1912 section 2.4), c'est-à-dire qu'on ne peut avoir à la fois un CNAME et un A record pour le même nom de domaine.
Par exemple, ceci est interdit :
fr.wikipedia.org. IN CNAME text.wikimedia.org. fr.wikipedia.org. IN A 91.198.174.232
Par ailleurs, pour des raisons de performance, et pour éviter les boucles infinies du type
fr.wikipedia.org. IN CNAME text.wikimedia.org. text.wikipedia.org. IN CNAME fr.wikimedia.org.
les spécifications (RFC 1034 section 3.6.2, RFC 1912 section 2.4) recommandent de ne pas faire pointer un CNAME sur un autre CNAME ni sur un DNAME.
Ainsi, le premier exemple serait préférablement enregistré de la façon suivante :
fr.wikipedia.org. IN CNAME text.esams.wikimedia.org. text.wikimedia.org. IN CNAME text.esams.wikimedia.org. text.esams.wikimedia.org. IN A 91.198.174.232
NAPTR record[modifier]
Peu répandus à l'heure actuelle (ils sont surtout utilisés par ENUM), ils décrivent une réécriture d'une clé (un nom de domaine) en URI. Par exemple, dans ENUM, des enregistrements NAPTR peuvent être utilisés pour trouver l'adresse de courrier électronique d'une personne, connaissant son numéro de téléphone (qui sert de clé à ENUM).
Ses paramètres sont dans l'ordre :
- Order : indique dans quel ordre évaluer les enregistrements NAPTR ; tant qu'il reste des enregistrements d'une certaine valeur de order à examiner, les enregistrements des valeurs suivantes de order n'entrent pas en considération ;
- Preference : donne une indication de priorité relative entre plusieurs enregistrements NAPTR qui ont la même valeur de order ;
- Flags : indique par exemple si l'enregistrement décrit une réécriture transitoire (dont le résultat est un nom de domaine pointant sur un autre enregistrement NAPTR) ou une réécriture finale ; la sémantique précise du paramètre flags dépend de l'application DDDS ('Dynamic Delegation Discovery System', RFC 3401) employée (ENUM en est une parmi d'autres) ;
- Services : décrit le service de réécriture ; par exemple dans ENUM, la valeur de services spécifie le type de l'URI résultante ; la sémantique précise de ce paramètre dépend également de l'application DDDS employée ;
- Regexp : l'opération de réécriture elle-même, formalisée en une expression rationnelle ; cette expression rationnelle est à appliquer à la clé ; ne peut être fourni en même temps que replacement ;
- Replacement : nom de domaine pointant sur un autre enregistrement NAPTR, permettant par exemple une réécriture transitoire par délégation ; ne peut être fourni en même temps que regexp.
L'enregistrement NAPTR est défini par la RFC 3403.
SOA record[modifier]
Cet enregistrement permet d'indiquer le serveur de nom maître (primaire), l'adresse e-mail d'un contact technique (avec @ remplacé par un point) et des paramètres d'expiration.
Il désigne l'autorité (start of authority) ou le responsable de la zone dans la hiérarchie DNS.
Ces paramètres sont dans l'ordre :
wikipedia.org. IN SOA ns0.wikimedia.org. hostmaster.wikimedia.org. 2010060311 43200 7200 1209600 3600
- Serial : indique un numéro de version pour la zone (32 bits non signé). Ce nombre doit être incrémenté à chaque modification du fichier zone ; on utilise par convention une date au format « yyyymmddnn » (« yyyy » pour l'année sur 4 chiffres, « mm » pour le mois sur 2 chiffres, « dd » pour le jour sur 2 chiffres, « nn » pour un compteur de révision si le numéro de série est modifié plusieurs fois dans un même jour. Cette convention évite tout débordement du 32 bits non signé jusqu'en l'an 4294) ;
- Refresh : l'écart en secondes entre les demandes successives de mise à jour réalisées depuis le serveur secondaire ou les serveurs esclaves ;
- Retry : le délai en secondes que doivent attendre le serveur secondaire ou les serveurs esclaves lorsque leur précédente requête a échoué ;
- Expire : le délai en secondes au terme duquel la zone est considérée comme invalide si le secondaire ou les esclaves ne peuvent joindre le serveur primaire ;
- Minimum ou negative TTL : utilisé pour spécifier, en secondes, la durée de vie pendant laquelle sont conservées en cache les réponses qui correspondent à des demandes d'enregistrements inexistants.
Les versions récentes de BIND (named) acceptent les suffixes M, H, D ou W pour indiquer un intervalle de temps en minutes, heures, jours ou semaines respectivement.
Time to live[modifier]
Chaque record est associé à un Time to live (TTL) qui détermine combien de temps il peut être conservé dans un serveur cache. Ce temps est typiquement d'un jour (86400 s) mais peut être plus élevé pour des informations qui changent rarement, comme des records NS. Il est également possible d'indiquer que des informations ne doivent pas être mises en cache en spécifiant un TTL de zéro.
Certaines applications, comme des navigateurs web disposent également d'un cache DNS, mais qui ne respecte pas nécessairement le TTL du DNS. Ce cache applicatif est généralement de l'ordre de la minute, mais Internet Explorer par exemple conserve les informations jusqu'à 30 minutes9, indépendamment du TTL configuré.
Glue records[modifier]
Quand un domaine est délégué à un serveur de noms qui appartient à ce sous-domaine, il est nécessaire de fournir également l'adresse IP de ce serveur pour éviter les références circulaires. Ceci déroge au principe général selon lequel l'information d'un domaine n'est pas dupliquée ailleurs dans le DNS.
Par exemple, dans la réponse suivante au sujet des NS pour le domaine wikimedia.org :
wikimedia.org. IN NS ns2.wikimedia.org. wikimedia.org. IN NS ns1.wikimedia.org. wikimedia.org. IN NS ns0.wikimedia.org.
Il est nécessaire de fournir également les adresses IP des serveurs indiqués dans la réponse, car ils font partie du domaine en question :
ns0.wikimedia.org. IN A 208.80.152.130 ns1.wikimedia.org. IN A 208.80.152.142 ns2.wikimedia.org. IN A 91.198.174.4
Mise à jour dynamique[modifier]
Une extension du DNS nommée DNS dynamique (en) (DDNS) permet à un client de mettre à jour une zone avec des informations qui le concernent (RFC 2136). Ceci est utile quand des clients obtiennent une adresse IP par DHCP et qu'ils souhaitent que le DNS reflète le nom réel de la machine.
Considérations opérationnelles[modifier]
Mise à jour du DNS[modifier]
Les mises à jour se font sur le serveur primaire du domaine, les serveurs secondaires recopiant les informations du serveur primaire dans un mécanisme appelé transfert de zone. Pour déterminer si un transfert de zone doit avoir lieu, le serveur secondaire consulte le numéro de version de la zone et le compare à la version qu'il possède. Le serveur primaire détermine à quelle fréquence le numéro de version est consulté. Quand un changement est effectué, les serveurs envoient des messages de notification aux serveurs secondaires pour accélérer le processus.
Il se peut que des informations qui ne sont plus à jour soient cependant conservées dans des serveurs cache. Il faut alors attendre l'expiration de leur Time to live pour que ces informations cachées disparaissent et donc que la mise à jour soit pleinement effective. On peut minimiser le temps nécessaire en diminuant le TTL associé aux noms de domaines qui vont être modifiées préalablement à une opération de changement.
Cohérence du DNS[modifier]
Quand la liste des serveurs de noms change, ou quand une adresse IP qui fait l'objet d'un Glue Record est modifiée, le gestionnaire du domaine de niveau supérieur doit effectuer la mise à jour correspondante.
Robustesse du DNS[modifier]
Pour éviter les points individuels de défaillance, on évite de partager l'infrastructure entre les serveurs qui font autorité. Un serveur secondaire sera de préférence délocalisé et routé différemment que le serveur primaire.
Bien que cela soit techniquement possible, on évite de mêler sur un même serveur le rôle de DNS récursif et celui de serveur qui fait autorité.
De même, un hôte sera configuré avec plusieurs serveurs récursifs, de sorte que si le premier ne répond pas à la requête, le suivant sera employé. En général, les serveurs récursifs fournis par les FAI refusent les requêtes émanant d'adresses IP appartenant à d'autres FAI.
Il existe des services de DNS récursifs ouverts, c'est-à-dire qu'ils acceptent les requêtes de tous les clients. Il est donc possible à un utilisateur de configurer ceux-ci en lieu et place de ceux fournis par le FAI. Ceci pose cependant les problèmes suivants :
- il n'y a pas de garantie que les réponses fournies seront les mêmes qu'avec des serveurs récursifs habituels. Un tel service pourrait en effet faire référence à une autre hiérarchie depuis la racine, disposer de TLD additionnels non standard, restreindre l'accès à certains domaines, voire altérer certains records avant leur transmission au client.
- il n'y a pas de garantie de confidentialité, c'est-à-dire que ce service pourrait déterminer à quels domaines un utilisateur à accès en conservant des traces des requêtes DNS.
Sécurité du DNS[modifier]
Le protocole DNS a été conçu avec un souci minimum de la sécurité. Plusieurs failles de sécurité du protocole DNS ont été identifiées depuis. Les principales failles du DNS ont été décrites dans le RFC 3833 publié en août 2004.
Interception des paquets[modifier]
Une des failles mises en avant est la possibilité d'intercepter les paquets transmis. Les serveurs DNS communiquent au moyen de paquets uniques et non signés. Ces deux spécificités rendent l'interception très aisée. L'interception peut se concrétiser de différentes manières, notamment via une attaque de type « man in the middle », de l'écoute des données transférées et de l'envoi de réponse falsifiée (voir paragraphe ci-dessous).
Fabrication d'une réponse[modifier]
Les paquets des serveurs DNS étant faiblement sécurisés, authentifiés par un numéro de requête, il est possible de fabriquer de faux paquets. Par exemple, un utilisateur qui souhaite accéder au site http://mabanque.example.com fait une demande au site DNS. Il suffit, à ce moment, qu'un pirate informatique réponde à la requête de l'utilisateur avant le serveur DNS pour que l'utilisateur se retrouve sur un site d'hameçonnage.
Corruption des données[modifier]
La trahison par un serveur, ou corruption de données, est, techniquement, identique à une interception des paquets. La seule différence venant du fait que l'utilisateur envoie volontairement sa requête au serveur. Cette situation peut arriver lorsque, par exemple, l'opérateur du serveur DNS souhaite mettre en avant un partenaire commercial.
Empoisonnement du cache DNS[modifier]
L'empoisonnement du cache DNS ou pollution de cache DNS (DNS cache poisoning ou DNS cache pollution en français) est une technique permettant de leurrer les serveurs DNS afin de leur faire croire qu'ils reçoivent une requête valide tandis qu'elle est frauduleuse10.
Déni de service[modifier]
Une attaque par déni de service (ou attaque par saturation ; en anglais, Denial of Service attack ou DoS attack) est une attaque sur un serveur informatique qui résulte en l'incapacité pour le serveur de répondre aux requêtes de ses clients.
DNSSEC[modifier]
Pour contrer ces vulnérabilités, le protocole DNSSEC a été développé.
Exemple d'attaques majeures contre des serveurs DNS[modifier]
En juillet 2008, quelques jours après la publication du rapport de la United States Computer Emergency Readiness Team concernant la faille de sécurité des serveurs DNS permettant d'empoisonner leur cache, plusieurs serveurs DNS majeurs ont subi des attaques. Une des plus importantes fut celle menée contre les serveurs de AT&T. L'attaque empoisonnant le cache des serveurs DNS de AT&T a permis au pirate informatique de rediriger toutes les requêtes à Google vers un site d'hameçonnage11.
Détails du protocole[modifier]
DNS utilise en général UDP et le port 53. La taille maximale des paquets utilisée est de 512 octets. Si une réponse dépasse cette taille, la norme prévoit que la requête doit être renvoyée sur le port TCP 53. Ce cas est cependant rare et évité, et les firewalls bloquent souvent le port TCP 53. Les transferts de zone s'effectuent par TCP sur le même numéro de port. Pour des raisons de sécurité, les serveurs restreignent généralement la possibilité de transférer des zones.
L'extension EDNS0 (RFC 2671) permet d'utiliser une taille de paquets plus élevée, sa prise en charge est recommandée pour IPv6 comme pour DNSSEC.
La norme prévoit qu'il existe une classe associée aux requêtes. Les classes IN (Internet), CH (Chaos) et HS (Hesiod (en)) sont définies, seule la classe IN étant réellement utilisée en pratique. La classe chaos est utilisée par BIND pour révéler le numéro de version12.
Exemples de consultation DNS[modifier]
Pour vérifier l'association entre un nom et une adresse IP, plusieurs commandes sont disponibles suivant les systèmes d'exploitation utilisés. Pour exemple sur Windows la commandenslookup est disponible via l'invite de commande :
C:\>nslookup www.google.fr
Serveur : Livebox-6370
Address: 192.168.1.1
Réponse ne faisant pas autorité :
Nom : www.l.google.com
Addresses:
209.85.229.104
209.85.229.106
209.85.229.103
209.85.229.147
209.85.229.105
209.85.229.99
Aliases: www.google.fr
www.google.com
dig www.google.com aaaa ; <<>> DiG 9.7.0-P1 <<>> www.google.com aaaa ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47055 ;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 4, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.google.com. IN AAAA ;; ANSWER SECTION: www.google.com. 422901 IN CNAME www.l.google.com. www.l.google.com. 77 IN AAAA 2a00:1450:8004::67 www.l.google.com. 77 IN AAAA 2a00:1450:8004::68 www.l.google.com. 77 IN AAAA 2a00:1450:8004::69 www.l.google.com. 77 IN AAAA 2a00:1450:8004::6a www.l.google.com. 77 IN AAAA 2a00:1450:8004::93 www.l.google.com. 77 IN AAAA 2a00:1450:8004::63 ;; AUTHORITY SECTION: google.com. 155633 IN NS ns2.google.com. google.com. 155633 IN NS ns1.google.com. google.com. 155633 IN NS ns3.google.com. google.com. 155633 IN NS ns4.google.com. ;; Query time: 0 msec ;; SERVER: ::1#53(::1) ;; WHEN: Sun May 23 16:23:49 2010 ;; MSG SIZE rcvd: 292
