第108回IETF Meeting報告

2020年7月27日から31日にかけて、第108回IETF Meeting（以下、IETF 108）が、完全オンライン会合として開催されました。IETFが完全オンライン会合で開催されるのは前回のIETF 107に引き続き、2回目となります。

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

• オンライン会合の開催に関する話題
  - 開催の状況
  - 利用されたツールの状況
• IETF 106以降のDNS関連RFCの発行状況
  - DLVの「歴史的」ステータスへの移行（RFC 8749）
  - AppleのDNS Long-Lived Queries（LLQ）拡張（RFC 8764）
  - DNSプッシュ通知（RFC 8765）
  - マルチキャストDNSベースのサービス発見用ディスカバリープロキシー（RFC 8766）
  - 期限切れキャッシュデータを用いた名前解決の継続（RFC 8767）
  - ルートサーバーのローカルでの実行
• dnsop WGにおける話題
  - 議論された主な提案の内容と作業の進行状況
• dprive WGにおける話題
  - 議論された主な提案の内容と作業の進行状況
• add WGにおける話題
  - WGにおける議論の状況と今後の予定
• 今後のIETF Meetingに向けた動き
  - shmoo WGの創設

▼開催の状況

前回のIETF 107では、開催直前の2020年3月10日に完全オンライン会合への変更が決定されました。変更に対応する準備期間が十分に確保できなかったことから、WG創設に向けたBoFと創設後に初めて会合を開催するWGを優先した、規模を縮小した形での開催となりました。

今回のIETF 108では、約2カ月前の2020年5月14日に完全オンライン会合での開催が発表されました[*1]。完全オンライン会合を前提とした事前準備が進められ、前回は会合期間中には開催されなかったdnsop、dpriveなどのDNS関連WGやハッカソンなども含まれた、フルアジェンダの形で開催されました[*2]。

▼利用されたツールの状況

今回の会合のため、以前からIETF会合で発表と質疑応答に使われていたMeetecho[*3]の機能・動作環境が強化されました[*4]。これに伴い、対面の会合では紙ベースであった会議参加記録（ブルーシート）もMeetechoによる自動記録に変更され、匿名でのハム（Hum）[*5]も可能になりました。

また、完全オンライン会合への移行に伴い従来は無料であったオンライン参加が有料化され、参加登録と結び付けられたIETF Datatracker[*6]のアカウントによるサインインが必須とされました。

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

▼DLVの「歴史的」ステータスへの移行

• RFC 8749: Moving DNSSEC Lookaside Validation (DLV) to Historic Status
  （Standards Track、draft-ietf-dnsop-obsolete-dlv）

本RFCは、DNSSEC Lookaside Validation（DLV）の仕様を定義した2本のRFC（RFC 4431、RFC 5074）を「歴史的（Historic）」ステータスに移行させます。

DLVは、親ゾーンがDNSSECに対応しておらずDSリソースレコード[*7]を登録できない場合に、特定のサーバーにDSリソースレコードに相当するDLVリソースレコードを登録し、DNSSEC対応リゾルバー側で検証するようにすることでDNSSECに対応する手法です。

DLVは、ルートやTLDがDNSSECに対応していない場合にDNSSECに対応する手段として開発されました。その後、ルートやTLDにおけるDNSSEC対応が進んだことを受け、今回「歴史的」ステータスに移行されることとなりました。

▼AppleのDNS Long-Lived Queries（LLQ）拡張

• RFC 8764: Apple's DNS Long-Lived Queries Protocol
  （Informational、draft-sekar-dns-llq）

DNS Long-Lived Queries（LLQ）は、サーバー側からクライアント側にDNSデータの変更を知らせることができるようにするためにAppleが独自に開発した、DNSの機能拡張です。

LLQは、IETFで標準化された「DNSプッシュ通知（RFC 8765、次で説明）」に置き換えられました。本RFCは、LLQからDNSプッシュ通知への円滑な移行のために文書化され、Informational（情報提供）RFCとして発行されました。

