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

メールマガジン「FROM JPRS」

バックナンバー：vol.207

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2022/12/12━
                    ◆ FROM JPRS 増刊号 vol.207 ◆
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
                        第115回IETF Meeting報告
                  ～IETF全般、DNS関連WGにおける話題～
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2022年11月5日から11日にかけて、第115回IETF Meeting（以下、IETF 115）が、
英国ロンドンの現地会場とオンラインによるハイブリッド形式で開催されまし
た。

今回のFROM JPRS増刊号ではIETF 115から、FROM JPRS編集局が注目した話題に
ついてお伝えします。

  ・IETF 116 Yokohamaに関心をお持ちの方へ
    - 「The Tao of IETF」の新バージョンが公開
    - 託児サービスの提供
    - IETF 116 Yokohamaの開催予告
  ・開催の状況
  ・DNS関連RFCの発行状況
  ・DNS関連WGの状況
    - dnsop WGの状況
    - dprive WGの状況
    - add WGの状況
  ・次回のIETF Meetingについて

          ◇                     ◇                     ◇

■IETF 116 Yokohamaに関心をお持ちの方へ

次回の第116回IETF Meeting（以下、IETF 116）は、横浜での開催が予定されて
います。国内での開催は2015年11月に横浜で開催されたIETF 94以来、8年ぶり
となります。

本号ではIETF 115全般の話題の中から、IETF 116に関心をお持ちの方・参加を
ご検討されている方に役立つ情報をお届けします。

▼「The Tao of IETF」の新バージョンが公開

2022年9月9日に、IETFの初心者向けガイド「The Tao of IETF（以下、Tao）」
の新バージョンが公開されました[*1]。

[*1] IETF | The Tao of IETF: A Novice's Guide to the Internet
     Engineering Task Force
     https://www.ietf.org/about/participate/tao/

Taoは、IETF会合・WGの仕組み・関連する組織・標準化プロセスなどを平易な
文章で紹介しており、IETFになじみのない人や初めて参加する人が「IETFのや
り方」を理解するのに役立つ文書となっています。

Taoの最初のバージョンは1994年に公開されました。当初はRFCとして発行・改
訂されていましたが、2012年からはIETFの公式Webページで公開されています。
Taoの改訂作業はメーリングリストとGitHubによる、公開の場で進められてい
ます[*2]。

[*2] GitHub - ietf/tao: The Tao of the IETF
     https://github.com/ietf/tao

今回の改訂は2019年5月以来3年ぶりとなり、新型コロナウイルス感染症の拡大
を受けた、オンラインミーティングに関する記述などが追加されています。

なお、旧バージョンではありますが、2012年11月2日版のTaoの日本語翻訳版が、
IETFの公式Webページで公開されています[*3]。

[*3] IETFのタオ：初心者のためのインターネット技術タスクフォースガイド
     https://www6.ietf.org/tao-translated-ja.html

▼託児サービスの提供

IETF 115では、現地参加者向けに託児サービスが提供されました[*4]。

[*4] IETF | IETF onsite childcare
     https://www.ietf.org/how/meetings/115/childcare/

また、会合では、2023年以降に開催されるすべてのIETF Meetingで託児サービ
スの提供を予定している旨が、IETFチェアから発表されました。

▼IETF 116 Yokohamaの開催予告

IETF 116の開催予告が、ホストを務めるWIDEプロジェクトの関係者から発表さ
れました。

発表では、協賛を表明したスポンサーの一覧が示され、日本への入国にはワク
チン接種証明または陰性証明が必要になること、開催時期は桜の季節であり、
訪日の良い機会であることなどが共有されました。

  全体会議（Plenary）での発表
  （出典：https://www.youtube.com/watch?v=UqwL7HBrBiU）

■開催の状況

IETF 115には、世界各地から1,600人以上が参加しました。会合終了後の公式
発表によると参加者数は現地852人、オンライン766人で[*5]、2019年11月にシ
ンガポールで開催されたIETF 106以来、3年ぶりに現地参加者数がオンライン
参加者数を上回りました。

[*5] IETF | Past meetings
     https://www.ietf.org/how/meetings/past/

英国では「COVID-19と共に生きる（Living with COVID-19）」政策が実施され
ており、現地会場の一般エリアやロンドン市内では、マスクを着用している人
は見受けられませんでした。しかし、現地会場では受付時に新型コロナウイル
ス感染症の検査キットが無償配布され、会議室でのマスクの着用が義務付けら
れるなど、感染拡大防止のための対策が継続して実施されました。

■DNS関連RFCの発行状況

IETF 114の開催直後に発行されたRFC 9276以降、DNS関連のRFCは発行されてい
ません。

本稿執筆時点で、dnsop WGから提案されたHTTPS/SVCBリソースレコード（以下、
RR）（draft-ietf-dnsop-svcb-https）とadd WGの3本の提案
（draft-ietf-add-ddr、draft-ietf-add-dnr、draft-ietf-add-svcb-dns）の作
業が終了しており、RFC発行待ち（RFC Ed Queue）となっています。

