JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト
JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト
メールマガジン「FROM JPRS」
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2018/12/13━
◆ FROM JPRS 増刊号 vol.180 ◆
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
第103回IETF Meeting（バンコク）報告
～DNS関連WG、及び周辺会合における話題～
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2018年11月3日から9日にかけて、第103回IETF Meeting（以下、IETF 103）が
タイのバンコクで開催されました。
今回のFROM JPRSでは、IETF 103とその周辺で開催された会合の中から、FROM
JPRS編集局が注目した以下の話題をお伝えします。
・IETF 102以降のDNS関連RFCの発行状況
- EDNS0のパディングオプションの実装ポリシー（RFC 8467）
- Yeti DNSテストベッドと実験の概要（RFC 8483）
- DNS over HTTPS（DoH）の仕様（RFC 8484）
- ISPのためのIPv6逆引きDNSの管理運用手法と考慮事項（RFC 8501）
- DNS用語集（RFC 8499）
- 問い合わせタイプANYの応答サイズの小型化（RFC 8482）
・dnsop WGにおける話題
- 議論された提案の内容と標準化作業の進行状況
・「Root KSK futures」ミーティングの開催
・IEPG会合における話題
- 名前解決における権威DNSサーバーの選択
・次回のIETF Meetingについて
◇ ◇ ◇
■IETF 102以降のDNS関連RFCの発行状況
前回のIETF 102以降に発行されたDNS関連のRFCは、以下の4本です。
▼EDNS0のパディングオプションの実装ポリシー（RFC 8467）
・RFC 8467: Padding Policies for Extension Mechanisms for DNS
(EDNS(0))
（Experimental、draft-ietf-dprive-padding-policy）
RFC 8467は、EDNS0（*1）のパディング（*2）オプションの実装ポリシー
を記述しています。
DNSでは、データサイズや問い合わせのパターンがいくつかに限定されて
います。そのため、単純な暗号化のみではプライバシー保護の観点から、
機密性の確保には不十分であることが指摘されています。
これに対応するため、DNSでやりとりされるデータにランダムなパディン
グを追加することで機密性を高めるパディングオプションが、RFC 7830で
標準化されました。本RFCでは、RFC 7830をアプリケーションに実装する
際の具体的なポリシーと方策について記述しています。
（*1）EDNSは、RFC 6891で定義されているDNSの拡張方式で、バージョン
番号を示すためにEDNS0またはEDNS(0)と呼ばれます。EDNS(0)の詳
細は、JPRS用語辞典をご参照ください。
https://jprs.jp/glossary/index.php?ID=0147
（*2）パディング（padding）
データの長さを調整するため、データの前後に意味を持たないデー
タを追加すること。また、追加したデータ。
▼Yeti DNSテストベッドと実験の概要（RFC 8483）
・RFC 8483: Yeti DNS Testbed
（Informational、draft-song-yeti-testbed-experience）
RFC 8483は、2015年5月に開始されたYeti DNS（*3）テストベッドの活動
の紹介と、これまでに実施された実験の概要をまとめたものです。
Yeti DNSテストベッドではIPv6専用のルートサーバー、トラストアンカー
の自動更新、DNSSECにおけるRSA以外のアルゴリズムの運用など、ルート
サーバーの設定変更を要するさまざまな実験環境の構築と試験運用が行わ
れています。
なお、Yeti DNSテストベッドについては利用者の混乱を引き起こすオルタ
ネート・ルート（*4）であるという懸念も表明されており、本RFCではそ
の論争と、テストベッドの運営者自身による見解も紹介されています。
（*3）Yeti DNS
https://yeti-dns.org/
（*4）独自のルートサーバーを立ち上げ、ICANNの管理下にないドメイン名
空間を構築したものです。オルタネート・ルートの存在によって、
ドメイン名の一意性が保障できない可能性があるため、問題視され
ています。
▼DNS over HTTPS（DoH）の仕様（RFC 8484）
・RFC 8484: DNS Queries over HTTPS (DoH)
（Standards Track、draft-ietf-doh-dns-over-https）
RFC 8484は、DNSの通信をHTTPS（*5）の通信路上で実現するDNS over
HTTPS（DoH）の仕様を定義しています。
DNSの通信路の暗号化は、DNS over TLS（*6）で実現できます。しかし、制
限されたネットワーク環境ではDNS over TLSで使うTCPのポート853番がブ
ロックされている可能性があり、DNS over TLSを使えない場合があります。
そうした背景から、DNSの通信路にWebの通信で使われるためブロックされ
にくいHTTPSを使うアイデアが提案され、DNS over HTTPSとして標準化され
ました。DNS over HTTPSではHTTPSのGET/POSTメソッドを用いて、DNSパ
ケットをそのままの形で扱います。
（*5）RFC 2818で定義される、インターネット越しのHTTPコネクションを
セキュアにするためにTLSを使うプロトコルです。
（*6）RFC 7858で定義される、HTTPSで用いられているTLS（Transport
Layer Security）をDNSに適用する方式です。
▼ISPのためのIPv6逆引きDNSの管理運用手法と考慮事項（RFC 8501）
・RFC 8501: Reverse DNS in IPv6 for Internet Service Providers
（Informational、draft-ietf-dnsop-isp-ip6rdns）
RFC 8501は、ISP向けのIPv6の逆引きDNSの管理運用の手法と考慮点につい
て分析し、まとめたものです。
IPv4では、ISPが顧客に割り当てたすべてのIPアドレスの逆引きDNSを設定
することが一般的です。しかし、IPv6はアドレス空間が膨大であることか
ら、IPv4と同じ手法で逆引きDNSを設定することは困難です。本RFCでは、
IPv6の逆引きDNSの管理運用においてISPがとりうる手法と考慮点をまとめ、
管理運用に役立てるための情報提供をしています。
また、以下の2本がRFC発行に向けた最終段階（AUTH48-DONE、AUTH48）となっ
ており、RFC番号が割り当てられています。最終確認が終了次第、RFCとして発
行される予定です。
▼DNS用語集（RFC 8499）
・RFC 8499: DNS Terminology
（Best Current Practice、draft-ietf-dnsop-terminology-bis）
RFC 8499は、DNS用語集であるRFC 7719を置き換え、ネガティブキャッ
シュについて定義したRFC 2308の内容を一部更新するもので、RFC 7719に
引き続きJPRSの藤原和典が著者の一人となっています。
▼問い合わせタイプANYの応答サイズの小型化（RFC 8482）
・RFC 8482: Providing Minimal-Sized Responses to DNS Queries that
have QTYPE=ANY
（Standards Track、draft-ietf-dnsop-refuse-any）
RFC 8482は、DNSリフレクター攻撃（*7）の効果を低減するため、ANYリ
ソースレコード（以下、RR）の問い合わせに対する権威DNSサーバーの応答
の仕様を変更して、最小サイズの応答を可能にします。
本RFCでは、問い合わせタイプANYの応答として、権威DNSサーバーが知っ
ているすべてのRRを返すという従来の動作に加え、その時点で有効な一部
のRRSetのみを返すことができることを明確化します。また、RFC 1034と
1035には含まれていなかった、DNSサーバーまたはクライアントの動作に関
する指針を提供します。
（*7）DNSを利用したDoS攻撃の一つです。送信元IPアドレスを偽った通常
のDNS問い合わせをDNSサーバーに送ることでDNSサーバーが応答パ
ケットを攻撃対象に送り、サービス不能の状態に陥らせます。DNS
リフレクター攻撃の詳細は、JPRS用語辞典をご参照ください。
https://jprs.jp/glossary/index.php?ID=0156
■dnsop WGにおける話題
dnsopはDNS Operationsに由来しており、DNSサーバーや登録情報の管理など、
DNSの運用全般に関するガイドラインの作成を目的としています。WGでは、運
用上の課題に着目したDNSプロトコルの拡張・メンテナンスも活動項目として
います。
▼議論された提案の内容と標準化作業の進行状況
▽期限切れキャッシュを使った名前解決の継続（draft-ietf-dnsop-serve-
stale）
名前解決においてリゾルバーがすべての権威DNSサーバーに到達できなくなり、
キャッシュが期限切れになってしまった場合に、期限切れとなったキャッシュ
を再利用して名前解決を継続可能にするための提案です。
本提案は、DDoS攻撃や事故などによって権威DNSサーバーに到達できない状態
が続いた際に、名前解決エラーの発生を回避することを目的としています。な
お、本提案はBINDやKnot Resolverなど一部のソフトウェア実装や主要なパブ
リックDNSサービスにおいて、既に利用されています。
今回のWGでは、最大1週間、すべての権威DNSサーバーから応答がなくてもTTL
値30でstale RRsetsを返すようにすることや、応答の際、権威DNSサーバーと
通信できない状態であることを返せるようにするためのEDNSオプションの追加
などが提案されています。
会場からは、提案された30秒のタイマー値の理由や、期限切れのキャッシュを
再利用する際の条件と期間などについてコメントがあり、今後も継続して作業
を進めることになりました。
▽ANAMEリソースレコードの定義（draft-ietf-dnsop-aname）
CDN（Content Delivery Network）での利用を想定した、ゾーン頂点に指定可
能なANAME（Address-specific DNS aliases）という、CNAME RRと同様のRRを
追加することが提案・議論されています（*8）。
（*8）ANAMEが提案された背景とその目的の詳細については、過去のドメイン
名関連会議報告をご参照ください。
https://jprs.jp/related-info/event/2017/0829IETF.html
なお、今回の提案からANAMEの名称が、Address-specific DNS Name
RedirectionからAddress-specific DNS aliasesに変更されています。
今回のWGでは親ゾーンへ委任情報の代わりにCNAME RRとDNAME RRを設定するこ
とで98%以上のケースで正常動作したというIETF Hackathon Bangkokでの実験結
果や、Amazon Route 53における実装（エイリアスレコード）が紹介されました。
また、ANAME RRの追加をDynamic Updateで実装するという提案、SRV RRを使っ
て閲覧者のWebブラウザーの設定を変更するという提案などの議論が行なわれ
ましたが結論には至らず、継続して議論を進めることとなりました。
▽QNAME minimisationのStandards Track化（draft-ietf-dnsop-rfc7816bis）
QNAME minimisationはRFC 7816で定義される、プライバシー保護の観点から
フルリゾルバー（キャッシュDNSサーバー）の名前解決アルゴリズムを変更す
るための仕組みです（*9）。
本提案は、現在は実験（Experimental）仕様となっているQNAME minimisation
を、標準化過程（Standards Track）にするためのものとなっています。
（*9）QNAME minimisationの詳細は、過去のドメイン名関連会議報告をご参照
ください。
https://jprs.jp/related-info/event/2015/0421IETF.html
なお、QNAME minimisationは、今回の提案からQuery Minimisationに名称が変
更される予定となっています。
今回のWGでは、主要なフルリゾルバーやパブリックDNSサービスにおける対応
状況を追記・更新したこと、予期した応答が得られなかった場合のフォール
バックの戦略（Fallback strategies）については更なる議論が必要であるこ
となどが報告され、継続して作業を進めることとなりました。
▽ルートサーバーへのアクセス時間の短縮（draft-ietf-dnsop-7706bis）
本提案は2015年に発行された、RFC 7706を更新するものです。RFC 7706では、
リゾルバーと同じサーバーでルートゾーンのコピーを保持する権威DNSサー
バーを動作させることでルートサーバーへのアクセス時間を短縮し、名前解決
を効率化する方法を記述しています（*10）。
（*10）RFC 7706の詳細については、過去のドメイン名関連会議報告をご参照く
ださい。
https://jprs.jp/related-info/event/2014/1217IETF.html
RFC 7706では、ループバックインタフェースを意識した実装方法が細かく定め
られていましたが、それ以外の方法も含め、具体的な実装方法についてはそれ
ぞれの実装者に委ねる形に、提案が修正されています。
発表では、リゾルバーが保持するルートゾーンのコピーに問題があった場合の
対応が課題として挙げられました。会場からは、インターネットのすべての
ホームルーターがルートゾーンのコピーを保持することを想定した場合、技術
的に対応可能かどうかについて質問や確認がありました。
今後は、アクセス時間の短縮だけでなく安定性が求められる場合など、本件の
ユースケースをより明確にする形で提案を修正することが報告され、継続して
作業を進めることとなりました。
■「Root KSK futures」ミーティングの開催
IETF 103開催中の2018年11月7日と11月9日に、現在作業が進められているルー
トゾーンKSKロールオーバーの今後に関する意見交換を目的とした「Root KSK
futures」ミーティングが、ICANNのPaul Hoffman氏の主催で開催されました。
なお、このミーティングはIETFの公式プログラムではなく、非公式のSide
Meetingでした（*11）。
（*11）Unofficial Side Meetings at IETF 103
https://trac.ietf.org/trac/ietf/meeting/wiki/103sidemeetings
https://www.ietf.org/mail-archive/web/dnsop/current/msg24497.html
このミーティングでは、ルートゾーンのKSKを今後どのように維持管理すべき
であるかという問いかけ／アイデアの募集と、今回のルートゾーンKSKロール
オーバーに関する情報共有・議論が行われました。議論内容としては、ルート
ゾーンKSKロールオーバーそのものの必要性に関するものと、今回の作業にお
いて実際に観測・発生した状況に関するものが中心でした。
ルートゾーンKSKロールオーバーそのものについては、今後も定期的な実施が
望ましいという意見が大勢を占めました。その理由として、鍵の危殆（きたい）
化やサーバーのハードウェアの変更などに対応するため、常日頃から鍵の更新
のオペレーションを経験しておくべきであることや、ルートゾーンにおいても
アルゴリズムロールオーバーをいずれかのタイミングで実施すべきであり、そ
れに備える必要があるといった点が指摘されました。
ロールオーバーで観測された内容については、障害の発生状況と鍵更新におけ
る具体的なオペレーションに関する内容が報告・共有されました。APNICの
Geoff Huston氏が実施した調査において、75のネットワークでエラーを検出・
対応し、その中には100万人の利用者を持つISPも含まれていたことが報告され
ました。
また、このミーティングを主催したPaul Hoffman氏からは、今回のルートゾー
ンKSKロールオーバーに起因する障害事例や状況報告を求めており、情報があ
る場合、ksk-rolloverメーリングリスト（*12）に共有してほしい旨が呼び掛
けられました。
（*12）ksk-rollover Info Page
https://mm.icann.org/listinfo/ksk-rollover
■IEPG会合における話題
IEPG（Internet Engineering and Planning Group）は、IETF会合に先立って
日曜日午前に開催される会合で、インターネットの運用に関連するさまざまな
テーマを取り扱っています。
▼名前解決における権威DNSサーバーの選択
NLnet LabsでUnboundの開発を担当しているBenno Overeinder氏から、Unbound
に実装されている権威DNSサーバー選択アルゴリズムの概要を紹介する発表が
ありました。
フルリゾルバーが非再帰的問い合わせ（*13）を実行する際、あるゾーンの複
数の権威DNSサーバーのいずれを選択するかのアルゴリズムは標準化されてお
らず、それぞれの実装により異なっています。
（*13）DNSにおいて、スタブリゾルバー（DNSクライアント）からの名前解決
の依頼（要求）に応じて名前解決を実行するための問い合わせです。
詳細は、JPRS用語辞典をご参照ください。
https://jprs.jp/glossary/index.php?ID=0174
名前解決の効率を向上させるため、フルリゾルバーは応答のRTT（*14）や応答
の受信におけるタイムアウトの制御（*15）といったさまざまな条件を加味し、
権威DNSサーバーの選択アルゴリズムを実装・決定しています。
（*14）通信相手にデータを送信してから応答が返ってくるまでの時間（通信の
往復時間）です。RTTの詳細は、JPRS用語辞典をご参照ください。
https://jprs.jp/glossary/index.php?ID=0195
（*15）Unboundにおけるタイムアウトの制御方法が、以下で公開されています。
NLnet Labs Documentation - Unbound - Unbound Timeout Information
https://www.nlnetlabs.nl/documentation/unbound/info-timeout/
発表では、Unboundが名前解決においてどのように権威DNSサーバーを選択して
いるかが紹介され、DNS全体のパフォーマンスの向上とインターネットの安定
性確保のためには、適切なサーバーの選択が重要であることが示されました。
■次回のIETF Meetingについて
次回の第104回IETF Meeting（IETF 104）は2019年3月23日から29日にかけ、
チェコのプラハで開催されます。
◇ ◇ ◇
◎関連URI
- 103 Meeting Index
https://www.ietf.org/how/meetings/103/
（IETF 103公式ページ）
- IETF 103 meeting materials
https://datatracker.ietf.org/meeting/103/materials.html
（IETF 103発表資料一覧）
- Domain Name System Operations (dnsop)
https://datatracker.ietf.org/wg/dnsop/charter/
（dnsop WG公式ページ）
- IEPG Meeting - November 2018
https://iepg.org/2018-11-04-ietf103/
（2018年11月4日のIEPG Meeting公式ページ）
━━━━━━━━━━━━━━━━━━━━━━━━━━━【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), 2018 Japan Registry Services Co., Ltd.
Copyright©2001-2024 Japan Registry Services Co., Ltd.