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

メールマガジン「FROM JPRS」

バックナンバー：vol.131

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2013-05-02━
　　　　　　　　　　◆ FROM JPRS 増刊号 vol.131 ◆
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
　　　　　　　　　　　第86回IETF Meeting報告（前編）
　　　　　　　　　～ドメイン名／DNS関連の話題から～
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

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

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

　　　　　◇　　　　　　　　　　 ◇　　　　　　　　　　 ◇

■dnsext WGの動向と最近の標準化状況

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

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

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

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

（*1）2013年4月30日にRFC 6944が発行され、RFC化されていないインターネッ
      トドラフトは残り1本（draft-ietf-dnsext-dnssec-algo-signal：2013
      年5月1日現在、IESGによる評価中）となりました。

ここでは最近の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 WGの動向と最近の標準化状況

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

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

▼DNS in JSON

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

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

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

▼Negative Trust Anchors

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

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

（*2）Comcast社はDNSSEC検証が失敗しているドメイン名の情報を、速報とし
      て公開しています（関連URIを参照）。

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

▼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）。

（*3）CDSレコードのリソースレコードタイプの番号として、IANAから59が割
      り当てられています（関連URIを参照）。

（*4）CDSレコードを公開した時点で子のゾーンがDNSSECにより保護されてい
      ることが前提となります。すなわち、CDSレコードによる自動化の対象
      はKSK情報の更新や削除となります。

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における話題から

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の全てのレコード型を容易にサポート可能であると
のことです。

（*5）その後、2013年4月2日にコメント募集の終了と最初のメジャーバージョ
      ンとなる「getdns April 2013」のリリースが同氏から発表されました。

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

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

▼SOPA RR

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

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

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

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

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

■後編の内容について

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

　　　　　◇　　　　　　　　　　 ◇　　　　　　　　　　 ◇

◎関連URI

　- IETF 86 - Orlando, FL, USA
　　http://www.ietf.org/meeting/86/
　　（IETF86ホームページ）

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

　- DNS Extensions (dnsext) - Charter
　　http://datatracker.ietf.org/wg/dnsext/charter/
　　（dnsext WG公式ページ）

　- Domain Name System Operations (dnsop) - Charter
　　http://datatracker.ietf.org/wg/dnsop/charter/
　　（dnsop WG公式ページ）

　- Comcast DNS | News
　　http://dns.comcast.net/
　　（Comcastが公開しているDNSサーバーの情報、DNSSEC検証失敗情報を含む）

　- Domain Name System (DNS) Parameters
　　http://www.iana.org/assignments/dns-parameters/dns-parameters.xml
　　（DNSパラメーターのレジストリ（IANA））

　- Description of the getdns API
　　http://www.vpnc.org/getdns-api/
　　（getdns APIの仕様）

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

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