한국   대만   중국   일본 
Domain Name System ? Wikipedia Aller au contenu

Domain Name System

Un article de Wikipedia, l'encyclopedie libre.
Page d’aide sur les redirections

≪ DNS ≫ redirige ici. Pour les autres significations, voir DNS (homonymie) .

Domain Name System

Informations
Fonction Resolution de nom de domaine en adresse IP
Sigle DNS
Port 53
RFC 1983  : RFC  882 [ 1 ] - RFC  883 [ 2 ]
1987  : RFC  1034 [ 3 ] - RFC  1035 [ 4 ]
1994 : RFC  1591 [ 5 ]
2011  : RFC  6195 [ 6 ]
2013  : RFC  6895 [ 7 ]
2018  : RFC  8375 [ 8 ] - RFC  8467 [ 9 ] - RFC  8483 [ 10 ] - RFC  8484 [ 11 ]
2019  : RFC  8499 [ 12 ]

modifier Consultez la documentation du modèle

Le Domain Name System [ 13 ] (Systeme de nom de domaine) ou DNS est un service informatique distribue qui associe les noms de domaine Internet avec leurs adresses IP ou d' autres types d'enregistrements . En fournissant des les premieres annees d'Internet, autour de 1985, un service distribue de resolution de noms, le DNS est un composant essentiel du developpement du reseau informatique .

A la demande de l' agence americaine pour les projets de recherche avancee de defense (DARPA), Jon Postel et Paul Mockapetris concoivent le DNS et en redigent la premiere implementation en 1983 .

Role du DNS [ modifier | modifier le code ]

Les equipements (ou hotes) connectes a un reseau IP, comme Internet , possedent une adresse IP qui les identifie sur le reseau. Ces adresses sont numeriques afin de faciliter leur traitement par les machines. En IPv4 , elles sont representees sous la forme ≪ - - - . - - - . - - - . - - - ≫, ou chaque groupe de trois tirets est substituable par un nombre entre 0 et 255 (en representation decimale ). En IPv6 , les adresses sont representees sous la forme ≪ .... : .... : .... : .... : .... : .... : .... : .... ≫, ou chaque groupe de quatre points est substituable par une valeur hexadecimale de 0000 a FFFF.

Pour faciliter l'acces aux hotes sur un reseau IP, un mecanisme a ete mis en place pour associer un nom a une adresse IP. Ce nom, plus simple a retenir qu'une suite de chiffres, est appele ≪  nom de domaine  ≫. Resoudre un nom de domaine consiste a trouver l'adresse IP qui lui est associee.

En plus des adresses IP, des informations complementaires peuvent etre associees aux noms de domaines comme des enregistrements dans le contexte de la lutte contre le spam ( SPF ), RRSIG pour la securite des informations du DNS ( DNSSEC ) ou NAPTR pour associer des numeros de telephone a des adresses e-mail ( ENUM ).

Histoire [ modifier | modifier le code ]

Article detaille : hosts .

Avant le DNS, la resolution d'un nom sur Internet devait se faire grace a un fichier texte appele HOSTS.TXT ( RFC  608 [ 14 ] ) maintenu par le NIC du Stanford Research Institute et copie sur chaque ordinateur du reseau par transfert de fichier. En 1982, ce systeme centralise montre ses limites et plusieurs propositions de remplacement voient le jour, parmi lesquelles le systeme distribue Grapevine de Xerox et IEN 116 [ 15 ] . Le premier ( Grapevine ) est juge trop complique tandis que le second (IEN 116) est insuffisant [ 16 ] . C’est finalement l’equipe dirigee par Elizabeth Feinler au NIC qui definira le Domain Name System afin de gerer la croissance de l'internet en deleguant la gestion des noms de domaine a des serveurs de noms distribues. Paul Mockapetris publie la conception du systeme dans les RFC  882 [ 1 ] et RFC  883 [ 2 ] en 1983. La norme correspondante est publiee dans les RFC  1034 [ 3 ] et RFC  1035 [ 4 ] en 1987. En 1987, le fichier HOSTS.TXT contenait 5 500 entrees, tandis que 20 000 hotes etaient definis dans le DNS.

Un systeme hierarchique et distribue [ modifier | modifier le code ]

Hierarchie du DNS.
Resolution iterative d'un nom dans le DNS par un serveur DNS (etapes 2 a 7) et reponse (etape 8) suite a l'interrogation recursive (etape 1) effectuee par un client ( resolver ) DNS. (remarque: Le serveur DNS recursif est dit recursif car il accepte ce type de requetes mais il effectue des requetes iteratives)

Hierarchie du DNS [ modifier | modifier le code ]

Le systeme des noms de domaine consiste en une hierarchie dont le sommet est appele la racine . On represente cette derniere par un point. Dans un domaine, on peut creer un ou plusieurs sous-domaines ainsi qu'une delegation pour ceux-ci, c'est-a-dire une indication que les informations relatives a ce sous-domaine sont enregistrees sur un autre serveur. Ces sous-domaines peuvent a leur tour deleguer des sous-domaines vers d'autres serveurs.

