ニュースレターNo.57/2014年8月発行

DNS関連WG報告

dnsop WG (Domain Name System Operations WG)報告

IETF 89でのdnsop WG会合は、2014年3月7日(金)の朝、9：00からのセッションで行われました。しかしそれより以前に、DNSのプライバシーに関する議題が提起されたため、急きょ3月6日(木)の18：40からも非公式な会合が開催されています。DNSのプライバシーに関する議論は、3月4日(火)に開催された、後述するDNSE BoF(Encryption of DNS requests for confidentiality BoF)にて話し合われた議題であり、その結果を受けて急きょdnsop WGの会合が追加開催されることとなりました。これらのDNSのプライバシーに関する議論については、DNSE BoF紹介にてまとめて紹介します。

dnsop WG本来の金曜日の会合では、最初にDNSSECの鍵交換に関する議論が行われました。具体的には、draft-ietf-dnsop-child-syncronizationとdraft-ietf-dnsop-delegation-trust-maintenanceに関しての議論が行われ、鍵交換を簡易化するために、下位ゾーンから上位ゾーンに対してリソースレコード(RR)を用いて通知を行うという手法の有用性が確認されました。近いうちにワーキンググループ内でのラストコールが行われる予定です。

次に、AS112に関する議論が行われました。AS112の運用を続けていくこと、またDNAMEを用いたゾーンのリダイレクションにより、新たなゾーンをAS112に動的に加えることができるようにすることが確認され、関連する文章に対してのレビュアーが募集されました。

さらに、上位ゾーンの更新に関する議論(draft-andrews-dnsop-update-parent-zones)、DNSの応答パケットサイズに関する議論(draft-ietf-dnsop-respsize)、DNSのプライミング挙動に関する議論(draft-ietf-dnsop-resolver-priming)が行われました。draft-andrews-dnsop-update-parent-zonesは、上位ゾーンの委譲に関するレコードを、TSIG (Transaction Signature)を用いてレジストリも含め、動的に更新する仕組みを提供する提案です。以前からあった提案ですが、会場では多くの質問が出され、実現のためにはさらなる議論と提案の更新が必要と感じられました。

draft-ietf-dnsop-respsizeは、かなり以前から存在する文章であり、2012年から更新が停滞していたため、再度更新して15版として提出されました。512バイトのUDPメッセージサイズに入りきるようなDNS応答と、それを超えるような応答を行う場合の問題点を述べたものです。レビュアーが募集され、再度WGドラフトとして復活することとなりました。draft-ietf-dnsop-resolver-primingに関しても、会場からレビュアーが募集され、何人かが名乗り出ていました。

その後、新たな提案や文章に関する議論が行われました。主に、DNSのSpecial Nameに関しての議論が行われ、これに関連してdnsop WG自体のあり方、ドメイン名とDNSの関係といった、DNSの根本に関わるような発表や議論が行われました。Special Nameは、RFC 6761にも述べられているような、DNSラベルにおいて特別な用途として扱われる名前を定義するものです。ドメイン名とDNSはそもそも同一のものではなく、ドメイン名の一部の空間をDNS以外のデータベース構造に委ねる、といったことも必要なのではないかという提案や、DNSの名前空間を分割するべきではないといった議論が行われました。名前に関するICANNとIETFの関係も議論となり、DNS以外で管理する名前空間として「.alt」や「.non-dns」を使うのはどうだろうといった提案も行われました。議論は収束せず、引き続きWGとしては議論が行われるようです。

DNSE BoF報告

3月4日(火)の午後、14：20から1時間半のセッションとして、DNSのプライバシーに関する、Encryption of DNS requests for confidentiality(DNSE)BoFが開催されました。このBoFは、DNSの名前解決において、その過程で交換される情報を暗号化したい、という要求のもとに開催されました。どのような名前を解決しているのかといった情報は、個人のプライバシーに関連する情報である、という観点からの要求です。

BoFでは、そもそも何が問題なのか、これを解決するためにはどのような技術や手法があるのか、またその技術的な問題点は何なのか、といったことが議論されました。使える技術としては、パケットの暗号化であり、IPsecやDTLS(Datagram Transport Layer Security)といったものが存在する、といった議論がなされました。DNScurveやDNScryptといった提案も存在し、新たなプロトコルを開発するべきかとの問いかけも行われました。まだ議論は開始されたばかりであり、DNSプロトコルに大きな影響を与える可能性がある議論のため、今後に注目したいと思います。

DNSSD WG(Extensions for Scalable DNS Service Discovery WG)報告

DNSSD WGの会合は、3月3日(月)の午後、13：00から2時間のセッションとして開催されました。まず、前回に引き続き要求事項に関する議論が行われました。draft-ietf-dnssd-requirementsに関して議論が行われ、文章の訂正に関して詳細な議論が行われました。次回の会合までに、今回指摘された修正が行われる予定です。

次に、標準化に向けた議論が行われました。サービス発見を実現するために必要となる、新たな概念の導入や、名前の衝突といった運用上の問題を解決する必要がある、という認識が共有されました。

続けて、いくつかの文章に関する技術的な議論が行われました。まず、draft-otis-dnssd-mdns-xlinkに関する議論が行われました。これはRBridge機能を用いて、Layer-2におけるmulticastドメインを自動的に拡張することで、mDNS(Multicast DNS)によるサービス発見を広域に行う手法を提案しています。この提案に関しては、サービス発見のためだけにRBridgeを使うのはコストが大きすぎるなど、否定的な意見が出されました。

次に、draft-cheshire-dnssd-hybridに関する議論が行われました。これは、DNS Proxyを用いることでmulticastとunicastの変換を行い、Layer-2 multicastドメインを拡大せずとも、サービス発見が行える範囲を拡大するという提案です。この提案に関しても、構成が複雑になったり、認証が必要となったりするなど、導入へのコストが高いため、否定的な意見が多く出されました。

最後に、draft-sullivan-dnssd-mdns-dns-interopに関する議論がありました。この文章は、サービス発見に用いる名前の命名規則に関して、相互接続性を持たせられるように統一したルールを提案したものです。名前の規則に関する議論なので、さまざまな意見が出ましたが、現在はサービス発見のための名前の規則はWGのチャーターに含まれていないため、必要性も含めて引き続き議論が行われることとなりました。

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