Domain Name System

Le Domain Name System, généralement abrégé DNS, qu'on peut

traduire en « système de noms de domaine », est le service Domain Name System
informatique distribué utilisé pour traduire les noms de domaine
Internet en adresse IP ou autres enregistrements. En fournissant
dès les premières années d'Internet, autour de 1985, un service Informations
distribué de résolution de noms, le DNS a été un composant
essentiel du développement du réseau.
Fonction Traduction de nom de domaine
en adresse IP
À la demande de la DARPA (Defense Advanced Research Sigle DNS
Projects Agency, « Agence pour les projets de recherche avancée
Port 53
de défense ») américaine, Jon Postel et Paul Mockapetris ont 1 2
RFC 1983: RFC 882 - RFC 883
conçu le « Domain Name System » en 1983 et en ont rédigé la 3 4
1987: RFC 1034 - RFC 1035
première implémentation. 5
1994: RFC 1591
6
2011: RFC 6195
7
2013: RFC 6895
8 9
2018: RFC 8375 - RFC 8467
10 11
- RFC 8483 - RFC 8484
12
2019: RFC 8499
 Sommaire
Rôle du DNS
Histoire
Un système hiérarchique et distribué
Hiérarchie du DNS
Résolution du nom par un hôte
Résolution inverse
Résolution inverse CIDR

Serveurs DNS racine

Fully Qualified Domain Name
Nom de domaine internationalisé
Les techniques du DNSRound-Robin pour la distribution de la charge
Principaux enregistrements DNS
NS record
PTR record
MX record
CNAME record
NAPTR record
SOA record
Time to live
Glue records
Mise à jour dynamique
Considérations opérationnelles
Mise à jour du DNS
Cohérence du DNS
Robustesse du DNS
Sécurité du DNS
Interception des paquets
Fabrication d'une réponse
Corruption des données
Empoisonnement du cache DNS
Déni de service
DNSSEC
Chiffrement
Exemple d'attaques majeures contre des serveurs DNS
Détails du protocole
Exemples de consultation DNS
Notes et références
Voir aussi
Articles connexes
Liens externes

Rôle du DNS
Les équipements (hôtes) connectés à un réseau IP, comme Internet, possèdent une adresse IP qui les identifie sur le réseau. Ces
adresses sont numériques afin de faciliter leur traitement par les machines. En IPv4, elles sont représentées sous la forme
« [Link] », où « xxx » est un nombre entre 0 et 255 (en représentation décimale). En IPv6, les adresses sont représentées
sous la forme « xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx », où « xxxx » représente une valeur
hexadécimale.

Pour faciliter l'accès aux hôtes sur un réseau IP

, un mécanisme a été mis en place pour associer un nom à une adresse IP
. Ce nom, plus
simple à retenir, est appelé « nom de domaine ». Résoudre un nom de domaine consiste à trouver l'adresse IP qui lui est associée.

