ニュースレターNo.43/2009年11月発行
DNS関連WG報告
dnsop WG(Domain Name System Operations WG)報告
dnsop WGの会合は、月曜日の朝一番の時間帯にて開催されました(2009年7月27日)。会合の冒頭では、いつも通りInternet-Draftの状態確認が行われ、今までのInternet-Draftには特に大きな進展はないことが確認されました。
まず、draft-morris-dnsop-dnssec-key-timing-00に関する報告と議論がなされました。このInternet-Draftは、RFC4641を拡張したものであり、主にDNSSECにおける鍵更新のタイミングについて、より詳しく提案したものです。前回のIETFにおいても発表されたInternet-Draftであり、WG draftとするかどうか、議論が行われました。結果、数式が多く読みにくいという意見も出され、新たなバージョンが発行されるのを待つことになりました。
次に、draft-wijngaards-dnsop-trust-history-00について、発表と議論がなされました。これは、DNSSECで検証を行う際の起点となるTrust Anchorを更新するにあたって、期限切れとなったTrust Anchorを、DNSのプロトコルを用いて更新する仕組みを提案したものです。発表後の議論では、RFC5011との違いが取り上げられ、鍵やDNSの更新がどのぐらいの頻度で行われるか、過去の鍵情報はどの程度まで保存しておけばよいのか等、議論されました。過去の鍵を保存する方法のみに特化した方がよいのでは、という意見も出され、メーリングリストでの議論が続けられることとなりました。
さらに、draft-livingood-dns-redirect-00について発表がなされました。これは、DNSの応答を用いて、ユーザーを別のWebページに誘導するような仕組みについて、そのガイドラインを述べた文章です。DNSによる誘導は、DNSSECとの相性や、存在しない名前を入力した場合にもNXDOMAINが返らない等、セキュリティ上の問題を抱えるため、推奨すべきではないとの意見も出されました。このInternet-Draftも、引き続きメーリングリストにて議論が行われることとなりました。
他に特筆すべきものとしては、draft-ljunggren-dps-framework-00です。これは、DNSSECを用いてTLDゾーンを署名するにあたって、レジストリが担う役割を明記した文章です。会場からは、有用でありWG draftとすべきだとの意見が出ました。次の更新を待って議論が続けられることとなりました。
今回の会合は、DNSSECに関連するInternet-Draftの議論が多く、あらためてDNSSECが導入されつつあるという現状がうかがえました。
dnsext WG(DNS Extensions WG)報告
dnsext WGの会合では、主にforgery resilience※に関する議論と、EDNS0に関する議論、ならびに毎度のことになりますが、WGのチャーターに関する議論が行われました。
まずforgery resilienceに関する議論では、今までの議論の経緯がまとめられ、現在出ている提案が列挙されました。DNSへの詐称攻撃を防ぐために、ポート番号やクエリID等のランダム性を増加させる手法としては、DNS Pingやdns0x20、RTT Bandingといった手法が提案されています。また、DNSリゾルバサーバの挙動としては、キャッシュの上書き防止や、CNAME/DNAME連鎖の確認、TCPによる再問い合わせ等が提案されています。これらをまとめたものとして、draft-barwood-dnsext-fr-resolvermitigations-08とdraft-wijngaards-dnsext-resolver-sidemitigation-01が提案されており、議論の最後に、どちらの提案をWG draftとして採用するかの決がとられました。結果として、両方の提案をマージして一つのWG draftとする方がよい、という意見が多数を占め、著者と調整することとなりました。ただし、会場の雰囲気としては、これらの手法は少なからずDNSの既存実装に手を入れる必要があるため、それほど積極的にやらなくてもよいのではないか、という意見もかなり出ていました。
次にEDNS0に関する議論が行われました。
draft-ietf-dnsext-rfc2671bis-edns0-02ならびにdraftgudmundsson-dnsext-setting-ends0-do-bit-00が取り上げられていました。前者は主にEDNS0のバッファサイズとMTUに関する問題点を取り上げた文書であり、後者はDNSSECにおけるペイロード増大に関して、DNSバッファサイズとの関連を述べた文章です。draft-ietf-dnsext-rfc2671bis-edns0-02では、EDNS0によって通知されるバッファサイズが、必ずしもMTU値と一致していないため、経路途中にPMTUができないルータ等が存在すると、UDPパケットのフラグメントが行われず、結果としてEDNS0のパケットが届かない、という問題を指摘しています。これに対して、DNSバッファサイズを減らして再試行するようEDNS0の仕様を変更するという提案を行っています。
draft-gudmundsson-dnsext-setting-ends0-do-bit-00では、リゾルバサーバが扱うことのできるDNSバッファサイズが1,220Bytesより小さい場合には、DO(DNSSEC OK bit)を有効にしないよう推奨する提案を行っています。これらに関しては、引き続き議論が行われることとなりました。
その他には、behave WGのinternet-draftである、draftietf-behave-dns64-00におけるDNSSECの扱いに関する報告や、DNSSECにて利用される、新たな暗号アルゴリズムに関するinternet-draftの紹介がありました。dnsop WGと同様に、DNSSECに関連する議論が、時間の多くを占める結果となりました。
(JPNIC DNS運用健全化タスクフォースメンバー/東京大学 情報基盤センター 関谷勇司)
- ※ forgery resilience
- RFC5452にて述べられている、DNSへの詐称パケット攻撃に対する対策。
