La meilleure façon de protéger les données contre la surveillance, c'est de ne pas avoir de données. Ce principe de base de la protection de la vie privée est souvent oublié. C'est pourtant un des deux piliers de la confidentialité, avec la protection technique des données. Le DNS a pendant longtemps transmis trop de données, et ce RFC décrit une technique qui va limiter les fuites, la QNAME minimisation, ou « réduction de la question posée ». [...]

Si vous regardez les vidéos sur le fonctionnement du DNS (comme celle-ci) ou lisez les textes expliquant « le DNS pour les nuls », vous y trouverez souvent une fausse explication de la résolution DNS, où les serveurs faisant autorité ne reçoivent que la question strictement nécessaire. Ainsi, dans la vidéo citée ci-dessus, le serveur de la racine reçoit une question où ne figure que le TLD. Mais la réalité du DNS, aujourd'hui, est tout autre : les serveurs faisant autorité reçoivent la totalité de question originale. Ainsi, si vous visitez www.alcooliques-anonymes.fr, la racine voit que vous vous intéressez à l'alcoolisme, alors que ce n'était nullement nécessaire pour son travail (puisqu'elle ne connait que les TLD). Si votre logiciel BitTorrent demande _bittorrent-tracker._tcp.domain.example, les serveurs faisant autorité pour .example sauront que vous faites du BitTorrent, alors qu'ils ne connaissaient que les domaines situés immédiatement sous .example. [...]

Dans le dernier cas, pour que la résolution se passe bien, il aurait suffit de demander à la racine « quels sont les serveurs de noms de .example » et à ces serveurs « quels sont les serveurs de noms de domain.example ». C'est le principe de base de la QNAME minimisation.

Bien sûr, on pourrait chiffrer le trafic DNS (et le groupe de travail DPRIVE de l'IETF travaille précisément sur ce sujet). Mais cela ne protège que contre un tiers écoutant le réseau : les serveurs faisant autorité verraient quand même les données et pourraient en faire ce qu'ils veulent. [...] Lorsqu'on parle de vie privée, pas mal d'informaticiens réagissent en criant « cryptographie ! » alors que celle-ci ne protège pas contre tout et notamment pas contre le serveur à qui on parle.

Et pourquoi est-ce que les résolveurs DNS envoyaient la question complète (full QNAME où QNAME veut dire Query NAME) ? Uniquement parce que la protection de la vie privée n'était pas tellement prise en compte à l'époque ? Pas uniquement : il y avait quelques raisons techniques spécifiques à l'époque (le RFC les détaille mais, surtout, il ne faut pas oublier que toutes les décisions concernant le DNS n'ont pas forcément été mûrement réfléchies).

Pour les personnes curieuses comme moi, cette raison est :

Sending the full QNAME to the authoritative name server is a tradition, not a protocol requirement. In a conversation with the author in January 2015, Paul Mockapetris explained that this tradition comes from a desire to optimise the number of requests, when the same name server is authoritative for many zones in a given name (something that was more common in the old days, where the same name servers served .com and the root) or when the same name server is both recursive and authoritative (something that is strongly discouraged now). Whatever the merits of this choice at this time, the DNS is quite different now.

On retrouve toujours ce principe d'optimisation dans la gestion des glue record par Verisign, voir http://www.guiguishow.info/2013/09/11/dns-glue-records-netcomorg-et-error-2003/ .

Revenons au billet de blog :