En plus des adresses IP, des informations complémentaires peuvent être associées aux noms de domaines comme des enregistrements
dans le contexte de la lutte contre le spam (SPF), RRSIG pour la sécurité des informations du DNS (DNSSEC) ou NAPTR pour
associer des numéros de téléphone à des adresses e-mailENUM).
(

Histoire
13
Avant le DNS, la résolution d'un nom sur Internet devait se faire grâce à un fichier texte appelé [Link] (RFC 608 ) maintenu
par le NIC du Stanford Research Institute(SRI) et copié sur chaque ordinateur du réseau par transfert de fichier. En 1982, ce système
centralisé montre ses limites et plusieurs propositions de remplacement voient le jour, parmi lesquelles le système distribué
14 15
Grapevine de Xerox et IEN 116 . Le premier (Grapevine) est jugé trop compliqué tandis que le second (IEN 116) est insuffisant .
1 2
La tâche de développer un autre système revient à Paul Mockapetris qui publie le design du système dans les RFC 882 et RFC 883
3 4
en 1983. La norme correspondante est publiée dans lesRFC 1034 et RFC 1035 en 1987. En 1987, le fichier [Link] contenait
5 500 entrées, tandis que 20 000 hôtes étaient définis dans le DNS.

Un système hiérarchique et distribué

Hiérarchie du DNS
Le système des noms de domaine consiste en une
hiérarchie dont le sommet est appelé laracine. On
représente cette dernière par un point. Dans un
domaine, on peut créer un ou plusieurs sous-
domaines ainsi qu'une délégation pour ceux-ci,
c'est-à-dire une indication que les informations
relatives à ce sous-domaine sont enregistrées sur
un autre serveur. Ces sous-domaines peuvent à
leur tour déléguer des sous-domaines vers d'autres Hiérarchie du DNS.
serveurs.

Tous les sous-domaines ne sont pas nécessairement délégués. Les délégations créent des zones, c'est-à-dire des ensembles de
domaines et leurs sous-domaines non délégués qui sont configurés sur un serveur déterminé. Les zones sont souvent confondues avec
les domaines.

Les domaines se trouvant immédiatement sous la racine sont appelés domaine de premier niveau (TLD : Top Level Domain). Les
noms de domaines ne correspondant pas à une extension de pays sont appelés des domaines génériques (gTLD), par exemple .org ou
.com. S'ils correspondent à des codes de pays (fr
, be, ch…), ce sont desdomaines de premier niveau national, aussi appelés ccTLD de
l'anglais country code TLD.

On représente un nom de domaine en indiquant les domaines successifs séparés par un point, les noms de domaines supérieurs se
trouvant à droite. Par exemple, le domaine org. est un TLD, sous-domaine de la racine. Le domaine [Link]. est un sous-
domaine de .org. Cette délégation est accomplie en indiquant la liste des serveurs DNS associée au sous-domaine dans le domaine de
niveau supérieur.

Les noms de domaines sont donc résolus en parcourant la hiérarchie depuis le sommet et en suivant les délégations successives, c'est-
à-dire en parcourant le nom de domaine de droite à gauche.
Pour qu'il fonctionne normalement, un nom de
domaine doit avoir fait l'objet d'une délégation
correcte dans le domaine de niveau supérieur
.

Résolution du nom par un hôte

