第113回IETF Meeting報告

2022年3月18日から25日にかけ、第113回IETF Meeting（以下、IETF 113）が、オーストリアのウィーンに設けられた現地会場とオンラインによるハイブリッド形式で開催されました。現地会場での開催は2020年3月のIETF 107以来で、およそ2年ぶりとなります。

今回のFROM JPRS増刊号では、会合の開催状況、DNS関連RFCの発行状況、及びDNS関連WGにおける話題について、以下の項目に沿ってお伝えします。

• 会合の開催に関する検討と状況
  - 開催形式の検討
  - 開催の状況
• IETF 112以降に発行されたDNS関連のRFC
  - プロトコル拡張機構の長期的な有効性（RFC 9170）
  - TCP上のDNSトランスポートにおける運用上の要件（RFC 9210）
  - 国際化ドメイン名の基本仕様（IDNA2008）とUnicode 12.0.0（RFC 9233）
• dnsop WGにおける話題
  - 議論された主な提案の内容と作業の進行状況
• dprive WGにおける話題
  - 議論された主な提案の内容と作業の進行状況
• add WGにおける話題
  - 議論された主な提案の内容と作業の進行状況
• 次回のIETF Meetingについて

▼開催形式の検討

新型コロナウイルス感染症の拡大を受け、IETF MeetingはIETF 107以降、完全オンラインでの開催が続いていました。

IETFではIETF 108の開催時に、会合の開催形式を対面とオンラインのどちらにするかを判断するための枠組みを作成し[*1]、以降の会合ではその枠組みにより、開催形式を決定してきました。

IETF 113の開催においても、この枠組みによって現地開催の可否が検討されました。その結果、当初予定していたタイのバンコクからオーストリアのウィーンに開催地を変更し、参加者と会場における感染予防策・拡大防止策を徹底した上で、参加者を500人まで（通常の現地開催の50％）とすれば現地開催が可能であるという判断に至った旨が、2021年12月22日に発表されました[*2]。

その後、2022年2月24日に、IETF 113を現地とオンラインのハイブリッド形式で開催する旨と、新型コロナウイルス感染症の状況が変化し、現地開催を計画通りに実施できなくなった場合は完全オンラインに変更する旨が、IETF ChairのLars Eggert氏から発表されました[*3]。

▼開催の状況

このような状況の中、IETF 113には世界各地から1,400人以上が参加しました。会合終了後の公式発表によると、現地参加が314人、オンライン参加が1,114人で[*4]、参加者の約20%が現地参加したことになります。

オンライン会合には前回に引き続きMeetecho[*5]が使われ、現地とオンラインの双方の参加者が、すべての発表に参加可能になるように設定・運用されました。

会合の時間は、開催地であるウィーンの時間帯（UTC+1）でスケジュールされました。

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

▼プロトコル拡張機構の長期的な有効性

• RFC 9170: Long-Term Viability of Protocol Extension Mechanisms
  （Informational: draft-iab-use-it-or-lose-it）

RFC 9170は、インターネットで使われるプロトコルの仕様変更・拡張の仕組みについて、これまでに発生した問題を振り返ると共に、仕様変更・拡張を長期にわたって継続できるようにするため、設計において取り得る戦略を考察しています。本RFCは、IETFの標準化プロセスを監督するIAB[*6]が、標準化活動を進めるために公開したものです。

本RFCはDNSでこれまでに発生した問題として、実装とシステムが硬直化し、新しいリソースレコード（以下、RR）タイプの導入が困難になった結果、TXT RRを使った安易な機能拡張がされるようになっていたことと[*7]、互換性確保のために導入されたフォールバック機能がEDNS0[*8]の普及を妨げ、結果としてDNS flag day[*9]のような大規模な調整が必要になったことを挙げています。

また、本RFCではプロトコルの設計時に取り得る戦略として、以下の四つを挙げています。

• 適用可能な範囲が広い拡張箇所を、より少なく設定する
• 仕様変更できない・しない部分を明確にする
• プロトコルに参加するエンティティーの数が少なくなるように設計する
• 問題発見のため、効果的なフィードバックの仕組みを導入する

▼TCP上のDNSトランスポートにおける運用上の要件

• RFC 9210: DNS Transport over TCP - Operational Requirements
  （Best Current Practice: draft-ietf-dnsop-dns-tcp-requirements）

RFC 9210は、DNSメッセージをTCPで送受信する際の運用上の要求事項を、現状における最良の慣行（Best Current Practice：BCP）としてまとめたものです。TCPでの送受信には、暗号化されたものも含まれます。

本RFCは、DNSのTCPサポートにおける実装上の要求事項を定めたRFC 7766に対応するものであり、RFC 1123とRFC 1536を更新します。本RFCにより、すべてのリゾルバーと権威DNSサーバーは、TCPとUDPの双方をサポートしてサービスを提供することが必須となります。

▼国際化ドメイン名の基本仕様（IDNA2008）とUnicode 12.0.0

