ニュースレターNo.51/2012年8月発行

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

dnsop WG報告

dnsop WGの会合は、最終日である3月30日(金)の午前中に1時間の枠で開催されました。最初にInternet-Draft等の状況確認が行われ、情報の共有がなされました。WGドラフトとしては、draft-ietf-dnsop-rfc4641bisとdraft-ietf-dnsop-dnssec-dpsframeworkに関する報告がなされました。

draft-ietf-dnsop-rfc4641bisは、10版が発行され、その差分がほとんど編集的な変更であることと、2週間程度待ってコメントがなければ、WGラストコールをかけることが確認されました。

また、draft-ietf-dnsop-dnssec-dps-frameworkに関しても、差分はほぼ編集的な変更のみであることが報告され、IESGレビューに回されることが確認されました。WGドラフトはこの2本のみであり、その後、個人ドラフトに関する発表と議論に移りました。

まず、draft-gersch-dnsop-revdns-cidr-01に関する発表がありました。これは、CIDR Prefixの逆引きゾーンをDNSに定義する場合の手法に関して記述した文章です。例えば、129.82.64.0/18というCIDR Prefixを逆引きとして表すにあたって、1.0.m.82.129.in-addr.arpaと定義することが提案されました。詳しい変換方法はドラフトに明記されていますが、mという文字を区切りとしてオクテット表現から二進数のバイナリ表現に切り替えて表記する手法です。この提案に対して会場からは、「CIDR Prefi xに基づいてDNS逆引きゾーンを区切ることは、CIDR Prefixに応じた委譲ができるようにするためだと思うが、単なる表記の提案に終わっている」といった指摘や、「既存のCIDR委譲方法に比べて何が優れているのか」、といった質問が出ました。メーリングリスト(ML)にて議論が引き継がれると思われます。

次に、draft-pappas-dnsop-long-ttl-04に関する発表と議論が行われました。このドラフトは、DNSの各レコードのTTLをどの程度にしておけば、DDoSのような攻撃によってDNSサーバが利用不能になった場合にも、ユーザーは影響を受けることなく名前を解決できるか、という分析と指針を示したものです。1,500万ゾーンからランダムに抽出した10万ゾーンを4ヶ月観測した結果、75％のNSレコードとそれに対応するA/AAAAレコードの組は変更されていないという結果が示されました。そのため、RootやgTLDといった重要なゾーンに対するレコードは、TTLを7日間程度にした方が良いという指針が示されました。この発表に対して会場からは、「当たり前だけどトレードオフだよね」といった意見や、「DNSSECの場合はDSレコードが変更されるので、DSレコードのTTLは短くしないといけない」といった指摘がなされました。このドラフトに関しても、引き続きMLにて議論が行われると思われます。

dnsext WG報告

dnsext WGの会合は、1時間の枠にて開催されました。そのため、議論をする時間も少なく、淡々とした進行がなされました。また、今回の会合をもって、dnsext WGを終了することが宣言されました。残っているWGドラフトに関しては、引き続きMLにて議論を行い、早々にRFCとしての発行を目指すことが確認されました。

まず、WG ドラフトの状況確認が行われました。WGドラフトはRFCエディタの発行待ちであったり、IESGレビューに入っているものが4本、WGラストコールを行うべきものが6本あるということが確認されました。

次に、draft-ietf-dnsext-rfc6195bis-00に関する発表と議論が行われました。RFC6195は、RRTYPEの割り当てに関する定義とその割り当て方法について述べた文章です。この文章は、RFC6195から、RRTYPEの割り当て手続きに対する更新を行った文章になっています。特に目立った質問もなく、変更点は承認されました。引き続いて、draft-ietf-dnsext-rfc1995bis-ixfr-00に関する発表が行われました。この文章は、IXFRに関する定義を行っているRFC1995を更新するものであり、IXFR-ONLYオプションを定義して、常にIXFRによるゾーン転送を行うことができる仕組みを定義したものです。

また、NSEC4に関する発表も行われました。NSEC4は、NSEC3に比べDoS攻撃への耐性を高めたり、ゾーン内部でのOpt-outによるラベル挿入が可能になっています。また、NSEC3PARAMのようなソルト値とイテレーション数(反復処理数)を記述するためのレコードも不要になるよう設計されています。会場からは、dnsext WGが終了するのにNSEC4なのか、といった声も出ていましたが、それ以上の議論はありませんでした。引き続きMLにて議論されると思われます。

その他、DNSSECに関する話題として、DNSSECのリゾルバ性能を計測した結果の発表や、ゾーンがDNSSEC対応しているかをチェックするためのツールである、“DNSSEC-Check”の紹介がありました。このツールは次のURLからダウンロードできます。

http://www.dnssec-tools.org/dnssec-check/

1時間という短い時間だったため、議論よりも発表に終始する形となりました。最後にWGチェアから、これにてdnsext WGの会合は最後となる旨が宣言され、拍手とともに終了しました。

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