Les hôtes n'ont qu'une connaissance limitée du
système des noms de domaine. Quand ils doivent
résoudre un nom, ils s'adressent à un ou plusieurs
serveurs de noms dits récursifs, c'est-à-dire qu'ils
vont parcourir la hiérarchie DNS et faire suivre la
requête à un ou plusieurs autres serveurs de noms
pour fournir une réponse. Les adresses IP de ces
serveurs récursifs sont souvent obtenues via
DHCP ou encore configurés en dur sur la
machine hôte. Les fournisseurs d'accès à Internet
mettent à disposition de leurs clients ces serveurs
récursifs. Il existe également des serveurs
récursifs publics comme ceux de Google Public Résolution itérative d'un nom dans le DNS par un serveur DNS
DNS ou OpenDNS. (étapes 2 à 7) et réponse (étape 8) suite à l'interrogation récursive
(étape 1) effectuée par un client (resolver) DNS. (remarque: Le
Quand un serveur DNS récursif doit trouver serveur DNS récursif est dit récursif car il accepte ce type de
l'adresse IP de [Link], un processus requêtes mais il effectue des requêtes itératives)
itératif démarre pour consulter la hiérarchie DNS.
Ce serveur demande aux serveurs DNS appelés
serveurs racine quels serveurs peuvent lui répondre pour la zone org. Parmi ceux-ci, le serveur va en choisir un pour savoir quels
serveurs sont capables de lui répondre pour la zone [Link]. C'est un de ces derniers qui pourra lui donner l'adresse IP de
[Link]. S'il se trouve qu'un serveur ne répond pas, un autre serveur de la liste sera consulté.

Pour optimiser les requêtes ultérieures, les serveurs DNS récursifs font aussi office de DNS cache : ils gardent en mémoire (cache) la
réponse d'une résolution de nom afin de ne pas effectuer ce processus à nouveau ultérieurement. Cette information est conservée
pendant une période nomméeTime to live et associée à chaque nom de domaine.

Un nom de domaine peut utiliser plusieurs serveurs DNS. Généralement, les noms de domaines en utilisent au moins deux : un
primaire et un secondaire. Il peut y avoir plusieurs serveurs secondaires.

L'ensemble des serveurs primaires et secondaires font autorité pour un domaine, c'est-à-dire que la réponse ne fait pas appel à un
autre serveur ou à un cache. Les serveurs récursifs fournissent des réponses qui ne sont pas nécessairement à jour, à cause du cache
mis en place. On parle alors de réponse ne faisant pas autoriténon-authoritative
( answer).

Cette architecture garantit au réseau Internet une certaine continuité dans la résolution des noms. Quand un serveur DNS tombe en
panne, le bon fonctionnement de la résolution de nom n'est pas remis en cause dans la mesure où des serveurs secondaires sont
disponibles.

Résolution inverse
Pour trouver le nom de domaine associé à une adresse IP, on utilise un principe semblable. Dans un nom de domaine, la partie la plus
générale est à droite : org dans [Link], le mécanisme de résolution parcourt donc le nom de domaine de droite à gauche.
Dans une adresse IP V4, c'est le contraire : 213 est la partie la plus générale de [Link]. Pour conserver une logique cohérente,
on inverse l'ordre des quatre termes de l'adresse et on la concatène au pseudo domaine [Link]. Ainsi, par exemple, pour trouver
le nom de domaine de l'adresse IP [Link], on résout [Link].in-addr
.arpa.
La déclaration inverse est importante sur les adresses IP publiques Internet puisque l'absence d'une résolution inverse est considérée
16
comme une erreur opérationnelle (RFC 1912 ) qui peut entraîner le refus d'accès à un service. Par exemple, un serveur de
messagerie électronique se présentant en envoi avec une adresse IP n'ayant pas de résolution inverse (PTR) a de grandes chances de
se voir refuser, par l'hôte distant, la transmission du courrier (message de refus de type IP
: lookup failed).

De plus, cette résolution inverse est importante dans le cadre de la réalisation de diagnostics réseaux car c'est elle qui permet de
rendre les résultats de la commande traceroute humainement exploitables. Les dénominations des noms d'hôtes inverses sont souvent
des composites de sous-domaines de localisation (ville, région, pays) et de domaines explicites indiquant le fournisseur d'accès
Internet traversé comme [Link] ([Link]) et [Link]
([Link]) pourFrance Télécom, ou encore [Link] ([Link]) pourFree.

Une adresse IP peut être associée à différents noms de domaine via l'enregistrement de plusieurs entrées PTR dans le sous-domaine
.arpa consacré à cette adresse ([Link]. pour IPv4 et [Link]. pour IPv6). L'utilisation d'enregistrements PTR multiples pour une
même adresse IP est éventuellement présente dans le cadre de l'hébergement virtuel de multiples domaines web derrière la même
adresse IP mais n'est pas recommandée dans la mesure où le nombre des champs PTR à renvoyer peut faire dépasser à la réponse la
taille des paquets UDP de réponse et entraîner l'utilisation du protocole TCP (plus coûteux en ressources) pour envoyer la réponse à
17
la requête DNS .

Résolution inverse CIDR

Les délégations des zones inverses se font sur une frontière d'octet, ce qui fonctionne quand les blocs d'adresses sont distribués de
façon classful mais pose des problèmes quand les blocs assignés sont de taille quelconque.

Par exemple, si deux clients A et B disposent chacun des blocs [Link]/25 et [Link]/25, il n'est pas possible de déléguer
[Link]. au premier pour qu'il puisse définir les PTR correspondant à ses hôtes, car cela empêcherait le second de faire
de même.
18
La RFC 2317 a défini une approche pour traiter ce problème, elle consiste à faire usage de domaines intermédiaires et de CNAME.

