第83回IETF Meeting報告

今回のFROM JPRSでは、2012年3月25日から3月30日にかけてパリで開催された第83回IETF Meeting（以下、IETF83）で議論された話題の中から、DNS関連の話題を中心にお伝えします。

7年ぶりに参加者数が1,300人を上回る

IETF83の参加者は1,395人と前回（IETF82）の948人から大きく回復し、2005年に同じくパリで開催されたIETF63以来、7年ぶりに1,300人を上回りました。世界的な景気低迷が続いており予断を許さない状況ですが、ここ数回続いていた会議参加者数の低落傾向が途切れたことは、朗報であったといえるでしょう。

IETF94の横浜開催が決定～3度目の日本開催へ

3月28日に開催された全体会議（Operations and Administration Plenary）で、3年後の2015年11月に開催予定のIETF94の開催地として横浜が選ばれたことが、正式に発表されました。日本では、2002年のIETF54（横浜）、2009年のIETF76（広島）の2度にわたってIETF Meetingが開催されており、これが3度目の開催となります。

IEPGは、インターネットサービスオペレーターにより構成される、インターネット全体における運用環境や運用技術に関する技術的調整を円滑に進めるためのグループです。IEPGでは、毎回IETF Meetingに併設する形で会議を開催しており、初日の開催が通例となっています。

ここでは、IEPGで報告・議論された話題の中から、クライアントPCなどエンドホストでのDNSSEC検証を容易に実現するためのソフトウェア「Dnssec-Trigger」と、JPRSの藤原が発表した、JP DNSサーバーを継続的に観測した結果から分析した、バリデーター（*1）の数の推移について報告します。

 

Dnssec-Trigger～DNSSECの「ラストワンマイル」対応

DANE（*2）によるデジタル証明書の配送など、DNSインフラを用いたデータ配送の仕組みが検討され始めています。DANEを用いた安全な証明書の配送を実現するためには、発信元である権威DNSサーバーから実際に証明書を使用するエンドホストまでのすべての通信を安全に行う必要があります。

 

一般的なDNSSECの導入形態では、権威DNSサーバーからキャッシュDNSサーバー（バリデーター）までの通信の安全性はDNSSECで保障されますが、キャッシュDNSサーバーからエンドホスト（ユーザーが直接使用するPCなどの機器）までの通信の安全性は保障されません。そのため、安全なデータ配送を実現するためには、キャッシュDNSサーバーからエンドホストまでの通信の安全性の保障、つまり、DNSSECにおける「ラストワンマイル（*3）」への対応を実現する必要があります。

 

Dnssec-TriggerはNSDやUnboundなどを開発しているNLnet Labsで開発されている、エンドホストにおけるDNSSEC検証を実現するためのソフトウェアです。BSDライセンスのオープンソースソフトウェアとして公開されており、WindowsとMacOS Xのバイナリパッケージも提供されています。
Dnssec-Triggerはエンドホスト上でバリデーターとして動作することにより、ラストワンマイルの問題を解決します。Unboundをベースにしており、自らがフルリゾルバーとして動作し各権威DNSサーバーに直接問い合わせを送るモードのほか、透過型のDNSプロキシーとして動作し、ISPなどが提供するキャッシュDNSサーバーとの間の通信をDNSSEC対応にするモード、キャッシュDNSサーバーがDNSSECに対応していなかった場合に、NLnet Labsが用意した専用のキャッシュDNSサーバーとの間でSSL通信をすることで安全にDNSデータを入手するモードなどを備えています。
現時点におけるDnssec-Triggerの最新版は0.10で、NLnet Labsの公式サイト（関連URIを参照）からソースコードやバイナリパッケージを入手できます。通常の環境では特別な設定は必要なく、ダウンロード＆インストールするだけで簡単に実行できるようになっています。

JP DNSサーバーにおけるバリデーターの数の推移

JPRSの藤原が、JP DNSサーバーを約1年間にわたって継続的に観測した結果から分析した、バリデーターの数の推移について発表しました。ここでは、

• 問い合わせ元がバリデーターかどうかを判別する手掛かりとして、JP DNSサーバーに対するDNSKEY及びDSレコードの問い合わせ状況に注目したこと
• DSレコードを問い合わせてきたIPアドレスの数が、DNSKEYレコードを問い合わせてきたIPアドレスの数よりも多かったこと
• DNSKEY及びDSレコードを問い合わせてきたIPアドレスの数は、いずれもJPドメイン名におけるDNSSECサービスの開始からほぼ線形に近い形で増加していることから、バリデーターの数も線形に近い形で増加していると考えられること
• 2011年2月から2012年2月までの1年間で、バリデーターであると考えられる問い合わせ元IPアドレスの数が約3,000から約10,000に増大した一方、問い合わせ元IPアドレスの総数には大きな変化は見られなかったこと

などを報告しました。

会場からは、バリデーターが線形に近い形で増加しているのは意外であり、通常は（対応が一度に進むことで）ギャップが生じるのではないかという指摘がありました。これに対し藤原からは、キャッシュDNSサーバーにおけるDNSSECへの対応は単純なバージョンアップで増える性格のものではなく、管理者がトラストアンカーを明示的に指定する必要があるため、線形に近い形で連続的に増えているのではないかと回答しました。

dnsop WGでは、DNSの運用に関する標準化活動を進めています。以下、今回のWGで議論された主な話題について報告します。