Tous les sous-domaines ne sont pas necessairement delegues. Les delegations creent des zones , c'est-a-dire des ensembles de domaines et leurs sous-domaines non delegues qui sont configures sur un serveur determine. Les zones sont souvent confondues avec les domaines.

Les domaines se trouvant immediatement sous la racine sont appeles domaine de premier niveau ( Top Level Domain , TLD). Les noms de domaines ne correspondant pas a une extension de pays sont appeles des domaines generiques (gTLD), par exemple .org ou .com. S'ils correspondent a des codes de pays (fr, be, ch, etc.), ce sont des domaines de premier niveau national , aussi appeles ccTLD de l'anglais country code TLD .

On represente un nom de domaine en indiquant les domaines successifs separes par un point, les noms de domaines superieurs se trouvant a droite. Par exemple, le domaine org. est un TLD, sous-domaine de la racine. Le domaine wikipedia.org. est un sous-domaine de .org . Cette delegation est accomplie en indiquant la liste des serveurs DNS associee au sous-domaine dans le domaine de niveau superieur.

Les noms de domaines sont donc resolus en parcourant la hierarchie depuis le sommet et en suivant les delegations successives, c'est-a-dire en parcourant le nom de domaine de droite a gauche.

Pour qu'il fonctionne normalement, un nom de domaine doit avoir fait l'objet d'une delegation correcte dans le domaine de niveau superieur.

Resolution du nom par un hote [ modifier | modifier le code ]

Les hotes (ordinateurs des utilisateurs finaux) n'ont qu'une connaissance limitee du systeme des noms de domaine. Quand ils doivent resoudre un nom, ils s'adressent a un ou plusieurs serveurs de noms dits recursifs (ou resolveur ) ou bien ils recherchent l'information dans les caches, comme ceux des navigateurs ou bien ceux des resolveurs eux memes.

Il y a deux types de serveurs DNS: les resolveurs (aussi appeles recursifs , bien qu'ils travaillent de maniere iterative) et les serveurs faisant autorite [ 17 ] . Les serveurs DNS recursifs ne font qu'interroger les serveurs faisant autorite. Les serveurs faisant autorite detiennent les informations DNS sur les domaines sur lesquels ils ont autorite.

serveurs faisant autorité
serveurs faisant autorite

Les serveurs recursifs vont parcourir la hierarchie DNS et faire suivre la requete a un ou plusieurs autres serveurs de noms ayant autorite pour fournir une reponse. Les adresses IP de ces serveurs recursifs sont souvent obtenues par l'utilisateur final via DHCP ou encore configures en dur sur la machine hote de l'utilisateur. Les fournisseurs d'acces a Internet mettent a disposition de leurs clients ces serveurs recursifs. Il existe egalement des serveurs recursifs publics comme ceux de Cloudflare , Yandex.DNS , Google Public DNS , OpenNIC ou FDN .

Quand l'ordinateur d'un utilisateur a besoin de charger une page internet de fr.wikipedia.org , il s'adresse d'abord a un serveur recursif pour trouver l'adresse IP (ie l'adresse numerique) de fr.wikipedia.org . Pour trouver l'adresse IP de fr.wikipedia.org , le serveur DNS recursif demarre un processus iteratif pour consulter la hierarchie DNS: Ce serveur demande a des serveurs DNS ayant autorite appeles serveurs racine quels serveurs ont autorite pour la zone org . Parmi ceux fournis dans la reponse, le serveur recursif va en choisir un pour lui demander quels serveurs ont autorite pour la zone wikipedia.org . C'est un de ces derniers qui pourra lui donner l'adresse IP de fr.wikipedia.org . S'il se trouve qu'un serveur ne repond pas, un autre serveur de la liste sera consulte.

Pour optimiser les requetes ulterieures, les serveurs DNS recursifs font aussi office de DNS cache  : ils gardent en memoire ( cache ) la reponse d'une resolution de nom afin de ne pas effectuer ce processus a nouveau ulterieurement. Cette information est conservee pendant une periode nommee Time to live et associee a chaque nom de domaine. Il existe aussi un cache au niveau du navigateur de l'utilisateur et eventuellement de son systeme d'exploitation.

Un nom de domaine peut etre defini, a l'identique, dans plusieurs serveurs DNS ayant autorite. Generalement, 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 autorite pour un domaine, c'est-a-dire que la reponse ne fait pas appel a un autre serveur ou a un cache. Les serveurs recursifs fournissent des reponses qui ne sont pas necessairement a jour, a cause du cache mis en place. On parle alors de reponse ne faisant pas autorite ( non-authoritative answer ).

Cette architecture garantit au reseau Internet une certaine continuite dans la resolution des noms. Quand un serveur DNS tombe en panne, le bon fonctionnement de la resolution de nom n'est pas remis en cause dans la mesure ou des serveurs secondaires sont disponibles.

Resolution inverse [ modifier | modifier le code ]

