JPNIC News & Views vol.739【臨時号】

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
    __
    /Ｐ▲         ◆ JPNIC News & Views vol.739【臨時号】2010.4.12 ◆
  _/ＮＩＣ
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ News & Views vol.739 です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

本号では、vol.736、vol.737に続き、2010年3月にアメリカのアナハイムで
開催された第77回IETFのレポート[第3弾]として、「DNS関連WG報告」をお届
けします。

なお、IPv6関連WG報告に関する報告は、以下のURLからご覧ください。

□第77回IETF報告
  ○[第1弾] IPv6関連WG報告(vol.736)
    ～v6ops WGについて～
    http://www.nic.ad.jp/ja/mailmagazine/backnumber/2010/vol736.html

  ○[第2弾] IPv6関連WG報告(vol.737)
    ～6man WG、behave WGについて～
    http://www.nic.ad.jp/ja/mailmagazine/backnumber/2010/vol737.html

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第77回IETF報告 [第3弾]  DNS関連WG報告
                             JPNIC DNS運用健全化タスクフォースメンバー
                                             東京大学 情報基盤センター
                                                              関谷勇司
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

■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 Names:国際化ドメイン
名)に関連する要求として上がってきた機能です。IDNの場合、その文字上の
表記は異なっていても、同じドメイン名として扱いたいという場合が発生し
ます。例えば日本語でのIDNの場合、"慶応義塾大学.日本"というドメイン名
と、"慶應義塾大学.日本"というドメイン名を、DNS的に全く同じものとして
扱いたい、という要求が出てくるかもしれません。日本語TLDでこのような
機能が導入されるかは全くわかりませんが、中国語TLDではこのような要求
があることが、以前のIETF会合にて報告されています。

この機能の提案に関して、会場では活発な議論が行われました。Paul Vixie 
氏は"CLONE RR"という新たなRRを導入して解決することを提案しました。発
表の中で例として挙げられていたのは、"vix.com"というドメイン名を、
"vixie.com"ならびに"vix.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-bis-updates-10に関す
る報告が行われました。09との差分が報告され、DNSSECでの応答に関しても
DO bitを設定することや、CD bitが設定された問い合わせに対しては、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-dps-framework-01に関する
報告が行われました。.SE TLDは、このフレームワークに従い、OpenDNSSEC
(*1)を用いた運用を開始したと紹介されました。また、Root zoneの署名に
関する事項も追記されています。

次に、draft-ietf-dnsop-dnssec-trust-history-01ならびに、
draft-ietf-dnsoprfc4641bis-02に関する報告が、Olaf M. Kolkman氏から行
われました。これらの報告に関しては、多くの質問がなされ、本当に提案し
たものを検証しているのか、また変更の意図は何なのか等の質問が出されま
した。会場の雰囲気としては、あまり説得されていない感触で、さらなる検
討を求める声が複数出された上で、より実践的な提案が求められる結果とな
りました。

その他のDNSSEC関連では、draft-morris-dnsop-dnssec-key-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を返す場合が非常
に限定される形となるため、やはりさまざまな意見が出されました。残念な
がら時間が押していたため、議論に多くの時間を取ることができず、メーリ
ングリストでの議論継続となりました。

(*1)OpenDNSSEC : http://www.opendnssec.org/

■その他の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"形式は継続されると思
われます。

(*2)DURZとは、意図的に検証不可能としたルートゾーン、またはDNSSECの検
    証をできないようにするため、意図的に入れられたダミーの署名データ
    のことを指します。


     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
       わからない用語については、【JPNIC用語集】をご参照ください。
            http://www.nic.ad.jp/ja/tech/glossary.html
     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
■■■■■  JPNICの活動はJPNIC会員によって支えられています  ■■■■■
  :::::  会員リスト  :::::  http://www.nic.ad.jp/ja/member/list/
  :::: 会員専用サイト ::::  http://www.nic.ad.jp/member/ (PASSWORD有)
□┓ ━━━  N e w s & V i e w s への会員広告無料掲載実施中 ━━━┏□
┗┛          お問い合わせは  jpnic-news@nic.ad.jp  まで          ┗┛
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
 JPNIC News & Views vol.739 【臨時号】

 ＠ 発行         社団法人 日本ネットワークインフォメーションセンター
                 101-0047 東京都千代田区内神田2-3-4 国際興業神田ビル6F
 ＠ 問い合わせ先   jpnic-news@nic.ad.jp
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
           本メールを転載・複製・再配布・引用される際には
       http://www.nic.ad.jp/ja/copyright.html をご確認ください
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
登録・削除・変更   http://www.nic.ad.jp/ja/mailmagazine/


■■◆                          ＠ Japan Network Information Center
■■◆                                     ＠  http://www.nic.ad.jp/
■■

Copyright(C), 2010 Japan Network Information Center
このページを評価してください
