第114回IETF Meeting報告

2022年7月23日から29日にかけ、第114回IETF Meeting（以下、IETF 114）が、米国フィラデルフィアの現地会場とオンラインによるハイブリッド形式で開催されました。

今回のFROM JPRS増刊号では、IETF 114の状況に加え、その直後の7月30日から31日にかけて同じ現地会場で開催された第38回DNS-OARC Workshop（以下、OARC 38）から、FROM JPRS編集局が注目した興味深い話題についてもお伝えします。

• 開催の状況
• IETF全般の話題から
  - 次々回のIETF 116は横浜で開催
  - DNS-directorateの新設に伴うボランティアの募集
  - IETFプロトコルバッジ・IETFサポーターバッジのライセンス条項制定
  - edmプログラムの状況
• OARC 38の話題から
  - nsec3-guidanceの影響と次回のDNS flag dayの提案
  - オープンソースDNSベンダーからの状況報告
• IETF 113以降に発行されたDNS関連のRFC
  - 大規模権威DNSサーバー運用者のための考慮事項（RFC 9199）
  - Oblivious DNS Over HTTPS（ODoH）の仕様（RFC 9230）
  - DNS over QUIC（DoQ）の仕様（RFC 9250）
  - リソースレコード処理に関する実装のアンチパターン（RFC 9267）
  - NSEC3パラメーター設定のガイダンス（RFC 9276）
• DNS関連WGの状況
  - dnsop WGの状況
  - dprive WGの状況
  - add WGの状況
• 次回のIETF Meetingについて

IETF 114には、世界各地から1,400人以上が参加しました。会合終了後の公式発表によると現地参加者が622人、オンライン参加者が803人であったとのことで[*1]、現地参加者の比率はIETF 113の約22%（314人）から、約44%に増加しました。

会合の時間は、開催地であるフィラデルフィアの時間帯（UTC-4）でスケジュールされました。

▼次々回のIETF 116は横浜で開催

IETF 114の全体会議（Plenary）で、次々回のIETF 116が2023年3月25日から31日にかけ、横浜市のパシフィコ横浜で開催されることが発表されました[*2]。

日本でのIETF Meetingの開催は、2002年のIETF 54、2009年のIETF 76、2015年のIETF 94に続き、4回目となります。IETF 116は過去3回と同様、WIDE Projectがホストとなり開催されます。

▼DNS-directorateの新設に伴うボランティアの募集

IETFには各分野の専門家の立場から提案をレビューする、Directorateという仕組みがあります[*3]。

今回、DNS関連の各WGの冒頭でInternet Area（int）とOperations and Management Area（ops）のエリアディレクター（AD）[*4]から、IESG[*5]とDNS関連の四つのWG（add・dnsop・dnssd・dprive）のチェアが、IETF 114の開催後に「DNS-directorate」を新設することに合意した旨が参加者に伝えられました。

DNSはインターネットの基盤技術の一つであり、DNS関連以外のWGの提案の中にも、DNSに関する内容が含まれることがあります。DNS-directorateはそれらの提案の内容について、DNSの専門家の立場から早い段階でレビューするための仕組みとして提案されたものです。

発表では2022年9月1日までに実施する次のステップとして、提案のレビューを担当する小グループのボランティアと、毎週のチェックを担当する2名の事務局を募集する旨が呼び掛けられました。

各WGの参加者からは、「新しいアイディアの提案を萎縮させるようにはしないで欲しい」「レビューで『DNSでこれを行うな』と言って良いか」などのコメントがあり、後者についてはADから良いとする回答がありました。

▼IETFプロトコルバッジ・IETFサポーターバッジのライセンス条項制定

IETFでは、特定のプロトコルの標準化活動への関与や、そのプロトコルを実装・サポートしていることを示す「IETFプロトコルバッジ」と、IETFの活動を支援していることを示す「IETFサポーターバッジ」を公開しています[*6]。

今回のPlenaryで、これらのバッジの利用に関するライセンス条項を制定した旨が発表されました[*7]。

ライセンス条項には、以下の内容が記述されています。Webサイトや印刷物などでバッジを使う場合、当該ライセンス条項を遵守する必要があります。詳細につきましては、リンク先のライセンス条項をご覧ください。