Pour trouver le nom de domaine associe a une adresse IP, on utilise un principe semblable. Dans un nom de domaine, la partie la plus generale est a droite : org dans fr.wikipedia.org, le mecanisme de resolution parcourt donc le nom de domaine de droite a gauche. Dans une adresse IP V4, c'est le contraire : 213 est la partie la plus generale de 213.228.0.42. Pour conserver une logique coherente, on inverse l'ordre des quatre termes de l'adresse et on la concatene au pseudo domaine in-addr.arpa . Ainsi, pour trouver le nom de domaine de l'adresse IP 91.198.174.2, on resout 2.174.198.91.in-addr.arpa.

La declaration inverse est importante sur les adresses IP publiques Internet puisque l'absence d'une resolution inverse est consideree comme une erreur operationnelle ( RFC  1912 [ 18 ] ) qui peut entrainer le refus d'acces a un service. Par exemple, un serveur de messagerie electronique se presentant en envoi avec une adresse IP n'ayant pas de resolution inverse (PTR) a de grandes chances de se voir refuser, par l'hote distant, la transmission du courrier (message de refus de type : IP lookup failed ).

De plus, cette resolution inverse est importante dans le cadre de la realisation de diagnostics reseaux car c'est elle qui permet de rendre les resultats de la commande traceroute humainement exploitables. Les denominations des noms d'hotes inverses sont souvent des composites de sous-domaines de localisation (ville, region, pays) et de domaines explicites indiquant le fournisseur d'acces Internet traverse comme francetelecom.net (- - - -.nctou202.Toulouse.francetelecom.net) et opentransit.net (- - - -.Aubervilliers.opentransit.net) pour France Telecom , ou encore proxad.net (- - - -.intf.routers.proxad.net) pour Free .

Une adresse IP peut etre associee a differents noms de domaine via l'enregistrement de plusieurs entrees PTR dans le sous-domaine .arpa consacre a cette adresse (in-addr.arpa. pour IPv4 et ip6.arpa. pour IPv6 ). L'utilisation d'enregistrements PTR multiples pour une meme adresse IP est eventuellement presente dans le cadre de l'hebergement virtuel de multiples domaines web derriere la meme adresse IP mais n'est pas recommandee dans la mesure ou le nombre des champs PTR a renvoyer peut faire depasser a la reponse la taille des paquets UDP de reponse et entrainer l'utilisation du protocole TCP (plus couteux en ressources) pour envoyer la reponse a la requete DNS [ 19 ] .

Resolution inverse CIDR [ modifier | modifier le code ]

Les delegations des zones inverses se font sur une frontiere d'octet, ce qui fonctionne quand les blocs d'adresses sont distribues de facon classful mais pose des problemes quand les blocs assignes sont de taille quelconque.

Par exemple, si deux clients A et B disposent chacun des blocs 192.168.0.0/25 et 192.168.0.128/25, il n'est pas possible de deleguer 0.168.192.in-addr.arpa. au premier pour qu'il puisse definir les PTR correspondant a ses hotes, car cela empecherait le second de faire de meme.

La RFC  2317 [ 20 ] a defini une approche pour traiter ce probleme, elle consiste a faire usage de domaines intermediaires et de CNAME. 

$ORIGIN 0.168.192.in-addr.arpa.
0/25 NS ns.clientA.fr.
128/25 NS ns.clientB.fr.

0 CNAME 0.0/25.0.168.192.in-addr.arpa.
1 CNAME 1.0/25.0.168.192.in-addr.arpa.
...
127 CNAME 127.0/25.0.168.192.in-addr.arpa.
128 CNAME 128.128/25.0.168.192.in-addr.arpa.
...
255 CNAME 255.128/25.0.168.192.in-addr.arpa.

Le client A definit la zone 0/25.0.168.192.in-addr.arpa. : 

$ORIGIN 0/25.0.168.192.in-addr.arpa.
1 PTR hote1.clientA.fr.
...
127 PTR hote127.clientA.fr.

Le client B fait de meme pour 128/25.0.168.192.in-addr.arpa. et les adresses 128 a 255.

La resolution inverse de 192.168.0.1 aboutira aux requetes suivantes : 

1.0.168.192.in-addr.arpa. CNAME 1.0/25.0.168.192.in-addr.arpa.
1.0/25.0.168.192.in-addr.arpa. PTR hote1.clientA.fr.

Ce qui assure le fonctionnement de la resolution inverse, moyennant un niveau d'indirection supplementaire.

Serveurs DNS racine [ modifier | modifier le code ]

Article detaille : Serveur racine du DNS .

Les serveurs racine sont geres par douze organisations differentes : deux sont europeennes, une japonaise et les neuf autres sont americaines. Sept de ces serveurs sont en realite distribues dans le monde grace a la technique anycast et neuf disposent d'une adresse IPv6 [ 21 ] . Grace a anycast, plus de 200 serveurs repartis dans 50 pays du monde assurent ce service [ 22 ] . Il existe 13 autorites de nom appelees de a a m.root-servers.net. Le serveur k recoit par exemple de l'ordre de 70 000 a 100 000 requetes par seconde en [ 23 ] .

Le DNS ne fournit pas de mecanisme pour decouvrir la liste des serveurs racine , chacun des serveurs doit donc connaitre cette liste au demarrage grace a un encodage explicite. Cette liste est ensuite mise a jour en consultant l'un des serveurs indiques. La mise a jour de cette liste est peu frequente de facon que les serveurs anciens continuent a fonctionner.

