Résumé

  • L’autorité qui reçoit une option ECS peut renvoyer une longueur de portée définissant les réseaux pour lesquels sa réponse peut être reprise depuis le cache.
  • Le résolveur décide séparément combien de bits du réseau client il révèle dans la longueur de préfixe source ; l’adresse est tronquée à cette limite.
  • Ni la portée ni le préfixe ne prouvent une identité ou une géographie. RFC 7871 décrit les coûts de confidentialité et de cache, et RFC 8932 recommande aux services de confidentialité d’éviter ECS ou d’en minimiser et d’en déclarer l’usage.

La portée vient de l’autorité

Pour une requête ECS, la longueur de portée vaut zéro. Dans la réponse, elle change de sens : l’autorité indique combien de bits initiaux décrivent le réseau couvert par la réponse. Une portée courte autorise une réutilisation plus large ; une portée plus longue peut signaler que le préfixe reçu n’était pas assez précis pour la sélection souhaitée.

Ce nombre ne garantit pourtant ni le serveur le plus proche, ni la meilleure latence, ni une localisation correcte. RFC 7871 laisse hors de son champ la méthode par laquelle l’autorité choisit une réponse. Il rappelle aussi que proximité topologique et proximité géographique ne se confondent pas. La portée gouverne donc la réutilisation d’un résultat, non sa vérité géographique.

Cette distinction déplace l’attention. ECS n’ajoute pas seulement un indice à une requête ; il permet à l’autorité de déterminer la taille du groupe de clients qui héritera ensuite de la même réponse. Une décision prise en amont devient une propriété durable du cache du résolveur.

Ce que le résolveur révèle

L’autre moitié du mécanisme se trouve dans la requête. L’option transporte une famille d’adresses, une longueur de préfixe source, une longueur de portée et une adresse de taille variable. Pour IPv4 ou IPv6, seuls les bits significatifs du préfixe source sont conservés ; le dernier octet nécessaire est complété, sans transmettre obligatoirement l’adresse entière.

Habituellement, une autorité voit l’adresse du résolveur récursif et non celle de l’origine. Cette approximation devient faible lorsqu’un résolveur central dessert des réseaux éloignés. ECS permet donc au résolveur de remplacer son propre emplacement comme seul indice par une partie du réseau client. L’autorité peut s’en servir pour adapter la réponse, mais c’est l’intermédiaire qui choisit la quantité d’information envoyée.

Un résolveur qui crée l’option dispose d’une longueur maximale qu’il accepte de mettre en cache et devrait employer un préfixe plus court que l’adresse complète. Si une requête entrante porte déjà une limite plus courte, un relais ultérieur ne doit pas l’élargir. La longueur source forme ainsi une borne de divulgation qui doit survivre aux étapes de résolution.

Le cache acquiert une dimension réseau

Le cache reste d’abord indexé par le triplet DNS habituel : nom, type et classe. Il sélectionne ensuite l’ensemble de réponses pertinent au moyen d’une correspondance de préfixes. Les enregistrements deviennent liés au réseau décrit par la portée reçue, et le rapport entre longueur source, longueur de portée et limite locale détermine leur réutilisation.

Une réponse sans option ECS est normalement traitée comme ayant une portée /0 : elle vaut pour toutes les adresses clientes. Si une autorité répond REFUSED, le résolveur compatible retente sans ECS afin de distinguer le refus de l’option des autres usages du même code.

Cette partition supplémentaire n’est pas gratuite. Pour un même nom, type et classe, plusieurs réseaux peuvent exiger plusieurs entrées. RFC 7871 signale une consommation mémoire accrue, une réutilisation réduite et une charge supérieure. Il recommande un fonctionnement désactivé par défaut, limité aux cas où l’avantage client est clair, avec des bornes sur le nombre de réseaux et de réponses conservés.

Le /0 et la réalité du refus

Un stub peut envoyer une longueur de préfixe source égale à zéro. Le résolveur récursif qui la reçoit ne doit alors pas ajouter l’adresse du client à ses requêtes suivantes. Il peut omettre ECS ou utiliser des informations qui lui sont propres. Un résolveur de relais doit, lui aussi, respecter la limite entrante.

La règle de paquet est nette ; l’accès pratique à ce choix l’était moins. RFC 7871 notait en 2016 que les logiciels exposaient rarement ce contrôle aux utilisateurs. Il s’agit d’un constat historique, pas d’un recensement actuel : les sources retenues ne permettent de quantifier ni l’adoption, ni les politiques des résolveurs publics.

En 2020, RFC 8932 a replacé cette question dans l’exploitation des services DNS privés. Le chiffrement protège le trajet entre le client et le résolveur contre certains observateurs, mais le résolveur voit toujours la requête et peut transmettre des données en amont. Le texte recommande d’honorer le /0, d’éviter ECS ou d’offrir un service sans ECS et, si l’option est utilisée, de choisir le préfixe opérationnel le plus court, de limiter si possible les autorités éligibles et de publier la politique réelle.

DNSSEC ne valide pas la délégation

DNSSEC et la portée ECS sont deux contrôles distincts. RFC 7871 recommande une portée /0 pour la plupart des données DNSSEC ; une signature RRSIG reste attachée au RRset qu’elle signe. La validation n’authentifie ni le préfixe du client, ni le choix du résolveur de le divulguer, ni la politique de sélection de l’autorité.

Le fait historique pertinent est donc circonscrit. ECS a rendu durables deux choix d’intermédiaires : la quantité de contexte réseau envoyée au nom du client, puis l’étendue de réutilisation imposée à la réponse. Cette lecture est une analyse des mécanismes documentés, non une mesure des déploiements contemporains.

Sources