ドメイン名関連会議報告
2023年
[第118回IETF Meeting] DNS関連RFCの発行状況
2023/12/11
本記事では、前回の第117回IETF Meetingから今回の第118回IETF Meetingまでに発行された、DNS関連のRFCの内容をご紹介します。
サブドメインのためのACME
（Standards Track: draft-ietf-acme-subdomains）
RFC 9444は、サブドメインの証明書の発行・更新にACME[*1]を使う方法を定義します。本RFCは標準化過程（Standards Track）として発行されました。
本RFCでは、認証局がサブドメインの証明書発行を許可している場合において、クライアントがDNSを用いて自分のAncestor Domain[*2]を認証し、個々のサブドメインの認証を不要とする方法についても定義します。
[*2] 本RFCではあるドメインにそのサブドメインが含まれており、そのサブドメインよりラベルの数が少ない場合を「Ancestor Domain」と定義しています。例えば、ホスト名がnnn.mmm.example.comであった場合、mmm.example.comとexample.comはいずれも、そのAncestor Domainとなります。
DNSを介したサービスバインディングとパラメーターの指定
（SVCB/HTTPSリソースレコードの仕様）
（Standards Track: draft-ietf-dnsop-svcb-https）
RFC 9460は、そのドメイン名で提供されるサービスへのアクセスに必要なさまざまな情報をまとめて設定する、SVCBリソースレコード（RR）とHTTPS RRの仕様を定義します。本RFCは標準化過程（Standards Track）として発行されました。
SVCBは、"Service Binding"に由来しています。SVCB RRはさまざまなサービスに適用可能な汎用の形で定義され、HTTPS RRはSVCBのバリエーションとして、HTTPS及びHTTPスキームに特化した形で定義されています。
HTTPS RRはWebサービスを円滑に提供・利用するためのRRとして、RFCの発行前から実装・普及が進んでおり、主なWebブラウザーやCDNサービスにおいて、既に使われています。
DNSサーバーのサービスバインディングマッピング
（Standards Track: draft-ietf-add-svcb-dns）
RFC 9461は、組織やネットワークで提供されるリゾルバーがどのようなサービスを提供しているかを記述するための、SVCB RRの仕様を定義します。本RFCは標準化過程（Standards Track）として発行されました。
例えば、doh.example.netで動作するDNS over HTTPSのリゾルバーがHTTP/2を使い、「https://doh.example.net/dns-query{?dns}」というURLでサービスを提供している場合、対応するSVCB RRは以下のように記述されます。
_dns.doh.example. 7200 IN SVCB 1 doh.example.net. (
alpn=h2 dohpath=/dns-query{?dns} )
本RFCで記述されるSVCB RRは、以下で解説するDDR（RFC 9462）とDNR（RFC 9463）から参照され、それぞれのサービスを実現するために使われます。
リゾルバーの構成を検出する仕組み（DDR）
（Standards Track: draft-ietf-add-ddr）
RFC 9462は、クライアントがDNSクエリにより暗号化リゾルバー[*3]の構成を検出する仕組みである、Discovery of Designated Resolvers（DDR）の仕様を定義します。本RFCは標準化過程（Standards Track）として発行されました。
[*3] 本RFC、及び以降で紹介するRFC 9463、9464では、DNSクライアントとの通信が暗号化されたリゾルバーを暗号化リゾルバー（Encrypted DNS Resolver）、暗号化されていないリゾルバーを非暗号化リゾルバー（Unencrypted DNS Resolver）と定義しています。
本RFCは、リゾルバーの情報を記述するための特殊用途ドメイン名として「resolver.arpa」を予約します。例えば、doh.example.netで動作するDNS over HTTPSのリゾルバーがHTTP/2を使い、「https://doh.example.net/dns-query{?dns}」というURLでサービスを提供している場合、対応するSVCB RRは以下のように記述されます。
_dns.resolver.arpa. 7200 IN SVCB 1 doh.example.net (
alpn=h2 dohpath=/dns-query{?dns} )
リゾルバー検出のためのDHCPとルーター広告のオプション（DNR）
（Standards Track: draft-ietf-add-dnr）
RFC 9463は、暗号化リゾルバーの構成を検出するためのDHCPとIPv6ルーター広告（Router Advertisement：RA）のオプション（DNR）を定義します。本RFCは標準化過程（Standards Track）として発行されました。
本RFCで定義されたオプションを使うことで、前述したRFC 9461と同様の暗号化リゾルバーの情報を、クライアントがネットワークに接続する際に伝えることができます。これにより、クライアントは暗号化リゾルバーの情報を自動的に取得・設定できるようになります。
暗号化DNSのための鍵交換プロトコル（IKEv2）の構成
（Standards Track: draft-ietf-ipsecme-add-ike）
RFC 9464は、DNR（RFC 9463）で暗号化リゾルバーを割り当てる際に使われる鍵交換プロトコル（IKEv2[*4]）の構成ペイロード属性タイプENCDNS_IP4とENCDNS_IP6、及び暗号化リゾルバーのTLS接続を検証する際に使用可能な証明書ダイジェスト[*5]ENCDNS_DIGEST_INFOの形式を定義します。本RFCは標準化過程（Standards Track）として発行されました。
[*4] Internet Key Exchange Protocol Version 2に由来するインターネット上で鍵交換を安全に行うためのプロトコルで、RFC 7296で定義されています。
委任応答におけるグルーレコードの要件
（Standards Track: draft-ietf-dnsop-glue-is-not-optional）
RFC 9471は、DNSの参照応答[*6]におけるグルーレコード[*7]の取り扱いに関する要件を定め、サーバーの動作を明確化します。本RFCは標準化過程（Standards Track）として発行されました。
[*6] 自らはそのドメイン名を管理しておらず、他のサーバーを参照先として返す際に使われる応答です。参照応答はDNSの名前解決において、委任情報を返す際に使われます。
本RFCではグルーレコードのタイプを「In-domainのネームサーバーのグルーレコード」と「Sibling domainのネームサーバーのグルーレコード」に分類し、それぞれのグルーレコードについて、その目的と実装における取り扱いを明確化しています[*8]。
[*8] In-domain、Sibling domainの意味については、過去のドメイン名関連会議報告をご参照ください。
[第117回IETF Meeting報告] DNS関連WG、及びDNS関連技術を用いた提案の状況
本RFCはDNSの基本仕様を定めた、RFC 1034を更新します。
特殊用途ドメイン名「.alt」の予約
（Standards Track: draft-ietf-dnsop-alt-tld）
RFC 9476は、DNSでない名前空間で使われる特殊用途ドメイン名「.alt」を予約すると共に、当該名前空間を作成する開発者向けのアドバイスとガイダンスを提供します。本RFCは標準化過程（Standards Track）として発行されました。
2015年10月に実施された.onion[*9]の予約において、特殊用途ドメイン名の取り扱いを定義したRFC 6761の問題点が指摘され、それらをまとめたRFC 8244が、2017年10月に発行されました。本RFCは.altを予約・利用することで、RFC 8244で指摘された問題点を解決することを目的としています。
[*9] TCP/IP接続の匿名性を高める技術であるTor（トーア）で使われる、特殊用途ドメイン名です。
IETF 118の終了後に発行されたGNU Name SystemのRFC（RFC 9498：The GNU Name System）では、本RFCで予約された.altを利用した「.gns.alt」というサフィックスを使用しています。
- 関連URI
-
RFC INDEX
https://www.rfc-editor.org/rfc-index2.html
（RFCの一覧（降順））
