ニュースレターNo.60/2015年7月発行

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

dprive WG(DNS Private Exchange WG)報告

DNS Private Exchange WGの会合は、2015年3月23日(月)の午後に90分間のセッションとして開催されました。このWGは、前回の第91回IETFから活動しており、今回で2回目の会合となります。DNSに問い合わせた名前はプライバシーに関する情報であり、この情報を攻撃者が盗み見ることによって、多くの情報を得ることができてしまうという問題を解決するためのWGとなります。

まず、Internet-Draftの確認から行われました。DNSのプライバシーに関する検討事項について述べたドラフト文書が、IESG(Internet Engineering Steering Group)のレビューに回されたことが確認され、このプライバシーに関する検討事項を解決するために現行提案されている手法について、確認が行われました。

次に、draft-am-dprive-eval-00に関する発表が行われました。この文書は、DNSの問い合わせに含まれるプライバシー情報を、攻撃者が盗み見る手法に関してのパターン分類や、それを防ぐための代表的な手法と、その効果の評価手法に関して述べたものです。dprive WGの出発点となる文書となっています。この発表に関しては、攻撃者が何を狙っているのか、また攻撃のパターン分類は適切かといった議論、ならびに「攻撃者」という定義が当てはまるのかといった用語的な議論が行われました。引き続き、議論される模様です。

さらに、Private DNSに関する発表が行われました。これは、プライバシーを保った状態で使うことのできるDNSサーバ、もしくは名前解決の仕組みを提供する手法をまとめた発表でした。Online Certificate Status Protocol(OCSP)での経験を元に、プライバシーが確保されることで、ネットワーク環境によって動作しなかったり、名前解決が遅延してしまうようなことが発生してはならない、という目標が示されました。また、実現手法として、HTTPS上でのJSON(JavaScript Object Notation)を用いた名前解決や、TCPでのTLS(Transport Layer Security)を用いた名前解決が提案されました。誰もが名前解決に使える従来のようなDNSサーバと、プライバシーを確保したい場合に用いるDNSサーバを、ユーザーが用途に応じて切り替えられることが必要だ、という議論が行われました。

関連して、draft-hzhwm-dprive-start-tls-for-dnsに関する発表と議論が行われました。これは名前の通り、DNSのトランザクションにTLSを用いる、という提案です。通常の53番ではなく、TLSを用いたTCPにて通信するための専用ポート番号を割り当てることを提案しています。この提案に関しては、DNSはUDP53番ポートと定義しているミドルボックス等も存在するため、新たなポート番号での名前解決が、必ずどの環境でもできるとは限らないといった指摘がありました。また、TLSのオーバーヘッドに関する質問も出ました。これに関しては、実装上の工夫として、TCP Fast Open(RFC7413)の利用等が提案されていました。

draft-wijngaards-dnsop-confidentialdnsに関する発表と議論も行われました。この文書は、opportunistic encryption、つまり必要な場合だけ暗号化を要求することを、DNSサーバとクライアントとの間で可能にする手法を提案したものです。ENCRYPTというリソースレコード(RR)を定義し、このRRを用いて鍵を交換することで通信を暗号化します。TLSに比べてアプリケーションレベルで暗号化を行うため、この方が負荷が高いのではないかといった議論や、鍵のやりとりはTCPにするべきでは、といった議論が行われました。引き続き議論が行われるようです。

最後に、このWGをどのように進めるべきか、の議論が行われました。現在出ている提案が列挙され、ハミングによる確認が行われました。有力であったのはDNS over TLSでしたが、引き続き議論が行われます。

dnsop WG(Domain Name System Operations WG)報告

dnsop WGの会合は、3月24日(火)の午後、2時間のセッションとして開催されました。まずいつも通り、Internet-Draftの確認が行われました。その後、draft-ietf-dnsop-qname-minimisationに関する発表が行われました。この文書は、DNSのプライバシー確保にも関連するものであり、DNSへの問い合わせにおいて省けるものはなるべく省いて、名前問い合わせを減らそうという提案です。最終的に解決したい名前を問い合わせるDNSサーバの数を減らす、もしくは名前を問い合わせる回数を減らすことで、プライバシー情報である、解決したい名前が漏れることを防ぎます。大きな反対はありませんでしたが、引き続き議論が行われることとなりました。

次に、draft-ietf-dnsop-root-loopbackに関する発表がありました。前回の第91回IETFにてWG draftとなった文書で、ホスト自身がルートDNSゾーンを有して、ユーザーからの名前解決要求に応じて、手元に保持するルートDNSゾーンから、TLDに関するRRの検索を行うことを可能にする提案です。これにより、今までルートDNSサーバに問い合わせて得ていた情報が、手元に保持するゾーンにて得られるため、名前解決に要する最終的な時間を短縮することが可能になります。また、手元に保持しているゾーンの情報が正しいものであるかどうかは、DNSSECを利用して確認します。ルートDNSゾーンはDNSSECにて署名されているため、改竄から守られており、手元に保持しているものが改竄されたとしても判別できます。

さらに、draft-ogud-dnsop-any-notimpに関する発表が行われました。この文書は、DNSサーバに対する問い合わせを拒否するための手法について提案したものです。例えば、明らかに攻撃であり、返答を行いたくないような問い合わせに対しては、REFUSEDやNOTIMP、もしくはRTYPE＝NULLなどの返答を行うという提案であり、またそのためのフィルタリング記述方法を定義しようという提案です。この提案に関しては、多くの意見が出されました。その動機がうまく述べられていないため誤用される心配があるといった指摘や、必要に応じて既に行われているのだから標準化してしまえばいいといった意見が出されました。引き続き議論が行われます。

他にも、

• Minimal IXFR(Incrememtal xfer)に関する発表と議論
• アプリケーションによって隠れて使われているTLDの存在の紹介
• ICANNの新gTLDプログラムの現状に関する報告
• NSEC(Next Secure)を用いたネガティブキャッシュの提案
• EDNSの正しい実装の普及具合

に関する報告等が行われました。

Minimal IXFRは、DNSSECで署名されたゾーンを転送する場合の、データ転送量を削減するための提案です。アプリケーションによって隠れて使われているTLDとして、.onionの紹介があり、さらに.mailや.home、.corpといったものも、実際のTLDとして使うことを避けた方がよい、という提案がなされました。NSECによるネガティブキャッシュの提案は、NSECを用いることで存在しないとわかっている範囲の名前は、積極的にネガティブキャッシュとして保持することで、DNSサーバへの無駄な問い合わせを減らすという提案です。特に、RFC6761にて定義される特別なドメイン名や、今回の会合で紹介されたような特別なTLDに関しては、取り出して集中議論する必要があるという意見が出され、次のIETF会合までにWebEXによる中間会合が開催されることとなりました。

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