ニュースレターNo.45/2010年7月発行
第77回IETF報告 DNS関連WG報告
dnsext WG
dnsext WGでは、前回のIETF76での会合から今回のIETF77での会合までに、一度会合が開催されていました。これは、どこかの会場にて開催されるいわゆるinterim meetingではなく、WebExを利用した遠隔会議として行われ、virtual interim meetingと呼ばれました。
WebExは、最近のIETFにおいてもいくつかのWG会合に導入されており、従来の音声中継に加えて、遠隔からの双方向参加を実現するツールとして利用され始めています。
今回のdnsext WGの会合では、まず“Name equivalences”に関する議論が行われました。これはinterim meetingにて話し合われた議題で、DNSに完全なaliasの機能を導入しようという動きです。現在利用されているCNAMEやDNAMEといった機能では、RR（Resource Record）単位もしくはzone単位のredirectionが提供されますが、NS（Name Server）やMX（Mail Exchange）を含めたすべてのRRに完全なredirection（alias）は提供されません。
これは、もともとはIDN（Internationalized Domain Name:国際化ドメイン名）に関連する要求として上がってきた機能です。IDNの場合、その文字上の表記は異なっていても、同じドメイン名として扱いたいという場合が発生します。例えば日本語でのIDNの場合、“慶応義塾大学.日本”というドメイン名と、“慶應義塾大学.日本”というドメイン名を、DNS的に全く同じものとして扱いたい、という要求が出てくるかもしれません。日本語TLDでこのような機能が導入されるかは全くわかりませんが、中国語TLDではこのような要求があることが、以前のIETF会合にて報告されています。
この機能の提案に関して、会場では活発な議論が行われました。Paul Vixie氏は“CLONE RR”という新たなRRを導入して解決することを提案しました。発表の中で例として挙げられていたのは、“vix.com”というドメイン名を、“vixie.com”ならびに“vixie.sf.ca.us”というドメイン名にaliasする例です。BINDのzone表記に従うと、以下のように定義します。
$ORIGIN vix.com
@ IN CLONE vixie.com.
@ IN CLONE vixie.sf.ca.us.
このようにTLDから異なるドメイン名に関しても完全なaliasを提供することを提案しています。もちろん、まだ単なる提案レベルであり、セキュリティ的な問題やaliasのループ等、気をつけるべき多くのことがあるとも報告されました。会場の雰囲気としては、あまり導入に前向きとは言えず、まだ多くの慎重な議論が必要である、という方向性になりました。
その他の議題としては、draft-ietf-dnsext-dnssec-bisupdates-10に関する報告が行われました。09との差分が報告され、DNSSECでの応答に関してもDO bitを設定することや、CDbitが設定された問い合わせに対しては、CD bitを設定した応答をすることが必須とされました。
さらに、2009年12月16日に発生した、in-addr.arpa zoneに対するDNSKEY問い合わせの増大に関する報告も行われました。これは、Fedora OSにあらかじめ設定されていたDNSKEYが有効期限切れになったことに起因して、世界中のFedora OSを利用したDNSリゾルバサーバから一斉に、in-addr.arpa zoneに対するDNSKEYの問い合わせが増大したという現象です。現在は収まりつつあることが報告されましたが、BINDへの改善要求も出され、DNSSEC導入に向けての一つの教訓となりました。
dnsop WG
dnsop WGの会合では、通常通りWG draftの状況報告や、関連draftの報告が行われました。まず、draft-ietf-dnsop-dnssec-dpsframework-01に関する報告が行われました。.SE TLDは、このフレームワークに従い、OpenDNSSEC※1を用いた運用を開始したと紹介されました。また、Root zoneの署名に関する事項も追記されています。
次に、draft-ietf-dnsop-dnssec-trust-history-01ならびに、draft-ietf-dnsop-rfc4641bis-02に関する報告が、Olaf M.Kolkman氏から行われました。これらの報告に関しては、多くの質問がなされ、本当に提案したものを検証しているのか、また変更の意図は何なのか等の質問が出されました。会場の雰囲気としては、あまり説得されていない感触で、さらなる検討を求める声が複数出された上で、より実践的な提案が求められる結果となりました。
その他のDNSSEC関連では、draft-morris-dnsop-dnsseckey-timing-02の報告も行われました。このdraftに関しては、いくつかの質問が出ましたが、特に大きな反論も無く、WG draftとして採用されました。
WG draft以外としては、draft-howard-isp-ip6rdns-03ならびにNSEC3 Hash Performance、IPv6 & recursive resolversに関する報告が行われました。
IPv6の逆引きに関するdraftでは、主にCPEの場合におけるIPv6逆引きに関する事項が変更されたとの報告がありました。会場からはあまり反応も無く、引き続き議論が行われる運びとなりました。
NSEC3 Hash Performanceでは、NSEC3が導入されたzoneにおいて、DNSSECのvalidatorやAuthoritativeサーバにどの程度負荷が増えるのかの評価結果が報告されました。結果として、validatorは鍵長が増えることが、iteration（反復）の回数が増えることよりも負荷に影響を与えることがわかり、Authoritativeサーバは鍵長に影響されず、iterationの回数のみに負荷が影響されることがわかったと報告されました。
IPv6 & recursive resolversでは、Yahoo!社のIPv6リゾルバに関する提案が行われました。これは、サーバにAAAAアドレスを付加した場合、クライアント側のIPv6環境が適切でなければ、IPv6 timeoutによるIPv4 fallbackが頻発するという問題に対する提起です。ISPのDNSリゾルバサーバが、クライアントからの要求に対してAAAAを返答するにあたって、そのクライアントが適切なIPv6環境にあるかどうか、すなわちIPv6の到達性があるかどうかを判断してからAAAAを返すようにしたらどうか、という提案です。BINDでは、9.7.0b2から導入されたdisable-aaaa-on-v4-transportというオプションによって、IPv6トランスポートによるDNS問い合わせの場合のみAAAAを返すという機能が追加されています。この提案に関しては、AAAAを返す場合が非常に限定される形となるため、やはりさまざまな意見が出されました。残念ながら時間が押していたため、議論に多くの時間を取ることができず、メーリングリストでの議論継続となりました。
その他のDNS関連活動と雑感
その他のDNSに関連した活動としては、DNSSEC ROOT Q+A BoFが開催されました。このBoFでは、Root zoneがDURZ（Deliberately Unvalidatable Root Zone）※2によって署名され、いくつかのRoot DNSサーバが署名されたRoot zoneを提供開始したため、その影響や各Root DNSサーバでの計測結果が報告されました。TCPによる問い合わせの増加や、UDPにおけるパケットサイズの増大が見て取れる結果となりました。
今回のIETFはアナハイムで開催され、近くにディズニーリゾートがあったため、多くの参加者はディズニーリゾートに入園もしくはダウンタウンディズニーにて食事したのではないかと思われます。普段は一人で来ている人が、子供を連れて来ている様子も見受けられました。
IETFの会合自体は、金曜日の午後まで埋められており、以前に比べて会合の数が増えてきた印象を受けます。また、“Bar BoF”と呼ばれる、時間外に企画される簡易的なBoFが多く行われ始めています。これはもともとホテルのBarにて、夜に関係者だけが集まって話を行う形態で行われていたものですが、最近は昼食の時間帯に部屋を取り、気軽なミーティング形式で行われるものも“Bar BoF”と呼ばれています。これに関しては賛否両論あるようで、IETFメーリングリスト上でも議論が行われました。できるだけ通常のBoFとして行い、早めに事前アナウンスを行った方が参加者にとってもうれしい、という議論がなされました。次回以降も、“Bar BoF”形式は継続されると思われます。
（JPNIC DNS運用健全化タスクフォースメンバー/
東京大学 情報基盤センター 関谷勇司）
- ※1 OpenDNSSEC
- http://www.opendnssec.org/
- ※2 Deliberately Unvalidatable Root Zone（DURZ）
- 意図的に検証不可能としたルートゾーン、またはDNSSECの検証をできないようにするため、意図的に入れられたダミーの署名データのことを指します。
