JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト
メールマガジン「FROM JPRS」
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2015/04/24━ ◆ FROM JPRS 増刊号 vol.152 ◆ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ___________________________________ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ 第92回IETF Meeting報告(後編) ~dnsop WGにおける話題(2)/dprive WGに関する話題~ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 今回のFROM JPRS増刊号では、第92回IETF Meeting(以下、IETF 92)の後編と して、dnsop WGにおける話題の続きと、dprive WGにおける話題について報告 します。 ◇ ◇ ◇ ■dnsop WGにおける話題(2) ▼特殊な名前の取り扱い――.onion Tor(トーア)は、TCP/IPにおける接続経路(どの機器がどのネットワーク経 由で接続したか)の匿名性を高めるための技術で、米国のTor Project, Incに より開発されています。 Torでは利用者のみがアクセス可能な秘匿サービス(hidden services)の名前 として、「公開鍵のハッシュ.onion」という形式が使われています(*1)。こ れはTorのネットワーク内でのみ使用可能な、いわゆる内部利用名(internal name)の一つです。 (*1)現存する.onionの名前の数は約3万であると発表されています。 https://metrics.torproject.org/hidserv-dir-onions-seen.html ▽.onionの予約に関する提案 今回のWGではTor ProjectのJacob Appelbaum氏から、 ・.onionはRFC 6761で定められる「特殊用途ドメイン名(Special-Use Domain Names)」の条件を満たしており、IESG(*2)によって予約される べきものであること ・もし.onionが予約されない、あるいは予約が遅れた場合、以下の不具合が 発生・継続する危険性があり、作業を迅速に進める必要があること - 2015年10月1日をもって.onionを用いた内部利用名に対する証明書が無 効化され、Tor上の暗号通信のセキュリティレベルが低下する - リゾルバーにおける特殊処理が実施されず、利用者がどんな秘匿サービ ス名を検索したかがDNS(ルートサーバー)に流出し続ける - アプリケーションにおける特殊処理が実施されず、クライアントからリ ゾルバーに対し無駄な問い合わせが送られ続ける という提案がありました(draft-appelbaum-dnsop-onion-tld)。 (*2)Internet Engineering Steering Groupの略称。 IETFのWGが所属する各エリアのエリアディレクターにより構成され、 IETFの活動と標準化プロセスの技術管理を担当します。 この背景には、2011年から始まった新gTLD創設プログラムに伴って顕在化した、 名前衝突(Name Collision)(*3)の問題があります。名前衝突によるセキュ リティリスクを回避するため、CA/Browser Forum(*4)は内部利用名に対する 証明書の新規発行の禁止と期限を設定した上での発行済み証明書の無効化 (revoke)の実施を表明しており、.onionはこの影響を受けることになります。 (*3)JPNICが名前衝突の問題に関する解説を公開しています。 名前衝突(Name Collision)問題 https://www.nic.ad.jp/ja/dom/new-gtld/name-collision/ (*4)証明書を用いた通信の安全性や利便性向上のためのガイドラインを策定 している、会員制の任意団体。主な認証局(CA)やWebブラウザーベン ダーが参加しており、ガイドラインは事実上の業界標準となっています。 ▽提案の理由と議論の状況 この問題そのものは以前から指摘されており、.onionを含む既存のネットワー クサービスで用いられている主な疑似TLD(pseudo TLD)をIESGで予約するべ しという提案が、2013年に発表されています(grothoff-iesg-special-use- p2p-names)。今回の提案を発表したAppelbaum氏は、この提案の共著者でもあ ります。 Appelbaum氏は.onionの予約を別提案とした理由として、Torが広く利用されて おり(*5)、かつ.onionの証明書が無効化される期日が迫っていることから、 緊急に作業を進める必要があったことを挙げています(*6)。 (*5)Tor Projectは現在のTorの利用者数を約200万ユーザーと発表しています。 Tor Metrics - Direct users by country https://metrics.torproject.org/userstats-relay-country.html (*6)IETF 92終了後に更新された提案文書(draft-appelbaum-dnsop-onion- tld-01)に、この旨が追記されています。 今回のWGでは、RFC 6761に記述された特殊用途ドメイン名の振り返りと、 .onionに関する問題の明確化が行われました。会場からは、単に予約するだけ ではルートサーバーへの問い合わせの流出は回避できないため、AS112プロジェ クト(*7)と同様、.onionをルートゾーンから委任するのが良いのではないか というコメントがありました。 (*7)プライベートアドレスやリンクローカルアドレスなどの逆引きゾーンを ルートゾーンから委任することで、ルートサーバーへのDNS問い合わせ の数を減らし、負荷軽減を図るために始められたプロジェクトです。 AS112の名前は、使われているAS番号に由来しています。 今回のWGでは本件に関する明確な結論は出されず、問題解決に向けた関係者に よる電話会議での臨時ミーティングを、5月に別途開催することとなりました。 ▼EDNS0の対応状況調査 EDNS0はExtension Mechanisms for DNSに由来する、DNSを機能拡張するための 規格です(*8)。EDNS0はDNSのUDPメッセージサイズの拡大や応答コード・フ ラグの拡張など、さまざまな拡張機能をサポートしており、DNSを機能拡張す る際のベースとなるプロトコルとして、広く利用されています(*9)。 (*8)EDNS0の詳細についてはJPRSトピックス&コラム No.008を参照。 http://jprs.jp/related-info/guide/008.pdf (*9)DNSSECのサポートには、EDNS0のサポートが必須要件となります。 今回のWGではEDNS0の拡張機能への対応状況の調査結果と、それにより判明し た問題の内容が発表されました(draft-andrews-dns-no-response-issue)。 発表では、調査対象をルート及びTLD、Alexa(*10)のランキングから所定の 方法で抽出したドメイン名の権威DNSサーバーとしたこと、調査方法として、 対象の権威DNSサーバーに対しEDNS0のバージョン・オプション・フラグなどを 変化させたさまざまな問い合わせを送る方法を採用したことが説明されました。 (*10)Webサイトのアクセス量や訪問あたりの閲覧ページ数などを調査・公開 している米国企業。 また、調査結果として、本来返してはならないフォーマットエラー(FORMERR) やバージョンの不一致エラー(BADVERS)、不適切なパケットの切り詰め処理 や無応答など、EDNS0の実装エラーに起因すると考えられるさまざまな問題が 判明した旨が報告され、これらはEDNS0を利用した新しいDNSプロトコルの普及 を図る上での障害となりうることが、問題点として共有されました。 発表では問題解決のためのステップとして、ファイアーウォールや権威DNS サーバー、ゾーン管理者やDNSホスティングプロバイダーへの連絡、オンライ ン版のDNSチェッカーの開発などが挙げられました。 ▼DNS用語の明確化 DNSは現在、数十本以上のRFCによりプロトコル仕様が定義されています。それ らの仕様を定義するための用語は、各実装者・開発者・運用者がそれぞれに定 義したものが使われているのが現状であり、また長年にわたって使われ続ける 間に、最初の定義とは異なってきているものも存在しています。 このことは、DNSを理解・解説する際の障害の一つとなっています。そのため、 これまでに発行されたDNS関連のRFCで定義された数多くのDNS用語をまとめた 一つのドキュメントを作成し、用語を明確化するための作業が開始されました (draft-hoffman-dns-terminology)。本文書は、JPRSの藤原が共著者となっ ています。 今回のWGでは、本ドキュメントでは既存の用語を解説・明確化することに集中 し、新規の用語や新しい提案は別のドキュメントで規定することが再確認され ました。 この提案はIETF 92終了後の2015年4月14日にWGドキュメントとなり(draft- ietf-dnsop-dns-terminology)、今後WGとして標準化作業を進めていくことと なりました。 ■dprive WGにおける話題 dpriveはDNS PRIVate Exchangeに由来しており、Pervasive Monitoring(*11) に対抗するためのDNSトランザクションにおける機密性(confidentiality)の 提供(*12)を目的としています。 (*11)広域かつ網羅的な通信の傍受・情報収集のこと。2013年6月にEdward Snoden氏によって存在が暴露された米国NSAによる情報収集プログラム 「PRISM」が、大きな問題となりました。 (*12)現在のDNSにおけるデータの送受信(トランザクション)は平文であり、 ネットワーク上の第三者が傍受可能です。また、DNSSECはデータの出自 認証と完全性を提供しますが、機密性は提供しません。 ▼実装案の検討状況 前回のIETF 91では、候補となる以下の三つの実装案が提案されました。 1. ポート53/TCP以外の別ポートを使用し、DNSの通信路をTLS(*13)で保護 する 2. ポート53/TCPを継続使用し、STARTTLS(*14)による暗号化を導入する 3. DNS問い合わせ・応答をJSON(*15)で表現した新しいフレームプロトコ ルで包み、暗号通信に必要な鍵交換をJSONの機能で実現する このうち、1.のTLSによる通信路の保護と2.のSTARTTLSによる暗号化では、DNS の暗号通信にTCPを用いることが前提条件となっています。 (*13)Transport Layer Securityの略称。 SSL(Secure Socket Layer)を元に開発された、インターネットにお いて暗号通信を行うためのプロトコル。SSLにはプロトコル仕様上の脆 弱性があり、TLSへの移行が強く推奨されています。 (*14)平文の通信を暗号通信に拡張する方法の一つ。SMTPやPOP3/IMAPなど、 電子メール関連プロトコルによるものが実用化・普及しています。 (*15)JavaScript Object Notationの略称。 JavaScriptのオブジェクト表記方法に由来する簡便なデータ記述法。 今回のWGではこれらの実装案のうちの1.と2.を統合し、一本化する提案が発表 されました(draft-hzhwm-dprive-start-tls-for-dns)。この提案では、まず 別ポートでTLSを試し、次にポート53/TCPにSTARTTLSに相当するDNS問い合わせ を送ることでTLSモードへの移行を試す、という形式を採用しています。 会議では、この提案が現時点における最有力候補として、今後も継続して提案 の検討が進められることとなりました。 ■次回のIETF Meeting 次回の第93回IETF Meeting(IETF 93)は2015年7月19日から24日にかけ、チェ コのプラハで開催される予定です。 ◇ ◇ ◇ ◎関連URI - IETF 92 - Dallas, TX, USA http://www.ietf.org/meeting/92/ (IETF 92公式ページ) - IETF 92 Meeting Materials https://datatracker.ietf.org/meeting/92/materials.html (IETF 92発表資料一覧) - Domain Name System Operations (dnsop) - Charter http://datatracker.ietf.org/wg/dnsop/charter/ (dnsop WG公式ページ) - DNS PRIVate Exchange (dprive) - Charter https://datatracker.ietf.org/wg/dprive/charter/ (dprive WG公式ページ) - CA/Browser Forum - CAB Forum https://cabforum.org/ (CA/Browser Forum公式ページ) - Tor Project: Anonymity Online https://www.torproject.org/ (Tor Project公式ページ) ━━━━━━━━━━━━━━━━━━━━━━━━━━━【FROM JPRS】━ ■会議報告:http://jprs.jp/related-info/event/ ■配信先メールアドレスなどの変更:http://jprs.jp/mail/henkou.html ■バックナンバー:http://jprs.jp/mail/backnumber/ ■ご意見・ご要望:from@jprs.jp 当メールマガジンは、Windowsをお使いの方はMSゴシック、Macintoshをお使い の方はOsaka等幅などの「等幅フォント」で最適にご覧いただけます。 当メールマガジンの全文または一部の文章をホームページ、メーリングリスト、 ニュースグループ、他のメディアなどへ許可なく転載することを禁止します。 また、当メールマガジンには第三者のサイトへのリンクが含まれていますが、 リンク先のサイトの内容などについては、JPRSの責任の範囲外であることに ご注意ください。 その他、ご利用に当たっての注意事項は読者登録規約にてご確認ください。 http://jprs.jp/mail/kiyaku.html ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 編集・発行:株式会社日本レジストリサービス(JPRS) http://jprs.jp/ Copyright (C), 2015 Japan Registry Services Co., Ltd.