CIDRブロック情報を逆引きDNSで（revdns-cidr）

CIDRブロックの情報を逆引きDNSツリー上で表現するための命名規則が提案されました。この提案は、CIDRブロックが8ビット境界になかった場合、"m"（マスクに由来）ラベルを追加した上で残りのサブネットマスクをビットマップ形式で表すことにより、逆引きDNSツリー上にCIDRブロックを表すゾーンを定義しようとするものです。例えば、192.0.2.0/25というCIDRブロックは0.m.2.0.192.in-addr.arpaとなり、192.0.2.128/26というCIDRブロックは0.1.m.2.0.192.in-addr.arpaとなります。会場からは、この提案のユースケースに関する意見がいくつか寄せられました。

なお、この提案は、安全なインターネット経路制御プロトコルの標準化に取り組んでいるsidr（Secure Inter-Domain Routing） WGで発表された、経路制御情報を逆引きDNSツリー上で管理する提案（ROVER）とも関連しています。これについては後述します。

TTL値の長短に関する考察（long-ttl、kskro-failure-recovery）

DNSでは、キャッシュデータの有効期限を各レコードのTTL値で制御します。権威DNSサーバーにおける適切なTTL値の設定は、DNSの運用における最も重要なテーマの一つです。
2012年2月、匿名のハッカー集団アノニマス（Anonymous）の名前で、3月31日にルートサーバーを一斉攻撃し、インターネットを機能停止させるという予告がありました（*4）。この予告を受け、ルートゾーンやTLDなどの重要な権威DNS サーバーがすべてアクセスできなくなった場合に備え、これらの権威DNSサーバーに設定するNS、グルー、DNSKEY、DSなどといったレコードのTTL値を長く設定しておくことで、攻撃の影響を軽減可能になるのではないかという提案がありました。

 

また、これとは別にJPRSの米谷が、DNSSECのKSKロールオーバーに失敗した場合の影響を小さくするための方法のうち、最良と考えられるものを選ぼうという提案をしました。考察されている方法のいくつかはDS/NSレコードのTTL値を短くし、失敗の修正からの回復時間を短縮しようというものです。

これら二つは相反する提案であり、それぞれの発表の後、議論の時間が設けられました。会場からは、TTLを長くしすぎることに対する懸念がいくつか表明され、また、.seではDSのTTL値を1時間（3600）に設定しているという報告がありました（参考: .seの親側のNSのTTL値は1日（86400）に設定）。そして、会場での議論の結果、本件については今後WGのメーリングリストで議論を続けながら、WGとしての扱いを決めていくことになりました。

前述したようにsidr WGで、経路情報の正当性を逆引きDNSツリー上で確認可能にするための提案（ROVER: ROuting VERification）が発表されました。

発表内容は、dnsop WGで提案されたCIDRブロックの情報を逆引きDNSツリー上で表現するための命名規則を適用したうえで、RLOCK（Route Lock）リソースレコードとSRO（Secure Route Origin）リソースレコードという二つのレコードを定義することにより、CIDRブロックごとの経路情報とオリジン（起源）ASの情報を逆引きDNSツリー上で管理しようとするものです。

従来から、sidr WGでは電子署名の技術を使って不正なBGPメッセージから経路情報を守る技術としてBGPSEC（Border Gateway Protocol Security）の標準化を進めてきました。BGPSECでは、リソースPKI（RPKI）と呼ばれるIPアドレスやAS番号などのアドレス資源の使用権を示すデジタル証明書（リソース証明書）を発行する仕組みの構築、証明書の発行、証明書を用いた経路情報への署名、ルーターへの実装などが必要であり、本格的な普及までには多くの時間を要するといわれています。

今回の提案では、逆引きDNSツリーをDNSSECで保護することによりデータの信頼性を確保でき、かつDNSという広く普及しているインフラを利用できることからより早い普及が見込め、将来の機能拡張も容易であるとしています。また、この提案はRPKIを否定するものではなく、あくまでも補完する目的であるとしています。

「とりあえずDNSに入れておけ（Just put it into the DNS）」

前述したROVER提案のインターネットドラフトはIETF83直前の2月28日に公開され、その直後から多くの議論を呼びました。その中には「DNSはインターネットを支える重要な基盤技術の一つであり、必要以上に依存すべきではない」といった否定的な意見もありました。
また、IETF83の終了後にヨーロッパ地域のTLD連合体であるCENTRが公開したIETF83のレポートでは本件の報告について「とりあえずDNSに入れておけ（Just put it into the DNS）」という表現が使われており（参考URIを参照）、本提案に対するやや批判的な姿勢がうかがえます。

次回の第84回IETF Meeting（IETF84）は2012年7月29日から8月3日にかけてカナダのバンクーバーで開催されます。バンクーバーでIETFが開催されるのは4回目で、米国以外の都市では最も多い開催回数となります。
IETF Meetingはインターネットの標準化活動に直接参加できる貴重な機会であり、インターネットを作っている世界中の技術者や専門家と直接対話・交流できる機会でもあります。標準化提案を持っている人、議論中の標準化提案に対する前向きな意見や提言を持っている人は、次回のIETF84にぜひ参加されてみてはいかがでしょうか。

本会議報告は、JPRSのメールマガジン「FROM JPRS」の増刊号として発行した情報に写真などを交えてWebページ化したものです。「FROM JPRS」にご登録いただいた皆さまには、いち早く情報をお届けしております。ぜひご登録ください。