JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト

メールマガジン「FROM JPRS」

バックナンバー：vol.148

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2014/12/24━
                    ◆ FROM JPRS 増刊号 vol.148 ◆
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
                                                                      
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
                    第91回IETF Meeting報告（後編）                    
         ～dprive WG／.homeの予約／IEPG Meetingにおける話題～         
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

今回のFROM JPRS増刊号では、第91回IETF Meeting（以下、IETF 91）の後編と
してdprive WGと.homeの予約に関する提案、IETFに併設される形で開催された
IEPG Meetingにおける話題について報告します。

          ◇                     ◇                     ◇

■dprive WG

前々回のIETF 89で開催されたdnse BOF（*1）、会議終了後に開設されたdns-
privacyメーリングリストでの議論を受け、dprive WGが2014年10月17日付で発
足しました。

（*1）詳細についてはドメイン名関連会議報告「第89回IETF Meeting報告（前
      編）」を参照。
      http://jprs.jp/related-info/event/2014/0411IETF.html

dpriveはDNS PRIVate Exchangeに由来しており、Pervasive Monitoring（*2）
に対抗するための、DNSトランザクションにおける機密性（confidentiality）
の提供（*3）を目的としています。

（*2）広域かつ網羅的な通信の傍受・情報収集のこと。2013年6月にEdward
      Snoden氏によって存在が暴露された米国NSAによる情報収集プログラム
      「PRISM」が、大きな問題となりました。

（*3）現在のDNSにおけるデータの送受信（トランザクション）は平文であり、
      ネットワーク上の第三者が傍受可能です。また、DNSSECはデータの出自
      認証と完全性を提供しますが、機密性は提供しません。

▼目的と方針

dprive WGでは、DNSクライアントとキャッシュDNSサーバーの間の通信の機密
性の提供を主目的としており、キャッシュDNSサーバーと権威DNSサーバーの間
の通信の機密性、DNSトランザクション全体におけるエンドツーエンドの機密
性の提供については、その後に検討するとしています。

会議では、議論を円滑に進めるため、議長から以下の前提条件が示されました。

1）キャッシュDNSサーバー（の管理者）は信頼するものとする
2）完璧なものは目指さない（情報収集の効果を軽減できれば良い）

また、議長からはDNS 2.0を作るのではないこと、権威DNSサーバーの振る舞い
は変更しないことも併せて示されました。これは、今回のプロトコル開発では
既存のDNSプロトコルには大幅な変更を加えない方針であることを意味してい
ます。

▼各手法の比較・検討と懸念事項

その後、これまでに提案されている各手法が比較・検討されました。今回検討
された提案を以下に示します。

  ・DNSの通信路をTLS（*4）で保護する
    - HTTPSで使っているポート443/TCPを使用し、ALPN（*5）を用いてDNSプ
      ロトコルをそのまま通す（draft-hoffman-dprive-dns-tls-alpn）
    - ポート443/TCPを使用し、DNS問い合わせ・応答をHTTPに内包させて通す
      （draft-hoffman-dprive-dns-tls-https）
    - 443、53以外の新しいポート番号を割り当て、それを使用する（draft-
      hoffman-dprive-dns-tls-newport）
  ・ポート53/TCPを継続使用し、STARTTLS（*6）による暗号化を導入する
    （draft-hzhwm-dprive-start-tls-for-dns）
  ・DNS問い合わせ・応答をJSON（*7）で表現した新しいフレームプロトコル
    で包み、暗号通信に必要な鍵交換をJSONの機能で実現する（draft-
    hallambaker-privatedns）

このうち、TLSによる通信路の保護とSTARTTLSによる暗号化では、DNSの暗号通
信にTCPを用いることが前提条件となっています（*8）。

（*4）Transport Layer Securityの略称。
      インターネットにおいて暗号通信を行うためのプロトコル。

（*5）Application-Layer Protocol Negotiationの略称。
      TLS上で通信するアプリケーションプロトコルをクライアントとサーバー
      間事前交渉するための拡張機能。RFC 7301により標準化されています。

（*6）平文の通信を暗号通信に拡張する方法の一つ。SMTPやPOP3/IMAPなど、
      電子メール関連プロトコルによるものが実用化・普及しています。

（*7）JavaScript Object Notationの略称。
      JavaScriptのオブジェクト表記方法に由来する簡便なデータ記述法。

（*8）DNSの通信をTCPで行うための検討については、ドメイン名関連会議報告
      「第91回IETF Meeting報告（前編）」の「DNSにおけるTCPトランスポー
      トの利用」を参照。
      http://jprs.jp/related-info/event/2014/1217IETF.html

検討では懸念事項として、現在のインターネットには多数のミドルボックス
（Middlebox）（*9）が存在するため、未知のプロトコルやポート番号は既存
のミドルボックスによりフィルターされてしまう可能性があるのではないかと
いう問題が指摘され、それを防ぐためには暗号通信を通しやすいポート443を、
HTTPSプロトコルで使うのが良いのではないか、というコメントがありました。

（*9）RFC 3234で定義される、通信路の間（middle）に存在する、通常のルー
      ティング以外の動作をする装置（box）の総称。ミドルボックスの例と
      して、ファイアーウォールやネットワークアドレス変換（NAT）装置、
      侵入検知システム（IDS）などが挙げられます。

会議では本件に関する明確な結論は出されず、今後も議論を継続していくこと
となりました。また、プロトコルが満たすべき要件定義の項目（requirements）
についても、併せて議論していくこととなりました。

