[第126回IETF Meeting] DNS関連RFCの発行状況

DNS over CoAPの仕様

RFC 9953: DNS over CoAP (DoC)（Standards Track: draft-ietf-core-dns-over-coap）

RFC 9953は、CoAP [1]でDNSメッセージを交換するための仕様を定義します。本RFCは標準化過程（Standards Track）として発行されます。

CoAPは暗号化による通信路の保護をサポートしており、システムリソースに制約があるIoTデバイスなどにおいても、暗号化されたDNS通信が可能になります。

エンジニアのためのポスト量子暗号のガイド

RFC 9958: Post-Quantum Cryptography for Engineers（Informational: draft-ietf-pquip-pqc-engineers）

RFC 9958は、量子コンピューターによる既存のシステムへの影響と、その対応策として開発が進められているポスト量子暗号（PQC）の概要と暗号アルゴリズムの移行に伴う課題について、暗号の専門家ではないエンジニア向けにまとめたガイドです。本RFCは情報提供（Informational）として発行されます。

量子コンピューターにより、RSA暗号や楕円曲線暗号など、広く使われている公開鍵暗号方式の安全性が脅かされると言われています。PQCは従来の公開鍵暗号方式と比べ鍵の長さ（鍵長）や署名サイズが大きくなる傾向にあり、特性も異なるため、既存のプロトコルにPQCを組み込む場合、暗号アルゴリズムの移行に加え、プロトコルの再設計が必要になる可能性があります。

本RFCはPQCの概要と特性を解説することで、今後必要になるさまざまなプロトコルへの組み込みや、それに伴うプロトコルの再設計の際に利用可能な情報を提供しています。

eap.arpaの定義とプロビジョニング

RFC 9965: The eap.arpa. Domain and Extensible Authentication Protocol (EAP) Provisioning（Standards Track: draft-ietf-emu-eap-arpa）

RFC 9965は、拡張可能な認証プロトコル（EAP）[2]のピア（クライアント端末）が制限付き、かつ認証不要のネットワークアクセスをサーバーに要求する際に使われる特殊用途ドメイン名[3]「eap.arpa」を予約し、eap.arpaを使ったサービス提供のための仕様を定義します。

本RFCは標準化過程（Standards Track）として発行され、RFC 5216、9140、9190を更新します。また、本RFCはRFC 9140で特殊用途ドメイン名として定義されていた「eap-noob.arpa」を廃止し、「noob.eap.arpa」に置き換えます。

CDNS/CDSKEY及びCSYNCにおける整合性の確認の明確化

RFC 9975: Clarifications on CDS/CDNSKEY and CSYNC Consistency（Standards Track: draft-ietf-dnsop-cds-consistency）

RFC 9975は、親が子のCDS/CDNSKEYリソースレコード（以下、RR）[4]やCSYNC RR [5]を参照して自身のDS RRや委任情報を更新する場合、子の権威DNSサーバー間における設定内容の一貫性の確認を必須とする仕様を定義します。本RFCは標準化過程（Standards Track）として発行され、RFC 7344とRFC 7477を更新します。

DMARCの基本仕様

RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC)（Standards Track: draft-ietf-dmarc-dmarcbis）

RFC 9989は、電子メールの送信元認証に使われるDMARCの仕様を定義します。

従来のDMARCの仕様であるRFC 7489はInformational（情報提供）として発行されましたが、本RFCは標準化過程（Standards Track）として発行され、RFC 7489とRFC 9091を置き換えます。

DMARCの集約レポートの仕様

RFC 9990: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Aggregate Reporting（Standards Track: draft-ietf-dmarc-aggregate-reporting）

RFC 9990は、DMARCにおいて受信側のメールサーバーが一定期間内に受信した電子メールの認証結果を送信側にまとめて通知する、集約レポートの仕様を定義します。本RFCは標準化過程（Standards Track）として発行され、RFC 7489を置き換えます。

DMARCの失敗レポートの仕様

RFC 9991: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Failure Reporting（Standards Track: draft-ietf-dmarc-failure-reporting）

RFC 9991は、DMARCにおいて受信側のメールサーバーが認証に失敗した個々の電子メールについて、認証結果や失敗の理由などを送信側に通知する、失敗レポートの仕様を定義します。本RFCはRFCは標準化過程（Standards Track）として発行され、RFC 6591を更新し、RFC 7489を置き換えます。

IPv4/IPv6混在環境におけるDNSトランスポートの運用ガイドライン

RFC 10001: Operational Guidelines for DNS Transport in Mixed IPv4/IPv6 Environments（Best Current Practice: draft-ietf-dnsop-3901bis）

RFC 10001は、IPv4/IPv6が混在する環境で権威DNSサーバー、フルリゾルバー、及びスタブリゾルバーを運用する際の推奨事項を提供します。本RFCは現状における最良の慣行（Best Current Practice：BCP）として発行され、RFC 3901を置き換えます。

本RFCでは従来の運用ガイドラインであるRFC 3901から、以下の項目が追加・更新されています。

• DNS用語集のRFC（RFC 9499）に基づき、用語のセクションを拡充
• IPv4/IPv6のサポートの違いに起因する名前空間の分断について、「運用者の意図的な選択」「設定ミス」「ネットワークの状況」に関する記述を追加
• RFC 3901ではオプションであった権威DNSサーバーのIPv6トランスポートのサポートを、IPv4/IPv6双方のサポートを推奨する形に変更
• IPフラグメンテーション [6]の取り扱いに関する指針を追加
• フルリゾルバー、及びスタブリゾルバーにおけるIPv4/IPv6の取り扱いに関する指針を追加

DSリソースレコードの自動登録に関する運用上の推奨事項

RFC 10026: Operational Recommendations for DNSSEC Delegation Signer (DS) Automation（Best Current Practice: draft-ietf-dnsop-ds-automation）

RFC 10026は、子が提供するDS RRの自動登録を事業者（レジストリやレジストラ）がサポートする際の考慮点とその対処方法における、運用上の推奨事項を提供します。本RFCは現状における最良の慣行（Best Current Practice：BCP）として発行されます。

複数の問い合わせタイプの指定

RFC 10029: DNS Multiple QTYPEs（Standards Track: draft-ietf-dnssd-multi-qtypes）

RFC 10029は、DNSクライアントが一つのDNS問い合わせで複数の問い合わせタイプを指定するための仕様を定義します。本RFCは標準化過程（Standards Track）として発行されます。

DNS問い合わせで指定できるドメイン名とタイプは1種類であることが、RFC 9619で明確化されています。しかし、一つのDNS応答で複数の関連するRRを受け取りたいという要望は以前から存在しており、本RFCの仕様はそれに応える形で定義されました。

本RFCでは、EDNS0 [7]を使ってクライアントが受信を希望するタイプを追加指定できるようにすることで、サーバー側がサポートしている場合、同じドメイン名の複数のタイプのリソースレコードを一度の問い合わせで入手できるようになります。