ドメイン名関連会議報告
2017年
第100回IETF Meeting(シンガポール)報告
~DNS関連WG、及び周辺会合における話題~
2017/12/13
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
発表では、藤原が提示した比較表に対し参加者から活発にコメントが寄せられ、今後、この比較表を基にしつつ内容の追加や以降の進め方を検討することとなりました。
dnsop WGで発表するJPRS藤原
▽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)によって、調査対象の鍵がトラストアンカーとなっているかどうかを、クライアント側から調べることができるようにしています。なお、<tag-index>には、鍵タグを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回となります。
IEPG MeetingでコメントするJPRS米谷
次回のIETF Meetingについて
次回の第101回IETF Meeting(IETF 101)は2018年3月17日から23日にかけ、英国のロンドンで開催されます。
本会議報告は、JPRSのメールマガジン「FROM JPRS」の増刊号として発行した情報に写真などを交えてWebページ化したものです。
「FROM JPRS」にご登録いただいた皆さまには、いち早く情報をお届けしております。ぜひご登録ください。