第110回IETF Meeting報告

2021年3月8日から12日にかけ、第110回IETF Meeting（以下、IETF 110）が、オンラインで開催されました。新型コロナウイルス感染症の拡大を受け、IETFMeetingは2020年3月に開催されたIETF 107以降、オンラインでの開催が続いています。

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

• オンライン会合の開催に関する話題
  - 開催の状況
• IETF 110までに発行されたDNS関連のRFC
  - DNSゾーンのメッセージダイジェスト（RFC 8976）
• dnsop WGにおける話題
  - 議論された主な提案の内容と作業の進行状況
• dprive WGにおける話題
  - 議論された主な提案の内容と作業の進行状況
• add WGにおける話題
  - 議論された主な提案の内容と作業の進行状況
• 次回のIETF Meetingについて

▼開催の状況

前回に引き続き、今回のIETF 110もフルアジェンダの形でオンライン開催され、世界各地から1,000人以上が参加しました。会合の時間は、当初の開催予定地であったチェコのプラハの時間帯（UTC+1）を基準にしてスケジュールされました。

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

▼DNSゾーンのメッセージダイジェスト（ZONEMD）

• RFC 8976: Message Digest for DNS Zones
  （Standards Track、draft-ietf-dnsop-dns-zone-digest）

RFC 8976は、DNSゾーンデータ全体のメッセージダイジェスト（ハッシュ値[*1]）を生成し、ZONEMDリソースレコード（以下、RR）としてゾーンファイルに保持するプロトコル拡張の仕様を定義します。

ZONEMDをDNSSECと組み合わせて使うことで、ゾーンデータの受信者は受信したゾーンデータ全体の完全性と作成元の正当性を確認でき、ゾーン転送やその他の手段で受信したゾーンデータがオリジナルから変更されていないことを検証できます。DNSSECなしで使った場合、ZONEMDはチェックサムとしてのみ機能し、送信エラーや切り捨てなどの偶発的な破損からゾーンデータを保護します。

ZONEMD RRのフォーマットを以下に示します。スキームは現時点で1のSimpleのみが、ハッシュアルゴリズムは1のSHA-384と、2のSHA-512が定義されています。

  ＜フォーマット＞
  ドメイン名 TTL IN ZONEMD シリアル スキーム ハッシュアルゴリズム (
      ダイジェスト )

  ＜使用例（RFC 8976から引用）＞
  example.com. 86400 IN ZONEMD 2018031500 1 1 (
      FEBE3D4CE2EC2FFA4BA99D46CD69D6D29711E55217057BEE
      7EB1A7B641A47BA7FED2DD5B97AE499FAFA4F22C6BD647DE )

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

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

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

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

会合では発表者の藤原が、IPv4とIPv6におけるDNS/UDPの最大ペイロードサイズとしてどの値を採用するかを決めるため、いくつかの候補を示した上で参加者に問い掛けました。藤原が示した候補は、以下の通りです。

• DNSSECでサポートしなければならないと定められている最小値である1220
• DNS flag day 2020で推奨されている1232
• PPPoEやIPv4 over IPv6など、アクセス回線の状況を考慮した1400
• Geoff Huston氏の文書[*3]に記載されている1472（IPv4）及び1452（IPv6）
• 他に良い値があれば、その値と理由

議長からは、どうすれば値を決められるか意見が欲しい旨の参加者への呼び掛けと「実装者からのフィードバックを得て欲しい」という発表者へのコメントがありました。会合にはGoogle Public DNSの担当者も参加しており「特定の値を選ぶのは難しい」というコメントがありました。

また、「IPv4とIPv6で同じ値を選ぶ必要はなく、問題を起こさないと認識されている最大値をそれぞれ選ぶのがよい」「一つの値を理由と共に示し、変更を許容するのはどうか」などのコメントもあり、どの値を採用するかについてはメーリングリストで継続して作業を進めることとなりました。

▽DNSを介したサービスバインディングとパラメーターの指定
（draft-ietf-dnsop-svcb-https）

そのドメイン名で提供されるサービスへのアクセスに必要な情報を設定するSVCB RRとHTTPS RRの仕様を定義する、プロトコル拡張の提案です。