$ORIGIN [Link].
0/25 NS [Link].
128/25 NS [Link].

0 CNAME 0.0/[Link].[Link].
1 CNAME 1.0/[Link].[Link].
...
127 CNAME 127.0/[Link].[Link].
128 CNAME 128.128/[Link].[Link].
...
255 CNAME 255.128/[Link].[Link].

Le client A définit la zone 0/[Link].in-addr

.arpa. :

$ORIGIN 0/[Link].[Link].
1 PTR [Link].
...
127 PTR [Link].

Le client B fait de même pour 128/[Link].in-addr

.arpa. et les adresses 128 à 255.

La résolution inverse de [Link] aboutira aux requêtes suivantes :

[Link].[Link]. CNAME 1.0/[Link].[Link].

1.0/[Link].[Link]. PTR [Link].

Ce qui assure le fonctionnement de la résolution inverse, moyennant un niveau d'indirection supplémentaire.

Serveurs DNS racine
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
19 20
IPv6 . Grâce à anycast, plus de 200 serveurs répartis dans 50 pays du monde assurent ce service . Il existe 13 autorités de nom
appelées de a à [Link]. Le serveur k reçoit par exemple de l'ordre de 70 000 à 100 000 requêtes par seconde en avril
21
2019 .

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 que les serveurs anciens continuent à fonctionner
.

Fully Qualified Domain Name

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
[Link]. .

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é

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.
22
La RFC 3490 définit un format appeléPunycode qui permet l'encodage d'un jeu de caractère plus étendu.

Les techniques du DNS Round-Robin pour la distribution de la

charge
Lorsqu'un service génère un trafic important, celui-ci peut faire appel à la technique du DNS Round-Robin (en français tourniquet
DNS), une des techniques de répartition de charge qui consiste à associer plusieurs adresses IP à un FQDN. Les différentes versions
de Wikipedia, comme [Link] par exemple, sont associées à plusieurs adresses IP : [Link], [Link],
[Link], [Link], [Link] et [Link]. 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 dif
férents resolvers (client DNS).

Principaux enregistrements DNS

23
Le type d'enregistrement de ressource (RR pour Resource Record) est codé sur 16 bits , l'IANA conserve le registre des codes
24
assignés . Les principaux enregistrements définis sont les suivants :

A record ou address record (également appelé enregistrement d’hôte) qui fait correspondre un nom d'hôte ou un
nom de domaine ou un sous-domaine à une adresse IPv4 de 32 bits distribués sur quatre octets ex: [Link] ;
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 recordqui 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 recordqui 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 duA record ;
 NS record ou name server record qui définit les serveurs DNS de ce domaine ;
SOA record ou Start Of Authority recordqui 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 deMX record, mais qui propose aussi des fonctionnalités avancées comme
25
le taux de répartition de charge pour un service donné, standardisé dans la RFC 2782 ;
NAPTR record ou Name Authority Pointer recordqui donne accès à des règles deréécriture de l'information,
permettant des correspondances assez lâches entre un nom de domaine et une ressource. Il est spécifié dans la
26
RFC 3403 ;
TXT record permet à un administrateur d'insérer un texte quelconque dans un enregistrement DNS (par exemple,
cet enregistrement est 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 typeLOC indique l'emplacement physique d'un hôte, c'est-à-dire
sa latitude et sa longitude). Certaines personnes disent que cela aurait un intérêt majeur mais n'est que très
rarement utilisé sur le monde Internet.

NS record
L'enregistrement NS crée une délégation d'un sous-domaine vers une liste de serveurs.

Dans la zone org, les enregistrements NS suivants créent le sous-domainewikipedia 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 doma
ine.

wikipedia NS [Link].
wikipedia NS [Link].
wikipedia NS [Link].

PTR record
À l'inverse d'une entrée de type A ou AAAA, une entrée PTR indique à quel nom d'hôte correspond une adresse IPv4 ou IPv6. Si elle
est spécifiée, elle doit contenir l'enregistrement inverse d'une entrée DNS A ou AAAA.

