diff options
author | neodarz <neodarz@neodarz.net> | 2017-03-10 11:58:22 +0100 |
---|---|---|
committer | neodarz <neodarz@neodarz.net> | 2017-03-10 11:58:22 +0100 |
commit | bc1d70343807104ccf64b6bde9b2db54270203ff (patch) | |
tree | 122467d5cad8688bc609a1509e922dce5d70d391 /RFC_8027_DNSSEC_Roadblock_Avoidance.txt | |
download | read_it_later-master.tar.xz read_it_later-master.zip |
Diffstat (limited to '')
-rw-r--r-- | RFC_8027_DNSSEC_Roadblock_Avoidance.txt | 301 |
1 files changed, 301 insertions, 0 deletions
diff --git a/RFC_8027_DNSSEC_Roadblock_Avoidance.txt b/RFC_8027_DNSSEC_Roadblock_Avoidance.txt new file mode 100644 index 0000000..7e1e667 --- /dev/null +++ b/RFC_8027_DNSSEC_Roadblock_Avoidance.txt @@ -0,0 +1,301 @@ +Titre: RFC 8027: DNSSEC Roadblock Avoidance +Auteur: +Date: Sun 04 Dec 2016 01:00:00 +0100 +Lien: https://www.bortzmeyer.org/8027.html + +Normalement, en 2016, tous les résolveurs DNS sérieux devraient valider avec +DNSSEC. Mais ce n'est pas le cas. Il y a plusieurs raisons à cela, mais ce +nouveau RFC se focalise sur un problème précis : le cas d'un résolveur connecté +via un réseau pourri, non-neutre, et qui se permet d'interférer avec le +transport des paquets IP, menant le résolveur à de sérieuses difficultés. +Comment détecter ces réseaux pourris ? Et que faire pour valider quand même ? + +Si le résolveur est une grosse machine dans un centre de données, connectée +directement à des opérateurs neutres, il n'y a pas trop de problème. C'est le +cas des résolveurs des FAI, par exemple. Mais la situation est bien moins +favorable à M. Michu. Si celui-ci veut, à juste titre[1], avoir son propre +résolveur DNS sur sa machine, il dépend des réseaux où on laisse M. Michu se +connecter, et ceux-ci sont rarement neutres. (Le RFC couvre le cas où ce +résolveur local fait suivre - forwarde - les requêtes à un autre résolveur, et +celui où il parle directement aux serveurs faisant autorité.) + +La section 1.2 du RFC décrit les cas où la validation DNSSEC va être difficile +ou impossible : + + * Résolveur qui ne connait pas DNSSEC (évidemment), + * Intermédiaires (relais DNS dans la box, par exemmple), qui viole le + protocole DNS au point de gêner le fonctionnement de DNSSEC (ce cas est + décrit en détail dans le RFC 5625), + * Équipements réseau actifs qui modifient ou bloquent les messages DNS, par + exemple en supprimant les signatures DNSSEC (beaucoup de « firewalls » sont + dans ce cas), + * Réseau qui ne gère pas correctement les fragments, ce qui est plus fréquent + avec DNSSEC. + +Bien des outils ont été développés pour contourner ces problèmes, comme +dnssec-trigger[2]. + +Pour faire des tests des résolveurs et de tous les équipements intermédiaires +qui peuvent poser des problèmes de validation DNSSEC dans certains cas, le RFC +parle d'une zone de test nommée test.example.com. Elle n'existe pas en vrai +mais, aujourd'hui, la zone test.dnssec-tools.org fait la même chose (elle est +par exemple utilisée pour les travaux pratiques lors de la formation DNSSEC +chez HSC[3]). Cette zone est délibérement peuplée avec des noms mal signés. +Ainsi, le nom badsign-aaaa.test.dnssec-tools.org a un enregistrement AAAA dont +la signature a été modifiée, la rendant invalide. Testons (pour tous les tests, +comme le but était de voir le comportement DNSSEC, j'ai utilisé un fichier de +configuration ~/.digrc contenant +dnssec +multiline, merci à Landry Minoza de +l'avoir remarqué) : + + +% dig AAAA badsign-aaaa.test.dnssec-tools.org +; <><>>> DiG 9.9.5-9+deb8u8-Debian <><>>> AAAA badsign-aaaa.test.dnssec-tools.org +;; global options: +cmd +;; Got answer: +;; ->>HEADER<><>- opcode: QUERY, status: SERVFAIL, id: 60910 +;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 + +;; OPT PSEUDOSECTION: +; EDNS: version: 0, flags: do; udp: 4096 +;; QUESTION SECTION: +;badsign-aaaa.test.dnssec-tools.org. IN AAAA + +;; Query time: 3759 msec +;; SERVER: 127.0.0.1#53(127.0.0.1) +;; WHEN: Sun Dec 04 17:12:28 CET 2016 +;; MSG SIZE rcvd: 63 + + +% dig +cd AAAA badsign-aaaa.test.dnssec-tools.org +; <><>>> DiG 9.9.5-9+deb8u8-Debian <><>>> +cd AAAA badsign-aaaa.test.dnssec-tools.org +;; global options: +cmd +;; Got answer: +;; ->>HEADER<><>- opcode: QUERY, status: NOERROR, id: 29404 +;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 5 + +;; OPT PSEUDOSECTION: +; EDNS: version: 0, flags: do; udp: 4096 +;; QUESTION SECTION: +;badsign-aaaa.test.dnssec-tools.org. IN AAAA + +;; ANSWER SECTION: +badsign-aaaa.test.dnssec-tools.org. 86400 IN AAAA 2001:470:1f00:ffff::1 +badsign-aaaa.test.dnssec-tools.org. 86400 IN RRSIG AAAA 5 4 86400 ( + 20170101064820 20161202054820 19442 test.dnssec-tools.org. + nZ8bPLBleW/sW6x135+Iz4IhO6Lr04V8C9fC1bMVfCVY + 3rKqbOoBk1i+wnnGDCTWQ5iCicWTKLIpbDmCSW9C33pj + P2j7C/ensspbdwpD/7Ia8zN+XUSN+ThLU6lgYGKFuoVL + QmIG/vr1lOn6xdjXY2E4mStAjaGuertvKKDYy/I= ) + +;; AUTHORITY SECTION: +test.dnssec-tools.org. 280 IN NS dns1.test.dnssec-tools.org. +test.dnssec-tools.org. 280 IN NS dns2.test.dnssec-tools.org. +test.dnssec-tools.org. 280 IN RRSIG NS 5 3 86400 ( + 20170101064820 20161202054820 19442 test.dnssec-tools.org. + AK95JOAuvfZ1ZwEsrKiR8DP1zluoBvBkXHRXa78rrK5U + UuZdLnZwnYlnNplrZZOrQNuUaPyb4zI0TGfw/+aa/ZTU + qyx8uQODSHuBTPQTlcmCFAfTIyd1Q+tSTEs2TuGUhjKe + H9Hk+w6yOjI/o52c2OcTMTJ4Jmt2GlIssrrDlxY= ) + +;; ADDITIONAL SECTION: +dns1.test.dnssec-tools.org. 280 IN A 168.150.236.43 +dns2.test.dnssec-tools.org. 280 IN A 75.101.48.145 +dns1.test.dnssec-tools.org. 86400 IN RRSIG A 5 4 86400 ( + 20170101064820 20161202054820 19442 test.dnssec-tools.org. + zoa0V/Hwa4QM0spG6RlhGM6hK3rQVALpDve1rtF6NvUS + Sb6/HBzQOP6YXTFQMzPEFUza8/tchYp5eQaPBf2AqsBl + i4TqSjkIEklHohUmdhK7xcfFjHILUMcT/5AXkEStJg7I + 6AqZE1ibcOh7Mfmt/2f0vj2opIkz6uK740W7qjg= ) +dns2.test.dnssec-tools.org. 86400 IN RRSIG A 5 4 86400 ( + 20170101064820 20161202054820 19442 test.dnssec-tools.org. + hGq7iAtbHrtjCYJGMPQ3fxijhu4Izk8Ly+xZOa0Ag24R + lqpFgdd2amDstFVLTRs3x15UqQIO+hmFdlbSOterDkbg + /o2/FhtZOJr7c75Pu3EWi/DDbT9pULk4Uwjlie1QBopv + LLZ94SlqKO7eQ02NRyy5EL4gD2G5rSffsUqEkj8= ) + +;; Query time: 206 msec +;; SERVER: 127.0.0.1#53(127.0.0.1) +;; WHEN: Sun Dec 04 17:12:44 CET 2016 +;; MSG SIZE rcvd: 885 + +Le second test, celui fait avec le bit CD (Checking Disabled), montre que le +problème vient bien de DNSSEC. Autre test, avec une signature expirée : + + +% dig A pastdate-a.test.dnssec-tools.org +... +;; ->>HEADER<><>- opcode: QUERY, status: SERVFAIL, id: 46319 +... + + +% dig +cd A pastdate-a.test.dnssec-tools.org +... +;; ->>HEADER<><>- opcode: QUERY, status: NOERROR, id: 49547 +;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 5 +... +;; ANSWER SECTION: +pastdate-a.test.dnssec-tools.org. 86400 IN A 64.90.35.104 +pastdate-a.test.dnssec-tools.org. 86400 IN RRSIG A 5 4 86400 ( + 20161201224321 20161101234821 19442 test.dnssec-tools.org. + lIL0zcEZpG/4uG5hImvpivH1C/D3PFI3RNYHlPbZ [...] + +La liste de tous les noms à tester est en ligne[4]. + +Le but de ce RFC est de lister tous les tests que peut et devrait faire un +validateur local, pour arriver à valider malgré des résolveurs amont, ou bien +un réseau, hostile. Ces stratégies sont mises en œuvre, par exemple, dans +dnssec-trigger[2]. + +En détectant la non-conformité (compliance, un terme à la mode dans les +organisations), le validateur situé sur la machine terminale, ou bien dans le +réseau local, peut alors adopter la meilleure stratégie de contournement (ou, +dans le pire des cas, prévenir loyalement l'utilisateur qu'on ne pourra pas +faire de validation DNSSEC). Les tests doivent être faits au début d'une +nouvelle connexion réseau, ou bien lorsque celle-ci change. + +La section 3 du RFC est consacrée à ces tests de non-conformité. Je ne vais pas +décrire la totalité de ces tests, un sous-ensemble suffira. Ainsi, le premier +test, le plus trivial, est que la machine puisse parler en UDP à son résolveur +attitré (celui typiquement reçu en DHCP). On lui demande +good-a.test.dnssec-tools.org et on doit avoir une réponse sous forme d'une +adresse IP (comme son nom l'indique, ce nom est correctement signé). Si un test +aussi trivial ne marche pas, ce n'est sans doute pas la peine d'aller plus +loin. Un peu plus subtil, on teste le même résolveur en TCP. + +Après, on passe à EDNS (RFC 6891), qui est indispensable pour DNSSEC. Une +requête pour ce même nom, mais avec une option EDNS, doit passer. Si EDNS ne +marche pas, on peut arrêter, DNSSEC ne marchera pas non plus. Mais s'il +marche ? On teste alors avec le bit DO (DNSSEC OK) qui indique au serveur qu'il +doit envoyer les données DNSSEC, notamment les signatures. La réponse doit +inclure ce même bit DO. (C'est plus tard qu'on teste qu'on a bien reçu des +signatures. Rappelez-vous que la plupart des middleboxes sont horriblement +boguées. Certaines acceptent le bit DO et le renvoient, sans pour autant +transmettre les signatures.) + +On teste alors des zones qu'on sait signées et on regarde si le résolveur met +le bit AD (Authentic Data), au moins pour les algoritmes RSA + SHA-1 et RSA + +SHA-256. Si cela ne marche pas, ce n'est pas forcément une erreur fatale, +puisque, de toute façon, on voulait faire la validation nous-même. Il faut +aussi penser à faire le test inverse : un résolveur validant doit mettre le bit +AD pour une réponse signée correctement, et doit répondre avec le code de +retour SERVFAIL (Server Failure) si la réponse devrait être signée mais ne +l'est pas, ou bien l'est mal. Cela se fait en testant +badsign-a.test.dnssec-tools.org. + +Dans les enregistrements DNSSEC, il n'y a pas que les signatures (RRSIG), il y +a aussi les enregistrements servant à prouver la non-existence, NSEC et NSEC3. +Il faut donc également tester qu'ils sont reçus car, en pratique, on voit en +effet des middleboxes qui laissent passer les RRSIG mais bloquent stupidement +les NSEC et les NSEC3. On demande donc non-existent.test.dnsssec-tools.org, et +on doit récupérer non seulement une réponse avec le code NXDOMAIN (No Such +Domain) mais également les NSEC ou NSEC3 permettant de valider cette réponse : + + +% dig AAAA non-existent.test.dnsssec-tools.org +[...] +;; ->>HEADER<><>- opcode: QUERY, status: NXDOMAIN, id: 40218 +;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 1 +[...] +;; AUTHORITY SECTION: +h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org. 900 IN NSEC3 1 1 1 D399EAAB ( + H9PARR669T6U8O1GSG9E1LMITK4DEM0T + NS SOA RRSIG DNSKEY NSEC3PARAM ) +iruevfos0vs8jssfj22me5p458p0qj1e.org. 900 IN RRSIG NSEC3 7 2 86400 ( + 20161222153046 20161201143046 3947 org. + kgCZC/gE4ySP7eZUb1+2ORYRhTrvL5YBIHLCBK5F8pqK + MXGJXJ/hX+8LLrg4jHJaER2AelUgUGywRn4uY80ajYpg + eTuSGzRX1aVCKAR8UB80bX/YLUPUPKWOdfgxTekD4nZk + eoi/9JNmIMZRc0cmMGp8LSVMqX98F2bVJnZro8U= ) +iruevfos0vs8jssfj22me5p458p0qj1e.org. 900 IN NSEC3 1 1 1 D399EAAB ( + IRVVBMC65HCBCFQNQS8NQFTAB943LCFU + NS DS RRSIG ) +vaittv1g2ies9s3920soaumh73klnhs5.org. 900 IN RRSIG NSEC3 7 2 86400 ( + 20161222153046 20161201143046 3947 org. + Nj/zvU0GB8vQ7bFfpSSWW+inE7RiOFjOpNc1K/TMnQqG + QsKTLD9gBM8vgh3K1WdPXOCzthf/isDJAy2xLA/oRFFq + KZ+Coo+33FManVmuyndGJ5bdgQqnpa0xGP7yOgjTfUsh + Ff9HkX0mkzqYtWYzw0J7WnMPcOjmrlg26WsfwlU= ) +vaittv1g2ies9s3920soaumh73klnhs5.org. 900 IN NSEC3 1 1 1 D399EAAB ( + VAJB898DELVT5UJ4I9D1BRD2FRTBSCM1 + NS DS RRSIG ) + +Certains serveurs DNS (ou, plus exactement, certains ensembles serveur+réseau+ +middlebox) n'acceptent que certains types d'enregistrement DNS (les plus +connus, comme A, AAAA, MX, parfois SRV, etc). Il faut donc tester que le +serveur accepte bien tous les types d'enregistrement, + +Jusqu'à présent, on n'a testé que le résolveur « normal ». Même s'il ne valide +pas, tant qu'il transmet fidèlement toutes les données DNS, on pourra au moins +l'utiliser comme relais et cache. Par contre, dans certains cas, si on veut +valider avec DNSSEC, il faudra complètement le court-circuiter. Ainsi, s'il ne +transmet pas les signatures, on n'a pas d'autre choix que d'aller les demander +à un autre résolveur, ou bien directement aux serveurs faisant autorité. Il +faut donc tester qu'on puisse interroger ces serveurs, avec UDP et avec TCP. +(Ce n'est pas toujours possible, certains réseaux violent tellement la +neutralité de l'Internet[5] qu'ils bloquent le port 53[6], celui du DNS.) + +Avec DNSSEC, les réponses sont souvent de grande taille, et parfois +fragmentées. Il faut donc tester que les fragments passent (ils sont souvent +bloqués par des administrateurs réseau incompétents). + +Une fois ces tests faits, il reste à synthétiser les résultats (section 4). +L'idée est de pouvoir dire si le résolveur « normal » est : + + * Un validateur (on peut alors tout lui déléguer, en tout cas si on a + confiance en lui), + * Un résolveur DNSSEC (même s'il ne valide pas, il passe bien tous les + enregistrements DNSSEC), + * Une horreur à fuir. + +En pratique, tous les résolveurs (ou plutôt l'ensemble du résolveur et du +réseau situé devant, avec ses middleboxes qui cassent tout) ne rentrent pas +parfaitement dans une de ces trois catégories. Ainsi, certains vont bloquer les +fragments mais accepter TCP (ce qui permettra de quand même faire passer les +données de grande taille), tandis que d'autres n'auront pas TCP mais qu'UDP +fonctionnera bien, même en cas de fragmentation. + +Une fois ces données collectées, et le résolveur correctement classé, on pourra +alors déterminer comment contourner les éventuels problèmes (section 5 du RFC). +Par exemple : + + * Si le résolveur officiel est un validateur ou bien un résolveur DNSSEC, on + l'utilise comme forwarder pour transmettre les requêtes, profitant ainsi de + son cache et réduisant la charge sur les serveurs faisant autorité. + * Si le résolveur officiel est une horreur, mais que les requêtes DNS vers + l'extérieur marchent, alors, ne pas faire appel au résolveur officiel et + parler directement aux serveurs faisant autorité. + * Si le résolveur officiel est une horreur, et que les requêtes DNS vers + l'extérieur sont bloquées, tenter de joindre un résolveur extérieur de + confiance, en utilisant DNS sur TLS (RFC 7858), ce que fait dnssec-trigger[2] + (dans son fichier de configuration, des lignes comme tcp80: 185.49.140.67 + ou ssl443: 185.49.140.67 ...). + * Sinon, si rien ne marche, laisser tomber, prévenir l'utilisateur et + pleurer. + +La section 6 du RFC sert de voiture-balai, en mentionnant les cas spéciaux qui +peuvent être embêtants. Par exemple, DNSSEC dépend de l'horloge, puisqu'il faut +vérifier que les signatures n'ont pas expiré. Mais la synchronisation de +l'horloge dépend de NTP donc parfois du DNS si on a mis des noms de domaine +dans son ntp.conf. Si la machine a une horloge assez stable pour garder l'heure +entre un arrêt et un démarrage, ce n'est pas trop grave. Mais si la machine est +un engin bon marché avec une horloge qui dévie beaucoup (genre le Raspberry +Pi), que faire ? + +Autre problème, les affreux portails captifs. Tant qu'on n'a pas cliqué sur +« j'accepte cinquante pages de conditions d'utilisation que je n'ai pas lues, +je veux recevoir du spam, et je promets de ne pas partager de la culture », on +n'a pas un vrai accès Internet et le port 53 est sans doute bloqué. Il faudrait +donc refaire les tests après le passage par le portail captif. + +Face à ce genre de problèmes, une première solution est de ne pas tenter de +faire du DNSSEC tant qu'on n'a pas synchronisé l'horloge, passé le portail +captif (c'est ce que fait dnssec-trigger), au détriment de la sécurité. Au +moins, on peut prévenir l'utilisateur et lui proposer de réessayer plus tard. + +Liens: +[1]: http://www.bortzmeyer.org/son-propre-resolveur-dns.html (lien) +[2]: http://www.bortzmeyer.org/dnssec-trigger.html (lien) +[3]: http://www.hsc-formation.fr/formations/dnssec.html.fr (lien) +[4]: https://www.dnssec-tools.org/testzone/index.html (lien) +[5]: http://www.bortzmeyer.org/neutralite.html (lien) +[6]: http://www.bortzmeyer.org/port53-filtre.html (lien) |