第86回IETF Meeting報告（前編）

第86回IETF Meeting（以下、IETF 86）が、2013年3月10日から15日にかけて米国のオーランドで開催されました。FROM JPRSでは、今回から2回にわたりIETF 86で報告・議論された話題と会議終了後の動向について紹介します。

前編となる今回は、ドメイン名／DNS関連の話題について報告します。

IETFには、dnsextとdnsopという二つのDNS関連ワーキンググループがあります。そのうち、dnsextはDNS Extensionsに由来しており、DNSSECをはじめとするDNSの機能拡張に関する標準化活動を進めるために組織されました。

DNSSECの基本仕様が標準化され実運用が開始されたことを受け、最近のIETFMeetingではdnsext WGは開催されなくなっており、メーリングリストによる議論と、これまでに提案されたインターネットドラフトの標準化作業を進める体制に移行しています。

この方針は2011年3月に開催されたIETF 80で示されました。その後、NSEC3を改良する仕様として提案されたNSEC4について議論するために例外的に開催されたIETF 83を除き、今回のIETF 86を含め、現在までこの方針で運営されています。

なお、dnsext WGは2013年5月をもって終了（shutdown）予定であると発表されています。公式ページ（関連URIを参照）にもあるようにワーキンググループにおけるインターネットドラフトの標準化作業は全て終了しています（*1）。なお、メーリングリストはワーキンググループの終了後も継続される予定です。

ここでは最近のdnsext WGで標準化されたRFCのうち、特に重要な2本について紹介します。

EDNS0の仕様が改訂（RFC 6891）

DNSの拡張仕様の一つであるEDNS0の仕様が改訂され、2013年4月にRFC 6891として発行されました。従来のRFC 2671は廃止（obsolete）になっています。RFC 6891はDNSのバイナリーラベルの仕様を定義したRFC 2673も取り込んでおり、RFC 2671と同様にRFC 2673も廃止（obsolete）になっています。

従来の仕様（RFC 2671）からの主な変更点は以下の通りです。

• OPTレコードのサポートが義務化された。実装しないことを選択した場合、応答として明示的にFORMERRを返すようしなければならない。
• 拡張ラベルタイプの使用が「非推奨」に変更された。
• バイナリーラベルが「歴史的（Historic）」に変更された。
• EDNSのバッファーサイズ選択の方法が変更され、かつ選択方法の推奨（リコメンデーション）が提供されるようになった。

DNSSECの仕様明確化と実装ノート（RFC 6840）

DNSSECの基本仕様（RFC 4033～4035、5155）において不明確であった点を明確化し、DNSSECの実装者向けの注意点をまとめた文書が2013年2月にRFC 6840として発行されました。

RFC 6840は、RFC 4033～4035、5155の一部を更新するためのものであり、問い合わせにおけるADビットの取り扱いなど、従来のRFCでは定義されていなかった新しい仕様も含んでいます。そのため、これからDNSSECを実装する実装者・運用者にとって、基本仕様と共に必須の文書となっています。

dnsopはDNS Operationsに由来しており、DNSの運用における問題点や手法を議論し、運用に関する標準的手法を確立するための活動を進めることを目的として組織されました。

ここでは今回のdnsop WGにおいて議論された主な話題と、最近のdnsop WGで標準化されたRFCのうち、特に重要な2本について紹介します。

DNS in JSON

JSONはJavaScript Object Notationに由来しており、JavaScriptにおけるオブジェクトの表記方法に由来する簡便なデータ記述法をいいます。JSONはJavaScriptに限らず他のソフトウェアやプログラミング言語でも使用可能であり、異なるソフトウェアやプログラム間における汎用的なデータの受け渡しに使えるように設計されています。

今回のIETF 86ではDNSのデータをJSONで記述するための記述法が、AFNICのStephane Bortzmeyer氏から提案されました（draft-bortzmeyer-dns-json）。現在、DNSのデータはいわゆるワイヤーフォーマット（RFCに記述されているビット列形式のデータフォーマット）とゾーンファイル形式のフォーマットで記述されていますが、今回の提案ではそれに加え、JSONでの記述を定義するものです。

会議ではまずJSONによる記述の必要性について確認・合意された後、ドキュメントのレビュアーが募集・確保されました。

Negative Trust Anchors

DNSSEC署名されたゾーンにおいて運用上の事故や設定ミスが発生した場合、DNSSEC検証を有効に設定しているキャッシュDNSサーバーでは、そのゾーンを含むドメイン名の名前検索ができなくなってしまうことがあります。今回のIETF 86では特定のドメイン名配下のDNSSEC検証をキャッシュDNSサーバー側で一時的に無効にするための「ネガティブトラストアンカー」を導入することで、それらの名前が検索できなくなってしまうことを防止するための仕組みが提案されました（draft-livingood-negative-trust-anchors）。

提案者は米Comcast社のJason Livingood氏とChris Griffiths氏です。同社ではDNSSEC検証を有効にしたキャッシュDNSサーバーを他社に先駈けて運用していますが、今回の提案からは同社がしばしば発生しているDNSSEC検証エラーに悩まされており（*2）、これを解決したいという現状がうかがえます。

会議ではこのような仕組みの必要性について確認・合意された後、ドキュメントのレビュアーが募集・確保されました。

DNSSEC信頼の連鎖（DSレコード）維持管理の自動化