SVCBは、"Service Binding"に由来しています。SVCB RRはHTTPS以外のサービスにも適用可能な形で定義され、HTTPS RRはSVCBのバリエーションとして、HTTPS及びHTTPスキームに特化した形で定義されています。

SVCB RRと同様の機能を持つものに、RFC 2782で定義されるSRV RRがあります。SVCB RRにはSRV RRにはなかった、クライアントにプロトコルの変更やアップグレードを通知する機能や、新しいパラメーターで自身を拡張する機能が含まれています。

本稿では、一部のベンダーが先行導入を進めている、HTTPS RRについて説明します。HTTPS RRのフォーマットと使用例を以下に示します。

  ＜フォーマット＞
  ドメイン名 TTL IN HTTPS 優先度 ターゲット名 [ サービスパラメーター ]


  ＜使用例（draft-ietf-dnsop-svcb-httpsから引用）＞
  （CDNサービス利用者のゾーン）
  $ORIGIN aliased.example.
  @     7200 IN HTTPS 0 pool.svc.example.

  （CDNサービスプロバイダーのゾーン）
  $ORIGIN svc.example.
  pool  7200 IN HTTPS 1 h3pool alpn=h2,h3 echconfig="123..."
                HTTPS 2 .      alpn=h2 echconfig="abc..."
  pool   300 IN A        192.0.2.2
                AAAA     2001:db8::2
  h3pool 300 IN A        192.0.2.3
                AAAA     2001:db8::3

CDNサービス利用者のaliased.exampleゾーンで用いられるエイリアスモード（優先度に0を設定）は、CDNサービスを利用する際に、ゾーン頂点（zone apex）に別名を書けるようにするためのものです。この例では、CDNサービス利用者のaliased.exampleゾーン頂点のドメイン名（aliased.example）に、別名（pool.svc.example）を指定しています。

CDNサービスプロバイダーのsvc.exampleゾーンでは、WebブラウザーがHTTP/2やHTTP/3の接続に必要な、各種パラメーターと優先度を指定しています。この例では、WebブラウザーがHTTPS RRをサポートしている場合、そのCDNサービスプロバイダーへの接続はHTTPSにアップグレードされ、利用可能な場合、HTTP/3接続を使うようになります。

このように、CDNサービスプロバイダーが接続に必要なパラメーターをHTTPSRRで設定し、Webブラウザーが接続時にHTTPS RRを検索するようにすることで、HTTPS接続に必要な情報を、DNS検索で取り扱えるようになります。

本提案はWGでの議論を経て、現在ワーキンググループラストコール（WGLC）が実施されています。作業の進捗状況を受け、SVCB RRとHTTPS RRはIANAによるRRタイプの割り当てが完了しており[*4]、一部のWebブラウザーやCDNサービス事業者などで使われ始めています[*5]。

▽NSEC3パラメーター設定のガイダンス
（draft-hardaker-dnsop-nsec3-guidance）

DNSSECのNSEC3による不在証明について、現在の運用状況を基にパラメーター設定のガイダンスを提供する運用方式の提案です。

NSEC3では外部からのゾーン列挙[*6]をしにくくするため、ソルト[*7]付きのハッシュ計算を繰り返し実施します。NSEC3の仕様を定義するRFC 5155では繰り返し回数の最大値を、鍵長が1024ビットの場合150回、2048ビットの場合500回、4096ビットの場合2500回と定めています。

本提案では、不特定多数のクライアントのリクエストを処理することで計算リソースが制約されがちなパブリックDNSサービスにおいて、DNSSEC検証サポートが大幅に進んでいることを勘案し、リゾルバー側のDNSSEC検証におけるハッシュ計算の繰り返し回数を鍵長によらず最大100回に制限した上で、制限を超えた場合SERVFAILエラーにすることを推奨しています。

また、権威DNSサーバー側ではソルトの値を0にした上で繰り返し回数を0回にし、大規模なTLDのような非常に大きく、かつ署名されていない数多くの委任情報を持つゾーン以外では、Opt-Outフラグを設定しないことを推奨しています。

会合では「SERVFAILエラーではなく、知らない署名アルゴリズムと同じように安全ではない（Insecure）と扱うのが良いのでは」「TLDによってはゾーン内容を開示しないように、ソルトを設定した上でDNSSECを運用しているため、運用に悪影響を及ぼす可能性がある」などのコメントがあり、それらを検討するために継続して作業を進めることになりました。

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

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

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

