JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト
JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト
メールマガジン「FROM JPRS」
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2022/04/27━
◆ FROM JPRS 増刊号 vol.202 ◆
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
第113回IETF Meeting報告
～会合の開催状況と、DNS関連WGにおける話題～
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
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]、以降の会合ではその枠組みによ
り、開催形式を決定してきました。
[*1] IETF | Assessment framework for in-person vs online IETF 108
meeting
https://www.ietf.org/how/meetings/108/assessment-framework-person-vs-online-ietf-108-meeting/
IETF 113の開催においても、この枠組みによって現地開催の可否が検討されま
した。その結果、当初予定していたタイのバンコクからオーストリアのウィー
ンに開催地を変更し、参加者と会場における感染予防策・拡大防止策を徹底し
た上で、参加者を500人まで（通常の現地開催の50％）とすれば現地開催が可
能であるという判断に至った旨が、2021年12月22日に発表されました[*2]。
[*2] IETF 113 will be a hybrid onsite/online meeting in Vienna, Austria
https://mailarchive.ietf.org/arch/msg/ietf-announce/eegvx3psp4u6jvom21by9aj4b3m
その後、2022年2月24日に、IETF 113を現地とオンラインのハイブリッド形式
で開催する旨と、新型コロナウイルス感染症の状況が変化し、現地開催を計画
通りに実施できなくなった場合は完全オンラインに変更する旨が、IETF Chair
のLars Eggert氏から発表されました[*3]。
[*3] IETF 113 going ahead as a hybrid meeting
https://mailarchive.ietf.org/arch/msg/ietf-announce/jblxcnx6ucxk2l46tfo9sijvj5m/
▼開催の状況
このような状況の中、IETF 113には世界各地から1,400人以上が参加しました。
会合終了後の公式発表によると、現地参加が314人、オンライン参加が1,114人
で[*4]、参加者の約20%が現地参加したことになります。
[*4] IETF | Past meetings
https://www.ietf.org/how/meetings/past/
オンライン会合には前回に引き続きMeetecho[*5]が使われ、現地とオンライン
の双方の参加者が、すべての発表に参加可能になるように設定・運用されまし
た。
[*5] RTC Experts - Meetecho
https://www.meetecho.com/
会合の時間は、開催地であるウィーンの時間帯（UTC+1）でスケジュールされ
ました。
■IETF 112以降に発行されたDNS関連のRFC
前回の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ではプロトコルの設計時に取り得る戦略として、以下の四つを挙
げています。
・適用可能な範囲が広い拡張箇所を、より少なく設定する
・仕様変更できない・しない部分を明確にする
・プロトコルに参加するエンティティーの数が少なくなるように設計する
・問題発見のため、効果的なフィードバックの仕組みを導入する
[*6] JPRS用語辞典｜IAB（アイエービー）
https://jprs.jp/glossary/index.php?id=0025
[*7] IABが、2009年にRRタイプの追加を好ましい解決策としたRFC 5507を公開
したことを受け、2010年以降は新しいRRタイプが積極的に導入されるよ
うになっています。
[*8] JPRS用語辞典｜EDNS0（イーディエヌエスゼロ）
https://jprs.jp/glossary/index.php?ID=0147
[*9] DNS flag dayに関する文書の公開と対応状況の確認について（2019年1月
28日更新）
https://jprs.jp/tech/notice/2019-01-21-dns-flag-day.html
▼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）における、Unicode
12.0.0への対応における変更点について記述したものです。
本RFCには、Unicode 6.0.0からUnicode 12.0.0までに追加された個々の文字を
国際化ドメイン名でどのように取り扱うかを定めた一覧表が記載されており、
国際化ドメイン名におけるそれらの文字の取り扱いを定めています。
■dnsop WGにおける話題
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]からあったことが紹介され、継続して作業
を進めることとなりました。
[*10] Internet Engineering Steering Groupの略称。
IETFの各エリアのエリアディレクターにより構成され、IETFの活動と標
準化プロセスを管理し、議論の方向性をガイドする役割を担います。
その後、本提案は会議終了後の2022年4月7日に、WG Draftとなる
draft-ietf-dnsop-dnssec-bcpに更新されました。
▽名前解決失敗のネガティブキャッシュ
（draft-dwmtwc-dnsop-caching-resolution-failures）
現在の仕様ではオプションとなっている、名前解決が失敗したことのキャッ
シュを必須にするための、仕様変更の提案です。
DNSでは、名前解決で得られたRRに加え、そのRRが存在しなかったこと（不在
応答）もキャッシュします。このキャッシュを、ネガティブキャッシュ[*11]
と呼びます。
[*11] JPRS用語辞典｜ネガティブキャッシュ（negative cache）
https://jprs.jp/glossary/index.php?id=0177
RFC 2308・8020で定義される現在のネガティブキャッシュの仕様では、そのド
メイン名と子孫の名前すべてにはいずれのRRも存在しなかったこと（NXDOMAIN
応答）と、そのドメイン名には要求されたRRが存在しなかったこと（NODATA応
答）をキャッシュします。しかし、
・サーバー側の問題で、問い合わせを処理できなかったこと（SERVFAIL応答）
・問い合わせが拒否されたこと（REFUSED応答）
・一定の時間内に応答を受信できず、タイムアウトしたこと
・委任のループが発生したこと
・CNAME RR／DNAME RRのエイリアスループが発生したこと
・DNSSEC検証に失敗したこと
など、名前解決が失敗したことのキャッシュはオプションとなっています。
本提案の動機として、2021年10月のFacebook（現Meta Platforms）におけるDN
S障害の際に、com/netの権威DNSサーバーへの問い合わせ数が通常時の100倍以
上に増加したこと[*12]、2020年以降、NXNSAttack[*13]やtsuNAME[*14]といっ
た、委任情報を利用した新しいDDoS攻撃の手法が公開されたことなどが紹介さ
れ、本提案を標準化・実装することで、これらの緩和が可能になる旨が説明さ
れました。
[*12] Observations on Resolver Behavior During DNS Outages - Verisign
Blog
https://blog.verisign.com/security/facebook-dns-outage/
[*13] JPRS用語辞典｜NXNSAttack（エヌエックスエヌエスアタック）
https://jprs.jp/glossary/index.php?id=0262
[*14] JPRS用語辞典｜tsuNAME（ツネーム）
https://jprs.jp/glossary/index.php?id=0275
WGでは本提案の標準化をサポートする意見が寄せられ、継続して作業を進める
こととなりました。
▽参照グルーにおける要件（draft-ietf-dnsop-glue-is-not-optional）
メッセージサイズの制限により委任応答にグルーレコード[*15]を含めること
ができない場合、TCビット[*16]をセットすることで再問い合わせが必要であ
る旨を伝えるようにするための、プロトコル更新の提案です。
[*15] JPRS用語辞典｜グルーレコード（glue records）
https://jprs.jp/glossary/index.php?id=0185
[*16] JPRS用語辞典｜TCビット
https://jprs.jp/glossary/index.php?ID=0204
発表では、前回からの変更点として、
・本提案の範囲をDNS応答における取り扱いのみとし、ゾーンデータやレジ
ストリのデータにおける取り扱いは対象外としたこと
・dprive WGにおけるグルーレコードの拡張に関する議論を受け、本提案の
範囲である従来からのグルーレコードについて「参照グルー（referral
glue）」という用語を定義・使用することとしたこと
・委任先のドメイン名とネームサーバーホスト名がインドメイン[*17]の関
係である場合の参照グルーを「インドメイングルー（in-domain glue）」、
シブリングドメイン[*18]の関係である参照グルーを「シブリンググルー
（sibling glue）」とし、TCビットのセットを必須とするケースを、イン
ドメイングルーの場合のみとしたこと
・再問い合わせに使用する通信手段として、TCP以外も想定した内容に更新
したこと
が説明されました。
[*17] DNSの用語を定めるRFC 8499で定義されており、委任先のドメイン名が
example.jp、ネームサーバーホスト名がns.example.jpのように、ネー
ムサーバーホスト名に委任先のドメイン名が完全に含まれている場合を
指します。
[*18] DNSの用語を定めるRFC 8499で定義されており、委任先のドメイン名が
example.jp、ネームサーバーホスト名がns.example.ne.jpのように、
ネームサーバーホスト名が委任元のゾーン（この例ではjp）の子孫であ
るが、インドメインの関係ではない場合を指します。
また、現在は参照（referral）とグルー（glue）の定義があいまいであり、委
任応答に含まれるNS RRとA/AAAA RRの双方を指すのか、片方なのかが明確では
ないため、これらの用語の明確化・統一も図りたい旨が発表されました。
WGでは、DNS用語を定義するRFC 8499の共著者であるPaul Hoffman氏から、本
提案で新しい用語が定義・標準化された場合、それらを現在作業中のRFC 8499
の改訂版に取り込みたい旨がコメントされ、継続して作業を進めることとなり
ました。
▽DNSSECの予行演習（ドライラン）（draft-yorgos-dnsop-dry-run-dnssec）
名前解決サービスに影響を及ぼすことなくDNSSECの導入・設定変更をテストす
る予行演習（ドライラン[*19]）を可能にするための、プロトコル拡張の提案
です。
[*19] dry run：事前に手順を間違えずに作業を実行でき、システムが正常に
動作すること確認するための、リハーサル・事前練習を指します。
DNSSECでは導入・設定変更の誤りが名前解決エラーにつながるため、慎重な作
業が必要になります。また、親ゾーンに誤ったDS RR[*20]を登録してしまった
場合、キャッシュされたDS RRによるDNSSEC検証エラーで名前解決ができない
状態が長時間にわたり継続する可能性があります[*21]。
[*20] JPRS用語辞典｜DSリソースレコード（ディーエスリソースレコード）
https://jprs.jp/glossary/index.php?ID=0213
[*21] 2021年10月に発生したSlackのDNSSEC障害では、comゾーンに設定された
DS RRのTTLが86400（1日）であったことが、被害規模の拡大につながり
ました。
本提案では、DS RRのダイジェストタイプにドライランを示す値を追加し、リ
ゾルバー側でそれを検知して、DNSSECエラーが発生した場合にDS RRが存在し
ない（DNSSEC検証をしない）状態にフォールバックすることで、名前解決サー
ビスを継続しながら実環境におけるDNSSECの導入試験が可能になり、DNSSECの
普及につながる旨が記述されています。
WGでは、本件に関する好意的な反応が多く寄せられ、継続して作業を進めるこ
ととなりました。
■dprive 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]と連携したい旨が提案されました。
[*23] Internet Research Task Force
https://irtf.org/
IETFの姉妹団体で、プロトコル、アプリケーション、アーキテクチャ、
及び技術の進化に関する研究を推進しています。
[*24] Measurement and Analysis for Protocols (maprg)
https://datatracker.ietf.org/rg/maprg/about/
WGでは、チャーターにExperimentalと書かれているため、本件を進めるために
は必要に応じたリチャーター（チャーターの再設定）が必要である旨がコメン
トされ、継続して作業を進めることとなりました。
■add WGにおける話題
addはAdaptive DNS Discoveryに由来しており、パブリックネットワーク・プ
ライベートネットワーク・VPNを含むさまざまなネットワーク環境において、
DNSクライアントがリゾルバーを発見・選択するための技術的な仕組みの作成
を目的としています。
▼議論された主な提案の内容と作業の進行状況
▽スプリットホライズン環境におけるローカル権威DNSの確立
（draft-reddy-add-enterprise-split-dns）
スプリットホライズンDNS（split-horizon DNS）[*25]が動作している環境に
おいて、分割されたネットワークの内側に存在するドメイン名をクライアント
に通知・設定するための、機能拡張の提案です。
[*25] スプリットDNS、またはスプリットホライズンDNS：
送信元の状況（例：送信元IPアドレス）の違いに応じ、特定のドメイン
名の問い合わせに対し異なる応答を返すように設定されている状況・環
境を指します。
本提案では、クライアントがネットワークに接続した際、そのネットワークに
おいてローカルに名前解決するドメイン名とリゾルバーのセットを得られるよ
うにし、クライアントがその情報を使ってリゾルバーを適切に設定できるよう
にします。
こうした状況は組織内・家庭内ネットワークやVPN環境、複数の接続先を使い
分ける場合など、さまざまなユースケースが考えられるため、WG参加者の間で
必要性が認識されており、継続して作業を進めることとなりました。
▽リゾルバーの情報の公開（draft-reddy-add-resolver-info）
RRタイプRESINFO（RESINFO RR）を追加し、リゾルバーが自身の情報をDNSで公
開できるようにするための、機能拡張の提案です。
本提案ではRESINFOレコードに記述される内容として、リゾルバーにおける
QNAME minimisation[*26]や拡張DNSエラー（EDE）[*27]のサポートの有無、
利用におけるクライアントの認証の必要性、リゾルバーの情報を記述したURL、
リゾルバーの概要を説明する文章などが想定されています。
[*26] RFC 9156で定義される、プライバシー保護の観点から、フルリゾルバー
の名前解決アルゴリズムを名前解決に必要な最低限の情報を問い合わせ
るように変更するための仕組みです。
[*27] RFC 8914で定義される、DNSエラーに関する追加情報を提供するための、
プロトコル拡張の仕組みです。
WGでは、こうした情報が必要であるという考え方には賛成できるというコメン
トがあり、継続して作業を進めることとなりました。
■次回のIETF Meetingについて
次回の第114回IETF Meeting（IETF 114）は、2022年7月23日から29日にかけて、
米国のフィラデルフィアで開催される予定です。
◇ ◇ ◇
◎関連URI
- IETF | IETF 113 Vienna
https://www.ietf.org/how/meetings/113/
（IETF 113公式ページ）
- IETF 113 Proceedings
https://datatracker.ietf.org/meeting/113/proceedings
（IETF 113議事録）
- 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.
Copyright©2001-2024 Japan Registry Services Co., Ltd.