Modifications des comportements du DNS


Modifications apportées aux serveurs de noms .com/.net/.edu en vue de l'introduction du protocole DNSSEC

Le 1er mars 2010, Verisign a apporté à ses serveurs de noms officiels deux modifications affectant leur comportement pour les zones .com, .net et .edu ([a-m].gtld-servers.net). Ces modifications font partie des conditions préalables au déploiement du protocole DNSSEC dans ces trois zones. Les deux modifications sont les suivantes :
Nouveau comportement en matière de renvois et L'enregistrement "glue" n'accède plus au statut officiel.

Nouveau comportement en matière de renvois 

Par le passé, lorsque les serveurs de noms officiels des zones .com et .net recevaient des requêtes concernant un enregistrement A ou AAAA jouant le rôle d'enregistrement "glue" (enregistrement d'adresse situé au même niveau que les enregistrements NS d'un point de délégation ou à un niveau inférieur), ils renvoyaient l'enregistrement "glue" dans la réponse. Cependant, la réponse n'était pas marquée comme officielle, dans le sens où le bit AA n'était pas défini. Ce comportement était conforme aux normes DNS, mais des serveurs officiels récents ne fonctionnaient pas de cette manière. Ainsi, lorsqu'ils recevaient une requête concernant un nom situé au niveau d'un point de délégation ou à un niveau inférieur, ces serveurs officiels récents répondaient par un renvoi vers la zone déléguée. Ce comportement était également conforme aux normes DNS.

Les serveurs [a-m].gtld-servers.net ont adopté ce dernier comportement de renvoi : les requêtes concernant des enregistrements "glue" génèrent des renvois en lieu et place de réponses non officielles.

Sachez que cette modification influe sur la résolution de certains domaines situés sous .com et .net, et qui dépendent les uns des autres. Par exemple, la configuration suivante des zones interdépendantes "exemple.com" et "exemple.net" fonctionnait parfaitement par le passé :

exemple.com. NS ns1.exemple.net.
exemple.com. NS ns2.exemple.net.

exemple.net. NS ns1.exemple.com.
exemple.net. NS ns2.exemple.com.

Ces deux domaines étaient configurés en cycle : tous les serveurs de exemple.com se trouvaient dans le domaine exemple.net, et tous les serveurs de exemple.net se trouvaient dans le domaine exemple.com. Cette configuration cyclique permettait la résolution des noms, d'une part parce que les serveurs [a-m].gtld-servers.net faisaient autorité pour les zones .com et .net, et d'autre part parce que ces serveurs renvoyaient des requêtes sous forme de réponses non officielles pour les enregistrements "glue" (voir ci-dessus).