Fully Qualified Domain Name [ modifier | modifier le code ]

Article detaille : Fully qualified domain name .

On entend par Fully Qualified Domain Name (FQDN, Nom de domaine pleinement qualifie) un nom de domaine ecrit de facon absolue, y compris tous les domaines jusqu'au domaine de premier niveau (TLD), il est ponctue par un point final, par exemple fr.wikipedia.org.

La norme prevoit qu'un element d'un nom de domaine (appele label ) ne peut depasser 63 caracteres, un FQDN ne pouvant depasser 253 caracteres.

Nom de domaine internationalise [ modifier | modifier le code ]

Article detaille : Nom de domaine internationalise .

Dans leur definition initiale, les noms de domaines sont constitues des caracteres de A a Z (sans difference de casse  : les lettres capitales ne sont pas differenciees), de chiffres et du trait d'union.

La RFC  3490 [ 24 ] definit un format appele Punycode qui permet l'encodage d'un jeu de caractere plus etendu.

Les techniques du DNS Round-Robin pour la distribution de la charge [ modifier | modifier le code ]

Article detaille : DNS round-robin .

Lorsqu'un service genere un trafic important, celui-ci peut faire appel a la technique du DNS Round-Robin (tourniquet DNS), une des techniques de repartition de charge qui consiste a associer plusieurs adresses IP a un FQDN . Les differentes versions de Wikipedia, comme fr.wikipedia.org par exemple, sont associees a 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 renvoyees sera modifie d'une requete a la suivante. Une rotation circulaire entre ces differentes adresses permet ainsi de repartir la charge generee par ce trafic important entre les differentes machines ayant ces adresses IP. Il faut cependant nuancer cette repartition car elle n'a lieu qu'a la resolution du nom d'hote et reste par la suite en cache sur les differents resolvers (client DNS).

Principaux types d'enregistrements DNS [ modifier | modifier le code ]

Article detaille : Liste des enregistrements DNS .

Le type d'enregistrement de ressource (RR, Resource Record ) est code sur 16 bits [ 25 ] , l' IANA conserve le registre des codes assignes [ 26 ] . Les principaux types d'enregistrements definis sont les suivants :

  • A record ou address record (egalement appele enregistrement d’hote ) qui fait correspondre un nom d'hote ou un nom de domaine ou un sous-domaine a une adresse IPv4 de 32 bits distribues sur quatre octets ex: 123.234.1.2 ;
  • AAAA record ou IPv6 address record qui fait correspondre un nom d'hote a une adresse IPv6 de 128 bits distribues sur seize octets ;
  • CNAME record ou canonical name record qui permet de faire un alias d'un domaine vers un autre.
  • MX record ou mail exchange record qui definit les serveurs de courriel pour ce domaine ;
  • PTR record ou pointer record qui associe une adresse IP a 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 definit les serveurs DNS de ce domaine ;
  • SOA record ou Start Of Authority record qui donne les informations generales de la zone : serveur principal, courriel de contact, differentes durees dont celle d'expiration, numero de serie de la zone ;
  • SRV record qui generalise la notion de MX record , mais qui propose aussi des fonctionnalites avancees comme le taux de repartition de charge pour un service donne, standardise dans la RFC  2782 [ 27 ]  ;
  • NAPTR record ou Name Authority Pointer record qui donne acces a des regles de reecriture de l'information, permettant des correspondances assez laches entre un nom de domaine et une ressource. Il est specifie dans la RFC  3403 [ 28 ]  ;
  • TXT record permet a un administrateur d'inserer un texte quelconque dans un enregistrement DNS (par exemple, cet enregistrement est utilise pour implementer la specification Sender Policy Framework ) ;
  • d'autres types d'enregistrements sont utilises occasionnellement, ils servent simplement a donner des informations (par exemple, un enregistrement de type LOC indique l'emplacement physique d'un hote, c'est-a-dire sa latitude et sa longitude). Certaines personnes [Qui ?] disent que cela aurait un interet majeur mais n'est que tres rarement utilise sur le monde Internet.

NS record [ modifier | modifier le code ]

L'enregistrement NS cree une delegation d'un sous-domaine vers une liste de serveurs.

Dans la zone org , les enregistrements NS suivants creent le sous-domaine wikipedia et deleguent celui-ci vers les serveurs indiques.

L'ordre des serveurs est quelconque. Tous les serveurs indiques doivent faire autorite pour le domaine. 

wikipedia NS ns1.wikimedia.org.
wikipedia NS ns2.wikimedia.org.
wikipedia NS ns0.wikimedia.org.

PTR record [ modifier | modifier le code ]

A l'inverse d'une entree de type A ou AAAA, une entree PTR indique a quel nom d'hote correspond une adresse IPv4 ou IPv6 . Si elle est specifiee, elle doit contenir l'enregistrement inverse d'une entree DNS A ou AAAA.

Par exemple (pour une adresse IPv4 ) cet enregistrement PTR : 

232.174.198.91.in-addr.arpa. IN PTR text.esams.wikimedia.org.

correspond a cette entree A : 

text.esams.wikimedia.org. IN A 91.198.174.232

Dans le cas d'une adresse IPv6 , les entrees de type PTR sont enregistrees dans la zone ip6.arpa. (pendant de la zone in-addr.arpa. des adresses IPv4 ).

La regle permettant de retrouver l'entree correspondant a une adresse IPv6 est similaire a celle pour les adresses IPv4 (renversement de l'adresse et recherche dans un sous-domaine dedie de la zone arpa.), mais differe au niveau du nombre de bits de l'adresse utilises pour rediger le nom du domaine ou rechercher le champ PTR : la ou pour IPv4 le decoupage de l'adresse se fait par octet, pour IPv6 c'est un decoupage par quartet qui est utilise.