• 許可される使い方
  - IETFの標準化活動への関与を示す
  - 製品・サービスにおいて、当該プロトコルのサポートを示す
  - IETFまたはその活動への支援を示す
  
• 禁止される使い方
  - バッジの形式・大文字小文字（capitalization）・比率・色を変更する
  - バッジの短縮・省略・改変、及び結合商標の一部として使用する
  - 製品・サービスの出自について、誤解を生じさせる
  - IETFの承認・後援がある旨の印象を与えたり、誤認させたりする
  - IETFまたは関連団体の活動を誤解させたり、軽蔑的に扱ったりする
  

▼edmプログラムの状況

IETF 114の期間中にIAB[*8]が主催する形で、edmプログラムのミーティングが開催されました。

edmは「Evolvability, Deployability, & Maintainability」に由来しており、IETFが標準化するプロトコルの進化・普及・保守における戦略を策定・分析する文書の作成に取り組むために創設された、IABのプログラムです[*9]。

edmでは、プロトコル拡張における設計上の考慮事項についてまとめたRFC 6709[*10]の更新・拡張を始めとする文書の作成に取り組んでいます。edmにはIESGのメンバーと、実装を支援するツールチームが含まれています。

今回のミーティングではIABが作成を進めている「The Harmful Consequences of the Robustness Principle（参考訳：堅牢性の原則の有害な結末）[*11]」の状況が共有されました。本文書にはインターネットにおいて長年重要視されてきた「送信では厳密に・受信では寛容に」という堅牢性の原則がプロトコルのエコシステムに悪影響を与えた旨が書かれており、この原則は長期的な観点では有害であり、回避すべきであることが示されています。

edmの活動はIETFの標準化活動の方針そのものに影響を与えるものであり、今後の動向が注目されます。

DNS-OARC[*12]はDNSのセキュリティ・安定性・理解の向上を目的とした、非営利の会員組織です。JPRSは、2007年からDNS-OARCのメンバーとなっています。

DNS-OARCは情報交換を目的としたワークショップを定期的に開催しています。今回のFROM JPRS増刊号ではOARC 38のプログラムの中から、DNSの運用に影響する二つの話題をご紹介します。

▼nsec3-guidanceの影響と次回のDNS flag dayの提案

10年以上に及ぶ大規模な運用経験の蓄積から、当初最適と考えられていたDNSSECの運用パラメーターの見直しが行われています。JPRSの米谷嘉朗が「Are we ready for nsec3-guidance?」と題し、現状における最良の慣行（Best Current Practice：BCP）RFCとして発行される予定のNSEC3パラメーターの設定に関するガイダンス（nsec3-guidance）[*13]が運用に与える影響と、その影響を回避するためにTLDの権威DNSサーバー・DNSSEC検証を実施するフルリゾルバー（バリデーター）・DNSコミュニティが実施すべき対応案について説明しました。

NSEC3の検証では外部からゾーン列挙[*14]を行いにくくするため、ハッシュ計算を実行します。nsec3-guidanceではハッシュ計算の過剰な繰り返しによりバリデーターのパフォーマンスが低下することを懸念し、権威DNSサーバーの設定推奨値とバリデーターの動作について、以下のように定めています。

• 権威DNSサーバーで設定する繰り返し回数を0、ソルト[*15]を空とする（MUST）
• バリデーターは設定されている繰り返し回数が0より大きい場合、安全でない（Insecure）、またはDNSSEC検証失敗（SERVFAIL）応答を返してよい（MAY）

米谷は、2022年7月9日時点において1,148のTLDが1以上の繰り返し回数を設定しており、nsec3-guidanceのRFCが発行され、バリデーターがSERVFAIL応答を返すように設定された場合、TLDレベルでの大規模なDNSSEC検証エラーが発生する可能性がある旨を示しました。

そして、その可能性を低減するため、それぞれの関係者が実施すべき対応案として、以下を示しました。

• TLDの権威DNSサーバーの関係者
  - できるだけ速やかに、NSEC3パラメーターの設定をnsec3-guidanceが推奨する内容に変更する
• バリデーターの関係者
  - 本件においてInsecure応答やSERVFAIL応答を返すのはオプションであり、導入は慎重に検討する

