JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト


ドメイン名関連会議報告

2024年

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

本記事では、前回の第118回IETF Meetingから今回の第119回IETF Meetingまでに発行された、DNS関連のRFCの内容をご紹介します。

GNU Name System(GNS)の仕様

RFC 9498: The GNU Name System
(Informational: draft-schanzen-gns)

RFC 9498は、検閲耐性を高めた分散型の名前解決システムとして開発されているGNU Name System(GNS)の仕様を提供します。本RFCの仕様はIETFで開発されたものではないため、情報提供(Informational)として発行されます。

DNS用語集

RFC 9499: DNS Terminology
(Best Current Practice: draft-ietf-dnsop-rfc8499bis)

RFC 9499は、DNSで使われる用語を一つの文書にまとめ、その定義を示したDNS用語集です。本RFCはJPRSの藤原和典が共著者となっています。

本RFCは現状における最良の慣行(Best Current Practice:BCP)として発行され、従来のDNS用語集であるRFC 8499を置き換えます。本RFCで新たに追加された用語・定義が変更された用語については、JPRSが2024年3月22日に公開したWebトピックスをご参照ください[*1]

集中化・分散化とインターネット標準

RFC 9518: Centralization, Decentralization, and Internet Standards
(Informational: draft-nottingham-avoiding-internet-centralization)

RFC 9518は、インターネットにおける集中化・分散化とインターネット標準の関係と、集中化・分散化においてIETFとインターネット標準が果たし得る項目について、著者の見解をまとめたものです。

本RFCの著者は長年にわたりIETFで活動し、現在はhttpbisワーキンググループ(WG)のチェアを務めているMark Nottingham氏で[*2]、情報提供(Informational)として発行されます。

[*2] 本RFCについての考えが、著者のブログで公開されています。
  RFC 9518 - What Can Internet Standards Do About Centralisation?

本RFCではDNSについて、複数のサーバーが連携して動作する分散システムの側面を持ちながら、名前空間がルートゾーンを起点として集中管理されているという、分散化と集中化の双方の側面を持っていることが解説されています。

名前解決失敗のネガティブキャッシュ

RFC 9520: Negative Caching of DNS Resolution Failures
(Standards Track: draft-ietf-dnsop-caching-resolution-failures)

RFC 9520は、名前解決の失敗をネガティブキャッシュ[*3]するための仕様拡張を定義します。本RFCは標準化過程(Standards Track)として発行され、RFC 2308、RFC 4035、RFC 4697の内容を更新します。

本RFCでは、従来はオプションであった以下の3項目のネガティブキャッシュの実装をリゾルバーに求めることで、名前解決に失敗した際に発生する再問い合わせの頻度を低減することを目的としています。

  • 名前解決の失敗(RFC 2308で定義)
  • DNSSEC検証の失敗(RFC 4035で定義)
  • 名前解決失敗時の祖先ゾーンからの委任情報の再取得(RFC 4697で定義)

フルリゾルバーと権威DNSサーバー間の暗号通信における日和見方式の展開

RFC 9539: Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS
(Experimental: draft-ietf-dprive-unilateral-probing)

RFC 9539は、フルリゾルバー(キャッシュDNSサーバー)と権威DNSサーバーの間の暗号通信に日和見方式[*4]を展開する手順を定めます。本RFCは実験(Experimental)として発行されます。

[*4] RFC 7435で定義される、暗号化を試みる際に認証が利用できない場合であっても、提供された暗号化の手段をそのまま利用する方式です。なお、認証が利用できる場合には、その認証方法を使用します。

本RFCは通信方式を簡略化することで、DNSの暗号通信を迅速に展開できるようにすることを目的としています。本RFCの作業を進めたdprive WGでは今後1年掛けて実験を評価するためのデータを収集・分析し、必要な合意が得られた場合、本RFCを標準化過程(Standards Track)に改訂するためのリチャーター(チャーターの再設定)を実施する予定です。

SVCBリソースレコードを介したObliviousサービスの検出

RFC 9540: Discovery of Oblivious Services via Service Binding Records
(Standards Track: draft-ietf-ohai-svcb-config)

RFC 9540は、SVCBリソースレコード(RR)とHTTPS RRでOblivious HTTP[*5]のOblivious Gateway Resource(ゲートウェイ)を記述可能にするための、パラメーターの仕様を定義します。本RFCは標準化過程(Standards Track)として発行されます。

[*5] RFC 9458で定義される、HTTP通信におけるプライバシーを保護するための通信方式です。HTTPクライアントとHTTPサーバーの間にリレーとゲートウェイを導入することで、利用者の問い合わせ元IPアドレスとHTTPリクエストの内容を同時に入手できないようにします。

本RFCは、Oblivious HTTPを意味するSVCB/HTTPS RRのサービスパラメーターキーとして「ohttp」を定義します。例えば、HTTP/2とOblivious HTTPをサポートするWebサーバー「svc.example.com」のHTTPS RRの記述例は、以下のようになります。

  svc.example.com. 7200  IN HTTPS 1 . ( alpn=h2 ohttp )

当該WebサーバーがOblivious HTTPでのアクセスのみをサポートしている場合のHTTPS RRの記述例は、以下のようになります。

  svc.example.com. 7200  IN HTTPS 1 . ( alpn=h2 mandatory=ohttp ohttp )

また、HTTP/2とOblivious HTTPによるDNS over HTTPS(DoH)をサポートしているリゾルバー「doh.example.net」をDDR[*6]で検出できるようにする場合のSVCB RRの記述例は、以下のようになります。

  _dns.resolver.arpa.  7200  IN SVCB 1 doh.example.net. (
      alpn=h2 dohpath=/dns-query{?dns} ohttp )

[*6] RFC 9462で定義される、クライアントがDNSクエリで暗号化リゾルバーの構成を検出するための仕組みです。詳細については過去のドメイン名関連会議報告をご参照ください。
  [第118回IETF Meeting] DNS関連RFCの発行状況