ニュースレターNo.59/2015年3月発行

第91回IETF報告　DNS関連WG報告

dnsop WG（Domain Name System Operations WG）

第91回IETFにおいては、火曜日に2時間の枠において、dnsop WGの会合が開催されました。今回の会合では、複数の議題が予定されており、時間内にて議論が行われましたが、特に興味深かったのが、DNSトランスポートをTCPで行うことに関する議論でした。

まず、チェアから現状のWGドラフトに関する確認が行われました。その後、DNS Cookiesに関する発表が行われました。以前から提案されていたドラフトであり、Webの場合と同様に、DNSサーバとクライアントの間においてもCookieと呼ばれる固有のトークン値を提供しようとするものです。実際には、以前にメッセージを交換したDNSサーバやクライアントのCookiesを記憶しておくことで、なりすましや外部からの攻撃を判別しやすくするという手法です。BIND 9.10.1b1に試験的に実装されたことが報告され、WGドラフトとして採用してもいいのでは、といった議論がなされました。

次に、QNAME minimisationに関する発表が行われました。これは、ある名前を解決する場合に、DNSサーバへの問い合わせの回数を減らすことで、どのような名前を引いたかということを推測しにくくし、プライバシーを強化しようという提案です。DNSサーバが担当するZoneの切れ目を学習することで、余分な問い合わせを減らすという手法が用いられています。この提案に関しては、まだWGドラフトになったばかりであり、引き続きレビューを行うことが確認されました。

続いて、DNS Transport over TCPに関する議論が行われました。発表においては、現在のDNSサーバの実装と、TCP Fast Openを用いたDNS問い合わせクエリに関する実装例が紹介されました。TCPにて問い合わせを行うことの利点と欠点が議論され、TCPで行うことの可能性について議論が行われました。WGドラフトとして、引き続き議論を行うことが確認されました。

また、IPv6の逆引きゾーンに関するドラフトである、draft-howard-dnsop-ip6rdns、ならびに新たな提案であるdraft-wkumari-dnsop-root-loopbackに関する発表も行われました。前者は、逆引きによるホストの認証や、メールサーバの認証を行っている運用手法に対して、IPv6の逆引きが適切な名前で設定されていることを期待しないよう指摘するガイドラインをめざした文書です。後者は、Root DNSの仕組みに関する新たな提案で、リゾルバDNSサーバにRoot Zoneのコピーを持たせることで、Root DNSサーバへの無駄な問い合わせを減らすという手法の提案です。新たな提案であるため、その目的や概要等が説明され、また議論されました。このRoot DNSに関する新たな提案に関しては、その後、香港にてワークショップが開催される旨がアナウンスされました。このワークショップはdnsop WGとは独立して行われたものでしたが、この提案と、もう一つの別のRoot DNSに関連する提案を中心に、次世代のRoot DNSの構造に関するワークショップが開催されました。dnsop WGとしては、引き続き議論を行っていくのではないかと思われます。

dprive WG（DNS PRIVate Exchange WG）

dprive WGは、クライアントとDNSサーバの間の名前解決における、プライバシー問題を解決するために設立されたWGです。

1. draft-hallambaker-privatedns
2. draft-hzhwm-dprive-start-tls-for-dns
3. draft-hoffman-dprive-dns-tls-alpn
4. draft-hoffman-dprive-dns-tls-https
5. draft-hoffman-dprive-dns-tls-newport

といったI-Dが取り上げられ、議論が行われました。具体的には、クライアントとリゾルバDNSサーバの間の通信を、何かしらの方法を用いて暗号化することを目標としています。

（1）draft-hallambaker-privatednsは、DNSトランスポートプロトコルとして、よりセキュリティに優れた仕組みを提案しているドラフトです。JSONベースのJCX（JSON Service Connect）プロトコルを用いて、DNSクライアントとリゾルバサーバ、ならびにDNSサーバ間の通信を行うという手法です。当然、従来のDNSトランスポートプロトコルとは大きな違いがあるため、どのような用途に適しているのか、またどう実現するのかといった説明や議論が行われました。