■.homeの予約に関する提案

今回の会議において、.homeを家庭内ネットワークのための特別なTLDとして予
約・活用しようという提案が発表されました（draft-cheshire-homenet-dot-
home）。

.homeは、ICANNにより進められている新gTLDプログラムにおいて名前衝突のリ
スクが高いと評価され、.corp、.mailと共にレジストリへの委任が無期限延期
となっています。この提案は委任が無期限延期となったことを逆手に取り、イ
ンターネット上に存在しないTLDとして有効活用を図ろうとするものです
（*10）。

（*10）提案者はRFC 6762（Multicast DNS）の共著者の一人です。なお、RFC
      6762では.localを主にMulticast DNSで用いる特別なTLDとして予約して
      います。

この提案は当初、homenet WG（*11）で提案されました。しかし、WGではこの
提案の標準化はdnssd WG（*12）の担当である旨の指摘があり、dnssd WGで取
り扱われることになりました。

（*11）家庭内LANなどの比較的小規模なネットワーク内、及びネットワーク間
      におけるさまざまな技術課題について取り扱うWG。

（*12）DNSを用いたservice discovery（サービス発見：提供可能なサービス
      を検索・通知する手法）の仕様を拡張し、企業や大学など大規模なネッ
      トワークにおいても動作可能にするための手法の標準化を担当するWG。

しかし、参加者の本提案に対するモチベーションは高まらず、その後のメーリ
ングリストでの議論でも「TLDの予約ではなく、.arpaのサブドメインを用いる
形であればIETFから提案しやすいのではないか」といった意見が出ていました。

▼IETF参加者のICANN・TLDに対する認識

また、今回v6ops WG（*13）で提案されたものの中にも、.v4を特別なTLDとし
て予約・活用しようという提案がありました（*14）。しかし、IETFが技術的
な理由でTLDを予約することに対し、WG参加者の一部から強い反対の声が上が
りました。

こうした状況の背景として、

  ・TLDの予約はICANNの領域であり、IETFの仕事ではない
  ・技術者として、政治的な状況にはできる限り巻き込まれたくない

という認識が、IETF参加者の間にあることが挙げられます。

（*13）IPv6に関する運用全般について取り扱うWG。

（*14）IPv6環境において、IPv4アドレスの直接表記をDNS64（*15）で扱える
       ようにするための提案（draft-osamu-v6ops-ipv4-literal-in-url）。

（*15）RFC 6147で定義される、AレコードからAAAAレコードを合成するための
       仕組み。NAT64と組み合わせることで、 IPv4アドレスのみを持つサー
       バーへのIPv6ネットワークからのアクセスを実現します。

■IEPG Meetingにおける話題

IEPGは、IETF Meetingに先立って日曜日午前に開催される略式の会合で、イン
ターネットの運用に関連するさまざまなテーマを取り扱っています。

ここでは、今回のIEPG Meetingで報告・議論された話題のうち、FROM JPRSが
特に注目したものについてお伝えします。

▼ワイルドカードゾーンによるオンザフライ署名

ワイルドカードゾーンを用いたオンザフライ（動的）署名を実装した実験用の
権威DNSサーバーの開発について、Nominet UKのRay Bellis氏から発表があり
ました。

この権威DNSサーバーの開発のきっかけは、APNICのGeoff Huston氏による
DNSSECのパフォーマンス計測実験であったとのことです（*16）。この実験で
は75万個の署名済みゾーンを1台のサーバー上に準備する必要があり、通常の
BIND 9ではゾーンファイルの再読み込みに3～4時間を要することから、ワイル
ドカードを用いた委任を記述することでDNSSEC署名された応答を動的に生成す
る権威DNSサーバーを開発し、実験に使用することで問題を解決できたとのこ
とです。

（*16）Geoff Huston氏の実験結果は以下のURIで公開されています。
       Measuring DNSSEC Performance
       http://labs.apnic.net/blabs/?p=341

この権威DNSサーバーのソースはGitHubで公開されており、以下から入手可能
です（*17）。

（*17）Dynamic zone generator and signer
       

■次回のIETF Meeting

次回の第92回IETF Meeting（IETF 92）は2015年3月22日から27日にかけ、米
国のダラスで開催される予定です。

          ◇                     ◇                     ◇

◎関連URI

  - IETF 91 - Honolulu, Hawaii
    http://www.ietf.org/meeting/91/
    （IETF 91公式ページ）

  - IETF 91 Meeting Materials
    https://datatracker.ietf.org/meeting/91/materials.html
    （IETF 91発表資料一覧）

  - WG Action: Formed DNS PRIVate Exchange (dprive)
    https://www.ietf.org/mail-archive/web/ietf-announce/current/msg13360.html
    （dprive WG創設のアナウンス）

  - DNS PRIVate Exchange (dprive) - Charter
    https://datatracker.ietf.org/wg/dprive/charter/
    （dprive WG公式ページ）

  - DPRIVE - New IETF Working Group On DNS Privacy | Deploy360 Programme
    http://www.internetsociety.org/deploy360/blog/2014/10/dprive-new-ietf-working-group-on-dns-privacy/

  - IEPG Meeting - November 2014 @ IETF 91
    http://www.iepg.org/2014-11-09-ietf91/
    （2014年11月のIEPG Meeting公式ページ）

━━━━━━━━━━━━━━━━━━━━━━━━━━━【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), 2014 Japan Registry Services Co., Ltd.