Directives pour les sous-réseaux EDNS Client

Introduction

Le protocole RFC 7871 (Sous-réseau client dans les requêtes DNS) définit un mécanisme pour les résolveurs récursifs tels que le DNS public de Google afin d'envoyer des informations sur les adresses IP partielles des clients aux serveurs de noms DNS faisant autorité. Les réseaux de diffusion de contenu (CDN) et les services sensibles à la latence l'utilisent pour fournir des réponses géolocalisées précises lorsqu'elles répondent à des recherches de noms provenant de résolveurs DNS publics.

Le document RFC décrit les fonctionnalités ECS que les serveurs de noms faisant autorité doivent implémenter, mais les développeurs ne les respectent pas toujours. Il existe également des problèmes d'exploitation et de déploiement d'ECS qui ne sont pas résolus par la RFC, qui peuvent poser problème aux résolveurs tels que le DNS public de Google qui détectent automatiquement la compatibilité ECS sur les serveurs de noms faisant autorité, ainsi qu'aux résolveurs nécessitant une liste blanche ECS, comme OpenDNS.

Ces consignes visent à aider les opérateurs et les responsables de la mise en œuvre DNS faisant autorité à éviter de nombreuses erreurs courantes qui peuvent causer des problèmes à ECS.

Définition des termes

Nous utilisons les termes suivants pour décrire des opérations ECS:

  • Un serveur de noms implémente (ou prend en charge) ECS s'il répond aux requêtes ECS avec des réponses ECS qui ont des options ECS correspondantes (même si les options ECS ont toujours une longueur de préfixe de /0 à l'échelle mondiale).

  • Une zone est activée pour ECS si les requêtes ECS envoyées à ses serveurs de noms dont le préfixe source est différent de zéro reçoivent des réponses ECS dont le champ d'application a une valeur autre de zéro.