▽フルリゾルバーと権威DNSサーバー間の通信の暗号化
（draft-ietf-dprive-opportunistic-adotq）

フルリゾルバーと権威DNSサーバーの間の通信の暗号化に関する提案の内容が、前回のIETF 109で提案されたものから大きく変更されました。

最初のバージョン（-00）では、認証方式にはopportunistic（日和見）[*8]を、暗号化にはDoTまたはDNS over QUIC（DoQ）を使い、暗号化の有無は権威DNSサーバーのDoTのポート（853/TCP）でのサービス提供の有無で検出する方式が採用されていました。

会合直前の2021年2月22日に公開された次のバージョン（-01）では、認証方式として日和見に加え、設定されているTLSA RR[*9]でサーバー証明書を検証し、通信相手の正当性を認証する方式が追加され、TLSA RRが存在しない、あるいは検証に失敗した場合、名前解決エラーにする厳密なモードも定義されました。

同時に、暗号化の有無を検出する方式も、TLSA RRの存在をチェックする方法に変更されました。内容が大幅に変更されたことを受け、本提案は標準化過程（Standards Track）RFCを目指すものから、実験的（Experimental）RFCを目指すものに変更されました。

会合終了後の2021年3月22日、本提案の第一著者であるPeter van Dijk氏がWGのメーリングリストに、本件に関する今後の進め方の案を投稿しました[*10]。投稿では、本提案と別に公開された提案（draft-rescorla-dprive-adox-latest）の内容を取り込み、認証方式としてTLSAに代えてSVCB RR[*11]を採用することでプロトコルの柔軟性を高め、DoTとDoQ以外の暗号化の方式も使えるようにする形で作業を進めたい旨が提案されています。

メーリングリストでは現在も本件に関するさまざまな意見が投稿されており、作業全体の方向性がまとまり、RFCが発行されるまでには、まだかなりの作業を要すると予想されます。

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

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

▽リゾルバーの構成を検出するための仕組み
（draft-ietf-dns-ddr）

クライアントがDNS経由で暗号化リゾルバー[*12]の構成を検出する仕組みである「Discovery of Designated Resolvers（DDR）」を定義する提案です。

本提案は、非暗号化リゾルバーのIPアドレスのみを知っているクライアントが、リゾルバーを非暗号化リゾルバーから暗号化リゾルバーに移行するために使うことを想定しています。具体的には、特殊用途ドメイン名として「resolver.arpa」を予約し、「_dns.resolver.arpa」に暗号化リゾルバーのサービスを検出するためのSVCB RRを設定する方法が提案されています。

また、本提案は、暗号化リゾルバーのホスト名を知っているクライアントが、そのリゾルバーがどのような暗号化プロトコルをサポートしているかを検出するために使うことも想定しています。具体的には、暗号化リゾルバーのホスト名が「resolver.example.com」であった場合、「_dns.resolver.example.com」に暗号化プロトコルを検出するためのSVCB RRを設定する方法が提案されています。

会合では、「接続先の確認の際、サーバー証明書にIPアドレスの記載がないと信用できないのではないか」「特殊用途ドメイン名はDNSSECに対応できないため、実際のドメイン名を使う方法にすべき」「ホスト名がCNAMEで提供された場合の対応はどうするのか」といったコメントがあり、それらを検討するために継続して作業を進めることになりました。

▽暗号化されたリゾルバーを検出するためのDHCP及びIPv6 RAのオプション
（draft-ietf-add-dnr）

クライアントが暗号化に対応しているリゾルバーをローカルネットワーク内で検出できるようにするため、DHCPv4/v6、及びIPv6 RAに新しいオプションを定義する、プロトコル拡張の提案です。

会合では、最初に問い合わせ先の情報をクライアントに応答する際、どのようなフォーマットでデータを渡すべきかについて議論されました。「DDRと同じ情報が必要なのであれば、同じ仕組みを適用してSVCB RRで渡せばよく、別の仕組みを作る必要はないのではないか」というコメントがあり、それらを検討するために継続して作業を進めることになりました。

次回の第111回IETF Meeting（IETF 111）は2021年7月24日から30日にかけ、米国のサンフランシスコで開催される予定となっています。開催形式が変更される場合、IETFから別途アナウンスされる予定です。

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