La section 2 décrit la QNAME minimisation. Elle est mise en œuvre dans le résolveur DNS (aucun changement n'est fait dans le serveur faisant autorité, la QNAME minimisation ne change pas le protocole DNS). [...]

Les experts en DNS ont noté un problème : il n'y a pas forcément un jeu de serveurs faisant autorité pour chaque composant. Si je prends www.st-cyr.terre.defense.gouv.fr, il n'y a par exemple aujourd'hui pas de serveurs de noms pour gouv.fr, ce sont ceux de .fr. En termes techniques, il n'y a pas de limite de zone (zone cut, cf. RFC 2181, section 6) à chaque composant. Dans le cas de ce dernier nom, il y a une limite de zone entre la racine et .fr, une autre entre fr et defense.gouv.fr mais pas entre .fr et gouv.fr. Un résolveur qui veut faire de la QNAME minimisation doit donc tenir compte des limites de zone. S'il valide avec DNSSEC, pas de problème, il les connait déjà, car leur connaissance est nécessaire au bon fonctionnement de DNSSEC. Sinon, il doit les trouver tout seul, par exemple avec l'algorithme de l'annexe A.

La QNAME minimisation ne change pas le protocole DNS. Elle ne pose donc pas de problème avec les vieux serveurs. En théorie car, en pratique, il existe pas mal de serveurs incorrects qui ne suivent pas les règles et poseront quelques problèmes (section 3 du RFC, voir aussi un intéressant exposé et un « storify » d'une discussion.) Le problème n'est en général pas dû aux serveurs en logiciel libre sérieux qui forment l'essentiel de l'infrastructure du DNS (BIND, NSD, Knot...) mais plutôt aux appliances boguées que certains s'obstinent à placer devant des serveurs qui marcheraient parfaitement autrement. C'est par exemple le cas de certains répartiteurs de charge qui répondent aux requêtes pour certains QTYPE mais qui échouent lorsque le QTYPE vaut NS (répondant, par exemple REFUSED). Pire, certains ne répondent pas du tout, comme ceux de www.ratp.fr. Il s'agit bien d'une bogue, et qui cause plein de problèmes, pas seulement à la QNAME minimisation.

Un autre problème est celui des serveurs bogués (comme djbns) qui ne réagissent pas correctement aux ENT. Qu'est-ce qu'un ENT ? Un Empty Non-Terminal (terme décrit dans le RFC 7719, section 6) est un domaine qui n'a pas d'enregistrements DNS mais qui a des sous-domaines qui en ont. gouv.fr, cité plus haut, est un ENT mais ceux-ci sont particulièrement fréquents sous ip6.arpa. Normalement, la bonne réponse à un ENT est le code NOERROR, sans enregistrements (ce qu'on appelle parfois NODATA, bien que ce dernier ne soit pas un code de retour explicite dans le DNS). Mais certains serveurs boguées répondent à la place NXDOMAIN, code qui indique normalement que le domaine n'existe pas (ce qui est faux). [...] Le résolveur qui se fierait à ce NXDOMAIN croirait alors que sa recherche est terminée et que le nom demandé n'existe pas. C'est pour cela que les mises en œuvre existantes de la QNAME minimisation ont des comportements spécifiques pour les réponses NXDOMAIN, pour contourner cette bogue. [...] Pour se protéger contre les serveurs bogués dont je parlais plus haut (ceux qui répondent NXDOMAIN en cas d'ENT), Knot réessaie avec le QNAME complet lorsqu'il reçoit un NXDOMAIN (les deux dernières lignes). Mauvais pour la vie privée mais sans doute nécessaire aujourd'hui. [...]

Sauf erreur de ma part, le code de retour à utiliser pour un ENT est aussi peu normalisé que l'est l'envoi du QNAME complet par le récursif-cache…

Et les performances ? Elles seront parfois meilleures et parfois pires, avec la QNAME minimisation. Meilleures car le résolveur enverra moins de requêtes aux serveurs faisant autorité. Aujourd'hui, si un résolveur reçoit trois requêtes successives, pour A.example, B.example et C.example, les trois requêtes seront envoyées aux serveurs racine, et donneront toutes les trois un NXDOMAIN (puisque .example n'est pas délégué). Avec la QNAME minimisation, seule la première requête déclenchera une demande à la racine, pour le nom example. Cela suffira au résolveur.

Par contre, les performances peuvent se dégrader dans certains cas. Si un nom comporte beaucoup de composants (c'est fréquent dans ip6.arpa), la recherche initiale des limites de zone nécessitera bien plus de paquets. Ceci dit, cela ne durera que le temps de remplir le cache, tout ira plus vite après, une fois que le résolveur connaitra les limites de zone.

À noter que Verisign a un brevet dont ils prétendent qu'il couvre la QNAME minimisation. Ils promettent une licence (attention, le diable est dans les détails) gratuite et non-discriminatoire. Ces brevets ont bien perturbé la réflexion du groupe de travail. Personnellement, je pense que ce brevet n'a pas de sens : l'idée de QNAME minimisation est évidente et avait déjà été discuté plusieurs fois, mais sans laisser de trace écrite précise, ce qui permet à Verisign de prétendre qu'il n'y a pas de prior art. Ce n'est sans doute pas un hasard si les deux premières mises en œuvre de la QNAME minimisation ont été faites en Europe, où il n'y a (normalement) pas de brevet logiciel. [...]

LOL… … … C'est tellement désolant.

La QNAME minimisation est mise en œuvre dans Unbound et dans le résolveur Knot [...]

Pas encore dans BIND mais qui ose encore utiliser BIND en tant que récursif-cache ?!

Unbound a la QNAME minimisation depuis la version 1.5.7 (sortie en décembre 2015, cf. l'historique de ce travail). Ce n'est pas activé par défaut, il faut mettre dans la configuration :

server:
qname-minimisation: yes

Pour vérifier si votre résolveur met bien en œuvre la QNAME minimisation, vous pouvez tester avec le domaine qnamemintest.internet.nl. Ici, le résolveur est un Unbound récent :

% dig +nodnssec +short TXT qnamemintest.internet.nl

Bon, on n'a pas encore la bonne version de Unbound dans Debian stable (à la prochaine stable, stretch). En attendant, on peut tester en utilisant les backports. Évidemment, ce n'est pas pour mettre en production vu que l'équipe de la sécurité de Debian ne s'occupe pas des backports. Ça fait depuis début 2016 que j'avais envie de tester, c'est désormais chose faite. C'est plutôt amusant parce que, comme le fait remarquer Stéphane, le comportement d'un récursif utilisant la qname minimisation est celui qui est décrit, à tort, dans bon nombre de ressources documentaires pour débutant-e-s (genre Wikipedia fr :- ).