▼DNSプッシュ通知

• RFC 8765: DNS Push Notifications
  （Standards Track、draft-ietf-dnssd-push）

DNSにおいて、サーバー側からクライアント側にDNSデータの変更を知らせることができるようにするための、DNSの機能拡張を定義しています。DNSプッシュ通知は、前述したLLQを置き換えるために開発されました。

本機能では、利用したいクライアント側からのリクエストをサーバー側が受け付けた場合にのみ、クライアント側から事前に接続しておいたTCP接続を用いてサーバーが変更を通知するという形で、プッシュ通知を実現しています。

▼マルチキャストDNSベースのサービス発見用ディスカバリープロキシー

• RFC 8766: Discovery Proxy for Multicast DNS-Based Service Discovery
  （Standards Track、draft-ietf-dnssd-hybrid）

ローカルネットワークでマルチキャストDNS[*8]を用いて実現されるDNSベースのサービス発見（DNS-SD）[*9]を広域ネットワークで実現するための、マルチキャストDNSとDNSの間を仲介するディスカバリープロキシーの仕様を定義しています。

▼期限切れキャッシュデータを用いた名前解決の継続

• RFC 8767: Serving Stale Data to Improve DNS Resiliency
  （Standards Track、draft-ietf-dnsop-serve-stale）

フルリゾルバー（キャッシュDNSサーバー）が所定の権威DNSサーバーにアクセスできず、期限切れのデータを更新できない場合に、期限切れとなったキャッシュデータを用いた名前解決を可能にし、サービスの停止を回避する方法を定義しています。

本RFCは、DDoS攻撃や事故などで必要な権威DNSサーバーに到達できない状態が続いた場合の、名前解決エラーの発生の回避を目的としています。

▼ルートサーバーのローカルでの実行

• RFC 8806: Running a Root Server Local to a Resolver
  （Informational、draft-ietf-dnsop-7706bis）

ルートサーバーへの到達時間の短縮、ルートサーバーからの応答の確保、ルートサーバーに対するクエリ監視の防止などを実現するため、他の利用者に影響しない形でルートゾーンのローカルコピーを保持する方法・留意点と、主なフルリゾルバー実装における設定例について記述しています。

RFC 8806は、既存のRFC 7706を置き換えます。

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

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

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

JPRSの藤原和典が第一著者となっている、DNSにおけるIPフラグメンテーション（断片化）を回避するための提案です。本提案はIETF 107の終了後にWGで作業を進めることが採択され、2020年6月30日に最初のWG draftが公開されています。

今回のWGでは、藤原が現在の提案内容と旧版からの変更点について紹介しました。変更点が少なかったこともありWGでの質問はなく、メーリングリストで継続して作業を進めることとなりました。

なお、DNSからのIPフラグメンテーションの排除を主目的とした「DNS flag day 2020」の実施が、2020年10月1日に予定されています。本提案はDNS flag day 2020の公式サイト[*10]や関係者の資料などからも参照され、実施根拠の一つとなっています。

▽DNSKEYリソースレコードへのDELEGATION_ONLYフラグの追加
（draft-ietf-dnsop-delegation-only）

DNSKEYリソースレコードに、そのゾーンの内容が委任のみである旨を示す「DELEGATION_ONLY」フラグを追加するための提案です。DNSSECに対応したリゾルバーはこのフラグによってそのゾーンに設定される内容が委任情報のみであることを検証でき、違反する応答をBogus（DNSSEC検証失敗）とすることができます。

本提案はWGで作業を進めることが採択され、メーリングリストで継続して作業を進めることとなりました。

▽プライミング仕様の明確化
（draft-klh-dnsop-rfc8109bis）

RFC 8109で定義される、プライミング[*11]の仕様を明確化するための提案です。

