Comité consultatif du système des serveurs racine (RSSAC)
En plus des langues de l’ICANN, ce contenu est aussi disponible en
Foire aux questions du RSSAC
Cette page apporte des réponses à bon nombre des questions les plus fréquemment posées sur le Comité consultatif du système des serveurs racine (RSSAC). Elle sera mise à jour dès que les réponses changeront ou que de nouvelles questions deviendront fréquentes.
Si vous avez une question qui ne figure pas ci-dessous, ou si vous voulez obtenir des informations ou des précisions, n’hésitez pas à écrire directement à [email protected]. Si vous souhaitez évoquer une question de cette foire aux questions, veuillez inclure le numéro et le titre de la question dans votre e-mail. Les opérateurs du serveur racine ont également une foire aux questions.
Index thématique
1 Nombre de serveurs racine
1.1 Pourquoi y a-t-il 13 serveurs de noms racine ?
En 1985, il existait quatre serveurs racine. Entre 1987 et 1991, on en comptait sept, tous situés aux États-Unis. En 1993, leur nombre s’élevait à huit. C’est à ce moment-là qu’un problème est survenu. Le document RFC 1035 stipule que « les messages du [DNS] portés par UDP sont limités à 512 octets ». Ajouter plus de serveurs de noms racine engendrerait une réponse initiale dépassant les 512 octets. Le document RFC 1035 ne fournit pas de justification à la limite de 512 octets, mais il convient de noter qu’à l’époque il existait une norme commune imposant aux paquets IP sur Internet d’être limités à 576 octets.
Les opérateurs de serveurs racine (RSO) se sont rendu compte que la compression de noms du DNS leur permettrait d’ajouter un plus grand nombre de serveurs racine. Ainsi, il a été proposé d’attribuer des noms aux serveurs racine dans la zone root-servers.net. En 1995, les neuf serveurs racine en fonctionnement ont été renommés « a.root-servers.net », « b.root-servers.net », et ainsi de suite. En 1997, quatre autres serveurs racine ont été ajoutés, portant à 13 le nombre total d’identificateurs de serveur racine (RSI).
Jusqu’en 1998, c’était Jon Postel, en sa qualité d’administrateur de l’IANA, qui se chargeait de désigner les RSO. Après son décès en 1998, le nombre d’opérateurs n’a pas changé, bien qu’un petit nombre d’entre eux ait changé de mains au fil des années.
Depuis 1998, le paysage a changé à plusieurs égards. Chaque serveur racine a ajouté sa propre adresse IPv6, et l’ICANN a signé la zone avec les extensions de sécurité du DNS (DNSSEC). De même, la taille des messages transmis sur UDP a augmenté à l’aide des mécanismes d’extension de protocole DNS (EDNS). Ces évolutions ont rendu la limite de 512 octets pour UDP et la limite de 13 RSI beaucoup moins importantes.
En 2002, l’Internet Software Consortium (ISC, désormais Internet Systems Consortium) est devenu le premier RSO à déployer l’adresse IP anycast, même si le projet WIDE avait déjà expérimenté cette technologie. Au fil des années, les autres RSO en ont fait de même. Anycast permet aux opérateurs de fournir le service à partir de multiples instances distinctes. Même si à l’heure actuelle on compte toujours 13 RSI, il y a en fait plus de 1 500 instances anycast en activité à travers le monde.
Pour mieux comprendre l’histoire du système des serveurs racine (RSS), veuillez consulter le document RSSAC023v2 : Histoire du système des serveurs racine. Si vous souhaitez en savoir plus sur l’évolution continue du RSS, veuillez consulter le document RSSAC037 : Proposition de modèle de gouvernance pour le système des serveurs racine du DNS.
1.2 Quelle était la logique derrière la limite de 13 identificateurs de serveurs racine ?
En 1997, les serveurs racine faisaient également office de serveurs faisant autorité pour les zones .COM, .NET et .ORG. Cette fonction supplémentaire limitait considérablement le nombre potentiel de RSI. Tout comme pour la requête initiale (priming) adressée à la zone racine, les requêtes envoyées au NS RRSET pour les zones .COM, .NET et .ORG ne pouvaient pas dépasser la limite de 512 octets, et comme les mêmes serveurs desservaient ces zones, la même limitation s’y appliquait.
Un paquet de réponses DNS contient aussi l’intégralité de la question posée dans la section Question. Une réponse à une requête initiale envoyée à la racine utilisera toujours 5 octets pour la section Question. Le QNAME utilise 1 octet, le QTYPE et le QCLASS utilisent chacun 2 octets, ce qui fait un total de 5 octets. Or, pour une requête initiale .COM, la taille de la section Question pourrait être bien plus grande.
| Objet |
Tableau 1 : explication du nombre d’octets utilisés dans la réponse initiale de la racine
Avec 435 octets utilisés, il en reste 77 disponibles pour QNAME dans la section Question. À l’époque, il avait été déterminé que 64 octets seraient suffisants pour la plupart des requêtes envoyées à .COM, .NET et .ORG. L’ajout d’un autre serveur nécessiterait 25 octets, et puisque 435 + 64 + 25 > 512, il a été décidé de ne pas le faire.
2 Anycast
2.1 Pourquoi certains opérateurs possèdent de nombreuses instances anycast alors que d’autres n’en ont qu’une poignée ?
Les RSO sont des organisations indépendantes avec des mandats, des modèles opérationnels et des sources de financement différents. Ces différences peuvent avoir un impact sur leur nombre d’instances anycast ainsi que sur d’autres choix opérationnels. Les RSO choisissent en toute indépendance la manière dont ils souhaitent déployer leur réseau. Voir le document RSSAC042 : Déclaration du RSSAC sur l’indépendance des opérateurs de serveurs racine. Tous les RSO s’engagent à fournir un service DNS racine de grande qualité.
2.2 Le nombre de nœuds anycast est-il illimité ou bien soumis à des contraintes de nombre ?
Le fonctionnement anycast est défini et décrit dans le document RFC 4786 « Fonctionnement des services d’envoi à la cantonade » et dans le document RFC 7094 « Considérations architecturales sur l’envoi IP à la cantonade ». Il n’y a pas de limite intrinsèque au nombre de nœuds dans un service anycast.
2.3 Les serveurs racine reproduisent la zone racine faisant autorité et la republient ; ensuite, les instances anycast republient les données des serveurs. Quelle est la différence entre ces deux types de republication ?
Les RSO reçoivent les données de la zone faisant autorité du responsable de la maintenance de la zone racine (RZM). Chaque RSO utilise alors son propre système de distribution interne afin de transmettre la zone à l’ensemble de ses sites et instances anycast.
2.4 Nous hébergeons une instance anycast d’un serveur racine dans une ville locale. Nous observons qu’elle répond à des requêtes des quatre coins de la planète. Que doit-on faire pour qu’elle ne réponde qu’à des requêtes provenant de la région ?
Cela dépend du routage IP et de la façon dont le RSO exploite son service anycast. Certains RSO configurent leurs routeurs et leurs sessions d’appairage de manière à ce l’instance anycast ne reçoive que du trafic local. D’autres les configurent pour recevoir le trafic global, en s’appuyant sur le système de routage pour choisir le meilleur chemin d’accès au réseau. Si vous observez des comportements indésirables de la part d’un serveur hébergé, n’hésitez pas à en discuter avec le RSO assurant le service.
2.5 En 2016, Dyn a été la cible d’une cyberattaque de grande envergure. L’ensemble des instances anycast du serveur racine pourraient-elles subir une attaque du même type ?
Oui, au moins en théorie. C’est l’une des raisons pour lesquelles le RSS a de nombreuses instances du serveur racine. Un nombre élevé d’instances anycast augmente la capacité du RSS, ce qui est certainement utile en cas d’attaque. Bien que le système des serveurs racine ait été attaqué globalement dans le passé, aucune attaque n’a jamais réussi à arrêter l’ensemble du système.
2.6 Comme demander une instance anycast d’un serveur racine pour mon organisation ?
Veuillez contacter directement les opérateurs de serveurs racine dont les coordonnées sont indiquées ci-dessous. De la même façon que pour la question 3.4, vous pouvez aussi envisager d’exploiter une copie locale de la zone racine, tel que décrit dans le document RFC 8806, sans faire officiellement partie du système anycast des serveurs racine.
Le Registre des adresses Internet d’Amérique latine et des Caraïbes (LACNIC) a également un projet appelé +Raices pour promouvoir l’installation d’instances de serveur racine anycast dans les pays de la région LACNIC. Pour en savoir plus, cliquez ici.
| Opérateur de serveur racine |
Tableau 2 : informations de contact pour demander des instances anycast
2.7 Comment puis-je savoir quelle instance d’une identité de serveur racine répond à mes requêtes ?
Vous pouvez utiliser l’utilitaire « dig » depuis un système informatique Unix ou Mac pour envoyer des requêtes spéciales à une identité de serveur racine. La réponse indiquera quel site anycast a reçu la requête.
Vous pouvez utiliser l’option NSID dans votre requête, et vérifier ensuite la chaîne NSID qui s’affiche dans la pseudo-section OPT du résultat dig :
$ dig +nsid @a.root-servers.net
…
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
; NSID: 6e 33 2e 75 73 2d 77 61 73 2e 72 6f 6f 74 ("n3.us-was.root")
…
Chaque identité de serveur racine est libre de choisir son propre schéma de dénomination de site anycast, mais généralement les sites sont nommés à l’aide des codes d’aéroport IATA ou UN/LOCODE. Certaines identités de serveur racine publient leurs conventions de dénomination de site dans la section « identificateurs » de leurs fichiers YAML respectifs, disponibles sur https://root-servers.org/.
3. DNS et réseau
3.1 Comment les serveurs récursifs choisissent-ils le serveur racine à interroger, et quel identificateur de serveur racine mon serveur récursif devrait-il privilégier ?
C’est ce que l’on appelle « l’algorithme de sélection de serveur ». Le protocole DNS ne précise pas comment un serveur de noms récursif doit faire son choix parmi un ensemble de serveurs pour une requête donnée. Ainsi, chaque fournisseur de logiciel récursif détermine son propre algorithme de sélection de serveur. Certaines mises en œuvre de résolveurs « se verrouillent » sur le serveur ayant la plus faible latence ou sur l’un des serveurs dont la latence est proche de la plus rapide. Certaines mises en œuvre de résolveurs choisissent toujours le serveur de manière aléatoire, tandis que d’autres distribuent les requêtes à l’aide de formules complexes.
Il est probablement plus fiable de laisser votre logiciel récursif faire le travail pour lequel il a été conçu plutôt que d’essayer de l’influencer pour qu’il préfère ou évite certains serveurs.
3.2 Pouvez-vous expliquer comment le DNS utilise UDP et le port TCP 53 ?
Presque tous les clients DNS utilisent par défaut le transport UDP pour leurs requêtes. Dans certaines situations, il est toutefois nécessaire d’utiliser le protocole TCP.
Le plus souvent, on a recours à TCP lorsqu’une réponse UDP est tronquée. Cela se produit quand la réponse d’un serveur est trop large pour tenir dans un seul message UDP. Cela dépend de la taille de la mémoire tampon UDP annoncée par le client et de toute limite de taille de la réponse que le serveur peut s’imposer. Lorsqu’un client reçoit une réponse tronquée, le protocole DNS l’invite à soumettre à nouveau la requête via TCP pour obtenir la réponse complète.
TCP est également utilisé pour les transferts de zones dans le DNS. Étant donné que les zones entières sont généralement beaucoup plus grandes que ce que peut contenir un seul message UDP, il est logique d’effectuer ces opérations via TCP.
Le protocole TCP peut également entrer en jeu lorsqu’un serveur fait l’objet d’une attaque. Le serveur peut envoyer aux clients des réponses tronquées afin de déterminer si oui ou non il s’agit de sources frauduleuses. Les clients qui établissent des connexions TCP peuvent être qualifiés de sources non frauduleuses. De plus, grâce à la technique de limitation du taux de réponse (RRL), des réponses tronquées sont périodiquement envoyées afin que les clients légitimes aient la possibilité de recevoir des réponses sur TCP, contrairement au trafic d’attaque qui ne fera pas de nouvelles tentatives.
La mise en œuvre de DNS sur TCP est obligatoire dans les logiciels DNS. Pour plus d’informations, veuillez consulter le document RFC 7766.
3.3 Comment réduire la latence entre le serveur récursif que j’exploite et un serveur racine ?
Tout d’abord, vous devez évaluer soigneusement s’il y a un réel avantage à être plus proche de (davantage de) serveurs racine. Le DNS fait un usage intensif des technologies de mise en cache. C’est pourquoi il est souvent peu utile de réduire la latence entre un serveur récursif et une instance de serveur racine. En outre, comme indiqué dans la réponse à la question 3.1, les algorithmes des logiciels de résolution cherchent généralement à interroger les serveurs racine ayant la plus faible latence. Par conséquent, un temps de latence élevé vers certains serveurs racine ne se traduit pas nécessairement par un temps de latence élevé pour les requêtes adressées au système des serveurs racine.
Analysez le trafic sortant de votre serveur de noms récursif pour des requêtes qui sont envoyées à des serveurs de noms racine. Si vous constatez que le trafic est plus important que prévu, vous pouvez peut-être modifier la configuration de vos applications ou de votre réseau de manière à éviter d’interroger la racine aussi souvent. Utilisez des programmes tels que l’utilitaire « dig » pour mesurer la latence réelle. Si les valeurs d’au moins deux serveurs racine sont inférieures ou égales à 100 millisecondes, cela est en général suffisant.
Utilisez des outils tels que « traceroute » pour explorer le chemin d’accès réseau entre votre serveur récursif et les serveurs racine que celui-ci utilise. Si quelque chose vous semble illogique (par exemple un routage passant par des points éloignés), demandez à votre FAI d’ajuster le routage.
Pour de plus amples informations sur les mesures de la qualité de service du DNS, le projet Atlas de RIPE (Réseaux IP européens) assure un suivi de la qualité du service racine avec son projet DNSMON. La latence de la plupart des serveurs, mesurée par des centaines de sondes RIPE Atlas, est inférieure à 60 ms.
S’il n’y a pas de serveurs racine raisonnablement proches, vous pouvez alors essayer d’identifier un point d’échange ou un centre de données proche où il serait possible d’installer un serveur racine. Demandez à un ou à plusieurs opérateurs de serveurs racine s’ils accepteraient de placer un serveur à cet endroit. Veuillez noter toutefois que si un site dispose déjà d’un serveur racine, les opérateurs ne voudront généralement pas en placer un autre au même endroit. Les coordonnées des opérateurs sont disponibles dans le tableau 2.
3.4 Peut-on configurer soi-même un serveur racine en téléchargeant le fichier de zone racine et en validant soi-même la signature ?
Le document RFC 8806 décrit comment le faire et contient de nombreuses mises en garde sur les inconvénients possibles de cette pratique. Veuillez noter que la validation DNSSEC est requise. Voir aussi le LocalRoot Project.
3.5 Pendant combien de temps un serveur récursif mettra-t-il des informations en cache ?
Chaque enregistrement DNS à une valeur de durée de vie (TTL) qui lui est attribuée par l’éditeur de la zone. Cette valeur détermine la durée pendant laquelle un serveur de noms récursif ou un autre client doit mettre en cache les données en vue de leur réutilisation. À l’issue de cette période, le serveur de noms récursif doit contacter de nouveau le serveur faisant autorité pour obtenir des données à jour.
Dans le cas de la zone racine, certains enregistrements ont une durée de vie (TTL) de 24 heures et d’autres de 48 heures. Certains résolveurs prévoient une durée de vie maximale du cache, généralement de 24 heures.
3.6 Étant donné que le cache fournit des informations erronées au bout d’un certain temps, comment un résolveur peut-il être mis à jour avec des informations DNS correctes ?
Si vous pensez que les données d’un cache d’un serveur de noms récursif sont obsolètes, vous pouvez vider son cache ou redémarrer le processus du serveur.
3.7 Que sont les requêtes et réponses initiales (priming) du DNS ?
Les résolveurs récursifs du DNS doivent initialiser leurs caches avec des données spécifiques de la zone racine avant de pouvoir commencer à répondre à des requêtes régulières. Le document RFC 8109 décrit les requêtes que les résolveurs récursifs envoient et les réponses qu’ils attendent des serveurs racine.
3.8 Quel rôle joue EDNS dans les requêtes DNS modernes et quel en est l’impact sur le fonctionnement des serveurs racine ?
Les mécanismes d’extension pour DNS (EDNS), définis dans le document RFC 6891 , augmentent les capacités du protocole DNS tout en préservant une compatibilité descendante. L’EDNS est essentiel pour les requêtes DNS modernes, dans la mesure où il permet d’obtenir des réponses de taille plus importante, telles que celles contenant des données DNSSEC ou des enregistrements supplémentaires.
3.9 Comment la mauvaise configuration d’un seul serveur racine peut-elle impacter sur l’ensemble de l’écosystème du DNS ?
La mauvaise configuration d’un seul serveur racine peut avoir des effets circonscrits ou temporaires. Cependant, le RSS est conçu pour garantir que l’ensemble de l’écosystème du DNS demeure résilient et fiable, y compris en cas de mauvaise configuration ou de panne d’une composante.
4 Intégrité de la zone racine
4.1 Comment les opérateurs s’assurent-ils que la zone racine est correctement copiée ?
Le transfert du fichier de zone racine du responsable de la maintenance de la zone racine (RZM) aux RSO s’effectue via les protocoles de transfert de zone DNS (AXFR dans le document RFC 5936 et IXFR dans le document RFC 1995). Ces messages de transfert de zone sont protégés par l’utilisation d’enregistrements de ressources TSIG, tel que décrit dans le document RFC 2845. Il s’agit de protocoles fiables et aucun cas de corruption de données n’a été recensé jusqu’à présent. En outre, étant donné que la zone racine est signée, les validateurs DNSSEC peuvent détecter les réponses incorrectes ou falsifiées. Le RSSAC encourage le recours à la validation DNSSEC lorsque cela est possible.
Le RZM utilise le mécanisme DNS NOTIFY défini dans le document RFC 1996 pour la notification rapide des changements de zone afin de prévenir les RSO qu’une nouvelle zone (c’est-à-dire la dernière version) est disponible pour être copiée ou transférée.
4.2 Qu’est-ce que ZONEMD et comment peut-il protéger l’intégrité des données de la zone racine ?
Étant donné qu’il est impossible d’empêcher la corruption de données sur tous les chemins d’accès, il est important que les résolveurs valident l’ensemble des réponses qu’ils reçoivent à l’aide de DNSSEC (voir section 5). D’autres mécanismes ont été mis en place pour que chaque instance de serveur racine déployée assure correctement le service des données au mieux de ses capacités. Comme vu précédemment, l’utilisation de TSIG par les RSO et le RZM garantit la non-corruption des données d’enregistrement pendant le transfert.
Le document RFC 8976 définit un mécanisme pour assurer l’intégrité d’un fichier de zone du DNS à l’aide d’un enregistrement ZONEMD qui « fournit un condensat cryptographique des données de zone DNS au repos ». La zone racine actuelle contient un enregistrement ZONEMD qui inclut une signature numérique de la zone racine.
ZONEMD permet aux destinataires d’une zone racine complète de vérifier le contenu de la zone du point de vue de l’intégrité des données et de l’authenticité de l’origine. DNSSEC permet aux utilisateurs finaux de données DNS signées (y compris la zone racine) de confirmer que les réponses qu’ils ont reçues sont authentiques, quels que soient le chemin d’accès et les serveurs ayant traité les données lorsqu’elles étaient en transit.
4.3 Où en est la mise en œuvre de ZONEMED pour les opérations des serveurs racine ?
ZONEMD (Zone Message Digest) est une technologie conçue pour renforcer la vérification de l’intégrité des données de zone DNS. Les RSO ne sont pas actuellement obligés de mettre en place la validation ZONEMD, mais ils surveillent son développement et son adoption. Des initiatives sont en cours pour tester ZONEMED dans des scénarios du monde réel afin d’en analyser les effets sur la performance et répondre à d’éventuels problèmes opérationnels.
5 DNSSEC
5.1 La confidentialité des requêtes ou réponses DNS est-elle assurée avec DNSSEC ?
Non, DNSSEC ne fait qu’ajouter une couche de sécurité supplémentaire à l’infrastructure du DNS en authentifiant l’origine des données DNS et en protégeant leur intégrité.
5.2 DNSSEC rend-il plus difficile de servir une copie de la zone racine au niveau local ?
Non, servir une copie locale de la zone racine signifie simplement servir des copies à jour de la zone racine sans aucun changement. La zone racine est fournie par le responsable de la maintenance de la zone racine (RZM) avec toutes les signatures DNSSEC requises en place.
6 RSSAC
6.1 Les réunions du RSSAC sont-elles ouvertes à tous ?
Le RSSAC tient des téléconférences périodiques et se réunit lors des conférences de l’ICANN. Les procès-verbaux des réunions et des téléconférences (le cas échéant) peuvent être consultés ici. Si vous souhaitez participer à une téléconférence ou à une séance de travail du RSSAC en tant qu’observateur, veuillez contacter [email protected] pour obtenir des renseignements sur la participation à distance.
La plupart des réunions du RSSAC tenues lors des conférences de l’ICANN sont ouvertes aux observateurs, à moins que la réunion ne soit marquée comme étant « à huis clos » dans le programme de l’ICANN. Le RSSAC tient également des séances publiques lors des réunions de l’ICANN, où les membres de la communauté sont invités à poser leurs questions.
6.2 Quelle est la relation entre le RSSAC et le SSAC ?
Le RSSAC et le Comité consultatif sur la sécurité et la stabilité (SSAC) sont les deux principaux comités consultatifs techniques de la communauté de l’ICANN. Toutefois, la portée de leur travail diffère. Le RSSAC s’occupe uniquement « du fonctionnement, de la gestion, de la sécurité et de l’intégrité du système des serveurs racine » tandis que le SSAC s’occupe de « questions relatives à la sécurité et à l’intégrité des systèmes de nommage et d’attribution d’adresses sur Internet ».
Il existe un certain chevauchement dans le champ d’action des deux groupes. Pour tenir chacun des groupes au courant du travail de l’autre, le SSAC nomme un agent de liaison auprès du RSSAC. En outre, lors des conférences de l’ICANN, le SSAC et le RSSAC tiennent une réunion conjointe.
Le SSAC est décrit à l’article 12.2(b) des statuts constitutifs de l’ICANN. Vous trouverez des informations supplémentaires ici.
6.3 Quelle est la relation entre le RSSAC et le RZERC ? Le RZERC est-il un sous-ensemble du RSSAC ?
Le RSSAC et le Comité de révision de l’évolution de la zone racine (RZERC) sont des comités distincts au sein de l’ICANN, bien qu’il existe des liens entre eux et qu’une même personne puisse siéger dans les deux comités.
En vertu de sa charte, le RSSAC :
« ... a pour fonction de conseiller la communauté et le Conseil d’administration de l’ICANN sur des questions liées au fonctionnement, à la gestion, à la sécurité et à l’intégrité du système des serveurs racine ». Pour de plus amples informations sur le rôle du RSSAC, veuillez consulter le document RSSAC033 : Déclaration du RSSAC sur la distinction entre RSSAC et Root-Ops.
En vertu de sa charte, le RZERC :
« ... examine les changements architecturaux proposés au contenu de la zone racine du DNS, aux systèmes (matériel et logiciel) utilisés pour modifier la zone racine du DNS et aux mécanismes utilisés pour la distribution de la zone racine du DNS ».
Le schéma suivant explique les rôles de chaque groupe.
Infographie du RSSAC et du RZERC
6.4 Existe-t-il une indication sur la date à laquelle nous connaîtrons le nombre de serveurs racine que le RSSAC souhaite avoir ? Quand aura lieu l’évaluation pour déterminer le nombre de lettres ?
Le RSSAC n’a pas d’idée préconçue sur le nombre de serveurs racine ou le nombre de RSO qu’il devrait y avoir. La limite actuelle du nombre d’opérateurs est technique et non pas administrative.
6.5 Où puis-je trouver les publications du RSSAC ?
Les publications du RSSAC sont disponibles sur la page des publications du RSSAC. Les personnes souhaitant se familiariser avec le système des serveurs racine sont invitées à consulter les documents RSSAC023v2 : Histoire du système des serveurs racine et RSSAC026v2 : Lexique du RSSAC.
6.6 Quel est le rôle du RSSAC dans l’ensemble du processus d’élaboration de politiques de l’ICANN ?
Le RSSAC joue un rôle consultatif au sein de l’ICANN et se concentre spécifiquement sur les questions liées à la stabilité opérationnelle, à la fiabilité et à la sécurité du système des serveurs racine. Bien que le RSSAC ne participe pas directement à l’élaboration de politiques de l’ICANN, son expertise technique et ses recommandations contribuent à éclairer les discussions en matière de politiques. Par exemple, le RSSAC formule des avis sur la mise en œuvre de nouvelles technologies et leur éventuel impact sur le système des serveurs racine. Ces contributions permettent de garantir que les politiques de l’ICANN s’alignent sur les meilleures pratiques en matière de gestion et de sécurité du DNS.
6.7 Comment les individus ou les organisations peuvent faire part de leurs retours ou échanger avec le RSSAC ?
Le RSSAC encourage l’ensemble de la communauté à le contacter et à lui faire part de ses retours. Les personnes et les organisations qui le souhaitent peuvent participer à ses réunions publiques et aux consultations publiques sur ses projets de publications, ou bien rejoindre le Caucus RSSAC en tant qu’experts métier. Des rapports réguliers sur les activités du RSSAC sont disponibles sur le site web de l’ICANN. Les membres de la communauté peuvent contacter le RSSAC directement par l’intermédiaire de l’équipe de soutien de l’ICANN. Ce processus participatif ouvert garantit que les travaux du RSSAC restent inclusifs et répondent aux besoins des parties prenantes.
7 Caucus RSSAC
Des informations sur le Caucus RSSAC sont disponibles sur leur page web.
7.1 Quelle est la différence entre un membre du RSSAC et un membre du Caucus RSSAC ?
Le RSSAC se compose de représentants titulaires et suppléants de chaque opérateur de serveur racine, ainsi que d’agents de liaison auprès et en provenance de plusieurs autres groupes. Le Caucus RSSAC est composé d’experts du DNS qui s’intéressent au système des serveurs racine. La plupart (mais pas la totalité) des avis publiés par le RSSAC sont élaborés par le Caucus RSSAC. Le RSSAC est le comité consultatif formel qui décide de l’approbation finale des publications à transmettre au Conseil d’administration et à la communauté de l’ICANN.
Tous les membres du RSSAC sont également membres du Caucus RSSAC. La liste des membres du RSSAC est disponible ici. La liste des membres du Caucus RSSAC est disponible ici. Des informations pour rejoindre le Caucus RSSAC sont disponibles sur la page du Caucus RSSAC.
7.2 Les réunions du Caucus RSSAC sont-elles ouvertes à tous ?
Le Caucus RSSAC tient des assemblées générales lors des réunions générales annuelles de l’ICANN et de l’IETF. Toutes ces assemblées générales sont ouvertes aux observateurs. Les réunions des groupes de travail du Caucus RSSAC ne sont pas ouvertes aux observateurs.
Tous les membres du Caucus RSSAC sont invités à participer à toutes les réunions générales du Caucus RSSAC et aux réunions du groupe de travail du Caucus RSSAC.
7.3 Existe-t-il une limite au nombre de membres du Caucus RSSAC ?
Non.
7.4 Combien de temps les membres du Caucus RSSAC doivent-ils consacrer à ces activités ?
Il est attendu des membres du Caucus RSSAC qu’il prennent part aux équipes de travail et qu’ils participent à la liste de diffusion du Caucus RSSAC. Certains membres seront en mesure d’y consacrer plus de temps que d’autres, sachant aussi que certaines équipes de travail et certaines révisions de documents requièrent plus de temps que d’autres. En règle générale, le RSSAC souhaite que les membres consacrent au moins 4 heures par mois aux activités du Caucus.
7.5 Comment le Caucus RSSAC contribue-t-il à l’élaboration des publications et des recommandations du RSSAC ?
Le Caucus RSSAC est un groupe d’experts métier bénévoles qui ont pour tâche de faire des recommandations, de rédiger des documents et de donner des avis techniques au RSSAC. Les membres du Caucus travaillent de manière collaborative sur des publications telles que des avis, des rapports et des évaluations techniques. Le Caucus se réunit régulièrement pour discuter des projets en cours et apporter son point de vue sur des thématiques telles que la technologie DNS, l’exploitation des serveurs racine et les menaces émergentes. Les membres de la communauté intéressés peuvent demander à rejoindre le Caucus et contribuer à cet important travail.
8 Malentendus courants
Pour une présentation du mode de fonctionnement du DNS, veuillez consulter « Le système des noms de domaine de l’Internet expliqué pour les non-experts », par Daniel Karrenberg.
8.1 Les serveurs racine contrôlent-ils la destination du trafic Internet ?
Non, les routeurs et le protocole BGP déterminent le chemin d’accès que les paquets empruntent à travers le réseau, entre le point de départ et le point d’arrivée. Le DNS établit une correspondance entre des noms faciles à retenir par les humains et des adresses IP. Ce sont ces adresses IP que les routeurs utilisent pour déterminer la destination des paquets.
8.2 La plupart des requêtes DNS sont-elles traitées par un serveur racine ?
Non, la plupart des requêtes DNS sont traitées par des résolveurs récursifs à partir des données qu’ils possèdent déjà dans leurs caches, sans interaction avec un serveur racine. Un résolveur récursif n’interagit avec un serveur racine que s’il ne dispose pas dans son cache d’informations non expirées sur des domaines de premier niveau ou sur les racines elles-mêmes. Presque toutes les requêtes reçues par les serveurs racine engendrent une réponse de renvoi qui indique au serveur de noms récursif où poser sa prochaine question.
8.3 Y a-t-il des identificateurs de serveur racine qui ont des significations spécifiques ?
Aucun identificateur de serveur racine n’est spécial.
8.4 Il n’y a que 13 serveurs racine ?
Il y a plus de 1 500 serveurs dans le monde, mais uniquement 13 identificateurs de serveurs racine (RSI), chacun d’entre eux associé à une adresse Ipv4, à une adresse IPv6 et à un routage anycast.
8.5 Les opérateurs de serveurs racine mènent-ils leurs activités en toute indépendance ?
Les RSO fonctionnent de manière indépendante tout en entretenant une étroite coordination entre eux par l’intermédiaire du RSSAC et d’autres forums. Pour plus d’informations, consultez le document RSSAC042 : Déclaration du RSSAC sur l’indépendance des opérateurs des serveurs racine.
8.6 Les serveurs racine ne reçoivent-ils que la partie TLD de la requête DNS ?
Actuellement, les serveurs racine (et en fait tous les serveurs DNS) reçoivent en général l’intégralité du nom de domaine recherché dans la requête DNS. Or, une fonctionnalité DNS a été mise en place afin d’envoyer uniquement la partie TLD du nom de domaine aux serveurs racine, lorsque cela s’avère nécessaire.
Le document RFC 9156 décrit comment les serveurs DNS récursifs peuvent envoyer uniquement la plus petite partie nécessaire du nom recherché par la requête. C’est ce qu’on appelle la minimisation de l’interrogation de nom ou minimisation QNAME. Avec la minimisation QNAME, des serveurs DNS récursifs n’envoient que les parties nécessaires d’un nom de domaine aux serveurs qu’ils interrogent. Les serveurs DNS récursifs qui utilisent la minimisation QNAME ne doivent envoyer aux serveurs racine que la partie TLD du nom recherché par la requête. Cela minimise la quantité d’informations sur le réseau et permet de mieux protéger la vie privée des utilisateurs qui interrogent le DNS.