Par exemple (pour une adresseIPv4) cet enregistrement PTR est :

[Link].[Link]. IN PTR [Link].

correspond à cette entrée A:

[Link]. IN A [Link]

Dans le cas d'une adresse IPv6, les entrées de type PTR sont enregistrées dans la zone [Link]. (pendant de la zone [Link]. 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 parquartet qui est utilisé.

Par exemple à l'adresse IPv6 :

[Link]

correspond le nom de domaine :

b.[Link].0.1.c.[Link].[Link].[Link].[Link].[Link].[Link].[Link]. PTR [Link].

MX record
Une entrée DNS MX indique les serveurs SMTP à contacter pour envoyer un courriel à un utilisateur d'un domaine donné. Par
exemple :

[Link]. IN MX 10 [Link].
[Link]. IN MX 50 [Link].

On voit que les courriels envoyés à une adresse en @[Link] sont envoyés au serveur [Link]. ou
[Link]. 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 [Link]. 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
L'enregistrement CNAME permet de créer unalias.

Par exemple :

[Link]. IN CNAME [Link].

[Link]. IN CNAME [Link].
[Link]. IN A [Link]

3 16
Celui-ci exclut tout autre enregistrement R
( FC 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 :

[Link]. IN CNAME [Link].

[Link]. IN A [Link]

Par ailleurs, pour des raisons de performance, et pour éviter les boucles infinies du type

[Link]. IN CNAME [Link].

[Link]. IN CNAME [Link].

3 16
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 (alias pour un nom et tous ses sous-noms).

Ainsi, le premier exemple serait préférablement enregistré de la façon suivante :

[Link]. IN CNAME [Link].

[Link]. IN CNAME [Link].
[Link]. IN A [Link]
NAPTR record
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 :

1. 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 valeurssuivantes de order n'entrent pas en
considération ;
2. Preference : donne une indication de priorité relative entre plusieurs enregistrements NAPTR qui ont la même
valeur de order ;
3. 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
27
flags dépend de l'application DDDS ('Dynamic Delegation Discovery System', RFC 3401 ) employée (ENUM en
est une parmi d'autres) ;
4. Services : décrit le service de réécriture ; par exemple dansENUM, 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 ;
5. Regexp : l'opération de réécriture elle-même, formalisée en uneexpression rationnelle ; cette expression rationnelle
est à appliquer à la clé ; ne peut être fourni en même temps quereplacement ;
6. 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.
26
L'enregistrement NAPTR est défini par laRFC 3403 .

SOA record
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. C'est l'acte de naissance de la zone DNS.

Ces paramètres sont dans l'ordre :

[Link]. IN SOA [Link]. [Link]. 2010060311 43200 7200 1209600 3600

1. 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) ;
2. Refresh : l'écart en secondes entre les demandes successives de mise à jour réalisées depuis le serveur
secondaire ou les serveurs esclaves ;
3. 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é ;
4. 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 ;
5. Minimum ou negative TTL : utilisé pour spécifier, en secondes, la duréede vie pendant laquelle sont conservées
en cache les réponses qui correspondent à des demandes d'enregistrements inexistants.
Les versions récentes deBIND (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
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 desnavigateurs 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
28
informations jusqu'à 30 minutes , indépendamment du TTL configuré.

Glue records
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 [Link]
g:

[Link]. IN NS [Link].
[Link]. IN NS [Link].
[Link]. IN NS [Link].

29
Il est nécessaire de fournir également les adresses IP des serveurs indiqués dans la réponse (glue records ), car ils font partie du
domaine en question :

[Link]. IN A [Link]
[Link]. IN A [Link]
[Link]. IN A [Link]

Mise à jour dynamique

Une extension du DNS nommée DNS dynamique (DDNS) permet à un client de mettre à jour une zone avec des informations qui le
30
concernent (RFC 2136 ). Ceci est utile quand des clients obtiennent une adresse IP parDHCP et qu'ils souhaitent que le DNS reflète
le nom réel de la machine.

Considérations opérationnelles

Mise à jour du DNS

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
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
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é dif
fé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 leAI.
F 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, voirealtérer certains records avant leur transmissionau
client.
il n'y a pas de garantie de confidentialité, c'est-à-dire que ce service pourrait déterminer à quels domaines un
utilisateur a accès en conservant des traces des requêtes DNS.

Sécurité du DNS
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é
31
identifiées depuis. Les principales failles du DNS ont été décrites dans leRFC 3833 publié en août 2004.

Interception des paquets

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

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 [Link] 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

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

L'empoisonnement du cache DNS ou pollution de cache DNS (en anglais, DNS cache poisoning) est une technique permettant de
32
leurrer les serveurs DNS afin de leur faire croire qu'ils reçoivent une requête valide tandis qu'elle est frauduleuse.

Déni de service
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
Pour contrer ces vulnérabilités, le protocoleDNSSEC a été développé.

Chiffrement
33
Depuis 2015 , l'IETF travaille à la sécurité du canal de communication du DNS (là où DNSSEC protège les données). Cela a
débouché sur la publication de plusieurs RFC permettant l'utilisation de TLS afin de chiffrer la communication entre les clients DNS
34
et les résolveurs. Il s'agit principalement de : DNS sur TLS (en) (RFC 7858 , utilisant le port 853) et DNS sur HTTPS (en)
11
(RFC 8484 , requête DNS encapsulée dans une requêteHTTP, et traitée par un serveur Web).

Il n'y a pas, en 2018, de possibilités de chiffrer – via TLS – les communications entre un résolveur et un serveur faisant autorité.

Exemple d'attaques majeures contre des serveurs DNS

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
35
a permis au pirate informatique de rediriger toutes les requêtes de Google vers un site hameçonnage
d' .

Détails du protocole
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.
36
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
37
version .

Exemples de consultation DNS

Pour vérifier l'association entre un nom et une adresse IP, plusieurs commandes sont disponibles suivant les systèmes d'exploitation
utilisés.

Par exemple sur Windows la commande nslookup est disponible via l'invite de commande :

> nslookup [Link]

Serveur : Livebox-6370
Address: [Link]

Réponse ne faisant pas autorité :

Nom : [Link]
Addresses:
[Link]
[Link]
[Link]
[Link]
[Link]
 [Link]
Aliases: [Link]
[Link]

ou encore dig sur les systèmes compatibles avecUNIX :

> dig [Link] aaaa

; <<>> DiG 9.7.0-P1 <<>> [Link] 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:
;[Link]. IN AAAA

;; ANSWER SECTION:
[Link]. 422901 IN CNAME [Link].
[Link]. 77 IN AAAA [Link]
[Link]. 77 IN AAAA [Link]
[Link]. 77 IN AAAA [Link]
[Link]. 77 IN AAAA [Link]
[Link]. 77 IN AAAA [Link]
[Link]. 77 IN AAAA [Link]

;; AUTHORITY SECTION:
[Link]. 155633 IN NS [Link].
[Link]. 155633 IN NS [Link].
[Link]. 155633 IN NS [Link].
[Link]. 155633 IN NS [Link].

;; Query time: 0 msec

;; SERVER: ::1#53(::1)
;; WHEN: Sun May 23 [Link] 2010
;; MSG SIZE rcvd: 292

Notes et références
1. (en) Request for Commentsno 882 ([Link]
2. (en) Request for Commentsno 883 ([Link]
3. (en) Request for Commentsno 1034 ([Link]
4. (en) Request for Commentsno 1035 ([Link]
5. (en) Request for Commentsno 1591 ([Link]
6. (en) Request for Commentsno 6195 ([Link]
7. (en) Request for Commentsno 6895 ([Link]
8. (en) Request for Commentsno 8375 ([Link]
9. (en) Request for Commentsno 8467 ([Link]
10. (en) Request for Commentsno 8483 ([Link]
11. (en) Request for Commentsno 8484 ([Link]
12. (en) Request for Commentsno 8499 ([Link]
13. (en) Request for Commentsno 608 ([Link]
14. IEN 116 ([Link] Name Server, Jon Postel 1979
15. Development of the Domain Name System([Link]
[Link]), Paul Mockapetris, Kevin Dunlap, Sigcomm 1988
16. (en) Request for Commentsno 1912 ([Link]
17. Voir la section 4.4 Usage and deployment considerationsdu draft draft-ietf-dnsop-reverse-mapping-considerations(ht
tp://[Link]/html/draft-ietf-dnsop-reverse-mapping-considerations-06)
18. (en) Request for Commentsno 2317 ([Link]
19. (en) « [Link] » ([Link] sur [Link]
20. « Root Server Technical Operations Assn» ([Link] sur [Link] (consulté le 28 avril 2019)
21. k statistics ([Link]
22. (en) Request for Commentsno 3490 ([Link]
23. RFC 1035, chapitre 3.2.1
24. « Domain Name System (DNS) Parameters» ([Link]
ml), sur [Link] (consulté le 28 avril 2019)
25. (en) Request for Commentsno 2782 ([Link]
26. (en) Request for Commentsno 3403 ([Link]
27. (en) Request for Commentsno 3401 ([Link]
28. « Comment Internet Explorer utilise le cache pour les entrées d’hôte DNS » ([Link]
63558/how-internet-explorer-uses-the-cache-for-dns-host-entries), sur [Link](consulté le
28 avril 2019)
29. « Glue Records (enregistrements Glue) — Documentation Documentation Gandi » ([Link]
maine/utilisateurs_avances/glue_records.html), sur [Link] (consulté le 28 avril 2019)
30. (en) Request for Commentsno 2136 ([Link]
31. (en) Request for Commentsno 3833 ([Link]
32. (en) « Multiple DNS implementations vulnerable to cache poisoning» ([Link] sur
[Link] (consulté le 28 avril 2019)
33. « Dprive Status Pages » ([Link] sur [Link] (consulté le 28 avril 2019)
34. (en) Request for Commentsno 7858 ([Link]
35. (en) « DNS Attack Writer a Victim of His Own Creation» ([Link]
html), sur PCWorld, 29 juillet 2008 (consulté le 28 avril 2019)
36. (en) Request for Commentsno 2671 ([Link]
37. dig CH @[Link] [Link] txt

Voir aussi

Articles connexes Sur les autres projets Wikimedia :

DNS black holing ICANN Domain Name System, sur Wikibooks

Dig Manipulation de
DNS Black Listing l'espace des noms de
domaine (DNS
Empoisonnement du
menteurs)
cache DNS
nslookup
Hébergement de nom
de domaine Serveur racine du
DNS
host
RadioDNS
Hosts

Liens externes
Auto-formation au DNS par l'AFNIC (en) RFC6195 relatives au DNS
DNS dans tous ses détails (en) RFC1035 relatives au DNS
DNS sur le site [Link] (en) Information sur le DNS
Support Cours de l'UREC/CNRS sur le DNS[PDF] (en) Bonne explication des NAPTR par Nominet
Tester la mise à jour des DNS

Ce document provient de «[Link]

La dernière modification de cette page a été faite le 28 avril 2019 à 19:03.

Droit d'auteur : les textes sont disponibles souslicence Creative Commons attribution, partage dans les mêmes
conditions ; d’autres conditions peuvent s’appliquer . Voyez les conditions d’utilisation pour plus de détails, ainsi que les
crédits graphiques. En cas de réutilisation des textes de cette page, voyezcomment citer les auteurs et mentionner la
licence.
Wikipedia® est une marque déposée de laWikimedia Foundation, Inc., organisation de bienfaisance régie par le
paragraphe 501(c)(3) du code fiscal des États-Unis.