ニュースレターNo.42/2009年7月発行

DNS関連WG報告

dnsop WG（Domain Name System Operations WG）報告

今回のIETFでは、dnsop WGの会合は100分の枠で開催されました。主な議題はDNSSECの運用に関するものでした。会合では、通常通り最初に、internet-draftの状態確認が行われました。

前回のIETF以降、internet-draftからRFCになったものはありませんでした。議論としては、まずdraft-ietf-dnsop-rfc4641bis-01について行われました。このinternet-draftは、DNSSECを導入するゾーン管理者のために注意事項を明記した、RFC4641を改訂したものです。変更点としては、RFC4641での文章的な間違い等の修正と、鍵長に関する記述の変更、ならびにDS（DelegationSigner）とTrust AnchorにおけるKSK（Key Signing Key）の扱いの違いについて記述が加えられました。これに関して、会場からは1024bitの鍵長では既に短いので、2048bitを推奨するようにとの指摘がありました。また、SHA-1ではなくSHA-2を使うようにとの指摘もありました。

次に、draft-morris-dnsop-dnssec-key-timing-00に関する議論が行われました。このdraftはDNSSECでの鍵更新に関して、通常時の更新方法や、緊急時の更新方法を述べたものであり、発表ではそれが時系列で図解して見せられました。DNSSECの鍵更新に特化して、鍵更新時に推奨される間隔を具体的に示した文章なので、DNSSEC普及のためのガイドラインとして重要であると思われます。

その他の発表では、Dynamic Updateを受け付けるゾーンでDNSSECの署名を行う場合において、冗長性のために複数台で署名を行い、かつ転送にIXFR^※1を使うと、RRSIG^※2が異なってしまうため不整合が発生する、という問題点も指摘されていました。

DNSSECに関連すること以外には、draft-liman-tld-names、draft-bagnulo-behave-dns64、RFC5205で定義されたHIP RRに関する発表が行われました。draft-liman-tld-namesでは、RFC952やRFC1123にてTLD（Top Level Domain）にはアルファベットで始まる文字のみ用いることができる、と定義されているが、国際化TLDが導入されるとこの規則に違反するのではないか、という問題提起がなされました。国際化TLDを導入するにあたっては、最小限の規則変更が必要だという認識が共有されました。

dnsext WG（DNS Extensions WG）報告

IETF74ではdnsext WGの会合が開催されませんでした。そのため、IETF73からIETF74までの間にメーリングリスト上にて行われた議論をまとめます。

話題としては、IETF73の期間中に行われたNSEC3 Workshopに関する報告や、draft-ietf-dnsext-dnsproxy、draft-ietfdnsext-dnssec-rsasha256、draft-ietf-dnsext-axfr-clarifyといったinternet-draftに関する議論が中心でした。また、DLV（DNSSEC Look-aside Validation）^※3をTLD単位で行えばどうか、といった提案も出され、多くの意見が投稿されていました。DLVは確かにDNSSECの普及を促進させる技術の一つだと思われますが、現在はISC（Internet Systems Consortium, Inc.）によってDLVtreeが管理されているため、それを問題視する意見も出されていました。

なお、IETF74では会合を開かない方向であることがあらかじめアナウンスされていました。IETF75やIETF76では会合を開催するかどうか、今後メーリングリストにて意見交換がなされるものと思います。

DNSSEC deployment BoF 報告

開催4日目（2009年3月25日）の夜に、DNSSEC deploymentに関するBoFが非公式に開催されました。このBoFは、DNSSECの普及に関して話し合う場（http://www.dnssec-deployment.org/） が別途存在し、そのメンバーが中心となって開催されました。

議論は、TAR（Trust Anchor Repository）^※4 に特化して行われました。TARを管理するのは誰なのか、管理するにあたって鍵更新はどのような段階に分かれるのか、といったことが議題にあがっていました。しかし実際には、TARで鍵交換や更新時に用いられる用語の定義に終始してしまいました。約2時間の会合だったのですが、その2時間を使い切ってもまだ用語の定義が終わりませんでした。DNSSECの鍵管理に関しては、さまざまな場面が存在し得るということを感じました。

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

---

※1 IXFR（Incremental Zone Transfer）

差分ゾーン転送と呼ばれる方式で、DNSサーバ間でゾーン情報を同期する際に、更新されたゾーンデータのみを転送する方式です。

※2 RRSIG（Resource Record Signature）

DNSSECにおいてRR（Resource Record）を電子署名する場合に、その署名アルゴリズムや有効期限等の付属情報と署名自体を格納するResource Recordです。

※3 DLV（DNSSEC Look-aside Validation）

DNSSEC専用のゾーンを提供することで、RootゾーンからDNSSECの署名がなされていなくても、Trust Anchorのような認証起点を設定すること無く、特定のゾーンをDNSSEC対応にすることができる仕組みです。現在ISC（Internet Systems Consortium, Inc.）によってサービスが提供されています。詳しくは、https://www.isc.org/solutions/dlv を参照してください。

※4 TAR（Trust Anchor Repository）

DNSSECにおける認証の起点を指定するDNSKEY RRをTrust Anchorと言い、そのDS RR（Delegation Signer Resource Record）を保存しているデータベースをTARと呼びます。