DNSSECにおける親子間の信頼の連鎖（chain of trust）は、子が生成・公開したDNSKEY（KSK）情報を親に登録し、親がその情報をDSレコードとして公開することにより構築されます。

現在のDNSSECの運用では、子から親へのKSK情報の登録・更新はDNSの仕組みの外で実行されます。そのため、これをDNSの仕組みの中で実行できるようにするための仕組みが提案されました（draft-kumari-ogud-dnsop-cds）。

提案では「CDS（Child DS）」という新しいリソースレコードを定義しています（*3）。CDSレコードはDSレコードと同一の形式で、子が自分のゾーンで公開します。そして、親は子ゾーンへのDNS問い合わせにより子のCDSレコードを入手し、DSレコードとして公開します（*4）。

KSKの更新（ロールオーバー）はDNSSEC運用において細心の注意を要し、かつミスを誘発しやすい部分でもあります。この提案ではこの部分を自動化することにより、DNSSECの運用コストを低減することを目的としています。

会議では現在のレジストリ・レジストラ間のビジネスモデルとの関係、運用上問題になりうる点の指摘などが行われた後、ドキュメントのレビュアーが募集・確保されました。

DNSSEC運用ガイドラインが改訂（RFC 6781）

DNSSECの運用ガイドラインを定義するRFC 4641が改訂され、2012年12月にRFC 6781として発行されました。

RFC 4641、RFC 6781に共通する特徴として「At the time of (this) writing」という記述が多く見られる点があげられます。これは「（この）文書を書いている時点では」ということを意味しており、いずれの文書ともに「RFCの策定時点における」推奨事項であるという点が重要なポイントとなっています。

今回の改訂ではこれまでに指摘されたエラーの修正、RFCの策定時点における推奨パラメーターの変更（従来のRSA/SHA-1に加え、より推奨されるアルゴリズムとしてRSA/SHA-256を追加など）、推奨される鍵のサイズの変更などが行われています。また、従来は記述が無かったアルゴリズムロールオーバーや、非協力的なDNS運用者の変更に関する記述などが追加されています。

DNSSEC運用ステートメント（RFC 6841）

DNSSEC運用ステートメント（DNSSEC Practice Statements（以下、DPS））を記述するための枠組みが、2013年1月にRFC 6841として発行されました。

DPSは、管理対象ドメイン名におけるDNSSECサービスの安全性や運用のポリシー、考え方、手順などについて網羅的にまとめた文書で、そのドメイン名のDNSSEC運用者が必要に応じて作成・公開します。

DPSにより利用者はそのドメイン名におけるDNSSEC運用ポリシーを把握・評価でき、運用者はDPSを公開することで、自らのDNSSEC運用ポリシーを広く一般に提示できます。JPRSではJPドメイン名におけるDNSSECの運用に先立ち、運用ステートメントをJP DPSとして公開しています。

appsawgは「Applications Area Working Group」に由来しており、アプリケーションエリアの個別ワーキンググループに属さない話題（提案）を取り扱うためのワーキンググループです。

以下、今回のappsawgで報告・議論された話題から、DNS APIとSOPA RRについて報告します。

getdns API

従来からある代表的なDNSのAPIとして、BINDに付属のlibresolv、djbdnsに付属のdns library interface、NLnet Labsが開発したldnsなどがあります。

今回、VPN ConsortiumのPaul Hoffman氏から、現在開発中のgetdns APIの紹介とコメントの募集がありました（*5）。getdns APIはDNSSECに標準で対応し、非同期に動作することで名前解決の際のブロッキングを防止でき、これから定義されるものも含め、DNSの全てのレコード型を容易にサポート可能であるとのことです。

Hoffman氏によるとこのAPIの開発にはブラウザベンダーからの情報やコードの提供もあったということで、既に数カ月にわたる動作実績があるとのことでした。

getdns APIの仕様の詳細については、関連URIのリンクをご参照ください。

SOPA RR

Webブラウザーにおいてクッキーを取り扱う場合、あるドメイン名の「管理主体」の判定が重要になります。もし、クッキーの取り扱いが管理主体をまたいでいた場合、いわゆるクッキーモンスター問題が発生するおそれがあります。

そのため、最近のWebブラウザーでは「Public Suffix List」と呼ばれるリストを使用して、この問題の発生を防いでいます。Public Suffix Listにはクッキーの受け入れを拒否するドメイン名のリストが列挙されており、各Webブラウザーはクッキーの受け入れの際にこのリストを参照することで、不適切なクッキーの受け入れを防いでいます。

現在、Public Suffix ListはWebブラウザーFirefoxを開発しているMozillaFoundationが管理しています。また、このリストは静的なものであり、今後gTLDプログラムなどでgTLDが増加した場合の対応方法など、懸念事項があります。

この問題を解決するための提案（draft-sullivan-domain-origin-assert）が、Dyn, Inc.のAndrew Sullivan氏からありました。提案では管理上の境界（Administrative Boundaries）をDNSのゾーン内に定義するための新しいリソースレコードである、SOPA（Start Of Policy Authorityに由来）を提案しています。

会議の場では仕様についての明確な合意は得られず、継続して議論を進めていくこととなりました。

後編では、ドメイン名／DNS関連以外の話題、全体会議（プレナリー）におけるトピックスなどについてお伝えします。

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