Résumé

  • Un Internet-Draft individuel propose qu'un résolveur récursif qui ne valide pas DNSSEC efface le bit DO en amont si la requête reçue ne le porte pas.
  • Si un client demande ensuite les preuves, le résolveur doit reconnaître que son cache n'en contient pas et interroger de nouveau le serveur faisant autorité.

Le premier client obtient une réponse légère. Le second veut vérifier sa signature. Entre les deux, le cache est devenu un piège : il connaît la réponse, mais ne possède pas la preuve. Le projet publié le 30 octobre par Warren Kumari, Geoff Huston et Peter Thomassen déplace ainsi une partie du coût du transport vers le comportement du résolveur. Ce texte individuel est une proposition de discussion, sans statut de norme adoptée.

Le bit DNSSEC OK, ou DO, demande les enregistrements nécessaires à la vérification. RFC 3225 et RFC 4035 prescrivent aujourd'hui à un résolveur récursif conscient de DNSSEC de l'activer vers l'amont, même si son client ne l'a pas activé. Le résolveur peut retirer les preuves de la réponse remise à ce client tout en les gardant pour une demande ultérieure.

Le projet propose un autre réglage pour un résolveur qui ne valide pas lui-même et reçoit une requête sans DO : transmettre la requête sans DO. Le serveur faisant autorité n'enverrait pas automatiquement les preuves. Les signatures postquantiques, potentiellement plus volumineuses, motivent cette économie de taille et l'espoir de réduire les replis vers TCP. Le projet ne chiffre ni les octets gagnés ni la charge déplacée.

La contrepartie est écrite noir sur blanc : le résolveur doit marquer les entrées mises en cache sans preuves. À l'arrivée ultérieure d'une requête avec DO, il doit repartir vers l'autorité avec DO activé. Servir simplement l'entrée déjà présente priverait le client validateur des données requises. La discussion DNSOP oppose déjà ce pari sur des réponses UDP plus petites à un recours accru aux transports en flux. Un essai sérieux doit mesurer les deux ordres d'arrivée, la validation du second client et la charge réelle des deux serveurs. Il manque encore une implémentation et ces mesures.

Projet · RFC 3225 · RFC 4035