• RFC 9233: Internationalized Domain Names for Applications 2008(IDNA2008) and Unicode 12.0.0
  （Standards Track: draft-faltstrom-unicode12）

RFC 9233は、国際化ドメイン名の基本仕様（IDNA2008）における、Unicode12.0.0への対応における変更点について記述したものです。

本RFCには、Unicode 6.0.0からUnicode 12.0.0までに追加された個々の文字を国際化ドメイン名でどのように取り扱うかを定めた一覧表が記載されており、国際化ドメイン名におけるそれらの文字の取り扱いを定めています。

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

▼議論された主な提案の内容と作業の進行状況

▽DNSSECのRFCのまとめと紹介（draft-hoffman-dnssec）

現在有効なDNSSECに関するRFCの概要を、1本のRFCでまとめて紹介するための提案です。

現在のDNSSECの基本仕様は、2005年に発行されたRFC 4033・4034・4035の3本のRFCで定められています。これら3本のRFCにより、それまでの長期にわたるDNSSECの標準化作業がまとめられ、DNSSECの古い仕様を定めた9本のRFCが廃止されました。

その後もIETFではDNSSECの改良・機能の追加が進められ、いくつかのRFCが追加発行されました。そのため、実装者や運用者はそれら複数のRFCの内容を必要に応じて理解し、実装・運用を進める必要があります。

本提案はこの状況を改善するため、DNSSECに関する現在有効なすべてのRFCを1本のRFCでまとめて紹介し、実装者や運用者がDNSSECをよりよく理解できるようにすることを目的としています。

WGでは本件の活動について、調査から始め、うまく進むようであれば有用である旨のフィードバックがIESG[*10]からあったことが紹介され、継続して作業を進めることとなりました。

その後、本提案は会議終了後の2022年4月7日に、WG Draftとなるdraft-ietf-dnsop-dnssec-bcpに更新されました。

▽名前解決失敗のネガティブキャッシュ（draft-dwmtwc-dnsop-caching-resolution-failures）

現在の仕様ではオプションとなっている、名前解決が失敗したことのキャッシュを必須にするための、仕様変更の提案です。

DNSでは、名前解決で得られたRRに加え、そのRRが存在しなかったこと（不在応答）もキャッシュします。このキャッシュを、ネガティブキャッシュ[*11]と呼びます。

RFC 2308・8020で定義される現在のネガティブキャッシュの仕様では、そのドメイン名と子孫の名前すべてにはいずれのRRも存在しなかったこと（NXDOMAIN応答）と、そのドメイン名には要求されたRRが存在しなかったこと（NODATA応答）をキャッシュします。しかし、

• サーバー側の問題で、問い合わせを処理できなかったこと（SERVFAIL応答）
• 問い合わせが拒否されたこと（REFUSED応答）
• 一定の時間内に応答を受信できず、タイムアウトしたこと
• 委任のループが発生したこと
• CNAME RR／DNAME RRのエイリアスループが発生したこと
• DNSSEC検証に失敗したこと

など、名前解決が失敗したことのキャッシュはオプションとなっています。

本提案の動機として、2021年10月のFacebook（現Meta Platforms）におけるDNS障害の際に、com/netの権威DNSサーバーへの問い合わせ数が通常時の100倍以上に増加したこと[*12]、2020年以降、NXNSAttack[*13]やtsuNAME[*14]といった、委任情報を利用した新しいDDoS攻撃の手法が公開されたことなどが紹介され、本提案を標準化・実装することで、これらの緩和が可能になる旨が説明されました。

WGでは本提案の標準化をサポートする意見が寄せられ、継続して作業を進めることとなりました。

▽参照グルーにおける要件（draft-ietf-dnsop-glue-is-not-optional）

メッセージサイズの制限により委任応答にグルーレコード[*15]を含めることができない場合、TCビット[*16]をセットすることで再問い合わせが必要である旨を伝えるようにするための、プロトコル更新の提案です。

発表では、前回からの変更点として、

• 本提案の範囲をDNS応答における取り扱いのみとし、ゾーンデータやレジストリのデータにおける取り扱いは対象外としたこと
• dprive WGにおけるグルーレコードの拡張に関する議論を受け、本提案の 範囲である従来からのグルーレコードについて「参照グルー（referral glue）」という用語を定義・使用することとしたこと
• 委任先のドメイン名とネームサーバーホスト名がインドメイン[*17]の関係である場合の参照グルーを「インドメイングルー（in-domain glue）」、シブリングドメイン[*18]の関係である参照グルーを「シブリンググルー（sibling glue）」とし、TCビットのセットを必須とするケースを、インドメイングルーの場合のみとしたこと
• 再問い合わせに使用する通信手段として、TCP以外も想定した内容に更新したこと

が説明されました。

また、現在は参照（referral）とグルー（glue）の定義があいまいであり、委任応答に含まれるNS RRとA/AAAA RRの双方を指すのか、片方なのかが明確ではないため、これらの用語の明確化・統一も図りたい旨が発表されました。

