JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト
JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト
メールマガジン「FROM JPRS」
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2017/12/13━
◆ FROM JPRS 増刊号 vol.173 ◆
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
第100回IETF Meeting（シンガポール）報告
～DNS関連WG、及び周辺会合における話題～
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2017年11月11日から17日にかけて、第100回IETF Meeting（以下、IETF 100）
がシンガポールで開催されました。
今回のFROM JPRSでは、IETF 100における議論から、FROM JPRS編集局が注目し
た以下の話題をお伝えします。
・IETF 99以降のDNS関連RFCの発行状況
- 特殊用途ドメイン名における問題点
・dnsop WGにおける話題
- 議論された提案の内容と標準化作業の進行状況
・doh WGにおける話題
- doh WGの設立
- 議論された提案の内容と標準化作業の進行状況
・IEPG会合における話題
- TLD間におけるインフラ共有に関する調査
- ルートゾーンKSKロールオーバーの作業延期に関するアップデート
・次回のIETF Meetingについて
◇ ◇ ◇
■IETF 99以降のDNS関連RFCの発行状況
前回のIETF 99以降に発行されたDNS関連のRFCは、以下の1本です。
▼特殊用途ドメイン名における問題点
・RFC 8244：特殊用途ドメイン名における問題点
（Informational、draft-ietf-dnsop-sutld-ps）
特殊用途ドメイン名（Special-Use Domain Names）（*1）は、.localや
.testなど、通常のインターネットの利用以外の、特殊な用途のために予
約されるドメイン名です。特殊用途ドメイン名の取り扱いはRFC 6761で定
義されており、利用者やソフトウェアが対象のドメイン名を特殊用途ドメ
イン名であると認識し、通常とは異なる形で取り扱うことを想定していま
す。
RFC 8244は、特殊用途ドメイン名の取り扱いについて、IETFにおけるこれ
までの議論状況と現在の問題点をまとめて文書化したものです。このRFCで
挙げられた代表的な問題点は、以下の通りです。
- ICANNとIETFの連携のプロセスが定められていないこと
- ICANNやIETFが、アドホックな名前の利用を排除できる権限を持ってい
るわけではないこと
- インターネットに存在しない名前（内部利用名）である.onionの名前に
サーバー証明書が発行・利用されていたことが、特殊用途ドメイン名の
予約に影響を及ぼしたこと
（*1）これまでの特殊用途ドメイン名の取り扱いについての概要は、過去のド
メイン名関連会議報告をご参照ください。
https://jprs.jp/related-info/event/2015/1207IETF.html
■dnsop WGにおける話題
dnsopはDNS Operationsに由来しており、DNSサーバーや登録情報の管理など、
DNSの運用全般に関するガイドラインの作成を目的としています。WGでは、運
用上の課題に着目したDNSプロトコルの拡張・メンテナンスも活動項目として
います。
▼議論された提案の内容と標準化作業の進行状況
▽DNS用語の明確化（draft-ietf-dnsop-terminology-bis）
本提案はDNS用語集であるRFC 7719を改訂するもので、RFC 7719に引き続き
JPRSの藤原和典が著者の一人となっています。
今回のWGでは、提案の初版から現在の版までに拡張された主な用語の紹介と、
今後の予定として、DNSクエリに関する次の四つの用語を追加予定であること、
2018年1月15日にワーキンググループラストコール（WGLC）（*2）を実施予定
であることが示されました。
- Recursive query
- Non-recursive query
- Iterative query
- Iterative resolution
参加者からは、「用語を新しい定義で使う人がいる中、これまでの定義で使う
人も多くいることを認識すべき」「そもそも用語の定義は変化しうるものであ
る」「われわれが進めているのは用語の定義の固定化ではなく、辞書の作成で
ある」といったコメントがありました。
また、現在のRFC 7719はInformationalであったが、今回はStandards Trackで
の標準化を目指すことが、WGチェアから示されました。
（*2）標準化作業において、WGチェアがWGに呼びかける最終確認。
▽一つのDNSクエリで複数の応答を得る提案の比較検討
IETFでは以前から、一つのDNSクエリで複数の応答を得るための提案が何度か
行われてきました。しかし、これまではいずれの提案も合意が得られず、標準
化には至っていませんでした。
最近、この提案の議論が再開され、これまでに四つの提案が示されました。今
回、JPRSの藤原和典が五つ目の提案を行うと同時に、それら五つの提案につい
て技術的な特徴を比較検討した結果を発表しました。
比較検討の対象となった提案は、以下の通りです。
1. Answer secionにAAAAレコードを追加する提案
（draft-vavrusa-dnsop-aaaa-for-free）
2. EDNS0により、複数のタイプのDNSクエリを同時に送る提案
（draft-bellis-dnsext-multi-qtypes）
3. ゾーン管理者がAdditional sectionに応答を追加する提案
（draft-wkumari-dnsop-multiple-responses）
4. 通常のクエリに別のクエリを追加して送り、複数の応答を一つのDNS応答
に混ぜる提案（draft-yao-dnsop-accompanying-questions）
5. 権威DNSサーバーの実装者がAdditional sectionに追加する応答を選択・
確定する提案（draft-fujiwara-dnsop-additional-answers）
五つ目の藤原の提案は三つ目の提案と同様、Additional sectionに応答を追加
するものですが、以下の点が異なっています。
- ゾーン管理者ではなく権威DNSサーバーの実装者がAdditional sectionに
追加する応答を選ぶこと（*3）
- 追加対象のレコードが存在しなかった場合、不在証明に利用可能な
NSEC/NSEC3レコードを追加することで、RFC 8198（*4）を活用したDNSの
性能向上を想定していること
（*3）現在のBINDやNSDにおける、MXレコードやSRVレコードの応答と同様の形
式が想定されています。
（*4）RFC 8198の概要は、過去のドメイン名関連会議報告をご参照ください。
https://jprs.jp/related-info/event/2017/0829IETF.html
発表では、藤原が提示した比較表に対し参加者から活発にコメントが寄せられ、
今後、この比較表を基にしつつ内容の追加や以降の進め方を検討することとな
りました。
▽DNSエラーコードの拡張（draft-ietf-dnsop-extended-error）
EDNS0（*5）を用いてDNSのエラーコードを拡張するための、プロトコル拡張の
提案です。
（*5）RFC 6891で定義されたDNSの拡張方式で、512バイトよりも大きなメッ
セージサイズをUDPで扱えるように拡張し、フラグや応答コードも拡張
します。詳細は、JPRS用語辞典をご参照ください。
https://jprs.jp/glossary/index.php?ID=0147
現在のDNSの仕様では、名前解決処理においてサーバー側でエラーが発生した
場合、それを知らせるためのエラーコードであるServFailを応答に設定します。
しかし、DNSの運用においてServFailエラーが発生する原因はさまざまであり、
現在の仕様では問い合わせ側にそれを伝える手段がないため、DNSのトラブル
シューティングにおける課題となっていました。
本提案は、EDNS0を用いてServFailエラーの原因に関する情報を返すためのプ
ロトコル拡張を定義し、DNS及びDNSSECの障害の原因を問い合わせ元に伝達で
きるようにするものです。現在の提案では、DNSSEC Bogus・DNSSEC
Indeterminate・Lame・Prohibited・TooBusyの五つのエラーコードが新たに
定義されています。
今回のWGでは、パケットのデータ構造を決めるためのエンコード案が複数提案
され、活発な議論が行われましたが結論は出ず、継続して議論を進めることと
なりました。
▽トラストアンカーの状況をクライアント側から調べる方法
（draft-huston-kskroll-sentinel）
DNSクエリによって、DNSSECバリデーターのトラストアンカーの状況をクライ
アント側から調べるための仕組みを定義するプロトコル拡張の提案で、ルート
ゾーンKSKロールオーバーの進行状況の調査に用いることを想定しています。
提案では、以下に示す二つの特殊ラベル（special labels）によって、調査対
象の鍵がトラストアンカーとなっているかどうかを、クライアント側から調べ
ることができるようにしています。なお、には、鍵タグを16進表
記で指定します。
1. _is-ta-<tag-index>
<tag-index>で指定した鍵タグを持つ鍵が、問い合わせ先のDNSSECバリ
データーにおいてトラストアンカーとなっていることを調べる際に用い
るラベル。
2. _not-ta-<tag-index>
<tag-index>で指定した鍵タグを持つ鍵が、問い合わせ先のDNSSECバリ
データーにおいてトラストアンカーとなっていないことを調べる際に用
いるラベル。
今回のWGでは本提案に関心を持つ人が多く、WGとして標準化作業を進める方向
となりました。しかし、特殊ラベルとして名前に特別な意味を持たせることを
嫌う意見も多く、今後、WGの場で議論が進められることになります。
■doh WGにおける話題
▼doh WGの設立
過去のDNS関連WGやアプリケーション関連エリアにおける議論で、DNSの通信を
HTTPSの通信路で実現することの必要性が認識されました。それを受け、2017
年9月15日にdoh WGが設立され、標準化作業を進めることとなりました。dohは
DNS over HTTPSに由来しています。
▼議論された提案の内容と標準化作業の進行状況
今回のWGでは、前回のIETF 99 dispatch WG（*6）で提案・議論された、DNS
over HTTPSの提案の改訂版に関する議論が行われました。
（*6）dispatch WGは、ART（Applications and Real-Time Area）エリアにお
ける新提案の作業方針を検討するために設立されたWGです。
▽DNS over HTTPS（draft-ietf-doh-dns-over-https）
HTTPS通信のメッセージの本体に、DNSのワイヤーフォーマット（ビット列形式
のバイナリフォーマット）をそのまま用いる提案です（*7）。
（*7）これまでのDNS over HTTPSの取り扱いについての概要は、過去のドメイ
ン名関連会議報告をご参照ください。
https://jprs.jp/related-info/event/2017/0829IETF.html
現在の提案では、GETメソッドではBase64エンコード、POSTメソッドではバイ
ナリフォーマットのままで取り扱う形になっています。
WGでは、プロトコルの仕様としてHTTP/2を必須とするかどうかと、DNSの
キャッシュとHTTPのキャッシュの取り扱いの違いについて議論され、継続して
作業を進めることとなりました。
■IEPG会合における話題
IEPG（Internet Engineering and Planning Group）は、IETF会合に先立って
日曜日午前に開催される会合で、インターネットの運用に関連するさまざまな
テーマを取り扱っています。
▼TLD間におけるインフラ共有に関する調査
SIDN LabsのGiovane C. M. Moura氏が、権威DNSサーバーやそのネットワーク
がTLD間でどの程度共有されているかについて、ルートゾーンの設定内容から
調査した結果を発表しました。
あるドメイン名の権威DNSサーバーがDDoS攻撃の被害を受けた場合、同じ権威
DNSサーバーやネットワークインフラを使って提供されている攻撃対象外のド
メイン名も、巻き添えによる被害を受けることになります。
発表では、2014年と2017年のルートゾーンの設定内容を基に、TLD間における
ネームサーバー名・IPアドレスブロック・AS番号の共有状況を調査した結果が
発表されました。Moura氏からは、想定よりも多くのTLDでインフラが共有され
ていたことと、現在は「oversharing（過度に共有されている状態）」なので
はないかという見解が示されました。
▼ルートゾーンKSKロールオーバーの作業延期に関するアップデート
ICANN CTOのDavid Conrad氏が、10月に予定されていたルートゾーンKSKロール
オーバーの作業延期の経緯（*8）と、その後の状況について発表しました。
発表では、作業延期の理由と今後の予定に加え、作業延期の発表後にトラスト
アンカーとしてKSK-2017を保持するフルリゾルバーのIPアドレスの数が減り、
KSK-2010のみを保持するリゾルバーのIPアドレスの数が増えたことが報告され
ました。
RFC 5011によるトラストアンカーの自動更新を有効にしている場合、今回の作
業延期によって保持するトラストアンカーがKSK-2010のみになることはありま
せん。そのため、これらのフルリゾルバーはトラストアンカーを手動で設定し
ている可能性があり、今回の作業延期の発表を受け、管理者がトラストアン
カーの設定を元に戻したのではないかと推測されています。
発表では今後のステップとして、更に情報を集めて状況の理解を進めること、
作業をどの程度延期するかはまだ決定していないこと（*9）、KSK-2010のみを
保持しているフルリゾルバーが存在する原因の分析を継続することが示され、
今回の状況から「KSK-2017を削除しないでください」という旨の追加アナウン
スが必要になるかもしれないことが示されました。
（*8）詳細については以下をご参照ください。
ルートゾーンKSKロールオーバーによる影響とその確認方法について
（2017年9月29日更新）
https://jprs.jp/tech/notice/2017-07-10-root-zone-ksk-rollover.html
（*9）ルートゾーンのZSKロールオーバーの作業タイミングに一致させている
ため、ルートゾーンKSKロールオーバーの作業再開のタイミングは三カ
月に1回となります。
■次回のIETF Meetingについて
次回の第101回IETF Meeting（IETF 101）は2018年3月17日から23日にかけ、
英国のロンドンで開催されます。
◇ ◇ ◇
◎関連URI
- 100 Meeting Index
https://www.ietf.org/meeting/100/
（IETF 100公式ページ）
- IETF 100 meeting materials
https://datatracker.ietf.org/meeting/100/materials.html
（IETF 100発表資料一覧）
- Domain Name System Operations (dnsop)
https://datatracker.ietf.org/wg/dnsop/charter/
（dnsop WG公式ページ）
- DNS Over HTTPS (doh)
https://datatracker.ietf.org/wg/doh/charter/
（doh WG公式ページ）
- IEPG Meeting - November 2017
https://iepg.org/2017-11-12-ietf100/
（2017年11月の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), 2017 Japan Registry Services Co., Ltd.
Copyright©2001-2024 Japan Registry Services Co., Ltd.