Résumé

  • Le RRL réduit les réponses similaires répétées d’un serveur faisant autorité lorsque des requêtes UDP falsifiées pourraient en faire un amplificateur.
  • Le rôle de Paul Vixie est important mais collectif : ISC évoque des séances de stratégie défensive avec lui, et un ticket BIND cite aussi Vernon Schryver.
  • Le mécanisme regroupe des catégories de réponses et des plages d’adresses. Ce regroupement régule le trafic ; il n’identifie ni l’émetteur ni son intention.

La réponse peut devenir la charge utile

Dans une attaque par réflexion DNS, une requête atteint un serveur faisant autorité avec l’adresse de la victime comme fausse adresse source. La réponse du serveur est alors envoyée à cette victime. Si elle est bien plus volumineuse que la requête, l’attaquant mobilise le serveur pour expédier davantage de données qu’il n’en a lui-même émises.

La présentation d’ISC en 2014 illustre ce mécanisme : une requête ANY de 36 octets pour isc.org pouvait produire une réponse de 3 576 octets. C’est un exemple parlant, pas un facteur d’amplification valable pour tout le DNS. Le volume varie selon la question, le contenu de la zone, DNSSEC, le transport et la réponse obtenue. Le problème opérationnel est plus circonscrit : combien de réponses répétées et semblables un serveur faisant autorité doit-il continuer à envoyer quand les requêtes se ressemblent ?

ISC indique que des séances de stratégie défensive avec Paul Vixie ont conduit au RRL. Un ticket de développement de BIND attribue le correctif BIND 9 à Vixie et Vernon Schryver. Les sources attestent donc l’implication majeure de Vixie, pas une invention solitaire. Le RRL est issu d’un travail pratique associant une équipe, une implémentation et des réglages ultérieurs.

Le profil de l’Internet Hall of Fame replace cet épisode dans une carrière plus large consacrée au DNS. Il indique que Vixie a commencé à maintenir BIND 4 chez Digital Equipment Corporation en 1988, puis est devenu l’auteur principal et l’architecte technique de BIND 8. Il a également fondé MAPS, PAIX et l’Internet Software Consortium, et préparé un doctorat à Keio University portant sur le DNS et DNSSEC. Ces jalons éclairent l’étendue de son travail sans effacer le crédit partagé du correctif RRL, qui nomme aussi Schryver.

BIND 9.9.4 a introduit le RRL comme option de compilation. La page d’ISC « BIND 9.10 Significant Changes » indique que le RRL a ensuite rejoint la configuration de compilation par défaut. Cela décrit la disponibilité de la fonction dans BIND, pas son activation par tous les exploitants ni le comportement de tous les logiciels DNS.

Un compartiment mesure la ressemblance, pas l’identité

Le manuel actuel de BIND 9.20.29 décrit des compartiments de jetons ou de crédits construits autour de réponses similaires et de clients DNS. Chaque réponse consomme des crédits, reconstitués au rythme configuré pendant une fenêtre donnée. L’exploitant peut limiter différentes classes : réponses non vides, NODATA, NXDOMAIN, références, erreurs ou ensemble des réponses UDP. Au-delà du seuil, BIND peut abandonner ou modifier certaines réponses.

Le mot « client » dissimule un choix de politique. Les paramètres par défaut documentés de BIND regroupent les adresses IPv4 par /24 et IPv6 par /56 : les adresses d’un bloc sont comptabilisées ensemble. Un résolveur, une entreprise, un campus ou un fournisseur d’accès peut placer de nombreux utilisateurs sans lien entre eux derrière le même préfixe. Si l’un d’eux dépasse le seuil, un autre peut recevoir une réponse retardée, tronquée ou absente.

Cela ne rend pas le regroupement par préfixe nécessairement mauvais. Une limitation adresse par adresse peut être contournée en répartissant les requêtes ; le serveur doit aussi répartir sa capacité de sortie pendant une attaque. Le préfixe, la classe de réponse et le débit sont des réglages qui ont un coût en disponibilité. Ils constituent une politique d’exploitation explicite, pas une observation neutre de l’identité réelle du client.

Le paramètre slip de BIND rend le compromis visible. Avec slip=2, valeur par défaut documentée, une requête sur deux limitée et dépourvue de cookie serveur valide reçoit une réponse réduite : BADCOOKIE si le client a présenté un cookie, sinon le bit de troncature demande un nouvel essai en TCP. Certaines erreurs ne peuvent pas être tronquées et sont transmises au rythme de slip. slip=1 transmet une réponse tronquée pour chaque réponse limitée, privilégiant l’intégrité et la livraison au détriment de la suppression maximale du trafic de réflexion ; slip=0 abandonne toutes les réponses limitées. La voie de nouvel essai fait partie du dispositif.

Le rôle du service change le coût

ISC recommande le RRL pour les serveurs faisant autorité. Sa documentation avertit qu’un déploiement récursif peut créer des faux positifs et ralentir les clients qui interrogent souvent les mêmes noms ; il vaut mieux fermer la récursion ouverte que s’en remettre au RRL. La même fonction n’a pas le même coût lorsqu’elle répond à des requêtes faisant autorité ou sert les utilisateurs finaux.

BIND propose log-only afin d’observer des seuils envisagés avant leur application. Les compteurs comprennent RateDropped, QryDropped, RateSlipped et RespTruncated. Ils décrivent l’action du mécanisme configuré, mais ne révèlent pas l’identité de l’attaquant. Une adresse source peut être usurpée et l’appartenance à un compartiment ne constitue pas une attribution.

La Note 65 de Heng Lu sert ici de prisme éditorial : le comportement en fonctionnement montre ce qu’une implémentation contrôle réellement. Elle n’apporte aucun fait historique sur Vixie ni aucun fait technique sur le RRL. Pour cette fonction, les éléments utiles sont la version de BIND déployée, sa configuration, les compteurs et le comportement des clients lors des nouvelles tentatives — pas la simple présence d’une directive dans un document.

La conclusion doit rester mesurée. Le RRL peut réduire la contribution d’un serveur faisant autorité à un flux de réponses répétées utilisé en réflexion. Il peut aussi regrouper des utilisateurs légitimes et arbitrer entre livraison et suppression. Il n’authentifie pas les requêtes, ne prouve pas une intention, ne mesure pas l’adoption générale et ne garantit pas qu’une victime ne recevra aucun trafic réfléchi. Vixie a contribué à transformer une défense opérationnelle en mécanisme configurable dont les exploitants peuvent examiner les limites.

Sources