その後、米谷から参加者に対し、本件は次回のDNS flag day[*16]の候補となり得るのではないかという旨を提案しました。参加者からは「本件はDNSソフトウェアベンダーだけが対応すればよいものではない」、「バリデーターの段階的な移行を促すにはDNS flag dayは有用であろう」といった意見があり、提案に対する関係者の認識を向上できました。

本件についてはDNS flag dayの実施時期・段階的な移行などについて、議論を継続していく予定です。

▼オープンソースDNSベンダーからの状況報告

「Open-source DNS Vendors Panel」において、オープンソースDNSソフトウェアを開発している以下の4ベンダーから、それぞれの開発状況が発表されました。

• CZ.NIC（Knot DNS・Knot Resolver）
• ISC（BIND）
• NLnet Labs（NSD・Unbound）
• PowerDNS.COM BV（PowerDNS Authoritative Server・PowerDNS Recursor）

各ベンダーからは各ソフトウェアにおける最近の開発状況と、カタログゾーンやZONEMD[*17]リソースレコード（RR）、エラーコードの拡張などといった新しい標準仕様の実装予定が、ロードマップとして示されました。

なお、RFC 9250として標準化されたDNS over QUIC[*18]への対応については積極的なベンダーと慎重なベンダーがあり、慎重なベンダーは現時点においてQUICのライブラリが十分に整っていないことをその理由に挙げていました。

詳細については、OARC 38公式ページで公開されている資料をご参照ください。

▽BINDにおける委任情報の取り扱い変更に関する検討

本パネルにおいてISCから、BINDにおける委任情報（NS RR）の取り扱いを、現在の委任先（子）の設定内容を優先する方式から、委任元（親）の設定内容を優先する方式[*19]に変更することを検討している旨が発表されました。

本件はDNSの動作と運用に大きな影響を及ぼすため、ISCは公開の場で意見を募集しています[*20]。

前回のIETF 113以降に発行された、DNS関連のRFCの内容をご紹介します。

▼大規模権威DNSサーバー運用者のための考慮事項
・RFC 9199: Considerations for Large Authoritative DNS Server Operators
（Informational: draft-moura-dnsop-authoritative-recommendations）

RFC 9199は、TLDの権威DNSサーバーのような大規模な権威DNSサーバーの運用者が考慮すべき事項を、これまでの調査研究の結果に基づく形でまとめたものです。本RFCはIETFのWGで標準化されたものではなく、情報提供（Informational）として発行されています。

本RFCでは運用者の考慮事項として、以下の6項目を挙げています。

▼Oblivious DNS Over HTTPS（ODoH）の仕様
・RFC 9230: Oblivious DNS over HTTPS
（Experimental: draft-pauly-dprive-oblivious-doh）

RFC 9230は、利用者のプライバシーを保護するために開発されたOblivious DNS over HTTPS（ODoH）の仕様を定義します。本RFCはIETFのWGで標準化されたものではなく、実験（Experimental）として発行されています。

ODoHではDNSクライアントとリゾルバーの間にプロキシを追加し、クライアントとリゾルバーがエンドツーエンドでDNSデータを暗号化・復号することで、利用者の問い合わせ元IPアドレスとDNS問い合わせ内容を同時に入手できないようにします[*23]。

ODoHは、AppleのiCloud Private Relayで採用されています。

▼DNS over QUIC（DoQ）の仕様
・RFC 9250: DNS over Dedicated QUIC Connections
（Standards Track: draft-ietf-dprive-dnsoquic）

RFC 9250は、QUICを用いてDNSの通信を保護（暗号化）するための仕様（DNS over QUIC：DoQ）を定義します。DoQの仕様には、スタブリゾルバーとフルリゾルバー（キャッシュDNSサーバー）、フルリゾルバーと権威DNSサーバー、ゾーン転送におけるQUICの使用が含まれます。

DoQをサポートしたフルリゾルバー・権威DNSサーバーは、デフォルトでは853/UDPでQUICの接続を待ち受けます。DoQで送受信されるデータの内容は、TCPによるDNS通信と同じ形式となります。

▼リソースレコード処理に関する実装のアンチパターン
・RFC 9267: Common Implementation Anti-Patterns Related to Domain Name System (DNS) Resource Record (RR) Processing
（Informational: draft-dashevskyi-dnsrr-antipatterns）