Pour mieux comprendre pourquoi cette configuration fonctionnait, examinons la procédure suivie par un résolveur itératif (la partie d'un serveur de noms récursif qui envoie des requêtes) pour résoudre les données faisant partie du domaine "www.exemple.com" :

  • Le résolveur itératif interroge un serveur de noms .com officiel pour "www.exemple.com" et reçoit un renvoi vers "exemple.com" qui référence uniquement les serveurs de noms situés dans "exemple.net".
  • Même si le renvoi inclut des enregistrements A pour "ns1.exemple.net" et "ns2.exemple.net" dans la section additionnelle du message DNS, les résolveurs itératifs modernes ignorent ces enregistrements pour se protéger contre les empoisonnements de cache.
  • Une fois les enregistrements A de "ns1.exemple.net" et "ns2.exemple.net" rejetés, le résolveur itératif dispose de noms pour les serveurs de noms "exemple.com", mais il ne dispose d'aucune adresse. Il doit suspendre provisoirement la requête concernant "www.exemple.com" pour rechercher l'adresse de l'un des serveurs de noms de "exemple.com". Imaginons qu'il choisisse de résoudre "ns1.exemple.net".
  • Enfin, le résolveur itératif interroge un serveur de noms .net officiel pour obtenir les enregistrements A de "ns1.exemple.net". Avec le comportement de renvoi actuel de [a-m].gtld-servers.net, le serveur .net renvoie une réponse non officielle pour l'enregistrement A de "ns1.exemple.net". Le résolveur itératif utilise cette adresse pour contacter ce serveur de noms "exemple.com" et résoudre "www.exemple.com".

Cependant, depuis le 1er mars 2010, le serveur .net ne renvoie plus l'enregistrement A de "ns1.exemple.net", mais génère un renvoi vers "exemple.net". N'oubliez pas que tous les serveurs de noms "exemple.net" se trouvent dans le domaine "exemple.com". Désormais, le résolveur itératif essaie de résoudre "ns1.exemple.net" uniquement pour résoudre la requête initiale, "www.exemple.com", qui elle aussi se trouve bien évidemment dans le domaine "exemple.com". Ainsi, chaque domaine dépendant l'un de l'autre, la résolution ne peut plus fonctionner.

Verisign a créé deux listes de domaines .com et .net susceptibles d'être affectés par ce changement :

Liste 1. Domaines faisant partie d'un cycle

Les domaines figurant dans cette liste sont dépendants les uns des autres, comme expliqué ci-dessus. Par exemple, dans le scénario décrit ci-dessus, "exemple.com" et "exemple.net" figureraient dans la liste 1.

Liste 2. Domaines dépendant exclusivement des domaines faisant partie d'un cycle

Les domaines de cette liste ne font pas partie d'un cycle, contrairement à ceux de la liste 1. En revanche, tous les domaines de la liste 2 utilisent exclusivement des serveurs de noms appartenant à des domaines qui font partie d'un cycle. En d'autres termes, tous les serveurs de noms des domaines figurant dans la liste 2 appartiennent à un ou plusieurs domaines de la liste 1. Pour reprendre l'exemple déjà évoqué, si le domaine "foo.com" possédait les serveurs de noms "ns1.exemple.com" et "ns2.exemple.com", "foo.com" figurerait dans la liste 2.

Si un domaine figure dans l'une des deux listes, la modification du 1er mars nécessite la modification d'au moins un de ses serveurs de noms, de sorte que le cycle soit interrompu (pour les domaines de la liste 1) ou que la dépendance du domaine vis-à-vis d'un cycle soit rompue (pour les domaines de la liste 2).

Retour en haut

L'Enregistrement "glue" n'accède plus au statut officiel 

Dans le système de registre .com/.net, un domaine peut être placé en suspension administrative. Dans ce cas, le domaine n'est plus publié : les enregistrements NS déléguant le domaine sont supprimés de la zone .com ou .net. Par exemple, les registraires placent parfois un domaine en suspension administrative lorsqu'il est sur le point d'expirer et que le détenteur n'a pas répondu aux demandes de renouvellement, ou encore lorsqu'il est utilisé à des fins malveillantes.

Avant le changement du 1er mars 2010, lorsqu'un domaine était placé en suspension administrative, ses enregistrements NS étaient supprimés de la zone, mais les enregistrements A et AAAA des serveurs de noms de ce domaine étaient conservés. Imaginons par exemple que le domaine "exemple.com" figure dans le registre aux côtés du serveur de noms "ns.exemple.com". (Remarque importante : le fait que la zone "exemple.com" utilise ou non "ns.exemple.com" comme serveur de noms officiels n'influe en rien sur le comportement décrit ici. Il convient en revanche de remarquer que "ns.exemple.com" fait partie du domaine "exemple.com", c'est-à-dire qu'il se trouve dessous dans l'espace de noms DNS.)

Précédemment, si le domaine "exemple.com" était placé en suspension administrative, les enregistrements NS le déléguant étaient supprimés de la zone .com. Les enregistrements A et AAAA de "ns.exemple.com" étaient conservés dans la zone. En réalité, puisque ces enregistrements ne se trouvaient plus sous un point de délégation, ils accédaient au statut de données officielles.

Depuis le 1er mars 2010, lorsqu'un domaine est placé en suspension administrative, les enregistrements NS déléguant ce domaine sont supprimés de la zone et les enregistrements A et AAAA des serveurs de noms se trouvant sous le domaine n'accèdent plus au statut officiel. Ces enregistrements A et AAAA ne sont pas réellement supprimés : même s'ils ne sont pas renvoyés lorsqu'ils font l'objet d'une requête directe, ils figurent dans la section additionnelle des renvois qui les référencent.

Dans l'exemple ci-dessus, si "exemple.com" était placé en suspension administrative, ses enregistrements NS seraient supprimés de la zone. Cependant, si le domaine "exemple.net" utilise "ns.exemple.com" comme serveur de noms, la section additionnelle de la réponse de renvoi à "exemple.net" inclura les enregistrements A et AAAA de "ns.exemple.com".

Pour toute question concernant ces changements, contactez le groupe Verisign chargé du service client du registre.

Retour en haut


BESOIN DE PLUS D'INFOS ?

  • +1-703-948-3200