Consignes pour les serveurs de noms fiables

  1. Tous les serveurs de noms faisant autorité pour une zone compatible avec ECS doivent activer ECS pour la zone.

    • Même si un seul serveur de noms ne l'implémente pas ni ne l'active pour la zone, il devient rapidement la source de la plupart des données mises en cache. Étant donné que ses réponses ont un champ d'application global, elles sont utilisées (jusqu'à l'expiration de leur valeur TTL) comme réponse à toutes les requêtes portant le même nom (quel que soit le sous-réseau client). Les réponses des serveurs qui implémentent ECS et l'activent sont uniquement utilisées pour les requêtes des clients situés dans le champ d'application spécifique. Elles sont donc beaucoup moins susceptibles d'être utilisées que les réponses de niveau d'accès global.

  2. Les serveurs de noms faisant autorité qui implémentent ECS DOIVENT2 envoient des réponses ECS aux requêtes ECS pour toutes les zones desservies par une adresse IP ou un nom d'hôte NS, même pour les zones qui ne sont pas activées par ECS.

    • Le DNS public de Google détecte automatiquement la compatibilité ECS par adresse IP plutôt que par nom d'hôte de serveur de noms ou zone zonale, car le nombre d'adresses est inférieur au nombre de noms d'hôtes de serveurs de noms et beaucoup plus faible que le nombre de zones DNS. Si un serveur de noms faisant autorité n'envoie toujours des réponses ECS aux requêtes ECS (même pour les zones qui ne sont pas compatibles avec ECS), le DNS public de Google peut cesser d'envoyer ses requêtes ECS.

  3. Les serveurs de noms faisant autorité qui implémentent ECS doivent répondre à toutes les requêtes ECS par des réponses ECS, y compris les réponses négatives et les sites référents.

    • Les mêmes problèmes de détection automatique de la compatibilité d'ECS s'appliquent également ici.

    • Les réponses négatives (NXDOMAIN et NODATA) DOIVENT3 utilisent le champ d'application global /0 pour améliorer la mise en cache et la compatibilité avec la RFC 7871.

    • Outre NXDOMAIN et NODATA (avec une section de réponse vide), les autres réponses d'erreur aux requêtes ECS (en particulier SERVFAIL et REFUSED) doivent inclure une option ECS correspondante avec un champ d'application global de /0.

      • Si un serveur de noms faisant autorité tente de se débarrasser d'une attaque DoS, il peut renvoyer un SERVFAIL sans données ECS. En procédant ainsi, le DNS public de Google cessera d'envoyer des requêtes avec ECS (ce qui peut réduire le nombre de requêtes légitimes qu'il envoie, mais n'affecte pas les requêtes d'attaque aléatoire au sous-domaine). Réduire la charge de requêtes légitimes lors d'une attaque DoS peut ou non améliorer le taux de réussite des requêtes légitimes (bien que les réponses puissent être diffusées à partir du cache pour tous les clients).

        Une approche plus efficace consiste à envoyer toutes les réponses avec un champ d'application global /0 pour que le DNS public de Google continue à envoyer des requêtes ECS. Cela permet au DNS public de Google de renvoyer des réponses géolocalisées beaucoup plus rapidement après l'arrêt de l'attaque, car il n'a pas besoin de détecter la compatibilité ECS, simplement pour redemander une nouvelle requête lorsque les valeurs TTL de la portée du champ d'application global expirent.

    • Les réponses du site référent (délégation) doivent également comporter des données ECS correspondantes et DOIVENT4 utiliser un champ d'application global /0. Notez que les réponses de délégation ne sont jamais transférées aux clients dont les adresses apparaissent dans des données ECS. Par conséquent, tous les enregistrements NS, A ou AAAA géolocalisés doivent être sélectionnés par l'adresse IP du client Solver, et non par les données ECS.

  4. Les serveurs de noms faisant autorité qui implémentent ECS doivent inclure une option ECS correspondante dans les réponses à tous les types de requêtes reçus avec une option ECS. Il n'est pas suffisant de répondre aux requêtes d'adresse IPv4 (A) avec des données ECS. Les réponses aux types A, AAAA, PTR, MX ou tout autre type de requête doivent correspondre aux données ou résolveurs ECS. Dans ce cas, la réponse peut être fausse et le DNS public de Google peut cesser d'envoyer des requêtes contenant des données ECS.

    En particulier, les réponses ECS aux requêtes SOA, NS et DS doivent toujours utiliser le champ d'application global /0 pour une mise en cache améliorée et une vue cohérente de la délégation. Les réponses géolocalisées aux requêtes A/AAAA pour les noms d'hôte des serveurs de noms sont acceptées. Les réponses à tout type de requête (par exemple TXT, PTR, etc.) qui ne changent pas en fonction des données ECS ne doivent pas utiliser un champ d'application égal à la longueur du préfixe source. Elles doivent utiliser un champ d'application global /0 pour améliorer la mise en cache et réduire la charge des requêtes.

  5. Les serveurs de noms faisant autorité renvoyant des réponses CNAME compatibles avec ECS SHOULD5 n'incluent que le premier CNAME de la chaîne, et la cible finale de la chaîne CNAME doit être compatible ECS avec la même longueur de préfixe de champ d'application. En raison d'une ambiguïté de la spécification ECS, certains résolveurs récursifs (notamment Unbound6) peuvent renvoyer une réponse dont le champ d'application correspond au domaine final non CNAME (/0 s'il n'est pas compatible avec ECS).

  6. Les données ECS peuvent contenir des adresses IPv6 même pour les serveurs de noms IPv4 uniquement (et vice versa, bien que les serveurs de noms IPv6 uniquement soient rares).

    • Les serveurs de noms doivent répondre avec des données d'option ECS valides (le champ d'application 0 est acceptable, mais l'adresse source et la longueur du préfixe doivent correspondre).

    • Le paramètre ECS d'une zone peut être activé séparément pour les adresses IPv4 et IPv6.

  7. Les serveurs de noms fiables qui renvoient des réponses compatibles avec ECS NE DOIVENT PAS7 chevaucher les préfixes de leurs champs d'application. Voici un exemple de préfixes de champ d'application qui se chevauchent:

    • Requête avec le préfixe source 198.18.0.0/15 : réponse A avec le préfixe de champ d'application 198.0.0.0/8

    • Requête avec le préfixe source 198.51.100/24 : réponse B avec le préfixe de champ d'application 198.51.0.0/16

    Si un client interroge un résolveur récursif compatible ECS dans l'ordre ci-dessus, les deux requêtes peuvent obtenir la réponse A, car le champ d'application de la réponse mise en cache A inclut le champ d'application du préfixe de la deuxième requête. Même si les requêtes client sont effectuées dans l'ordre inverse et que les deux requêtes sont transmises à des serveurs de noms faisant autorité, les réponses mises en cache peuvent expirer à des moments différents. Les requêtes suivantes envoyées au résolveur récursif du préfixe 198.51.100/24 qui se chevauchent peuvent obtenir la réponse A ou B.

  8. Lorsque vous implémentez la compatibilité ECS pour la première fois sur les serveurs de noms, utilisez de nouvelles adresses IP pour les serveurs de noms desservant ces zones activées ECS.

    • Lorsque les serveurs de noms faisant autorité qui ont mis en œuvre ECS, mais ont renvoyé des résultats de champ d'application global, commencent à renvoyer des réponses ECS activées pour une zone, le DNS public de Google commence à renvoyer des réponses géolocalisées aux requêtes dès que les valeurs TTL des réponses globales précédentes expirent.

    • La détection automatique de la compatibilité ECS par le DNS public de Google tente très rarement d'exécuter des requêtes ECS pour une adresse IP (ou le nom d'hôte du serveur de noms) lorsqu'elle détecte automatiquement un manque de compatibilité ECS (délai avant expiration, FORMERR, BADVERS ou envoi de réponses autres qu'ECS). Les nouvelles implémentations ECS sur ces adresses IP (ou noms d'hôte NS) sont détectées automatiquement très lentement, voire pas du tout.

  9. Assurez-vous que les connexions réseau sont fiables et que la limitation du taux de réponse est suffisamment élevée pour que les serveurs de noms n'abandonnent pas les requêtes (ou pire, répondent avec des erreurs sans option ECS correspondante).

    • Pour les serveurs de noms qui implémentent une limitation du taux de réponse pour les requêtes ECS, la meilleure réponse est NODATA avec l'option troncature (TC) définie. Elle ne contient qu'une section de question correspondante et une option ECS correspondante.

  10. Envoyez des réponses rapides à toutes les requêtes (idéalement, dans la seconde qui suit).

    • L'utilisation de services de recherche en géoadresses IP en ligne pour des requêtes ECS ne fonctionne pas de manière fiable, car la latence cumulée de la requête DNS et du service d'adresses IP en ligne est susceptible de ne pas dépasser une seconde. La détection automatique de la compatibilité ECS par le DNS public de Google considère que les réponses différées indiquent une compatibilité ECS faible ou incomplète, et réduit le risque que de futures requêtes soient envoyées avec ECS. Si suffisamment de réponses sont retardées, l'envoi de requêtes ECS est interrompu.

Références RFC 7871 et autres notes de bas de page

1 https://tools.ietf.org/html/rfc7871#page-12

FAMILY, SOURCE PREFIX-LENGTH, and ADDRESS in the response MUST match those in the query. Echoing back these values helps to mitigate certain attack vectors, as described in Section 11.

2 https://tools.ietf.org/html/rfc7871#section-7.2.1

An Authoritative Nameserver that implements this protocol and receives an ECS option MUST include an ECS option in its response to indicate that it SHOULD be cached accordingly, regardless of whether the client information was needed to formulate an answer.

3 https://tools.ietf.org/html/rfc7871#section-7.4

It is RECOMMENDED that no specific behavior regarding negative answers be relied upon, but that Authoritative Nameservers should conservatively expect that Intermediate Nameservers will treat all negative answers as /0; therefore, they SHOULD set SCOPE PREFIX-LENGTH accordingly.

4 https://tools.ietf.org/html/rfc7871#section-7.4

The delegations case is a bit easier to tease out. In operational practice, if an authoritative server is using address information to provide customized delegations, it is the resolver that will be using the answer for its next iterative query. Addresses in the Additional section SHOULD therefore ignore ECS data, and the Authoritative Nameserver SHOULD return a zero SCOPE PREFIX-LENGTH on delegations.

5 https://tools.ietf.org/html/rfc7871#page-12

For the specific case of a Canonical Name (CNAME) chain, the Authoritative Nameserver SHOULD only place the initial CNAME record in the Answer section, to have it cached unambiguously and appropriately. Most modern Recursive Resolvers restart the query with the CNAME, so the remainder of the chain is typically ignored anyway.

6 https://unbound.net/pipermail/unbound-users/2015-May/003875.html

Il n'y a aucun danger à utiliser le champ d'application du domaine final dans une chaîne CNAME, car il est généralement déployé en tant que résolveur local de transfert ou résolveur de transfert, où tous les clients se trouvent dans le même sous-réseau et reçoivent la même réponse.

7 https://tools.ietf.org/html/rfc7871#page-13

Authoritative Nameservers might have situations where one Tailored Response is appropriate for a relatively broad address range, such as an IPv4 /20, except for some exceptions, such as a few /24 ranges within that /20. Because it can't be guaranteed that queries for all longer prefix lengths would arrive before one that would be answered by the shorter prefix length, an Authoritative Nameserver MUST NOT overlap prefixes.

When the Authoritative Nameserver has a longer prefix length Tailored Response within a shorter prefix length Tailored Response, then implementations can either:

  1. Deaggregate the shorter prefix response into multiple longer prefix responses, or

  2. Alert the operator that the order of queries will determine which answers get cached, and either warn and continue or treat this as an error and refuse to load the configuration.

…

When deaggregating to correct the overlap, prefix lengths should be optimized to use the minimum necessary to cover the address space, in order to reduce the overhead that results from having multiple copies of the same answer. As a trivial example, if the Tailored Response for 1.2.0/20 is A but there is one exception of 1.2.3/24 for B, then the Authoritative Nameserver would need to provide Tailored Responses for 1.2.0/23, 1.2.2/24, 1.2.4/22, and 1.2.8/21 all pointing to A, and 1.2.3/24 to B.