ニュースレターNo.52/2012年11月発行

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

dnsop WG

dnsop WGの会合は、1時間の枠にて開催されました。そのため、現在議論中のInternet-Draftの状態確認を行うことが主な議題となりました。

まず、今回の議題にあがっていないInternet-Draftについて、状況の確認が行われました。draft-ietf-dnsop-respsizeが取り上げられ、長い間議論されている文章であるため、すぐにもIESGレビューに進むべきだという確認がなされました。

次に、draft-ietf-dnsop-rfc4641bisに関しての状況報告と議論が行われました。この文章は、RFC4641にて定義されたDNSSEC Operational Practicesを更新したものであり、NSEC3等の新たなDNSSEC仕様に関する運用上の指針を示したものです。WGチェアとしては、ADレビューの結果を待ってIETFラストコールに進みたいという意見が述べられました。会場からも特に質問や指摘はありませんでした。

その次に、draft-ietf-dnsop-dnssec-dps-frameworkに関する状況報告と議論が行われました。この文章は、ドメイン管理者がDNSSEC運用の方針を決定したり公表するにあたってのフレームワークとなるものです。この文章には、トラストアンカーの配布やアルゴリズム更新時の手法といった議論点が残っており、まだ大きな変更が必要であるとの意見が出されました。この文章に関しては、メーリングリストにて引き続き議論が行われます。

今回、WG draftとして一番議論が行われたのは、draft-ietf-dnsop-dnssec-key-timingでした。この文章は、DNSSEC運用時にKey Rolloverを行うにあたっての手法とその手順を時系列で示したものです。一度議論が中断されて今回再度復活した文章であるため、まだWG draftとして議論を続ける必要があるか話し合われました。結論として、WGラストコールを行うということで合意されました。

最後に、WG draft以外のInternet-Draftとして、

• draft-wkumari-dnsop-omniscient-as112、
• draft-wouters-dnsop-secure-update-use-cases

に関する発表と議論が行われました。

draft-wkumari-dnsop-omniscient-as112は、AS112 Projectとして行われている、プライベートアドレスの逆引きゾーンを保持するDNSサーバ群について、新たな“empty” zoneという概念を導入するという提案です。これは、AS112 ProjectのDNSサーバは、管理者同士が緩く結びついているため、それらDNSサーバ群に新たなゾーンを追加したり、既存のゾーンを削除したりすることを一斉に行うのが難しいためです。そのため、empty zoneを用いることで、上位DNSゾーンからの委譲設定を変更するだけで、逆引きゾーンを追加したり削除したりすることができるようにするという手法です。これに関して、empty zoneという概念がはっきりしないため、どのように定義すればいいかといった質問や、すべての問い合わせに対してNXDOMAINを返すことは危険なのではといった意見が出されました。結論としては、AS112 Projectにとってとても重要な問題提起であるため、引き続き話し合っていくことが合意されました。

draft-wouters-dnsop-secure-update-use-casesは、DNSの委譲設定変更にあたって必要となる、上位ゾーンのNSやDSレコードの設定変更を、DNS DynamicUpdateを用いて行う手法を提案したものです。この提案に関しては、多くの人が質問の列に並び、意見が交換されました。反対意見もありましたが、結論としては重要な提案であり、今後継続して議論するべきかどうかを含めてメーリングリストで議論を行い、次回のIETFにてもう一度話し合いを行うことになりました。

今回は1時間の会合であったため、少し時間オーバーして議論を行っていました。dnsop WGは引き続き、次回のIETFにおいても会合が開かれるものと思われます。

dnsext WG

dnsext WGは、前回のIETF83の会合にて宣言された通り、会合は開かれませんでした。WGとしてのメーリングリストは残っており、議論は引き続きメーリングリスト上にて行われています。そのため、今回のIETF報告では、IETF83からIETF84までの間にメーリングリスト上で行われた議論に関して、主な話題を報告します。

まず、draft-ietf-dnsext-rfc6195bisに関する議論がありました。この文章は、DNSのパラメータ番号の割り当てに関して、IANAからの割り当ての指針を示したものです。RFC6195からの主な変更点は、パラメータ割り当て要求に関する審議の方法を一部修正したことです。この文章に関してWGラストコールが行われ、いくつかの修正提案が出ました。その後、更新版が発行され、引き続き議論対象となっています。

また、draft-ietf-dnsext-dnssec-algo-signalも議論されました。この文章は、DNSクライアントがDNSサーバに対して、DNSSECでどのアルゴリズムをサポートしているかを問い合わせるシグナリング手法を定めたものです。この文章の更新版が発行され、意見は無いのかといった呼びかけに対して、いくつかの意見や指摘が出されました。意見の多くは前向きにこの提案に賛成するものであり、引き続き議論が行われています。

draft-damick-dns-associated-names-recordという文章も発行され、議論が起こりました。この文章は、“AN (Associated Names)”という新たなRRをDNSプロトコルに追加する提案をしたものです。このRRは、名前とその名前に関連付けられたサービスを指定して問い合わせることで、そのサービスを提供している実体のサーバの名前やIPアドレスといった情報を集めて返答するという挙動を定義しています。この文章に関しては、否定的な意見が複数出されました。何の問題を解決するためのRRなのかが明確ではないといった意見が出され、著者も一度考え直す旨のコメントを出しました。

dnsext WGはメーリングリスト上での議論のみになったため、ある文章に対してラストコールがかかると意見や提案が集中してよせられたり、新しい-00版の文章が発行されると、その文章に対して意見が多く付いたりといった傾向があります。そのため、ある文章に対する議論が長期にわたって継続して行われる事例は無く、ラストコール等の節目にて集中的に議論が起こる傾向にあります。

● IETFではWikiによる情報提供も行われています

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