Par exemple a 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 | modifier le code ]

Une entree DNS MX indique les serveurs SMTP a contacter pour envoyer un courriel a un utilisateur d'un domaine donne. Par exemple : 

wikimedia.org. IN MX 10 mchenry.wikimedia.org.
wikimedia.org. IN MX 50 lists.wikimedia.org.

On voit que les courriels envoyes a une adresse en @wikimedia.org sont envoyes au serveur mchenry.wikimedia.org. ou lists.wikimedia.org. Le nombre precedant le serveur represente la priorite. Le serveur avec la priorite numerique la plus petite est employe en priorite. Ici, c'est donc mchenry.wikimedia.org. qui doit etre utilise en premier, avec une valeur de 10.

Les serveurs indiques doivent avoir ete configures pour accepter de relayer les courriers pour le nom de domaine indique. Une erreur courante consiste a 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 emetteurs conservant les messages pendant un temps determine (typiquement, plusieurs jours) jusqu'a ce que le serveur primaire soit a nouveau disponible.

Les entrees MX sont generalisees par les entrees SRV qui permettent de faire la meme chose mais pour tous les services, pas seulement SMTP (le courriel). L'avantage des entrees SRV par rapport aux entrees MX est aussi qu'elles permettent de choisir un port arbitraire pour chaque service ainsi que de faire de la repartition de charge plus efficacement. L'inconvenient c'est qu'il existe encore peu de programmes clients qui gerent les entrees SRV. Cependant, depuis 2009, avec l'augmentation de l'utilisation du protocole SIP sur les services de VoIP , les enregistrements SRV deviennent plus frequents dans les zones DNS.

CNAME record [ modifier | modifier le code ]

L'enregistrement CNAME permet de creer 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 [ 3 ] section 3.6.2, RFC  1912 [ 18 ] section 2.4), c'est-a-dire qu'on ne peut avoir a la fois un CNAME et un A record pour le meme 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 eviter les boucles infinies du type 

fr.wikipedia.org. IN CNAME text.wikimedia.org.
text.wikipedia.org. IN CNAME fr.wikimedia.org.

les specifications ( RFC  1034 [ 3 ] section 3.6.2, RFC  1912 [ 18 ] 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 preferablement enregistre de la facon 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 | modifier le code ]

Peu repandus a l'heure actuelle (ils sont surtout utilises par ENUM ), ils decrivent une reecriture d'une cle (un nom de domaine) en URI . Par exemple, dans ENUM, des enregistrements NAPTR peuvent etre utilises pour trouver l'adresse de courrier electronique d'une personne, connaissant son numero de telephone (qui sert de cle a ENUM).