これらのうち、HTTPS/SVCB RRの提案はtls WGが標準化作業を進めている
Encrypted ClientHello[*6]の仕様（draft-ietf-tls-esni）を参照しているた
め、RFCの発行は、そのRFCの発行後になると見込まれています。

[*6] TLSのClientHelloメッセージを暗号化し、アクセス先のバーチャルホスト
     が外部に漏えいしないようにするための仕組みです。

また、add WGの3本の提案は前述したSVCB RRを使っており、
draft-ietf-add-dnrは前述したEncrypted ClientHelloの仕様を参照している
ことから、RFCの発行は、これらのRFCの発行後になると見込まれています。

■DNS関連WGの状況

▼dnsop WGの状況

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

▽特殊用途ドメイン名.altの予約（draft-ietf-dnsop-alt-tld）

DNSではない名前空間のためのTLD「.alt」を、特殊用途ドメイン名[*7]として
予約するための提案です。

[*7] .localや.testなど、通常のインターネットの利用以外のために予約され
     るドメイン名です。

特殊用途ドメイン名の取り扱いは、RFC 6761で定義されています。しかし、
2015年10月に実施された.onion[*8]の予約においてRFC 6761に存在する複数の
問題点が指摘され、それらをまとめたRFC 8244が、2017年10月に発行されまし
た[*9]。本提案は.altを予約・利用することで、RFC 8244で指摘された問題点
を解決することを目的としています。

[*8] TCP/IP接続の匿名性を高める技術であるTor（トーア）で使われる、特殊
     用途ドメイン名です。

[*9] RFC 8244で指摘された問題点の概要については、過去のドメイン名関連
     会議報告をご参照ください。
     https://jprs.jp/related-info/event/2017/1213IETF.html

今回のWGでは作業を進めるため、リゾルバーにおける.altの特別扱いの有無、
ルートサーバーの負荷を軽減するための.altの委任の要否、.arpaゾーンのよう
にセカンドレベルドメインを予約・委任する場合の管理など、作業を進める上
での要考慮点が参加者に共有・議論されました。

本提案の初版は2014年に作成され、現在まで長年にわたり断続的に議論されて
きましたが、最終的な合意には至っていません。本件が取り扱う内容にはIETF
での技術的な検討だけでは解決が難しい項目も含まれており、WGでの合意形成
にはまだかなりの時間を要すると考えられます。

▽DNSプロキシーの制御オプション（draft-homburg-add-codcp）

スタブリゾルバーからDNSプロキシーを制御するための、EDNS0[*10]オプション
を定義するプロトコル拡張の提案です。

[*10] JPRS用語辞典｜EDNS0（イーディエヌエスゼロ）
      https://jprs.jp/glossary/index.php?ID=0147

DNS over TLS/HTTPS/QUICなど、スタブリゾルバーがフルリゾルバーとの通信で
使うプロトコルの種類が増えています。こうしたプロトコルをスタブリゾルバー
にそのまま実装すると、スタブリゾルバーのコード量が増え、構造が複雑にな
る恐れがあります。

そこで、複数のプロトコルでフルリゾルバーと通信可能なDNSプロキシーを別途
準備し、スタブリゾルバーとフルリゾルバーの間に挿入することで、スタブリ
ゾルバーを複雑化させることなく、それらのプロトコルをサポートできるよう
になります。本提案ではこの形で使われるDNSプロキシーを、スタブリゾルバー
からDNSクエリで制御する仕組みを提供します。

提案には、フルリゾルバーの選択・通信手段の指定・トラストアンカー[*11]
の提供などのオプションが含まれています。今回のWGでは、Connect by Name
[*12]というDNSライブラリを使って提案の実装・開発作業を進めていること、
Unboundの開発チームがIETF 116のハッカソン[*13]で実装を試作する予定であ
ることが共有され、継続して作業を進めることとなりました。

[*11] JPRS用語辞典｜トラストアンカー
      https://jprs.jp/glossary/index.php?ID=0196

[*12] NLnet; Connect by Name
      https://nlnet.nl/project/connectbyname/

[*13] ハッカソン（Hackathon）は、エンジニアが集中的に共同作業をする場
      を意味しています。IETFではIETF 92からハッカソンが実施されており、
      新しく標準化された、あるいは標準化作業中のプロトコルの実装の試作
      が、集中的に進められています。

▼dprive WGの状況

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

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

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

フルリゾルバーと権威DNSサーバー間の通信の暗号化について、フルリゾルバー
から853/tcp（DNS over TLS）と853/udp（DNS over QUIC）の通信を試みるこ
とで、暗号通信が可能かを検出・記憶する提案です。

フルリゾルバーと権威DNSサーバー間の通信における暗号化の実現、機能の検
出については、これまでのWGでさまざまな方式が提案されました。しかし、い
ずれの方式も合意に至らず、長い議論を経て現在のシンプルな方式に一本化さ
れました[*14]。