RFC 9267は、DNSクライアントのRRの処理において見られる、脆弱性を誘発するアンチパターン[*24]について記述しています。こうした脆弱性はそのDNSクライアントが動作する機器において、外部からのDoS攻撃やリモートコード実行など、不適切な動作につながる可能性があります。

本RFCは脆弱性「NAME:WRECK[*25]」を公開したセキュリティ研究者が、調査時の分析で得られた結果をまとめたもので、IETFのWGで標準化されたものではなく、情報提供（Informational）として発行されています。

▼NSEC3パラメーター設定のガイダンス
・RFC 9276・BCP 236: Guidance for NSEC3 Parameter Settings
（Best Current Practice: draft-ietf-dnsop-nsec3-guidance）

RFC 9276は、DNSSECの不在証明[*26]に用いられる、NSEC3パラメーターの設定と取り扱いに関するガイダンスを提供します。本RFCはBCPとして、運用手法をまとめたものです。

本RFCについては、本稿の「nsec3-guidanceの影響と次回のDNS flag dayの提案」でも記載しています。

▼dnsop WGの状況

dnsopはDNS Operationsに由来しており、DNSサーバーや登録情報の管理など、DNSの運用全般に関するガイドラインの作成を目的としています。WGでは、運用上の課題に着目したDNSプロトコルの拡張・メンテナンスも活動項目としています。

▽DNSにおけるIPフラグメンテーションの回避
（draft-ietf-dnsop-avoid-fragmentation）

JPRSの藤原和典が第一著者となっている、DNSにおけるIPフラグメンテーション[*27]を回避するための提案です。

本提案ではこれまでの議論の結果を受け、IPv4とIPv6においてPath MTUdiscoveryが失敗した、または不可能な場合のDNS/UDPの最大ペイロードサイズの推奨値を1400とした上で、2022年7月26日から3週間のWGでの合意確認期間（ワーキンググループラストコール（WGLC））が実施されています。

▼dprive WGの状況

dpriveはDNS PRIVate Exchangeに由来しており、通信の暗号化によってDNSトランザクションにおける機密性（confidentiality）を提供し、プライバシーを確保することを目的としています。

IETF 114では前回と同様、dprive WGは単独では開催されず、後述するadd WGの一部を割り当てる形で開催されました。

▽権威DNSサーバーとの暗号通信が可能かをフルリゾルバーから検出する仕組み
（draft-ietf-dprive-unilateral-probing）

フルリゾルバーと権威DNSサーバー間の通信の暗号化について、TCPとUDPのポート853でDNS over TLSまたはDNS over QUICの権威DNSサーバーを動作させ、フルリゾルバーでそれらのポートへの通信を試みることで暗号化の有無を検出・記憶する、シンプルな方式の提案です[*28]。

本提案は、暗号化の検出・記憶における権威DNSサーバーとフルリゾルバーの具体的な動作を、項目ごとに記述しています。発表ではそれらの動作について、権威DNSサーバーではPowerDNS Authoritative Server、フルリゾルバーではPowerDNS Recursorで実装を試していることが、開発者のPeter van Dijk氏から示されました。

▼add WGの状況

addはAdaptive DNS Discoveryに由来しており、パブリックネットワーク・プライベートネットワーク・VPNを含むさまざまなネットワーク環境において、DNSクライアントがリゾルバーを発見・選択するための技術的な仕組みの作成を目的としています。

▽標準化作業の進捗状況

add WGでは、以下の3件の提案について標準化作業を進めてきました。

これまでの作業により、これらの提案はいずれもWGLCを終了し、IESGに送られました。これらが標準化されることで、スプリットホライズンDNS[*31]における取り扱い[*32]などの残作業を除き、WGの当初の目的はほぼ完了することになります。

次回の第115回IETF Meeting（IETF 115）は、2022年11月5日から11日にかけて、英国のロンドン及びオンラインのハイブリッドで開催される予定です。

本会議報告は、JPRSのメールマガジン「FROM JPRS」の増刊号として発行した情報に写真などを交えてWebページ化したものです。
「FROM JPRS」にご登録いただいた皆さまには、いち早く情報をお届けしております。ぜひご登録ください。