ニュースレターNo.55/2013年11月発行

DNS関連WG報告

dnsop WG 報告

今回のIETF 87では、8月1日(木)の15：20から90分の枠にてdnsop WGの会合が開催されました。まず、Tim Wicinski氏が新たにco-chairに就任したことが報告されました。その後WG draftの状況確認が行われ、個々のdraftに関する議論に移りました。

はじめに、AS112に関する議論が行われました。現在のAS112サーバには、いくつかのゾーンが委譲されていますが、さらにゾーンを加えたいという要求が高まっています。しかし、AS112サーバは多くの組織によって分散して管理されているため、1度にすべてのAS112サーバを設定変更することが難しいという現状があります。そのため、omniscient-AS112サーバという、すべてのゾーンのどんなレコードに対してもNoError/NoDataを返答するDNSサーバを用意し、委譲したいゾーンを、DNAMEを用いてこのomniscient-AS112 DNSサーバに委譲することで、クエリを誘導するという手法が提案されました。この詳細はdraft-wkumari-dnsop-omniscient-as112やdraft-jabley-dnsop-as112-dnameにて述べられています。この提案に対して多くの前向きな意見が出され、まずは実験して、その結果を報告するべき、という方向で合意されました。

次に、CDSレコードに関する議論が行われました。CDSとは、Child Delegation Synchronizationの略で、下位のゾーンから上位のゾーンに対して、データの同期を行うための仕組みを提案したものです。具体的には、今までDSレコードを更新する場合には、上位のゾーンにDSレコードの更新を依頼していたものを、下位のゾーンにてCDSレコードとして発行することで、上位のゾーンに新たなDSレコードとして取り込んでもらうという仕組みです。これによって、DNSSECの鍵更新等の際に、オペレーター同士のやり取りが発生していたものを省くことができます。これに加えて、CSYNCというレコードの提案も行われました。

CSYNCは新たなレコードであり、下位ゾーンのどのレコードを上位ゾーンにコピーして欲しいか、を指定するために利用されます。これによって、NSレコードや、グルーとなるAやAAAAレコードの更新も、上位ゾーンへの依頼無しに下位ゾーンにて公開することで、自動的な更新を可能とするものです。会場では多くの意見が出されましたが、このような仕組みが有用であり、必要であるということが合意され、引き続き議論が行われることとなりました。

その他にも、DNSのキャッシュ性能を向上させる提案が、draft-wkumari-dnsop-hammerとして発表されました。あるレコードのTTLが過ぎても、再度の問い合わせで返答を得るまでそのレコードのキャッシュを保持しておく、もしくはTTLが切れる直前に再度問い合わせを行うことで、キャッシュが切れた後に再度問い合わせが行われて返答を得られるまでの時間を減らそう、という提案です。これに関しては、有用と思うがTTLの扱いを変えるものであるため、実験結果が必要だとの合意がなされました。 さらにDNSキャッシュに関連して、DNSリゾルバサーバに対して、DNSのキャッシュを消去するための通知を行う仕組みが提案されました。これはdraft-jabley-dnsop-dns-flushというドラフトに述べられています。この提案に関しては、キャッシュを保持しているリゾルバサーバに通知を行うのは現実的ではない、また規模性に問題がある等の否定的な意見が多く出されました。

最後に、RootゾーンのKSK更新について、ICANNのJoe Abley氏からその計画に関する報告が行われました。問題が発生した場合にはRollbackが行える体制であることや、新しいトラストアンカーは2014年7月頃に発行される予定であることが報告されました。

dnsext WG 報告

dnsext WGは既にクローズ段階であるため、会合は開かれませんでした。そのため、今回もML上にて行われた議論を紹介します。前回のIETF 86から今回のIETF 87までの間に、MLにて行われた議論としては

• draft-jabley-dnsext-eui48-eui64-rrtypes
• SPF RRTYPEの廃止

に関する話題です。

前者に関しては、以前に提出されたdraft-jabley-dnsext-eui48-eui64-rrtypesドラフトの更新版が提出されたことで、多くの意見がメールとして出され、ML上で議論が行われました。このドラフトは、EUI48とEUI64というリソースレコードを定義しており、あるノードが保持するEUI-48やEUI-64のアドレスをDNSに登録できるようにするという提案です。さらに、WGドラフトでもない、議論の最中である個人ドラフトに対して、IANAから既にEUI48とEUI64というレコードに対して番号が割り当てられていることがさらに大きな話題となりました。この提案に対して、DNSは便利なデータベースではないといった否定的な意見や、WGとしてはこのドラフトは却下の方向だったはずだ、といった否定的な意見が多く出されました。否定的な意見が多いにもかかわらず、このドラフトは更新され続けています。

次に、SPFレコードの廃止に関する提案が出され、ML上で多くの意見が出されました。これはdraft-ietf-spfbis-4408bisというドラフトにて提案されているものであり、現在の運用では、TXT RRに対してSPFを明記するのが通例となっており、新たなSPF RRは普及する気配がないために廃止するという提案です。これに対して、時間がかかってもSPF RRに移行する方が正しいといった意見や、現在の実装がTXT RRを見る仕様となっているためSPF RRには意味が無いといった、対立する意見が数多く出されました。この議論は、本原稿の執筆時点でも続けられており、まだまだ収束する気配がありません。

dnssdext BoF 報告

今回、dnssdext BoFと呼ばれる会合が開催されました。dnssdextとは、DNS-SD Extensionsの略であり、DNS-SDとはRFC6763にて提案されているDNS-Based Service Discoveryのことです。前回はIETF 85にて同様のBoFが開催されており、200名程度の人が参加しました。

mDNSやDNS-SDといった技術は、近年のサービス発見で頻繁に使われている技術ですが、実際には同一ネットワーク内部のサービス発見にしか利用されていないというのが実体です。そこでこのBoFでは、マルチリンクやネットワークセグメントをまたがったサービス発見を行うためのDNS-SDの拡張を議論するために開催されました。企業内や大学内において、広範囲なサービス発見を行うことをめざしたものです。

今回のBoFでは、チェアからチャーターの紹介と、DNS-SD Extensionsの要求事項に関する発表が行われました。この要求事項は、draft-lynn-mdnsext-requirementsというドラフトにまとめられており、ローカルな範囲でのZero configuration、グローバルな範囲でのMinimal configurationをめざすための要求事項を述べたものです。発表後に議論の時間が取られ、このような仕組みが必要であるとの意見交換がなされました。その結果、要求事項をまとめるボランティア、解決のための仕様を考えるボランティア等が募られ、WG設立をめざして活動することが確認されました。おそらく、次回以降のIETFにおいて、WGとして活動が開始されるものと思われます。

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