[*14] 本提案に至るまでの議論の経緯については、過去のドメイン名関連会議
      報告をご参照ください。
      https://jprs.jp/related-info/event/2022/0427ietf.html

今回のWGでは今後の方向性として、これまでの課題を反映した更新版の提案を
12月半ばに公開し、メーリングリストでの議論を反映した上で、2023年1月に
WGでのワーキンググループラストコール（以下、WGLC）を実施したい旨が報告
され、継続して作業を進めることとなりました。

▼add WGの状況

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

▽標準化作業の進捗状況

add WGでは主要な提案に関する作業を終え[*15]、スプリットホライズン環境
[*16]におけるリゾルバーの発見・選択の取り扱いなど、残っている作業を進め
ています。

[*15] add WGでまとめられた提案の内容については、過去のドメイン名関連会
      議報告をご参照ください。
      https://jprs.jp/related-info/event/2022/0830ietf.html

[*16] 送信元の状況（例：送信元IPアドレス）の違いに応じ、特定のドメイン
      名の問い合わせに対して異なる応答を返すように設定されている状況・
      環境を指します。

▽スプリットホライズン環境におけるローカルゾーンの権限確認
  （draft-ietf-add-split-horizon-authority）

スプリットホライズン環境において、DNSクライアントがローカルに名前解決
されるゾーン（以下、ローカルゾーン）の権限確認の手段を提供するプロトコ
ル拡張の提案です。

スプリットホライズン環境を実現する方法の一つとして、管理者がローカルゾー
ンの権威DNSサーバーを組織内のフルリゾルバーに設定し、利用者に提供する形
が挙げられます。この方法は、組織内の利用者がこのフルリゾルバーのみを使
う場合は有効ですが、複数のフルリゾルバーを使い分けたい場合、どのドメイ
ン名がローカルゾーンとして設定され、管理権限を有しているかの情報を、利
用者側から確認する必要があります。本提案は、そのための手段を提供します。

WGでは、.home.arpa、.localなどの特殊用途ドメイン名については対象外とし、
本提案による権限確認を禁止する旨を追加したことが共有されました。

その上で、追加の課題がなければWGLCに進みたい旨が発表され、継続して作業
を進めることとなりました。

■次回のIETF Meetingについて

冒頭でご紹介したように、次回のIETF 116は2023年3月25日から31日にかけて、
横浜で開催される予定です。

JPRSは、IETF 116にゴールドスポンサーとして協賛しています。IETF 116では、
IETFで取り扱う技術を採用した製品・活動の紹介の場であるBits-N-Bitesを再
開する旨がアナウンスされており[*17]、JPRSは協賛社として、参加・出展を
予定しています[*18]。

[*17] IETF 116 Yokohamaのお知らせ（江崎浩氏）
      https://drive.google.com/file/d/11sfhhxi-ekipq13v4fqevnbzbvep6n0_/view

[*18] JPRSが参加・出展したIETF 94のBits-N-Bitesの状況については、過去の
      ドメイン名関連会議報告をご参照ください。
      https://jprs.jp/related-info/event/2015/1207IETF.html

          ◇                     ◇                     ◇

◎関連URI

  - IETF | IETF 115 London
    https://www.ietf.org/how/meetings/115/
    （IETF 115公式ページ）

  - IETF 115 Proceedings
    https://datatracker.ietf.org/meeting/115/proceedings
    （IETF 115会議記録）

  - Domain Name System Operations (dnsop)
    https://datatracker.ietf.org/wg/dnsop/charter/
    （dnsop WG公式ページ）

  - DNS PRIVate Exchange (dprive)
    https://datatracker.ietf.org/wg/dprive/charter/
    （dprive WG公式ページ）

  - Adaptive DNS Discovery (add)
    https://datatracker.ietf.org/wg/add/charter/
    （add WG公式ページ）

━━━━━━━━━━━━━━━━━━━━━━━━━━━【FROM JPRS】━
■会議報告：https://jprs.jp/related-info/event/
■配信先メールアドレスなどの変更：https://jprs.jp/mail/henkou.html
■バックナンバー：https://jprs.jp/mail/backnumber/
■ご意見・ご要望：from@jprs.jp

当メールマガジンは、Windowsをお使いの方はMSゴシック、macOSをお使いの方
はOsaka等幅などの「等幅フォント」で最適にご覧いただけます。

当メールマガジンの全文または一部の文章をWebサイト、メーリングリスト、
ニュースグループ、他のメディアなどへ許可なく転載することを禁止します。
また、当メールマガジンには第三者のサイトへのリンクが含まれていますが、
リンク先のサイトの内容などについては、JPRSの責任の範囲外であることに
ご注意ください。
その他、ご利用に当たっての注意事項は読者登録規約にてご確認ください。
https://jprs.jp/mail/kiyaku.html
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
編集・発行：株式会社日本レジストリサービス（JPRS）
https://jprs.jp/
Copyright (C), 2022 Japan Registry Services Co., Ltd.