ニュースレターNo.50/2012年3月発行
第82回IETF報告
DNS関連WG報告
本稿では、DNSに関連した内容を議論するワーキンググループ(WG)である、dnsop WG(Domain Name System Operations WG)と、dnsext WG(DNSExtensions WG)について、最近の動向をご紹介します。
dnsop WG報告
今回のIETFにおいては、dnsop WGの会合は開催されませんでした。そのため、前回のIETFから今回のIETFまでの間に、メーリングリスト(ML)上にて行われた議論を中心に、活動の報告をします。
2011年12月現在、次の三つのinternet-draftがWG activeドラフトとして残っています。
- draft-ietf-dnsop-dnssec-dps-framework
ゾーン管理者がそのゾーンについてのDNSSEC運用ポシーを明記するための指針について述べた文章。 - draft-ietf-dnsop-respsize
DNSがUDPにてパケットを送信する際に、そのサイズの限界と1パケットに入りきるメッセージに関しての考察ならびに注意事項を述べた文章。 - draft-ietf-dnsop-rfc4641bis
DNSSEC運用のガイドラインと実際の運用に際しての注意事項を述べた文章。
dnsop WGのML上では、主に次の3点について議論が行われました
- 前述の3、draft-ietf-dnsop-rfc4641bisに関する議論
- draft-ietf-mif-dns-server-selectionに関する議論
- DNS エニーキャストサービスにおいてノードを特定するための新たな手法に関する議論
次に概要を紹介します。
-
draft-ietf-dnsop-rfc4641bisに関する議論
DNSSEC署名に用いるアルゴリズムの変更を行う際の手続きに関して、更新時のDNSKEYの使い方がより明快な記述となるよう議論が行われました。
-
draft-ietf-mif-dns-server-selectionに関する議論
mif WGにて議論が行われている、draft-ietf-mif-dns-server-selectionは、複数のインタフェースを持つホストにおいて、複数のDHCP情報もしくはVPNやPPP情報を用いてインタフェースが設定されるような場合に、DNSサーバをどう選択し、名前解決を行うかについて述べた文章です。dnsop WGでは、この文章に関して、そもそもそのような利用環境においても、DNSサーバの選択を行う必要は無いといった意見や、実際のVPN等の利用用途から考えると、組織内部のプライベートDNSサーバに問い合わせを送る必要がある場合も存在するといった意見、また、“bare-name”(ドットが一つも含まれない名前)は特殊扱いにして、別のDNSサーバへの問い合わせに用いようといった意見が出されました。特に、bare-nameの提案に対しては強い反対意見が多数見られました。
-
DNS エニーキャストサービスにおいてノードを特定するための新たな手法に関する議論
ここでは、draft-anycast-diagnosticsというドラフトに関して議論が行われました。このドラフトにて提案された手法は、“_ns-diagonostics”というサブドメインを作り、エニーキャストDNSサーバに関する情報を“_instance-id”、“_node-id”、“_unicast-ip”といったレコードで登録するというものです。このドラフトに関して、そもそも標準化するべき事項なのか、情報として公開するものなのかといった意見が出され、あまり肯定的な意見は出されませんでした。
dnsop WGは議論自体が散発的になっており、次回のIETFにおいて会合が開催されるかも分かりません。DNSSECの運用が開始され、WG自体が落ち着いてきた印象を受けます。
dnsext WG報告
dnsext WGも、今回のIETFにおいて会合が開催されませんでした。そのため、前回から今回のIETFまでにML上にて行われた議論を中心に、活動の報告をします。
dnsext WGでは、2011年12月現在3本のWG activeドラフトと、2本のIESG処理待ちドラフトが存在します。
- WG activeドラフト
- draft-ietf-dnsext-dnssec-algo-signal
DNSSECリゾルバがDNSSECサーバに対して、どのアルゴリズムをサポートしているかを問い合わせるためのプロトコルを定義した文章。 - draft-ietf-dnsext-dnssec-bis-update
RFC4033、RFC4034、RFC4035、RFC5155にて定義されているDNSSECbisを実装するにあたって、実装者が注意すべき点や、DNSSECbis文章の誤りをまとめて修正している文章。 - draft-ietf-dnsext-ecdsa
DNSSEC署名にElliptic Curve DSAを利用する手法を定義した文章。
- IESG処理待ちドラフト
- draft-ietf-dnsext-dnssec-registry-fixes
DNSSECにおいて使われる暗号化アルゴリズムの名前と番号を、サブレジストリとして定義することを提案した文章。IESGレビューにて、IANA以外で番号リストを管理することの是非に関する議論が行われ、その改善を盛り込んだ新たな版を求められている段階です。 - draft-ietf-dnsext-rfc2672bis-dname
DNAME RRの定義を更新する文章。RFC2672に対して、DNSSECやDynamic UpdateとDNAMEとの関連を追記した文章となっています。
dnsext WGのML上では、主に次の6点について議論が行われました。
- draft-jiang-dnsext-a6-to-historicに関する議論
- RRTYPEを拡張定義するための言語に関する議論
- draft-mohan-dns-query-xmlに関する議論
- draft-ietf-mif-dns-server-selectionに関する議論
- EDNSのバージョン番号の扱いに関する議論
- dnsext WGの終了に関する議論
次に各々の概要を紹介します。
-
draft-jiang-dnsext-a6-to-historicに関する議論
既にRFCとして定義されているA6 RRを、その運用上の問題点やセキュリティ上の問題点からHistoric状態に変更して、利用されないようにしようという意見が出されました。それに対して、A6は使われていないのでHistoricにすべきといった意見や、DNSSECとA6の組み合わせは問題がありHistoricにすべきといった意見が出されました。一方で、いくつかのリゾルバ実装はA6 RRを問い合わせるようになっており、Historicにはできないのでは、といった意見も出されました。
-
RRTYPEを拡張定義するための言語作成に関する議論
ここでは、過去にそのような議論が行われたが実現していないといった意見や、必要な機能であるといった意見も出されました。数人がドラフトをレビューすると立候補し、多数の人が興味を示す議論となりました。
-
draft-mohan-dns-query-xmlに関する議論
DNSクエリをHTTP/HTTPS経由でXMLとして送受信するための手法を定義した、draft-mohan-dns-query-xmlに関する議論では、DNS over HTTP/HTTPSをやることの意義とそのコストに関しての意見が出されました。XML定義することによって可読性が生まれるといった意見や、JSON等のプロトコルを用いてメッセージングができるため、通信にかかるコストを省くことができるといった意見が出されました。その一方で、HTTPを横取りしてキャッシュやリダイレクトをするような機器が入っている場合には、DNSクエリが壊れるといった意見も出され、非常に多くの意見がML上にて交換されました。
-
EDNSのバージョン番号の扱いに関する議論
サポートされていないEDNSのバージョン番号をつけたクエリを投げた場合のDNSサーバの挙動に関する議論が行われました。BADVERを返すのが正しいはずが、一部の実装ではFORMERRを返す場合があり、さらにQDCOUNTの値によってどのような返答を返すべきか、といった議論がなされました。
-
dnsext WGの終了に関する議論
dnsext WGのチェアからWGを終了する提案が出され、終了するまでにRFCして発行したいドラフトの候補が挙げられました。提案されたスケジュールは次の通りです。
2011年12月 DNSSEC-errata document to IESG
2012年1月 RFC3597-bis To IESG for standard
2012年2月 EDNS0-bis update to IESG
2012年3月 Feb 2012 IXFR-Only to IESG
2012年4月 Algorithm signaling document to IESG
2012年5月 Close down WGこの提案に対し、DNSのプロトコルを扱うWGがなくなるのは困るといった意見や、MLは残してほしいといった意見が出されました。しかし、長年続いたWGであるため一度終了するということに対して強い反対も出ず、このまま進むとdnsext WGは終了しそうな雰囲気です。
WGでのfのような議論の様子からも、DNSSECのプロトコル定義も一段落し、dnsop WGと同様にWG自体も一段落した感触を受けることからも、dnsext WGは終了という方向に進むと思われます。
(JPNIC DNS 運用健全化タスクフォースメンバー／東京大学 情報基盤センター 関谷勇司)
