ニュースレターNo.53/2013年3月発行

DNS関連WG報告

dnsop WG報告

前回のIETF84から今回のIETF85までに、dnsop WGのMLにおいて行われた議論をまとめます。まずは、いくつかのWGドラフトに関して、更新版が発行されました。

はじめに、draft-ietf-dnsop-rfc4641bis-12はIESG Reviewに回され、そのコメントを受けてdraft-ietf-dnsop-rfc4641bis-13が発行されました。このドラフトは、ゾーンに対してDNSSECによる署名を行うに当たっての運用手順のガイドラインを示した文章です。RFC4641の更新版として発行されています。13版における変更点は、Rollover時におけるDNSKEY削除時の手順変更と、DNSKEYの有効期間に関する変更、またNSEC3の署名に用いるsaltに関する注意点が盛り込まれました。その結果、このInternet-DraftはIESGレビューを通過し、RFCエディターの手に渡されました。しかし、その後にさらにいくつかの問題点が発覚し、ML上にて議論が継続されています。

さらに、draft-ietf-dnsop-dnssec-key-timing-03がWGラストコールされました。このドラフトは、Key Rolloverを行うに当たって発生する問題点に関する注意事項や懸念点をまとめたものです。このラストコールに対し、多くの意見が寄せられました。用語の使い方や説明が足りない部分の補足、逆に説明が詳し過ぎる部分などの指摘がありました。本稿執筆時点では、この議論に基づいた修正が行われ、次の版が発行されるのを待っている段階となります。

他にも、draft-ietf-dnsop-dnssec-dps-frameworkに関する議論が行われました。このドラフトは、DNSSECを導入するトップレベルドメインやセカンドレベルドメインのゾーン管理者が、DNSSEC導入ポリシーを決定するに当たってのガイドラインを示したものです。9版と10版が公開され、その後のコメントを元に11版が最新版として公開されていますが、まだ修正点が残っていると筆者自身がコメントしています。

それ以外に、いくつかの個人ドラフトが議論されました。draft-howard-isp-ip6rdnsやdraft-andrews-dnsop-rfc6598-rfc6303、draft-yoneya-dnssec-kskro-failure-recoveryといったドラフトです。特に、draft-howard-isp-ip6rdnsにはその問題点を指摘する多くのコメントが寄せられました。カスタマーに割り当てられたIPv6アドレスブロックのDNS逆引きをどう設定するか、多くの人がその必要性を感じている一方で、決定的な解決策がないため今まで放置状態でした。このドラフトによって、Dynamic DNSの利用やCPEへの委譲といった手法が提案されましたが、セキュリティ上の問題点やCPEを権威DNSサーバとした場合の問題点を指摘する意見が多数出ており、まだ収束しそうにはありません。

dnsext WG報告

dnsext WGも同様に、ML上にて行われた議論を中心に、動向をまとめます。

まず、RFC5011をStandard RFCに変更しようという提案がありました。RFC5011はDNSSECにて用いられる trust-anchorsを自動的に更新するためのプロトコルを定めたものです。この提案に対して、いくつかの前向きな意見が投稿されました。また実装もBIND9に取り入れられていることから、IESGへの正式なリクエストが行われました。

次に、SPF (Sender Policy Framework) RRに関する議論も行われました。SPFはメール送信のポリシーを記述するために用いられているものであり、IETFで標準化される以前からTXT RRに記述する形で利用されていました。その後IETFにて標準化され、SPF RRが新たに作られたのですが、これがほとんど利用されていないため、TXT RRに記述する形を標準とするということでよいのでは、という議論が行われました。結論は出ませんでしたが、実際問題としてSPFはTXT RRに記述されているようです。

さらに、draft-ietf-dnsext-rfc2671bis-edns0の9版が公開され、IESGからラストコールが行われました。このドラフトはRFC2671で標準化されたEDNS0(Extension Mechanisms for DNS)^※に関して、その仕様を更新するものです。この9版に対して議論が行われ、主にバイナリラベルの取り扱いに関して、廃止するかどうかの議論が行われました。明確な結論は出ませんでしたが、バイナリラベルの扱いを廃止してもよいという意見の方が多かったように見えます。

また、draft-ietf-dnsext-dnssec-bis-updatesの19版に関しての議論も行われました。このドラフトはDNSSECの仕様をNSEC3とSHA-2のアルゴリズムを加えた形に更新するものです。記述の一部に曖昧性があるため、もっと明確に記述した方がよいという提案に始まり、その提案に基づいて20版が公開され、IESGによってProposed Standard文章として認定されました。今後RFCに向けてさらに議論が続けられると思われます。

dnsext WGはもう会合を開かないと宣言していますが、MLでの議論は散発的ではあるものの活発に行われており、まだ残っているWGドラフトに関して、標準化が続けられる予定です。

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

※EDNS0

DNSの問い合わせや応答メッセージのプロトコルを規定したRFC1035を拡張し、512オクテットを超えるパケットを扱えるようにするための技術。

RFC2671: Extension Mechanisms for DNS (EDNS0)
http://www.nic.ad.jp/ja/translation/rfc/2671.html