FAQ DU RSSAC
Cette page apporte des réponses à bon nombre des questions les plus fréquemment posées sur le RSSAC. Elle sera mise à jour dès lors que les réponses changent ou dès que de nouvelles questions deviennent récurrentes.
Si vous avez une question qui ne figure pas ci-dessous, ou si vous voulez obtenir des informations ou des précisions, vous pouvez envoyer un e-mail directement à ask-rssac@icann.org. Si vous souhaitez évoquer une question de cette FAQ, veuillez inclure le numéro et le titre de la question dans votre e-mail. Les opérateurs du serveur racine maintiennent également une FAQ.
Liste de sujets
- Nombre de serveurs racine
- Anycast
- DNS et mise en réseau
- Intégrité de la zone racine
- DNSSEC
- RSSAC
- Caucus RSSAC
- Malentendus courants
-
Nombre de serveurs racine
1.1 Pourquoi y a-t-il 13 serveurs de noms racine ?
En 1985, il y avait quatre serveurs racine. Entre 1987 et 1991, il y en avait sept, tous situés aux États-Unis. En 1993, il y en avait huit. À ce moment-là, un problème s'est posé.Le document RFC 1035 stipule que « les messages du [DNS] transmis par l'UDP sont limités à 512 octets ». Ajouter plus de serveurs de noms racine engendrerait une réponse initiale supérieure à 512 octets.Le document RFC 1035 ne fournit pas de justification à la limite de 512 octets, mais il convient aussi 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 se sont rendu compte que davantage de serveurs racine pourraient être ajoutés s'ils pouvaient tirer profit de la compression des noms du DNS. Ainsi, il a été proposé de donner des noms aux serveurs racine dans la zone root-servers.net. En 1995, les neuf serveurs racine existants 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 le nombre total d'identificateurs de serveur racine (RSI) à 13.
Jusqu'en 1998, c'est le Dr. Jon Postel, en sa qualité d'administrateur de l'IANA, qui était chargé de désigner les opérateurs de serveurs racine. Après son décès en 1998, le nombre d'opérateurs n'a pas bougé, bien qu'un petit nombre d'entre eux ait changé de mains au fil des ans.
Depuis 1998, le paysage a été modifié de plusieurs façons. Chaque serveur racine a ajouté sa propre adresse IPv6, et l'ICANN a signé la zone avec les extensions de sécurité DNS (DNSSEC). De même, la taille des messages transmis sur l'UDP a augmenté à l'aide de l'extension de protocole EDNS (mécanismes d'extension pour le DNS). Tous ces changements ont fait perdre de l'importance à la limite de 512 octets de l'UDP et à la limite de 13 RSI.
En 2002, Internet Software Consortium (ISC, désormais Internet Systems Consortium) est devenu le premier opérateur de serveur racine à déployer l'adresse anycast IP, même si le projet WIDE avait déjà expérimenté cette technologie. Au fil des ans, les autres opérateurs de serveurs racine en ont fait de même. Anycast permet à chaque opérateur de fournir le service à partir de multiples instances distinctes. Alors qu'il reste aujourd'hui 13 RSI, il y a en fait plus de 1500 instances anycast en activité à travers le monde.
Afin de 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 davantage 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 logique justifiait 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, et cette fonction supplémentaire limitait considérablement le nombre potentiel de RSI. Tout comme avec la requête initiale pour la zone racine, l'envoi d'une requête au NS RRSET pour les zones .COM, .NET et .ORG ne pouvait dépasser la limite de 512 octets, et comme les mêmes serveurs desservaient ces zones, la même limite s'appliquait à tous.
Un paquet de réponses DNS contient également l'ensemble de la question posée dans la section Question. Une réponse à une requête initiale racine utilisera toujours 5 octets pour la section Question. Le QNAME utilise 1 octet, et le QTYPE et le QCLASS utilisent chacun 2 octets, pour un total de 5 octets. Toutefois, pour une requête initiale .COM, la section Question pourrait être bien plus grande.
Objet
Octets
En-tête DNS
12
Premier enregistrement NS
31
12 Enregistrements NS compressés
(12 * 15) 180
13 Enregistrements A
(13 * 16) 208
Section Question QTYPE et QCLASS
4
Section Question QNAME
?
=
435
Tableau 1 : Explication des octets utilisés dans la réponse initiale racine
Avec 435 octets en fonctionnement, 77 octets étaient alors disponibles pour la section Question QNAME. À ce moment-là, il était déterminé que 64 octets seraient suffisants pour prendre en charge la plupart des requêtes envoyées pour .COM, .NET et .ORG. L'ajout d'un autre serveur requerrait 25 octets, et comme 435 + 64 + 25 > 512, il a été décidé de ne pas ajouter un autre serveur.
-
Anycast
2.1 Pourquoi certains opérateurs possèdent de nombreuses instances anycast alors que d'autres en ont peu ?
Les opérateurs de serveurs racine (RSO) sont des organisations indépendantes avec des mandats différents, des modèles opérationnels différents et différentes sources de financement. Ces différences peuvent avoir un impact sur le nombre d'instances anycast ainsi que sur d'autres choix opérationnels. Les opérateurs de serveurs racine disposent d'une grande indépendance dans leur mode de déploiement de 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 de zone racine du DNS de qualité.
2.2 Le nombre de nœuds anycast est-il ou non limité ?
Le fonctionnement anycast est défini et décrit dans le documentRFC 4786 « Fonctionnement des services anycast » et dans le documentRFC 7094 « Considérations architecturales liées à Anycast IP ». 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, puis 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 l'instance anycast d'un serveur racine dans une municipalité. Nous observons qu'elle répond à des requêtes des quatre coins de la planète. Que dois-je faire afin qu'elle ne réponde qu'à des requêtes provenant de l'environnement local ?
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 sorte que l'instance anycast ne reçoit que du trafic local. D'autres les configurent de sorte à recevoir le trafic global, en se reposant 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é, vous devez en discuter avec le RSO assurant la fourniture du service.
2.5 En 2016, s'est produite une attaque de grande envergure sur Dyn. Les 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 nombreux opérateurs et de nombreuses instances du serveur racine. Un nombre élevé d'instances anycast augmente la capacité du RSS et est d'une grande aide 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 faire une demande d'instance anycast d'un serveur racine pour mon organisation ?
Veuillez contacter directement les opérateurs de serveur 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 de serveur 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.
Cogent Communications
Département de la défense des États-Unis (NIC)
ICANN
Internet Systems Consortium, Inc.
Centre de recherche Ames de la NASA
Netnod
RIPE NCC
https://www.ripe.net/analyse/dns/k-root/hosting-a-k-root-node
Université du Maryland
Université de Californie du Sud, Institut des sciences de l'information
Laboratoire de recherche de l'armée des États-Unis
Verisign, Inc.
Projet WIDE
2.7 Comment puis-je déterminer quelle instance d'une identité de serveur racine répond à mes requêtes ?
Vous pouvez utiliser l'utilitaire « dig » à partir d'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 de requête NSID, puis rechercher la chaîne NSID signalée dans la pseudo-section OPT de la sortie de 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/.
-
DNS et mise en 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 du serveur ». Le protocole DNS ne précise pas comment un serveur de nom récursif doit choisir parmi un ensemble pour une requête donnée. Ainsi, chaque fournisseur de logiciel récursif détermine son propre algorithme de sélection du serveur. Certaines mises en œuvre de résolveurs se « bloqueront » sur le serveur avec le moins de temps d'attente, ou sur l'un des serveurs ayant un temps d'attente similaire au serveur le plus rapide. Certaines mises en œuvre de résolveurs choisissent toujours le serveur de manière aléatoire, et d'autres distribuent les requêtes en se fondant sur des formules complexes.
Il est probablement plus fiable de laisser votre logiciel récursif faire le travail pour lequel il a été conçu que d'essayer de l'influencer afin de privilégier ou d'éviter certains serveurs.
3.2 Pouvez-vous expliquer comment le DNS utilise l'UDP et le port TCP 53 ?
Presque tous les clients DNS utilisent par défaut le transport UDP pour les requêtes. Toutefois, dans certains cas, c'est le TCP qui doit être utilisé.
Le plus souvent, on a recours au TCP lorsqu'une réponse UDP est tronquée. Une telle troncation survient lorsque la réponse d'un serveur est trop volumineuse 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 à la taille de la réponse que le serveur peut s'imposer à lui-même. Lorsqu'un client reçoit une réponse avec l'ensemble de bits tronqué, le protocole DNS invite à réessayer la requête sur le TCP afin d'obtenir la réponse complète.
Le TCP pour le DNS est également utilisé pour les transferts de zone. Comme l'ensemble des zones est généralement bien plus grand que la limite autorisée pour un seul message UDP, il est logique d'effectuer ces transferts sur le TCP.
Le TCP peut aussi 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, via la technique de limitation du taux de réponse (RRL), des réponses tronquées seront de temps en temps envoyées afin que les clients légitimes aient la possibilité de recevoir des réponses sur le TCP, tandis que le trafic d'attaque ne fera pas de nouvelle tentative.
Il est obligatoire de mettre en œuvre le DNS sur TCP dans les logiciels DNS. Pour plus d'informations, veuillez consulter le documentRFC 7766.
3.3 Comment réduire le temps d'attente entre le serveur récursif que j'exploite et un serveur racine ?
Premièrement, vous devez procéder à un examen minutieux vous permettant de déterminer s'il est réellement avantageux d'être plus proche de (plus de) serveurs racine. Le DNS utilise énormément de technologies de mise en cache. De ce fait, il y a souvent peu d'intérêt à diminuer la latence entre un serveur récursif et une instance de serveur racine. Aussi, comme mentionné dans la réponse à la question 3.1, les algorithmes de logiciels de résolveurs essaient généralement d'interroger les serveurs racine avec une latence plus faible. Et donc, disposer d'une latence élevée pour certains serveurs racine n'entraînera pas nécessairement l'envoi au système des serveurs racine de requêtes ayant une latence élevée.
Analysez le trafic sortant de votre serveur de nom récursif pour des requêtes qui sont envoyées à des serveurs de noms racine. Si vous observez plus de trafic que prévu, vous pouvez régler vos applications ou les configurations de votre réseau afin qu'ils n'aient pas à interroger la racine si souvent. Utilisez des programmes tels que l'utilitaire « dig » afin de mesurer les temps d'attente réels. Si le temps d'attente d'au moins deux serveurs racine est inférieur ou égal à 100 millisecondes, cela est en général suffisant.
Utilisez des outils tels que « traceroute » afin d'explorer le chemin d'accès réseau entre votre serveur récursif et les serveurs racine que votre serveur de nom récursif utilise. Si quelque chose vous semble illogique (par exemple un routage vers des emplacements éloignés), demandez à votre FSI si le routage peut être ajusté.
Pour de plus amples informations sur les mesures de la qualité de service du DNS, le projet Atlas du RIPE (Réseaux IP européens) assure un suivi de la qualité du service racine avec son projet DNSMON. Le temps d'attente de la plupart des serveurs comme mesuré par des centaines d'ancres RIPE Atlas est inférieur à 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 traitement de données proche où pourrait se trouver un serveur racine. Demandez à un ou plusieurs des opérateurs de serveurs racine s'ils souhaiteraient y placer un serveur. Toutefois, notez que si un emplacement a déjà un serveur racine, les opérateurs ne veulent en général pas en placer un autre. Vous pouvez trouver des coordonnées d'opérateurs en vous rendant surhttp://www.root-servers.org et en appuyant sur les boutons « E-mail » dans la section Serveurs racine en bas de page.
3.4 Pouvez-vous configurer un serveur racine vous-même en téléchargeant le fichier de zone racine et en validant la signature vous-même ?
Le document RFC 8806 décrit comment s'y prendre tout en mettant en garde contre les éventuels inconvénients liés à cette pratique. Veuillez noter que la validation des DNSSEC est requise. Consultez aussi leLocalRoot Project.
3.5 Pendant combien de temps un serveur récursif mettra en cache les informations ?
Chaque enregistrement DNS à un temps de validité de la réponse (TTL) qui lui est attribué par l'éditeur de la zone. Cela détermine la durée pendant laquelle un serveur de nom récursif ou un autre client doit mettre en cache les données à des fins de réutilisation. À l'issue de cette période, le serveur de nom 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 sont servis avec un TTL de 24 heures et d'autres avec un TTL de 48 heures. Certains résolveurs ont des durées de vie de mise en cache maximums, en général 24 heures.
3.6 La mise en cache donnant de fausses informations après un certain temps, comment un résolveur peut-il être mis à jour avec les informations correctes du DNS ?
Si vous pensez que les données d'un cache d'un serveur de nom récursif sont obsolètes, vous pouvez vous débarrasser de son cache ou redémarrer le processus du serveur.
3.7 Que sont les requêtes et réponses initiales du DNS ?
Les résolveurs récursifs du DNS doivent lancer 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 quelles requêtes les résolveurs récursifs envoient et les réponses qu'ils attendent des serveurs racine.
-
Intégrité de la zone racine
4.1 Comment l'opérateur assure-t-il que la zone racine est dûment reproduite ?
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 de 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, la zone racine étant signée, des réponses incorrectes ou falsifiées peuvent être détectées par des validateurs des DNSSEC. Lorsque cela est possible, le RSSAC encourage le recours à la validation des DNSSEC.
Le RTZM utilise la NOTIFICATION DNS définie dans le document RFC 1996 pour la notification rapide des changements de zone de sorte à prévenir les RSO qu'une nouvelle zone (c'est-à-dire la dernière version) est disponible à des fins de copie ou de transfert.
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 des DNSSEC (voir section 5). D'autres mécanismes ont été déployés afin d'assurer que chaque instance de serveur racine déployée transmette des données le mieux possible au vu de sa capacité. Comme vu précédemment, l'utilisation du 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 une synthèse de message cryptographique à des données de zone du DNS inactives ». Comme indiqué dans une déclaration publiée par les opérateurs de serveurs racine, les RSO n'autoriseront pas la vérification ZONEMD au cours de la première année après la publication initiale des enregistrements ZONEMD. Une telle vérification n'a pas encore été déployée, mais elle devrait l'être à l'avenir.
ZONEMD permettra aux destinataires d'une zone racine complète de vérifier le contenu de la zone afin de s'assurer de l'intégrité des données et de l'authenticité de l'origine. Les DNSSEC permettent aux utilisateurs finaux de données signées du DNS (y compris la zone racine) de garantir 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.
-
DNSSEC
5.1 Les DNSSEC assurent-elles la confidentialité des requêtes DNS ou des réponses ?
Non, elles se contentent d'ajouter une couche de sécurité à l'infrastructure du DNS en authentifiant l'origine des données du DNS et en protégeant leur intégrité.
5.2 Avec les DNSSEC, est-il plus compliqué de transmettre une copie de la zone racine au niveau local ?
Non, transmettre une copie locale de la zone racine signifie simplement transmettre des copies à jour de la zone racine sans changements. La zone racine provient du responsable de la maintenance de la zone racine (RZM) avec toutes les signatures DNSSEC requises en place.
Pour de plus amples informations sur la façon de transmettre la zone racine au niveau local, consultez la question 3.4 et le document RFC 8806.
-
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 réunions 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. Pour observer une téléconférence du RSSAC ou une séance de travail, veuillez contacter rssac-staff@icann.org pour obtenir des renseignements sur la participation à distance.
La plupart des réunions du RSSAC tenues lors des réunions de l'ICANN sont ouvertes aux observateurs, à moins que la réunion ne soit marquée comme « à huis clos » dans l'ordre du jour 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 « au fonctionnement, à la gestion, la sécurité et l'intégrité du système des serveurs racine » et 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 y a 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 réunions 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 En quoi sont liés le RSSAC et le RZERC ? Le RZERC est-il un sous-ensemble du RSSAC ?
Le Comité consultatif du système des serveurs racine (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'il soit possible de siéger aux deux comités.
En vertu de sa charte, le RSSAC :
« ...conseille le Conseil d'administration de l'ICANN et la communauté 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 :
« doit examiner 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 aide à comprendre les rôles de chaque groupe.
6.4 Existe-t-il une date à laquelle nous pouvons connaître le nombre de serveurs racine que le RSSAC souhaite avoir ? Quand l'évaluation sera-t-elle menée afin de déterminer le nombre de lettres ?
Le RSSAC n'a pas d'avis arrêtés 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 des publications du RSSAC ?
Des publications du RSSAC sont disponibles sur la page des publications du RSSAC. Nous conseillons vivement aux personnes souhaitant se familiariser avec le système des serveurs racine de consulter les documents suivants RSSAC023v2 : Histoire du système des serveurs racine, etRSSAC026v2 : lexique du RSSAC.
-
Caucus RSSAC
Des informations sur le Caucus RSSAC sont disponibles sur sa page Web principale.
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 désignés et de suppléants de chaque opérateur de serveur racine, ainsi que d'agents de liaison vers et depuis divers autres groupes. Le Caucus RSSAC est composé d'experts en matière de DNS qui ont un intérêt dans le système des serveurs racine. La plupart, mais pas tous les avis publiés par le RSSAC sont créés par le Caucus RSSAC, tandis que le RSSAC est le comité consultatif formel qui fournit l'approbation finale des publications pour les 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 sa page 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 assemblées 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 Quel temps les membres du Caucus RSSAC doivent-ils consacrer à ces activités ?
Les membres du Caucus RSSAC doivent participer aux équipes de travail et à la liste de diffusion du Caucus RSSAC. Certains membres pourront consacrer plus de temps que d'autres, et certaines équipes de travail et révisions de documents requièrent plus de temps que d'autres. Toutefois, le RSSAC souhaite, de manière générale, que ses membres consacrent au moins 4 heures par mois aux activités du Caucus.
-
Malentendus fréquents
Pour une présentation du mode de fonctionnement du DNS, veuillez consulterLe système des noms de domaine d'Internet expliqué pour les non-experts de Daniel Karrenberg.
8.1 Les serveurs racine contrôlent-ils la destination du trafic d'Internet ?
Non, les routeurs et le protocole BGP déterminent le chemin d'accès que les paquets empruntent jusqu'au réseau, entre le point de départ et le point d'arrivée. Le DNS fournit un mappage des noms axés sur l'humain vers les adresses IP, et ce sont ces adresses IP que les routeurs utilisent en fin de compte 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 sans interaction avec un serveur racine à partir des données qu'ils possèdent déjà dans leurs caches. Un résolveur récursif interagit uniquement avec un serveur racine s'il a des informations arrivées à expiration relatives aux domaines de premier niveau ou aux racines mêmes dans son cache. Presque toutes les requêtes reçues par les serveurs racine engendrent une réponse de renvoi qui indique au serveur de nom récursif où il doit maintenant poser sa 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 1500 serveurs dans le monde, mais uniquement 13 identificateurs de serveur racine (RSI), chacun d'entre eux utilisant une adresse IPv4 et 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 mènent leurs activités en toute indépendance, mais une coordination étroite entre eux est assurée par le RSSAC et d'autres forums. Pour plus d'informations, consultez le document RSSAC042 : Déclaration du RSSAC sur l'indépendance de l'opérateur 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 de fait tous les serveurs DNS) reçoivent en général l'intégralité du nom de requête dans la requête DNS. Toutefois, une nouvelle fonctionnalité DNS a été spécifiée ; elle n'enverra que la partie TLD du nom de domaine aux serveurs racine, lorsque cela s'avère nécessaire.
Le document RFC 9156 décrit la façon dont les serveurs DNS récursifs peuvent envoyer uniquement la plus petite partie nécessaire du nom de la requête. C'est ce qu'on appelle la minimisation du nom de la requête 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 ont recours à la minimisation QNAME ne doivent envoyer que la partie TLD de la requête des serveurs racine. Cela minimise la quantité d'informations sur le réseau et renforce donc la protection de la vie privée des utilisateurs interrogeant le DNS.
