JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト

メールマガジン「FROM JPRS」

バックナンバー：vol.118

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2012-04-25━
　　　　　　　　　　◆ FROM JPRS 増刊号 vol.118 ◆
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
　　　　　　　　　　　　第83回IETF Meeting報告
　　　　　　　　　　　 ～DNS関連の話題を中心に～
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

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

　　　　　◇　　　　　　　　　　 ◇　　　　　　　　　　 ◇

■IETF全般の状況

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

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

（*1）DNSSECにおいて署名を検証するプログラムやライブラリー。一般的な
      DNSSECの導入形態では、キャッシュDNSサーバーがバリデーターとなり
      ます。

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

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

（*2）DNS-based Authentication of Named Entitiesの略。
      DNSを用いてデジタル証明書の安全な配送や証明書とサーバーの関連付
      けの正しさを検証するためのプロトコルで、現在dane WGで標準化作業
      が進められています。詳細についてはFROM JPRS増刊号バックナンバー
      「第82回IETF Meeting報告」を参照ください。

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

（*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における話題

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値を
長く設定しておくことで、攻撃の影響を軽減可能になるのではないかという提
案がありました。

（*4）結果としてサーバーの異常は検出されず、障害は発生しませんでした。

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

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

■sidr 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を参照）、
本提案に対するやや批判的な姿勢がうかがえます。

■次回のIETFはバンクーバーで開催

次回の第84回IETF Meeting（IETF84）は2012年7月29日から8月3日にかけてカ
ナダのバンクーバーで開催されます。バンクーバーでIETFが開催されるのは4
回目で、米国以外の都市では最も多い開催回数となります。

IETF Meetingはインターネットの標準化活動に直接参加できる貴重な機会であ
り、インターネットを作っている世界中の技術者や専門家と直接対話・交流で
きる機会でもあります。標準化提案を持っている人、議論中の標準化提案に対
する前向きな意見や提言を持っている人は、次回のIETF84にぜひ参加されてみ
てはいかがでしょうか。

　　　　　◇　　　　　　　　　　 ◇　　　　　　　　　　 ◇

◎関連URI

　- IETF 83 - Paris, France
　　http://www.ietf.org/meeting/83/
　　（IETF83ホームページ）

　- IETF 83 Preliminary & Interim Materials
　　https://datatracker.ietf.org/meeting/83/materials.html
　　（IETF83発表資料一覧）

  - nlnetlabs.nl :: Dnssec-Trigger
　　http://www.nlnetlabs.nl/projects/dnssec-trigger/
　　（Dnssec-Trigger公式ページ）

  - CENTR-Report-IETF83-20120413
　　https://www.centr.org/CENTR-Report-IETF83
　　（CENTRによるIETF83報告）

━━━━━━━━━━━━━━━━━━━━━━━━━━━【FROM JPRS】━
■会議報告：http://jpinfo.jp/event/
■配信先メールアドレスなどの変更：http://jpinfo.jp/mail/henkou.html
■バックナンバー：http://jpinfo.jp/mail/backnumber/
■ご意見・ご要望：from@jprs.jp

当メールマガジンの全文または一部の文章をホームページ、メーリングリスト、
ニュースグループ、他のメディアなどへ許可なく転載することを禁止します。
また、当メールマガジンには第三者のサイトへのリンクが含まれていますが、
リンク先のサイトの内容などについては、JPRSの責任の範囲外であることに
ご注意ください。
その他、ご利用に当たっての注意事項は読者登録規約にてご確認ください。
http://jpinfo.jp/mail/kiyaku.html
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
編集・発行：株式会社日本レジストリサービス（JPRS）
http://jprs.jp/
http://日本レジストリサービス.jp/
Copyright(C), 2012 Japan Registry Services Co., Ltd.