本提案では、プライミングで得られる情報の内容、応答のTCビットの取り扱い、ICANN RSSAC[*12]の関連文書への参照、プライベートDNSに関する説明などが追加されています。

WGでは特に質問・コメントはなく、メーリングリストで継続して作業を進めることとなりました。

dpriveはDNS PRIVate Exchangeに由来しており、DNSトランザクションにおける機密性（confidentiality）の提供を目的としています。

当初の目的であった、スタブリゾルバーとフルリゾルバー間の通信のプライバシー確保に関する標準化作業は、DNS over TLS（DoT）とDNS over HTTPS（DoH）の標準化により完了しています。現在、WGでは次の段階として、フルリゾルバーと権威DNSサーバーの間や、権威DNSサーバー間の通信を暗号化するための作業が進められています。

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

▽TLS上でのゾーン転送
（draft-ietf-dprive-xfr-over-tls）

ゾーン転送をTLSで保護することで、権威DNSサーバー間の通信におけるプライバシーを確保する提案です。TLSは通信相手の認証も提供するため、DNSの通信に電子署名を付加して相手を認証する、TSIG[*13]の機能も実現できます。

本提案は目的・使い方が明確であることから標準化作業が進むことが予想され、実装も比較的容易であることからIETFハッカソンなどの場において、BIND 9やNSDなどへの実装実験が進められています。

▽DSリソースレコードへのDNS over TLS（DoT）情報の追加
（draft-vandijk-dprive-ds-dot-signal-and-pin）

DSリソースレコードの用途を拡張し、自分のゾーンの権威DNSサーバーがDoTに対応していることを伝える情報を追加する提案です。

権威DNSサーバーは、DoTで使うサーバー証明書から作成したDSリソースレコードを親ゾーンに登録します。フルリゾルバーは、名前解決の際にその情報を利用し、DoTの対応状況を確認できるようにするものです。

WGでは、本提案に対し好意的な意見が出され、今後も継続して作業を進めることとなりました。

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

addでは、DoTやDoHのようなトランスポートの暗号化に対応したリゾルバー（暗号化対応リゾルバー）と、従来の暗号化に対応しないリゾルバーの双方が対象となっています。また、活動の対象を技術的な仕組みの開発に絞り込んでおり、クライアントやサーバーのユースケース、ポリシーに関する推奨事項については、作業の対象外となっています。

▼WGにおける議論の状況と今後の予定

今回のWGでは、個別のユースケースを想定した暗号化対応リゾルバーの発見方法・枠組みに関する提案が5本、リゾルバーからクライアントに暗号化対応リゾルバーの情報を伝達するための提案が1本、暗号化対応リゾルバーを各ネットワークに展開する際の考慮点・必要な機能拡張に関する提案が2本発表されました。いずれの提案も、個人提案となっています。

今回の発表では、パブリックネットワーク・エンタープライズネットワーク・ホームネットワークなど、接続するネットワークに関する固有のユースケースが想定されていました。しかし、WGでは個別のユースケースについては作業の対象外となっており、提案内容に関する個別の議論は行われませんでした。

そのため、WGでは2020年9月10日と15日の2回にわたってオンラインの中間会合を開催し、今回の提案から一つないし二つの想定するユースケースを選び、要求条件を絞り込んだ形で議論が進められる予定となっています。

次回の第109回IETF Meeting（IETF 109）は2020年11月14日から20日にかけ、タイのバンコクで開催される予定となっていました。しかし、新型コロナウイルス感染症の状況から、IETF 108に引き続き、完全オンライン会合への変更が決定されました[*14]。

▼shmoo WGの創設

IETFでは今回の感染拡大を受け、状況の変化に対応できるようにIETF会合を進化させ、参加者とインターネットコミュニティによりよいサービスを提供し続けることを目的としたshmoo WGを、2020年7月10日に創設しました[*15]。WGでは現在、目的達成に向けた枠組み・ガイドラインの策定が進められています。

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