C'est quand quelqu'un t'oblige à faire confiance à un tiers qu'il faut aller lui chier sur son bureau.

Non ce blog n'est pas mort, il y a encore des survivants dans la cage pour venir te chatouiller les testicules là où ça gratte bien. Des survivants qui constatent que plus ça va, plus on se fout très ouvertement de leur gueule.

Je me suis donc intéressé récemment à comment que ça marche DNSSEC et comment ça va permettre de continuer à faire de la merde en toute quiétude malgré les menaces plus ou moins ouvertes des petits chouchous du législateur.

Bon alors skoi encore ce machin ?

Le gros souci du DNS, c'est que c'est pas fiable pour deux ronds. Pour éviter d'avoir à faire trop de résolutions, on se base sur des serveurs cache qui respectent plus ou moins les normes, mais surtout qui peuvent très facilement être censurés par l'administrateur de ce dernier ou par l'État.

Comme si ça ne suffisait pas, il est très facile pour un FAI indélicat ou un État « démocratique » de filtrer les requêtes à destination des serveurs racines et de répondre n'importe quoi. Bref, le DNS, c'est le premier point de censure. Et si ce n'est pas le seul problème que DNSSEC veut adresser, c'est ce qui m'intéresse pour le moment le plus.

Tout-à-fait Thierry !

Avant de s'attaquer à comment ça marche®, je tiens à préciser quelque chose tout de suite : on peut difficilement parler DNSSEC à la main. Parce qu'il y a de nombreuses opérations pour une seule résolution. La description suivante reprend donc les grands principes, mais pas le détail technique complet (je te rassure jeune chimpanzé, tu verras des trucs avec plus de poils pour la prochaine fois).

Commençons par le commencement : comment ça marche une résolution de nom ? Mettons que tu veuilles accéder à www.mescouilles.xxx (pour les intéressés, c'est libre pour le moment), voici à peu près ce que va faire ton résolveur :

• quoiqu'il arrive le zozo connaît ., la racine du DNS ; il va donc lui demander qui sont les nameservers pour xxx. ;
• puis il va demander aux namesevers de xxx. qui gère mescouilles.xxx. ;
• puis il va demander au responsable de ce nom de domaine quelle est l'adresse IP de www.mescouilles.xxx.

Avec DNSSEC cette réponse va s'accompagner d'un enregistrement RRSIG, la signature de l'enregistrement que l'on vient de recevoir. Signature qui est garantie par une classique paire de clés publique/privée (on parle alors de Zone Signing Key ou ZSK)… qui se trouve dans le DNS.

À ce moment-là, tu te dis sûrement que ça va être effectivement compliqué de forger à la volée un enregistrement et une clé correspondante, mais que ce n'est pas infaisable. En plus, si la zone DNS que tu interroges est polluée par un vilain pirate, rien ne l'empêche jusqu'à présent de modifier la zone pour y insérer sa clé et signer lui-même les enregistrements.

Sauf que, bien évidemment, tout a été prévu. Une seconde paire de clés sert à signer la clé publique de la ZSK. On parle de KSK Key Signing Key ''(NDLA : de ce que j'ai compris, celle-ci n'est pas indispensable, mais on y reviendra plus tard)'', donc la partie publique est dans le DNS (je te rassure il n'y a pas de KSKSK ni de DSK) et l'« emprunte » est partagée (Delegation Signer ou DS) dans la zone parente !

Le système est donc bouclé : la racine est auto-signée et tout le monde connaît sa clé publique ; les zones filles enregistrent systématiquement un DS dans la zone parente pour garantir la solidité de leurs propres enregistrements. Pour s'assurer de ne pas être victime des pirates de l'Internet ou des pirates de la politique, il suffit donc de vérifier chaque enregistrement renvoyé lors de chaque étape (et de garder le tout en cache pour accélérer les manœuvres suivantes).

Les questions que tu te poses sûrement

Pourquoi une ZSK et une KSK ?

Dans ce vaste bordel, tu n'auras pas manqué de remarquer qu'on utilise deux clés pour chaque zone. Une clé pour la signer et une clé pour signer la clé de signature (là, j'ai dû paumer les derniers lecteurs…). La première raison est cryptographique : possédant la clé publique, les messages en clair (les enregistrements) et les messages chiffrés (les signatures RRSIG), il est théoriquement plus facile de reconstituer une clé privée par simple calcul (ce fut l'un des principaux éléments dans le cassage du code d'Enigma par exemple). Donc la seule solution (débile), c'est de changer très régulièrement cette clé.

La seconde raison est surtout organisationnelle : il est plus pratique de ne charger qu'une seule fois la clé au niveau du registrar plutôt que de la changer tous les 3 mois pour resigner les zones.

Et il y a aussi une relation, que je n'ai pas bien comprise je dois le reconnaître, entre les enregistrements RRSIG, les TTLs des enregistrements de la zone et la durée de validité de la clé de signature de la zone.

Et pour les réponses négatives ?

Assez naturellement, on en vient à se dire que le censeur n'a pas grand chose à faire : au lieu de répondre de la merde qu'il ne pourra pas signer correctement, il suffit de répondre que le domaine n'existe pas.

Oui mais non, le cas a été prévu. Chaque zone dispose d'un enregistrement NSEC couplé à sa signature, qui permet donc de prouver que la réponse n'existe effectivement pas.

Les fans d'aspirine peuvent aller vérifier une requête complète et les différentes validations qui ont lieu. Pour les autres, rendez-vous la prochaine fois pour commencer à faire du caca avec des zones DNS.