Le 03/01/2015 20:41, Stephane Bortzmeyer a écrit : > Ces résolveurs ouverts sont une très mauvaise idée, ils servent > souvent de réflecteurs pour des attaques DoS
Ces récursifs ouverts gérés et supervisés de la moins mauvaise manière sont un compromis entre plusieurs notions dont liberté et sécurité. Ils sont un moindre mal, un point d'équilibre. Je ne reviendrai pas sur les avantages (et limites) de tels récursifs, j'ai déjà présenté mes arguments dans le billet cité par Julien dans ce même thread. Soyons clair : ici, on ne parle *PAS* de récursifs ouverts par méconnaissance/négligence et oubliés. Je pense que j'enfonce des portes ouvertes. Ce qui me dérange dans cet obscurantisme ou, au minimum, cette absence de documentation émanant de ceux (DNS OARC, par exemple) qui savent, de par leur expérience, configurer des récursifs ouverts gérés et supervisés sains, c'est que ça va à l'encontre de l'objectif que ces personnes/organisations souhaitent atteindre : en plus des récursifs ouverts par méconnaissance/négligence, on doit lutter contre les récursifs gérés ouverts par pure volonté mais mal configurés à cause justement de l'absence de documentation "how-to". Des personnes ont envie de mettre en place des récursifs ouverts mais ne trouvent pas de documentation complète et potable d'où des récursifs ouverts chaotiques voire dangereux. Cela se voit particulièrement à chaque épisode de censure administrative/judiciaire. On ne peut pas arrêter les personnes déterminées à agir, d'autant plus que la cause est noble, donc pourquoi ne pas proposer une documentation complète qui fait consensus sur « comment configurer un récursif ouvert sain » ? La configuration par défaut des principaux logiciels serveurs DNS sont sécurisées (fermées) depuis longtemps dans les principales familles de systèmes (GNU/Linux, *BSD, ...), de la prévention pour les récursifs ouverts négligemment et de la documentation pour les demandeurs de récursifs ouverts délibérément, ça ne peut pas être pire et ça permet d'agir sur l'ensemble de la typologie des récursifs ouverts. Juste mon avis. > comme celle dont vient d'être victime OVH Les tweets m'évoquent un pot-pourri donc si je devais réagir de la sorte, je dirais : interdisons les serveurs DNS qui font autorité sans RRL, les pools NTP gérés et supervisés, le matos Juniper et, pourquoi pas tout serveur web ouvert. :) Dit autrement : en l'absence de statistiques publiques plus détaillées, difficile de se faire un avis sur la partie de l'attaque imputable à des récursifs DNS ouverts, sujet de la présente causerie. > Le RFC 5358 dit bien qu'il faut les éviter (mon résumé en > <http://www.bortzmeyer.org/5358.html>) Mais pas les interdire complètement sinon on empêche de faire des choses bien, utiles et avec un risque limité. > D'autre part, rien ne garantit l'intégrité des réponses : même si on > a confiance dans les gérants du résolveur, le trajet est long, et les > paquets UDP pas signés... Récursif local (réseau ou machine) validant qui forward à un récursif mutualisé comme ceux indiqués ci-dessus. Ainsi on a morale/éthique/transparence et intégrité avec un impact minimal sur les serveurs DNS qui font autorité. En attendant qu'un plus grand nombre de zones soient signées, les récursifs présentés ci-dessus ne sont pas pire que ceux des grands FAI commerciaux (niveau morale/éthique/transparence) ou que Google Public DNS/OpenDNS/autre_prestataire (point de vue morale/éthique/transparence fluctuante par le passé et intégrité). Ces récursifs ouverts "de confiance" (ça dépend de l'observateur, comme d'habitude) sont aussi utiles pour mutualiser un cache quand on parle d'avoir un récursif (fermé) à la maison : <http://www.bortzmeyer.org/son-propre-resolveur-dns.html>. ;) > Et je ne parle même pas de confidentialité > <https://tools.ietf.org/html/draft-ietf-dprive-problem-statement> Certes, les récursifs ouverts gérés et supervisés ne vont pas rendre les poils plus soyeux, résoudre la faim dans le monde ou bien encore enlargir les pénis. :) > Une bonne partie des résolveurs cités dans la page à laquelle tu > faisais référence suivent les préconisations de rigueur > (supervision, rate-limit, etc) En effet : - FDN : rate-limiting des requêtes portant sur le QTYPE ANY et une adresse mail de contact valide. Le reste n'est pas porté à ma connaissance. - ARN/LDN : rate-limiting strict (1 r/s, 2r/s burst) des requêtes portant sur le QTYPE ANY, rate-limiting global 10r/s, 20r/s, limitation de la taille max des réponses fournies sur UDP, adresse mail de contact valide, supervision. - Le reste n'est pas porté à ma connaissance mais une piste est donnée ici : <https://lists.ffdn.org/wws/arc/diy-isp/2014-08/msg00006.html> --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
