Résumé

  • RFC 9953 stabilise la clé de cache CoAP en recommandant l’identifiant DNS zéro pour des requêtes DoC équivalentes.
  • Cette réutilisation ne vaut que dans un budget de durée : Max-Age, TTL DNS, RCODE, source, validation et décision locale restent des preuves distinctes.

Un capteur se réveille, cherche un nom et reçoit une réponse depuis un cache placé sur le chemin. La transmission a coûté peu d’énergie ; c’est précisément l’un des intérêts de DNS over CoAP. Mais la phrase « le cache a répondu » ne dit ni quel résolveur a produit l’information, ni si elle a été validée, ni combien de temps elle reste exploitable, ni ce que le programme local a ensuite autorisé.

RFC 9953, publié en mars 2026, définit DNS over CoAP (DoC) pour les requêtes DNS d’OPCODE 0. Une paire requête-réponse DNS devient une opération CoAP. La requête DNS voyage dans le corps d’un FETCH CoAP, et le format application/dns-message porte le numéro de Content-Format 553. Le choix répond aux contraintes de mémoire, d’énergie et de trame des environnements IoT. Il ne transforme pas une enveloppe CoAP en attestation générale sur le contenu DNS.

L’identifiant DNS illustre bien la discipline. Le client DoC DEVRAIT le fixer à 0 afin que des requêtes portant sur les mêmes données DNS aient la même clé de cache CoAP ; un proxy en route peut alors réemployer une représentation. Le serveur DoC DOIT recopier l’identifiant de la requête dans la réponse. Le zéro ne désigne donc ni un serveur de référence, ni une validation, ni une permission. Il retire simplement une variation inutile de la clé de cache.

La norme replace aussitôt cette commodité dans le temps. Le serveur DoC DOIT garantir que la somme du Max-Age CoAP et de chacun des TTL DNS contenus dans la réponse ne dépasse pas le TTL correspondant reçu de l’amont. Même l’absence d’option n’échappe pas à la règle : le Max-Age CoAP par défaut de 60 secondes compte. À réception, le client DoC DOIT ajouter le Max-Age transporté aux TTL DNS et utiliser les TTL ainsi calculés. Un cache qui oublie cette addition ne conserve pas seulement des octets ; il modifie la durée que ces octets prétendent avoir.

L’algorithme recommandé est sobre : prendre le plus petit TTL DNS comme Max-Age, puis le retrancher de tous les TTL du message DNS. Une représentation peut ainsi rester stable pour l’ETag tout en évitant qu’un cache intermédiaire serve involontairement un enregistrement expiré. Pour une erreur qui ne mérite qu’une brève rétention, le Max-Age peut être plus court, y compris nul. Cette règle ne hiérarchise pas les erreurs ; elle rend leur durée contrôlable.

Il faut également lire deux grammaires de résultat. Une réponse DNS lisible est recommandée dans une réponse CoAP 2.05 Content, même lorsque le DNS transporte NXDOMAIN ou un autre RCODE d’échec. Un code CoAP non réussi doit signaler une erreur de couche CoAP ou une requête qui ne respecte pas DoC, par exemple un format non pris en charge. Le tableau qui célèbre chaque 2.05 comme succès DNS perd le résultat DNS. Celui qui transforme NXDOMAIN en panne de transport perd le résultat CoAP.

Enfin, le cache n’identifie pas à lui seul celui qui répond. RFC 9953 permet au serveur DoC d’être autoritaire, stub ou récursif, et dit qu’il PEUT être validateur DNSSEC pour des clients contraints. (D)TLS ou OSCORE peuvent protéger l’échange ; ils ne prouvent pas que chaque réponse est validée DNSSEC, qu’une politique locale l’accepte ou qu’une application a obtenu l’effet attendu. Daniel Kade emploie ici la séparation des couches de réalité de Heng Lu comme lecture éditoriale : l’efficacité du cache et l’autorité de l’usage ne sont pas le même fait.

Sources