要約

  • RFC 9953 は、同じ DNS データを運ぶ DoC 問い合わせで CoAP Cache-Key を安定させるため、DNS ヘッダ ID を 0 にすることを推奨する。
  • その再利用は Max-Age と DNS TTL の計算に縛られ、DNS の結論、応答元、検証、ローカル判断、実際の結果を代替しない。

現場の小さな端末が休止から戻り、ひとつの名前を引く。経路上の CoAP キャッシュが一致する表現を持っていれば、無線区間も電池も節約できる。そこまでは観測できる。しかし「キャッシュが返した」という一文から、上流が権威サーバーだったのか再帰リゾルバだったのか、DNSSEC 検証があったのか、その情報がまだ使えるのか、端末がどんな規則で次の処理を選んだのかは分からない。

RFC 9953 は 2026 年 3 月に公開された DNS over CoAP（DoC）の仕様である。対象は OPCODE 0 の DNS クエリで、DNS の一組の問い合わせと応答を CoAP の要求・応答操作へ写す。クエリは CoAP FETCH の本文に入り、DNS のワイヤ形式は Content-Format 553 の application/dns-message で運ばれる。これは制約の強い IoT 環境向けの運搬方法であって、CoAP の外側が DNS の意味を保証する仕組みではない。

ID をゼロにする規則は、まさにキャッシュのための規則である。DoC クライアントは SHOULD として DNS ヘッダ ID を 0 にし、同じ DNS データを求める複数の要求が、従来のトランザクション ID の違いだけで別の CoAP Cache-Key にならないようにする。経路中のキャッシュやプロキシは表現を再利用できる。サーバーは MUST として要求 ID を対応する応答にコピーする。ゼロは信頼印でも、サーバー名でも、実行許可でもない。キャッシュキーから偶発的な差を除く処理にすぎない。

その処理の隣には必ず時計がある。DoC サーバーは、CoAP 応答の Max-Age と応答内の各 DNS TTL の合計が、上流 DNS から受けた対応 TTL を超えないことを MUST として保証する。Max-Age が書かれていない場合も、CoAP の既定 60 秒が数えられる。クライアントは受信時に Max-Age をすべての DNS TTL に加え、計算後の TTL を使わなければならない。輸送層で残る時間と DNS 表現で残る時間は、ひとつの寿命予算を分けて表したものである。

推奨アルゴリズムは、DNS 応答内で最小の TTL を Max-Age にし、その値を本文中の全 TTL から引く。これにより中間キャッシュが期限切れのレコードを意図せず返すのを防ぎ、内容から作る ETag は上流キャッシュの TTL 更新で変わりにくくなる。短くしか保持すべきでないエラーなら、Max-Age はより短く、ゼロにもできる。これはエラーを消すためではなく、時間を勝手に延ばさないための規律である。

応答には二種類の成否がある。DNS 応答を解析できるなら、DNS の中身が NXDOMAIN などの RCODE エラーでも CoAP 2.05 Content で返すことが推奨される。失敗した CoAP コードは CoAP 層のエラー、または DoC 要件を満たさない要求のために使う。外側の 2.05 だけを成功率にすれば DNS の失敗を落とす。RCODE だけを障害通知にすれば、輸送と上流 DNS の違いを落とす。

DoC サーバーは権威サーバー、stub、再帰リゾルバになり得て、制約端末のための DNSSEC バリデータにも MAY としてなり得る。(D)TLS や OSCORE でメッセージを保護できても、すべての返答の DNSSEC 検証やローカル利用方針、アプリケーションの結果までは決めない。Daniel Kade が Heng Lu の現実層の考え方を編集上のレンズとして使うのはこのためだ。再利用可能なバイト列と、それを行動の根拠にしてよいことは別の事実である。

出典