次に、（2）draft-hzhwm-dprive-start-tls-for-dnsに関する発表がありました。このドラフトは、TLSを用いてDNSトランスポートを暗号化し、その性能劣化を最小限にする方法を議論したものです。EDNS0のフラグとしてTLS OK（TO）ビットを用意し、TOビットが有効なクライアントとDNSサーバ間においてTLSを用いた通信を行います。また、TCPとTLSを用いることによる性能劣化を防ぐために、通常のTCPによるDNS問い合わせにSTARTTLSを用いてTLSを追加し、さらにTLS接続を継続して使いまわすという手法を提案しています。この点に関して、遅延の増加傾向やDNSサーバのCPU負荷の変化傾向等、数値的な評価も発表されました。さらに、試験的な実装も公開されています。

最後に、（3）draft-hoffman-dprive-dns-tls-alpn、（4）draft-hoffman-dprive-dns-tls-https、（5）draft-hoffman-dprive-dns-tls-newportに関する発表がありました。これらは、それぞれ別の手法にてDNSトランスポートにセキュリティを導入するための手法を提案しているものです。draft-hoffman-dprive-dns-tls-alpnは、TLS ALPN（Application Layer Protocol Negotiation）を用いてDNSトランスポートの暗号化方式を決定する手法を提案しています。draft-hoffman-dprive-dns-tls-httpsは、DNSの問い合わせや応答のトランザクションを、HTTPのURIフォーマットに変換して行うことを提案したものです。最後に、draft-hoffman-dprive-dns-tls-newportは、DNSクライアントとDNSリゾルバサーバの間でTLSを用いたDNSトランスポート通信を用いる場合に、ポート番号を443ではない別のポート番号を用いることを提案するものです。これを実現するための手法がいくつか提起され、議論が行われました。

dprive WGはまだ議論が開始されたばかりであり、今後も引き続いてDNSトランスポートのプライバシー問題解決に向けた議論が行われると思います。

dnssd WG（Extensions for Scalable DNS Service Discovery WG）

dnssd WGでは、まずDNS Long-Lived Queriesに関する発表が行われました。これはDNSを利用したサービス発見において、DNSサーバとの通信を状態管理することで、新たなサービス追加や削除などのイベントを管理できるようにする手法を提案したものです。この機能はすでにMac OS XのBonjour等に実装されており、dnssd WGでは、DoSに対する懸念点や、トランスポートプロトコルのTCPへの変更や、TLSの利用などが議論されました。TCPへの変更に関して、引き続き議論が行われる様子です。

次に、draft-rafiee-dnssd-mdns-threatmodel-01に関する発表がありました。このドラフトは、DNSSDによってローカルネットワークを越えてサービス通知が行われるにあたって、ネットワークの内部情報が漏れたり、名前の衝突が発生したり、なりすましが行われたりするような、DNSSDにおける脅威について分析したものです。会場の議論では、同じような脅威は別のプロトコルにも存在するため、よりDNSSDに特化した脅威について明確にすべき、といった意見が出ました。引き続き議論が行われます。

さらに、draft-cheshire-homenet-dot-homeに関する発表が行われました。これは、.homeという特殊なトップレベルドメインを、家庭内部のデバイス管理に利用するという提案です。会場では、.localドメインとの違いや利用方法の差異、dnsop WGやhomenet WGとの連携に関する議論が行われました。

また、draft-ietf-dnssd-hybrid-00に関する発表と議論も行われました。Multicast DNSによるサービス発見の結果を、Unicast DNSの名前空間にマッピングする手法を提案しているものです。新たにWG draftして発行され、WGラストコールに向けて改訂を進めることが確認されました。

（JPNIC DNS運用健全化タスクフォースメンバー／東京大学 情報基盤センター 関谷勇司）