[第116回IETF Meeting報告] DNS関連RFCの発行状況

本記事では、第116回IETF Meetingにおける話題から、DNS関連RFCの発行状況についてご紹介します。

RFC 9364は、これまでに発行されたDNSSECの仕様を定義するRFCをまとめ、紹介しています。本RFCによるDNSSECの仕様の更新はなく、現状における最良の慣行（Best Current Practice：BCP）として発行されています。

本RFCには発行の目的として、以下の3項目が記載されています。

• DNSSECを多面的に理解できるように、すべてのRFCをまとめて紹介する
• DNSデータの出自の認証にDNSSECを使うことが、現在のベストプラクティスであると宣言する
• DNSSECを参照したい他の文書に、単一の参照先を提供する

対象のドメイン名でサービスを提供する際に必要な情報を設定するHTTPSリソースレコード（以下、RR）は、主なWebブラウザー・DNSサーバーソフトウェア・CDN事業者・DNS事業者などにおいてサポートされはじめています。

しかし、その仕様を定めるRFCは発行が遅れており、本稿執筆時点においても未発行の状態になっています。ここでは、このRFCの発行が遅れた理由と、RFC発行のために実施された特別対応について解説します。

▽RFCの発行が遅れた理由

HTTPS/SVCB RRの仕様を定める提案（draft-ietf-dnsop-svcb-https）はdnsop WGでの作業を終えた後、2022年5月26日にIESGのレビューを通過し、RFC発行待ち（RFC Ed Queue）の状態になりました。

しかし、draft-ietf-dnsop-svcb-httpsはtls WGが標準化作業を進めているEncrypted ClientHello^[*1]の仕様（draft-ietf-tls-esni）を参照していたため、RFC Editorにおいて「参照先欠落（MISSREF）」の状態になりました。

MISSREFの状態になった提案は、参照先の仕様が確定するまで保留されます。そのため、draft-ietf-dnsop-svcb-httpsはEncrypted ClientHelloの仕様が確定するまで、保留されることになりました。

tls WGは、draft-ietf-tls-esniの標準化には運用経験からのフィードバックが必要であるとしており、現在もWGでの標準化作業が続いています。このため、draft-ietf-dnsop-svcb-httpsは6カ月以上にわたり、RFCの発行が保留された状態になっていました。

▽RFCの発行に向けた特別対応の状況

この状況を解決するため、2023年2月23日にdnsop WGの担当エリアディレクターのWarren Kumari氏が、以下の手順をWGのメーリングリストに提案しました。

1. RFC Editorに要請し、保留されているdraft-ietf-dnsop-svcb-httpsをIESGに戻す
2. 受け取ったdraft-ietf-dnsop-svcb-httpsを、dnsop WGに戻す
3. dnsop WGで、draft-ietf-tls-esniを参照する部分を削除する
4. 改めて、通常の手順で標準化手続きをやり直す
5. draft-ietf-tls-esniがRFCになった時点で、参照する部分の標準化作業を進める

この提案はdnsop WGで速やかに合意され、draft-ietf-dnsop-svcb-httpsは2023年3月11日にdnsop WGに戻されました。その後、2023年3月18日にIESGに再送され、RFCの発行に向けた作業が進められています。

なお、提案から削除されたdraft-ietf-tls-esniを参照する部分は別提案として、tls WGで作業が進められることとなりました（draft-sbn-tls-svcb-ech）。