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


ドメイン名関連会議報告

2014年

第91回IETF Meeting報告(後編)

~dprive WG/.homeの予約/IEPG Meetingにおける話題~

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

会場となったHilton Hawaiian Village

会場となったHilton Hawaiian Village

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
https://github.com/raybellis/apnic

次回のIETF Meeting

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

本会議報告は、JPRSのメールマガジン「FROM JPRS」の増刊号として発行した情報に写真などを交えてWebページ化したものです。
「FROM JPRS」にご登録いただいた皆さまには、いち早く情報をお届けしております。ぜひご登録ください。