ニュースレターNo.46/2010年11月発行
DNS関連WG報告
はじめに
今回のIETF78は、オランダのマーストリヒトにて開催されました。MECCと呼ばれるカンファレンスセンターにて開催されたのですが、その周囲には大学や企業しか存在せず、商店やレストランといったものが徒歩圏内に存在しませんでした。
そのため、会場近くのホテルに滞在している参加者は、食事をするにもバスや電車を利用してマーストリヒト市街まで出向く必要がありました。この点に関して、IETF78参加者のメーリングリストでは、もっと便利な場所を選べばいいのにといった否定的な意見が出ていました。その一方で、気候が素晴らしいといった肯定的な意見も出ていました。さまざまな意見があるのは当然ですが、個人的にはもっと便利な場所で開催して欲しいと感じたIETFでした。
IETFの会合としては、“Bar BoF（Birds of a Feather）”と呼ばれる、正規の時間帯ではない時間に、空いている会場を利用して暫定的に会合を開くグループが多く見られました。Bar BoFは、同じ問題や興味を共有する人々が集まって、活発に議論を行うためには良い形式なのですが、その一方で、IETF agendaに載っている正規の会合ではないため、気付かずに参加できない人が発生したり、正規のIETF会合との差がわからなくなってしまう等の問題があるため、その開催が増えることには賛否両論ありました。今回のIETF78では、私が把握している限りで18回のBar BoFが開催されていました。
dnsext WG
dnsext WGは、2回の会合を開催しました。主な議題はDNS zone aliasに関するものでした。あるDNS zoneをそのまま別ドメインのDNS zone定義として利用することができるようにする仕様で、前回のIETF77においても話し合われた議題です。このzone aliasは、TLDレベルのzoneに対しても利用できるように議論されており、例えば従来の国コード別TLD zoneとIDNによる国コード別TLD zoneとのaliasに利用するといった用途も考えられているようです。
zone aliasを実現するための提案としては、
- （1）BNAME RR（Resource Record）の導入
- （2）CNAME+DNAMEという定義の導入
という二つの案が出され、議論が行われました。
（1）の提案は、新たにBNAMEというzone aliasのためのリソースレコードを定義し、zone中にてBNAMEを利用してzonealiasを指定するという手法です。
例えば、aliasing-test.aaaというzoneを.bbbというzoneにaliasしたい場合には、aaa zoneにて
aliasing-testIN BNAMEbbb.
と記述します。これによって、aliasing-test.aaaというzoneに定義されている名前は、すべてbbbというTLD zoneの名前にaliasされます。つまり、www.hoge.aliasing-test.aaaという名前のARRを問い合わせると、www.hoge.bbbという名前にaliasされ、www.hoge.bbbに対応するA RRの応答が返ります。
（2）のCNAME+DNAME提案も、実現できることは同様です。従来のDNAMEによるzoneリダイレクションに加え、同様の定義をCNAME RRにて行うことで、同一の名前に対して、CNAMEとDNAMEで両方の定義があった場合のみ、zone aliasとして扱うようにするという提案です。CNAME+DNAMEの場合には、前述の例は、
aliasing-testIN CNAMEbbb.
aliasing-testIN DNAMEbbb.
と記述されます。
BNAMEは新たなRRの定義であるため、既存実装への影響が大きい一方で、既存のRR定義との混乱は起こりにくいといった意見が出されました。また、zone alias自体の賛否も含めた議論も行われ、結局どちらを標準とするかの結論は出ませんでした。その一方で、IDN TLDの導入も進んでおり、早急に仕様を決定したい、といった意見も出されました。引き続き議論が行われる模様です。
dnsop WG
今回のdnsop WGでは、特に中心となる大きな話題はなく、以前からあるいくつかの提案に関して報告と議論が行われました。
まずDNSSEC Operational Practicesに関する報告がありました。DNSSECの鍵管理について述べられた文章であり、RFC4641を更新するものです。DNSSECの仕様の更新に従ってRFC4641から変更されているものであり、特に議論はありませんでした。
次に、draft-mekking-dnsop-auto-cpsyncに関する発表がありました。この文章は、子ゾーンの鍵更新とともに、親ゾーンのDS RRを自動的に更新する仕組みを定義したものです。DNSのRR dynamic update機能を使い、親ゾーンのDSレコードを更新します。この提案に関しては、DSレコードのみではなく、それに付随するレジストリ的な管理情報もあるので、自動更新は適さないのではないかといった意見や、自動更新は必要だが、それはDNS dynamic update機能を利用するべきではない、といった意見が出されました。
また、draft-savolainen-mif-dns-server-selectionに関する発表がありました。これは、MIF（Multiple Interfaces）WGにて話し合われた提案をdnsop WGにて発表したものであり、複数のDNSサーバを選択するための手法を提案したものです。例えば、組織内部の名前を管理している内部用のDNSサーバと、外部の名前を解決するためのDNSサーバがあった場合に、クライアントがどう使い分けるか、という手法を定義しています。具体的には、DHCPv6に新たなオプションを定義し、クライアントはその情報を利用してDNSサーバの使い分けを行うという提案です。
最後に、dnsop WGの議題ではありませんが、Root zoneのDNSSEC導入に関する報告が、同じ会場にて行われました。まず、DURZ※1を用いてRoot zoneの署名を行い、DURZの導入を段階的に進めていったことが報告されました。2010年7月15日に、正式な鍵を用いて署名されたRoot DNS zoneがすべてのRoot DNSサーバに導入され、いくつかのTLDのDS RRもRoot zoneに導入されたことが報告されました。
（JPNIC DNS運用健全化タスクフォースメンバー／東京大学 情報基盤センター関谷勇司）
- ※1 DURZ（Deliberately Unvalidatable Root Zon）
- 意図的に検証不可能としたルートゾーン、またはDNSSECの検証をできないようにするため、意図的に入れられたダミーの署名データのことを指し、ルートゾーンにDNSSECを導入した場合に影響が出るかどうかの確認に利用されていました。
