第91回IETF Meeting報告（後編）

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

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

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

目的と方針

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）。
検討では懸念事項として、現在のインターネットには多数のミドルボックス（Middlebox）（*9）が存在するため、未知のプロトコルやポート番号は既存のミドルボックスによりフィルターされてしまう可能性があるのではないかという問題が指摘され、それを防ぐためには暗号通信を通しやすいポート443を、HTTPSプロトコルで使うのが良いのではないか、というコメントがありました。
会議では本件に関する明確な結論は出されず、今後も議論を継続していくこととなりました。また、プロトコルが満たすべき要件定義の項目（requirements）についても、併せて議論していくこととなりました。

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

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

この提案は当初、homenet WG（*11）で提案されました。しかし、WGではこの提案の標準化はdnssd WG（*12）の担当である旨の指摘があり、dnssd WGで取り扱われることになりました。
しかし、参加者の本提案に対するモチベーションは高まらず、その後のメーリングリストでの議論でも「TLDの予約ではなく、.arpaのサブドメインを用いる形であればIETFから提案しやすいのではないか」といった意見が出ていました。

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

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

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

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

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

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サーバーを開発し、実験に使用することで問題を解決できたとのことです。

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

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

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