Ses parametres sont dans l'ordre :

  1. Order  : indique dans quel ordre evaluer les enregistrements NAPTR ; tant qu'il reste des enregistrements d'une certaine valeur de order a examiner, les enregistrements des valeurs suivantes de order n'entrent pas en consideration ;
  2. Preference  : donne une indication de priorite relative entre plusieurs enregistrements NAPTR qui ont la meme valeur de order  ;
  3. Flags  : indique par exemple si l'enregistrement decrit une reecriture transitoire (dont le resultat est un nom de domaine pointant sur un autre enregistrement NAPTR) ou une reecriture finale ; la semantique precise du parametre flags depend de l'application DDDS ('Dynamic Delegation Discovery System', RFC  3401 [ 29 ] ) employee ( ENUM en est une parmi d'autres) ;
  4. Services  : decrit le service de reecriture ; par exemple dans ENUM , la valeur de services specifie le type de l' URI resultante ; la semantique precise de ce parametre depend egalement de l'application DDDS employee ;
  5. Regexp  : l'operation de reecriture elle-meme, formalisee en une expression rationnelle  ; cette expression rationnelle est a appliquer a la cle ; ne peut etre fourni en meme temps que replacement  ;
  6. Replacement  : nom de domaine pointant sur un autre enregistrement NAPTR, permettant par exemple une reecriture transitoire par delegation ; ne peut etre fourni en meme temps que regexp .

L'enregistrement NAPTR est defini par la RFC  3403 [ 28 ] .

SOA record [ modifier | modifier le code ]

Article detaille : SOA Resource Record .

Cet enregistrement permet d'indiquer le serveur de nom maitre (primaire), l'adresse e-mail d'un contact technique (avec @ remplace par un point) et des parametres d'expiration.

Il designe l'autorite ( start of authority ) ou le responsable de la zone dans la hierarchie DNS. C'est l'acte de naissance de la zone DNS.

Ces parametres sont dans l'ordre : 

wikipedia.org. IN SOA ns0.wikimedia.org. hostmaster.wikimedia.org. 2010060311 43200 7200 1209600 3600
  1. Serial  : indique un numero de version pour la zone (32 bits non signe). Ce nombre doit etre incremente a chaque modification du fichier zone ; on utilise par convention une date au format ≪ yyyymmddnn ≫ (≪ yyyy ≫ pour l'annee sur 4 chiffres, ≪ mm ≫ pour le mois sur 2 chiffres, ≪ dd ≫ pour le jour sur 2 chiffres, ≪ nn ≫ pour un compteur de revision si le numero de serie est modifie plusieurs fois dans un meme jour. Cette convention evite tout debordement du 32 bits non signe jusqu'en l'an 4294) ;
  2. Refresh  : l'ecart en secondes entre les demandes successives de mise a jour realisees depuis le serveur secondaire ou les serveurs esclaves ;
  3. Retry  : le delai en secondes que doivent attendre le serveur secondaire ou les serveurs esclaves lorsque leur precedente requete a echoue ;
  4. Expire  : le delai en secondes au terme duquel la zone est consideree comme invalide si le secondaire ou les esclaves ne peuvent joindre le serveur primaire ;
  5. Minimum ou negative TTL  : utilise pour specifier, en secondes, la duree de vie pendant laquelle sont conservees en cache les reponses qui correspondent a des demandes d'enregistrements inexistants.

Les versions recentes 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 | modifier le code ]

Chaque enregistrement est associe a un Time To Live (TTL) qui determine combien de temps il peut etre conserve dans un serveur cache . Ce temps est typiquement d'un jour (86400 s) mais peut etre plus eleve pour des informations qui changent rarement, comme des records NS. Il est egalement possible d'indiquer que des informations ne doivent pas etre mises en cache en specifiant un TTL de zero.

Certaines applications, comme des navigateurs web disposent egalement d'un cache DNS, mais qui ne respecte pas necessairement le TTL du DNS. Ce cache applicatif est generalement de l'ordre de la minute, mais Internet Explorer par exemple conserve les informations jusqu'a 30 minutes [ 30 ] , independamment du TTL configure.

Glue records [ modifier | modifier le code ]

Quand un domaine est delegue a un serveur de noms qui appartient a ce sous-domaine, il est necessaire de fournir egalement l'adresse IP de ce serveur pour eviter les references circulaires. Ceci deroge au principe general selon lequel l'information d'un domaine n'est pas dupliquee ailleurs dans le DNS.

Par exemple, dans la reponse 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 necessaire de fournir egalement les adresses IP des serveurs indiques dans la reponse ( glue records [ 31 ] ), 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 a jour dynamique [ modifier | modifier le code ]

Une extension du DNS nommee DNS dynamique (DDNS) permet a un client de mettre a jour une zone avec des informations qui le concernent ( RFC  2136 [ 32 ] ). Ceci est utile quand des clients obtiennent une adresse IP par DHCP et qu'ils souhaitent que le DNS reflete le nom reel de la machine.

Considerations operationnelles [ modifier | modifier le code ]

Mise a jour du DNS [ modifier | modifier le code ]

Les mises a jour se font sur le serveur primaire du domaine, les serveurs secondaires recopiant les informations du serveur primaire dans un mecanisme appele transfert de zone . Pour determiner si un transfert de zone doit avoir lieu, le serveur secondaire consulte le numero de version de la zone et le compare a la version qu'il possede. Le serveur primaire determine a quelle frequence le numero de version est consulte. Quand un changement est effectue, les serveurs envoient des messages de notification aux serveurs secondaires pour accelerer le processus.

Il se peut que des informations qui ne sont plus a jour soient cependant conservees dans des serveurs cache. Il faut alors attendre l'expiration de leur TTL pour que ces informations cachees disparaissent et donc que la mise a jour soit pleinement effective. On peut minimiser le temps necessaire en diminuant le TTL associe aux noms de domaines qui vont etre modifiees prealablement a une operation de changement.

Coherence du DNS [ modifier | modifier le code ]

Quand la liste des serveurs de noms change, ou quand une adresse IP qui fait l'objet d'un Glue Record est modifiee, le gestionnaire du domaine de niveau superieur doit effectuer la mise a jour correspondante.

Robustesse du DNS [ modifier | modifier le code ]

Pour eviter les points individuels de defaillance , on evite de partager l'infrastructure entre les serveurs qui font autorite. Un serveur secondaire sera de preference delocalise et route differemment du serveur primaire.

Bien que cela soit techniquement possible, on evite de meler sur un meme serveur le role de DNS recursif et celui de serveur qui fait autorite.

De meme, un hote sera configure avec plusieurs serveurs recursifs, de sorte que si le premier ne repond pas a la requete, le suivant sera employe. En general, les serveurs recursifs fournis par les FAI refusent les requetes emanant d'adresses IP appartenant a d'autres FAI.

Il existe des services de DNS recursifs ouverts, c'est-a-dire qu'ils acceptent les requetes de tous les clients. Il est donc possible a un utilisateur de configurer ceux-ci en lieu et place de ceux fournis par le FAI. Ceci pose cependant les problemes suivants :

  • il n'y a pas de garantie que les reponses fournies seront les memes qu'avec des serveurs recursifs habituels. Un tel service pourrait en effet faire reference a une autre hierarchie depuis la racine, disposer de TLD additionnels non standard, restreindre l'acces a certains domaines, voire alterer certains records avant leur transmission au client ;
  • il n'y a pas de garantie de confidentialite, c'est-a-dire que ce service pourrait determiner a quels domaines un utilisateur a acces en conservant des traces des requetes DNS.

Securite du DNS [ modifier | modifier le code ]

Le protocole DNS a ete concu avec un souci minimum de la securite. Plusieurs failles de securite du protocole DNS ont ete identifiees depuis. Les principales failles du DNS ont ete decrites dans le RFC  3833 [ 33 ] publie en .

Interception des paquets [ modifier | modifier le code ]

Une des failles mises en avant est la possibilite d'intercepter les paquets transmis. Les serveurs DNS communiquent au moyen de paquets uniques et non signes. Ces deux specificites rendent l'interception tres aisee. L'interception peut se concretiser de differentes manieres, notamment via une attaque de type ≪ man in the middle ≫, de l'ecoute des donnees transferees et de l'envoi de reponse falsifiee (voir paragraphe ci-dessous).

Fabrication d'une reponse [ modifier | modifier le code ]

Les paquets des serveurs DNS etant faiblement securises, authentifies par un numero de requete, il est possible de fabriquer de faux paquets. Par exemple, un utilisateur qui souhaite acceder au site http://mabanque.example.com fait une demande au site DNS. Il suffit, a ce moment, qu'un pirate informatique reponde a la requete de l'utilisateur avant le serveur DNS pour que l'utilisateur se retrouve sur un site d' hameconnage .

Corruption des donnees [ modifier | modifier le code ]

La trahison par un serveur, ou corruption de donnees, est, techniquement, identique a une interception des paquets. La seule difference venant du fait que l'utilisateur envoie volontairement sa requete au serveur. Cette situation peut arriver lorsque, par exemple, l'operateur du serveur DNS souhaite mettre en avant un partenaire commercial.

Empoisonnement du cache DNS [ modifier | modifier le code ]

Article detaille : empoisonnement du cache DNS .

L'empoisonnement du cache DNS ou pollution de cache DNS (en anglais, DNS Cache Poisoning ) est une technique permettant de leurrer les serveurs DNS afin de leur faire croire qu'ils recoivent une requete valide tandis qu'elle est frauduleuse [ 34 ] .

Deni de service [ modifier | modifier le code ]

Article detaille : Deni de service .

Une attaque par deni de service, ou attaque par saturation, (en anglais, Denial of Service attack ou DoS attack ) est une attaque sur un serveur informatique qui resulte en l'incapacite pour le serveur de repondre aux requetes de ses clients.

DNSSEC [ modifier | modifier le code ]

Article detaille : DNSSEC .

Pour contrer les vulnerabilites dues a la corruption des donnees, l'empoisonnement de cache DNS, etc., le protocole DNSSEC ( RFC  4033 [ 35 ] , RFC  4034 [ 36 ] , RFC  4035 [ 37 ] ) a ete developpe. Il utilise les principes de cryptographie asymetrique et de signature numerique pour garantir l'integrite des donnees, ainsi qu'une preuve de non-existence si l'enregistrement demande n'existe pas. La zone racine du DNS a ete signee le [ 38 ] , et le deploiement de DNSSEC sur les TLD continue, une liste des domaines couverts etant disponible.

Chiffrement [ modifier | modifier le code ]

Depuis 2015 [ 39 ] , l' Internet Engineering Task Force (IETF) travaille a la securite du canal de communication du DNS (la ou DNSSEC protege les donnees). Cela a debouche sur la publication de plusieurs RFC permettant l'utilisation de TLS afin de chiffrer la communication entre les clients DNS et les resolveurs. Il s'agit principalement de : DNS sur TLS ( RFC  7858 [ 40 ] , utilisant le port 853) et DNS sur HTTPS ( RFC  8484 [ 11 ] , requete DNS encapsulee dans une requete HTTP , et traitee par un serveur web).

Il n'y a pas, en 2018, de possibilites de chiffrer ? via TLS ? les communications entre un resolveur et un serveur faisant autorite.

Exemple d'attaques majeures contre des serveurs DNS [ modifier | modifier le code ]

En , quelques jours apres la publication du rapport de la United States Computer Emergency Readiness Team concernant la faille de securite des serveurs DNS permettant d'empoisonner leur cache, plusieurs serveurs DNS majeurs ont subi des attaques. Une des plus importantes fut celle menee 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 requetes de Google vers un site d' hameconnage [ 41 ] .

Details du protocole [ modifier | modifier le code ]

DNS utilise en general UDP et le port 53. La taille maximale des paquets utilisee est de 512 octets. Si une reponse depasse cette taille, la norme prevoit que la requete doit etre renvoyee sur le port TCP 53. Ce cas est cependant rare et evite, et les firewalls bloquent souvent le port TCP 53.

L'extension EDNS 0 ( RFC  2671 [ 42 ] ) permet d'utiliser une taille de paquets plus elevee, sa prise en charge est recommandee pour IPv6 comme pour DNSSEC.

La norme prevoit qu'il existe une classe associee aux requetes. Les classes IN (Internet), CH (Chaos) et HS ( Hesiod   (en) ) sont definies, seule la classe IN etant reellement utilisee en pratique. La classe chaos est utilisee par BIND pour reveler le numero de version [ 43 ] .

Exemples de consultation DNS [ modifier | modifier le code ]

Pour verifier l'association entre un nom et une adresse IP, plusieurs commandes sont disponibles suivant les systemes d'exploitation utilises.

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

> nslookup www.google.fr
Serveur : Livebox-6370
Address: 192.168.1.1

Reponse ne faisant pas autorite :
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

ou encore dig sur les systemes compatibles avec UNIX  : 

> 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

Exemples d'adresses de serveurs DNS [ modifier | modifier le code ]

Cloudflare  : 1.1.1.1

Google Public DNS  : 8.8.8.8

OpenDNS  : 208.67.222.222

Quad9  : 9.9.9.9

Notes et references [ modifier | modifier le code ]

  1. ↑ a et b (en) Request for comments n o  882
  2. ↑ a et b (en) Request for comments n o  883
  3. ↑ a b c et d (en) Request for comments n o  1034
  4. ↑ a et b (en) Request for comments n o  1035
  5. ↑ (en) Request for comments n o  1591
  6. ↑ (en) Request for comments n o  6195
  7. ↑ (en) Request for comments n o  6895
  8. ↑ (en) Request for comments n o  8375
  9. ↑ (en) Request for comments n o  8467
  10. ↑ (en) Request for comments n o  8483
  11. ↑ a et b (en) Request for comments n o  8484
  12. ↑ (en) Request for comments n o  8499
  13. ↑ What is DNS? | How DNS works | Cloudflare
  14. ↑ (en) Request for comments n o  608
  15. ↑ IEN 116 Internet Name Server , Jon Postel 1979
  16. ↑ Development of the Domain Name System , Paul Mockapetris , Kevin Dunlap, Sigcomm 1988
  17. ↑ ≪  serveur faisant autorite  ≫, sur bortzmeyer.org (consulte le )
  18. ↑ a b et c (en) Request for comments n o  1912
  19. ↑ Voir la section 4.4 Usage and deployment considerations du draft draft-ietf-dnsop-reverse-mapping-considerations
  20. ↑ (en) Request for comments n o  2317
  21. ↑ (en) ≪  named.root  ≫, sur www.internic.net
  22. ↑ ≪  Root Server Technical Operations Assn  ≫, sur root-servers.org (consulte le )
  23. ↑ k statistics
  24. ↑ (en) Request for comments n o  3490
  25. ↑ RFC  1035, chapitre 3.2.1
  26. ↑ ≪  Domain Name System (DNS) Parameters  ≫, sur www.iana.org (consulte le )
  27. ↑ (en) Request for comments n o  2782
  28. ↑ a et b (en) Request for comments n o  3403
  29. ↑ (en) Request for comments n o  3401
  30. ↑ ≪  Comment Internet Explorer utilise le cache pour les entrees d’hote DNS  ≫, sur support.microsoft.com (consulte le )
  31. ↑ ≪  Glue Records (enregistrements Glue) ? Documentation Documentation Gandi  ≫, sur docs.gandi.net (consulte le )
  32. ↑ (en) Request for comments n o  2136
  33. ↑ (en) Request for comments n o  3833
  34. ↑ (en) ≪  Multiple DNS implementations vulnerable to cache poisoning  ≫, sur www.kb.cert.org (consulte le )
  35. ↑ (en) Request for comments n o  4033
  36. ↑ (en) Request for comments n o  4034
  37. ↑ (en) Request for comments n o  4035
  38. ↑ (en-US) ≪  Root DNSSEC  ≫ (consulte le )
  39. ↑ ≪  Dprive Status Pages  ≫, sur tools.ietf.org (consulte le )
  40. ↑ (en) Request for comments n o  7858
  41. ↑ (en) ≪  DNS Attack Writer a Victim of His Own Creation  ≫, sur PCWorld , (consulte le )
  42. ↑ (en) Request for comments n o  2671
  43. ↑ dig CH @k.root-servers.net version.bind txt

Voir aussi [ modifier | modifier le code ]

Sur les autres projets Wikimedia :

Articles connexes [ modifier | modifier le code ]

Liens externes [ modifier | modifier le code ]

Bases de donnees et dictionnaires [ modifier | modifier le code ]


v  · m
7. Application
6. Presentation
5. Session
4. Transport
3. Reseau
2. Liaison
1. Physique
v  · m
Officiel
Non-officiel
Ce document provient de ≪  https://fr.wikipedia.org/w/index.php?title=Domain_Name_System&oldid=214742190  ≫.