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

RFC 9567は、名前解決エラーやDNSSEC検証エラーの発生をフルリゾルバー（キャッシュDNSサーバー）から報告（エラーレポート）できるようにするための仕様を定義します。本RFCは標準化過程（Standards Track）として発行されます。

本RFCにおけエラーレポート送信の流れを、以下に示します。

1. 応答の際、エラーレポートを受け取りたいゾーンの権威DNSサーバーがEDNS0を用いて、エラーレポートを受け取るために権威DNSサーバーの運用者が別途準備したドメイン名（エージェントドメイン）をフルリゾルバーに伝えます。

2. エラーを検知した場合、フルリゾルバーはその問い合わせのドメイン名・タイプ・エラーコードをエージェントドメインに組み込んだドメイン名を生成し、そのドメイン名を名前解決することでエラーの発生を伝えます。なお、この問い合わせのタイプにはTXTが指定されます。

例えば、broken.example.comのAリソースレコード（RR）の名前解決でDNSSEC検証エラーが発生した際のエラーレポートにおいて名前解決されるドメイン名は、以下のようになります。

_er.1.broken.example.com.7._er.(エージェントドメイン)

それぞれのラベルは、以下を意味しています。

• _er: エラーレポート用のラベル（エラーレポートの前後に指定）
• 1: エラーが発生した問い合わせのタイプ（A RR）
• broken.example.com: エラーが発生した問い合わせのドメイン名
• 7: DNSSEC検証エラーを示す拡張DNSエラーコード（RFC 8914で定義）

RFC 9606は、リゾルバーが自身の情報をクライアントに公開するRESINFO RRの仕様を定義します。本RFCは標準化過程（Standards Track）として発行されます。

RESINFO RRのフォーマットはTXT RRと同一で、key=valueの形式で、自身の情報を記述します。クライアントがリゾルバーにRESINFO RRを問い合わせることで、そのリゾルバーがサポートする機能や、リゾルバーの管理者が準備した詳細情報のWebページの情報などを入手できるようになります。

以下に、名前解決にQNAME minimisation[*1] を使用、拡張エラーコードの15から17までをサポートし、詳細情報をhttps://resolver.example.jp/guideで公開していることを示す、RESINFO RRの例を示します。

resolver.example.jp. 7200 IN RESINFO ( qnamemin exterr=15-17
                                       infourl=https://resolver.example.jp/guide )

RFC 9615は、委託先の権威DNSサーバーに設定するCDS/CDNSKEY RR経由で、DNSSECに未対応のゾーンをDNSSECに自動対応させる手法を定義します。本RFCは標準化過程（Standards Track）として発行され、RFC 7344とRFC 8078を更新します。

本RFCでは、子ゾーンに設定するCDS/CDNSKEYを委託先の権威DNSサーバーのゾーンにも設定できるようにすることで、マネージドDNSサービスプロバイダーを経由した、安全なDNSSECの新規導入を可能にしています。

以下に、DNSSECに未対応のゾーンexample.comのCDS RRをマネージドDNSサービスプロバイダーが管理する権威DNSサーバーns1.example.netに設定して、comゾーンにDS RRを自動設定する際の、CDS RRの設定例を示します。[*2]

（example.netゾーンの設定）
_dsboot.example.com._signal.ns1.example.net. IN CDS 12345 13 2 123456ABCDEF...

それぞれのラベルは、以下を意味しています。

• _dsboot: DS RRの初期設定であることを示すラベル（当該TLDレジストリが指定）
• example.com: DS RR設定対象のゾーン
• _signal: 本RFCによる設定であることを示すラベル（本RFCで予約）
• ns1.example.net: 委託先の権威DNSサーバーのホスト名

RFC 9619は、DNSメッセージの問い合わせ（Question）セクションの数（QDCOUNT）は通常1であることを明確にし、許可されていない値に遭遇した場合に必要になる動作を定義します。本RFCは標準化過程（Standards Track）として発行され、RFC 1035を更新します。

DNSメッセージのヘッダーにはQDCOUNTが含まれており、QDCOUNTに1より大きな値を設定することで、一つのDNSメッセージで複数の問い合わせを送ることができるかのように見えます。しかし、もしDNSメッセージに問い合わせが複数個含まれていた場合、応答にセットされるAAビットやRCODE[*3]がどちらの問い合わせに対するものかを通知・判断する方法がないため、1より大きな値は意味を持ちません。

そのため、本RFCでは通常問い合わせ[*4] におけるQDCOUNTについて、QDCOUNTに1より大きな値を設定してはならず、設定されていた場合は不正なメッセージとしてFORMERR（フォーマットエラー）を返さなければならない旨を定義し、仕様を明確化しています。