WGでは、DNS用語を定義するRFC 8499の共著者であるPaul Hoffman氏から、本提案で新しい用語が定義・標準化された場合、それらを現在作業中のRFC 8499の改訂版に取り込みたい旨がコメントされ、継続して作業を進めることとなりました。

▽DNSSECの予行演習（ドライラン）（draft-yorgos-dnsop-dry-run-dnssec）

名前解決サービスに影響を及ぼすことなくDNSSECの導入・設定変更をテストする予行演習（ドライラン[*19]）を可能にするための、プロトコル拡張の提案です。

DNSSECでは導入・設定変更の誤りが名前解決エラーにつながるため、慎重な作業が必要になります。また、親ゾーンに誤ったDS RR[*20]を登録してしまった場合、キャッシュされたDS RRによるDNSSEC検証エラーで名前解決ができない状態が長時間にわたり継続する可能性があります[*21]。

本提案では、DS RRのダイジェストタイプにドライランを示す値を追加し、リゾルバー側でそれを検知して、DNSSECエラーが発生した場合にDS RRが存在しない（DNSSEC検証をしない）状態にフォールバックすることで、名前解決サービスを継続しながら実環境におけるDNSSECの導入試験が可能になり、DNSSECの普及につながる旨が記述されています。

WGでは、本件に関する好意的な反応が多く寄せられ、継続して作業を進めることとなりました。

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

IETF 113ではdprive WGは単独では開催されず、後述するadd WGの前半部分を使う形で開催されました。

▼議論された主な提案の内容と作業の進行状況

▽暗号通信が可能かをフルリゾルバー側から検出・記憶する仕組み
（draft-ietf-dprive-unilateral-probing）

dprive WGでは、フルリゾルバー（キャッシュDNSサーバー）と権威DNSサーバー間の通信の暗号化の実現について、継続的な議論が進められてきました。これまでのWGで、暗号化対応の有無をどのように検出するかや、暗号通信に使うサーバー証明書の情報をどこにどう置き、どう検証するかといった課題に関する議論が活発に進められましたが、全体の方向性がまとまるまでには至りませんでした。

この状況を受け、WGでは対応する暗号方式をopportunistic（日和見）[*22] 方式に限定した上で、暗号通信が可能かをフルリゾルバー側から一方的に検出・記憶するようにし、暗号化による名前解決の遅延や悪影響を最小限に留めることを目的とした提案が作られ、これまでにWG Draftとなった提案は、本提案に置き換えられることとなりました。

[*22] 通信の暗号化を試みるが、相手の正当性を検証しない方式。

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

その上で、本提案は標準化課程（Standards Track）ではなく、いったん情報提供（Informational）または実験（Experimental）RFCの発行を目標として作業を進め、現時点で実装可能なものを作ることと、パフォーマンスの評価についてはIRTF[*23]のmaprg[*24]と連携したい旨が提案されました。

IETFの姉妹団体で、プロトコル、アプリケーション、アーキテクチャ、及び技術の進化に関する研究を推進しています。

WGでは、チャーターにExperimentalと書かれているため、本件を進めるためには必要に応じたリチャーター（チャーターの再設定）が必要である旨がコメントされ、継続して作業を進めることとなりました。

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

▼議論された主な提案の内容と作業の進行状況

▽スプリットホライズン環境におけるローカル権威DNSの確立（draft-reddy-add-enterprise-split-dns）

スプリットホライズンDNS（split-horizon DNS）[*25]が動作している環境において、分割されたネットワークの内側に存在するドメイン名をクライアントに通知・設定するための、機能拡張の提案です。

本提案では、クライアントがネットワークに接続した際、そのネットワークにおいてローカルに名前解決するドメイン名とリゾルバーのセットを得られるようにし、クライアントがその情報を使ってリゾルバーを適切に設定できるようにします。

こうした状況は組織内・家庭内ネットワークやVPN環境、複数の接続先を使い分ける場合など、さまざまなユースケースが考えられるため、WG参加者の間で必要性が認識されており、継続して作業を進めることとなりました。

▽リゾルバーの情報の公開（draft-reddy-add-resolver-info）

RRタイプRESINFO（RESINFO RR）を追加し、リゾルバーが自身の情報をDNSで公開できるようにするための、機能拡張の提案です。

本提案ではRESINFOレコードに記述される内容として、リゾルバーにおけるQNAME minimisation[*26]や拡張DNSエラー（EDE）[*27]のサポートの有無、利用におけるクライアントの認証の必要性、リゾルバーの情報を記述したURL、リゾルバーの概要を説明する文章などが想定されています。

WGでは、こうした情報が必要であるという考え方には賛成できるというコメントがあり、継続して作業を進めることとなりました。

次回の第114回IETF Meeting（IETF 114）は、2022年7月23日から29日にかけて、米国のフィラデルフィアで開催される予定です。

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