Résumé

  • La protection DoC atteste un échange entre client et serveur qui partagent un contexte, non le trajet DNS choisi ensuite par ce serveur.
  • Découverte fiable, contexte, réponse, amont, DNSSEC et acceptation applicative sont des reçus distincts.

La RFC 9953 place une requête DNS dans une requête CoAP et la réponse dans une réponse CoAP. DTLS, TLS ou OSCORE peut préserver l’intégrité et la confidentialité de cet échange. C’est un fait exploitable, mais il a deux extrémités précises.

La RFC avertit que le serveur DoC peut communiquer sans protection avec l’infrastructure DNS amont, notamment via DNS sur UDP. Il peut aussi employer une autre protection, mais cette protection reste opaque au client DoC. Une indication rassurante sur le premier lien ne décrit donc ni le résolveur récursif, ni le cache, ni le transport jusqu’à l’autorité.

Le choix du serveur ne comble pas davantage cette lacune. Le client doit connaître le serveur et la ressource; une configuration automatique ne doit venir que d’une source digne de confiance. Cela documente l’origine de la configuration, pas la validation DNSSEC d’une réponse ni la décision d’une application. La RFC laisse d’ailleurs hors de son champ l’expression de cette confiance.

Un dossier vérifiable conserve la source de découverte, l’URI, la durée du contexte, la requête, la réponse, la preuve amont lorsqu’elle est invoquée, la validation et la décision locale. Christian Amsüss est l’un des auteurs du texte collectif, non l’opérateur d’un résolveur déterminé.

Sources