ニュースレターNo.54/2013年7月発行

DNS関連WG報告

dnsop WG報告

dnsop WGの会合は、1時間の枠で開催されました。主な議題は、

(1)DNS in JSON
(2)Negative Trust Anchors
(3)Automating DNSSEC delegation

の三つでした。

これらに先立ち、会合の冒頭に、チェアからドラフトの状況に関する報告がありました。前回のIETF 85から現在までに、draft-ietf-dnsop-rfc4641bisがRFC6781として、draft-ietf-dnsop-dnssec-dps-frameworkがRFC6841として発行されたとの報告がありました。RFC6781はDNSSEC Operational Practicesの更新版であり、DNSSECに用いる鍵の生成からゾーンの署名、鍵の管理等、DNSSEC一連の運用に関してガイドラインを示した文章となっています。また、RFC6841はトップレベルドメインやセカンドレベルドメインの管理者が、DNSSECの導入や運用に関しての文章を作成するにあたってのフレームワークを提供する文章となっています。ドラフトの確認後、アジェンダとして予定されていた議題に移りました。

まず、(1)のDNS in JSON(JavaScript Object Notation)では、DNSの問い合わせや応答のフォーマットを、現在のバイナリ形式のワイヤーフォーマット以外にも定義し、アプリケーション間でDNSデータのやり取りをしやすくしようという意図から提案されました。具体的には、DNS Looking Glassなどからデータを抽出したり、HTTPを用いてDNSデータを交換したりする場合を想定しているようです。JSON WGでやるべきでは、との意見も出されましたが、JSONフォーマットを定義すること自体には大きな反対も無く、議論は続けられることとなりました。

次に、(2)のNegative Trust Anchorsに関する議論が行われました。この提案は、DNSSECを導入したドメインで、ゾーン管理者の設定ミスや管理のミスにより、ゾーン全体が無効になってしまうなどの事故が発生しても、ユーザーへの被害を最小限にするための手法です。過去にも、ZSK(Zone Signing Key) やKSK(Key Signing Key)が有効期限切れとなり、ゾーン全体が無効となってしまう事故が発生しています。この場合、DNSSECによる検証を有効にしたリゾルバを使っているユーザーは、そのゾーン全体を検索することができなくなってしまいます。これがISPや企業のリゾルバサーバであれば、ユーザーはそのゾーンが検索できないことに対するクレームを出し、結局リゾルバサーバ管理者は、そのリゾルバサーバのDNSSEC検証を無効にせざるを得ない事態となります。このような場合にも、このNegative Trust Anchorにより一時的にDNSSEC検証を無効にするドメインを指定することができれば、リゾルバサーバの管理者側で一時的な対応ができることになります。今のところ、企業やISPのDNSリゾルバサーバは全体的にDNSSECを使うか、使わないかという二つの選択肢しかありませんが、この提案は、DNSSECを使うかどうかをドメインごとに指定できることを目的としています。この提案に対しては前向きな意見が多く、レビューメンバーが募られ、引き続き議論が続けられることとなりました。

最後に、(3)のAutomating DNSSEC delegationの議論が行われました。これは、DNSSECのKSK rolloverをより簡単にする手法の提案です。現在のDNSSECでは、子ゾーンの管理者はDSレコードを作成し、それを親ゾーンに対して送付することで、信頼の連鎖を形成しています。一方、この提案では、現在親ゾーンに存在しているDSレコードを、CDS(Child DS)レコードで置き換えることでDSレコードの更新をほぼ自動化しています。CDSレコードはDNSKEYで署名されたレコードであり、子ゾーンの中のレコードとして発行されます。つまり、子ゾーンの管理者が自身のタイミングで自由に設定し、発行することが可能となっています。親ゾーンの管理者は、それを定期的に検証等することで、CDSが更新されていたらそれを検証し、親ゾーンに存在するDSレコードと置き換えることで、DSレコードの更新を行います。これによって、子ゾーンのKSKの更新時に、新たなDSレコードを親ゾーンに送付し、KSKをrolloverするという手順が簡略化されます。

この提案に対して、既存のツールが子ゾーンのDSレコードを親ゾーンに送付するという形での署名に対応したものとなっていたり、レジストラのビジネスモデルが既に存在したりすること等から、導入は難しいとの意見が出されました。その一方で、技術的には必要であるとの意見も出されました。結果として、レビューメンバーが募られ、引き続き議論が行われることとなりました。

dnsext WG報告

dnsext WGは、特段の事情が無ければIETFにて会合を開催しないことが合意されているため、今回も会合は開催されませんでした。ドラフトもdraft-ietf-dnsext-dnssec-algo-signalがIESG Last Callの段階であり、draft-ietf-dnsext-dnssec-algo-imp-status、draft-ietf-dnsext-rfc2671bis-edns0、draft-ietf-dnsext-rfc6195bisの三つのドラフトがRFCエディタ待ちになっているという状況で、これ以外にActive WGドラフトは存在しません。着実にWGをクローズする段階に入っていると言えます。メーリングリスト上では、前回のIETF 85から、draft-ietf-dnsext-dnssec-algo-signalとdraft-ietf-dnsext-dnssec-algo-imp-statusの議論、RFC5155の修正点に関する議論が行われた他は、散発的な議論が行われるのみでした。RFC5155の修正点に関しては、いくつかの指摘がなされ、用語的な指摘と、より間違いの無い定義をめざした文章への変更でした。どれも新たな提案ではなく、大きな議論も発生しませんでした。

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