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

メールマガジン「FROM JPRS」

バックナンバー：vol.137

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2013-12-06━
　　　　　　　　　　◆ FROM JPRS 増刊号 vol.137 ◆
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
　　　　　　　　　　第88回IETF Meeting報告（前編）　　　　　　　　　　
                      ～DNS関連WGにおける話題～                      
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

第88回IETF Meeting（以下、IETF 88）が、2013年11月3日から11月8日にかけ
てカナダのバンクーバーで開催されました。FROM JPRSでは今回から2回にわた
り、IETF 88及びそれに合わせて開催された会議で報告・議論された内容につ
いて紹介します。

前編となる今回はDNS関連WGにおける話題として、dnsop WG とdnssd WGの状況
をお伝えします。

　　　　　◇　　　　　　　　　　 ◇　　　　　　　　　　 ◇

■dnsop WGにおける話題

dnsopはDNS Operationsに由来しており、DNSサーバーや登録情報の管理など、
DNSの運用全般におけるガイドラインの開発を目的として組織されています。

ここでは今回のdnsop WGにおいて議論された話題のうち、FROM JPRSが特に注
目したものについてお伝えします。

▼子から親へのリソースレコードの同期

前回のIETF 87から継続して議論されている、DNSにおける親子間の関係を構築
するために親ゾーンに登録されるリソースレコード（DS、NS、グルー）を、子
ゾーンにおいて記述・公開するための複数の提案が議論されました。

本件についてはこれまで、CDSとCSYNCという二つの提案が議論されてきました。
今回はそれに加え、レジストリ・レジストラモデルにおいてDynamic Update
（*1）経由でこれらのリソースレコードを登録するための新たな提案が議論さ
れました。

（*1）RFC 2136により定義される、クライアントからの依頼により権威DNS
      サーバーが管理するゾーン情報を動的に更新するための拡張機能。

今回議論された三つの提案の概要を以下に示します。

1）CDS/CDNSKEY（draft-kumari-ogud-dnsop-cds）

  CDS/CDNSKEY（Child DS/Child DNSKEY）というリソースレコードを新たに定
  義し、これらのリソースレコードを用いて更新対象となるDS/DNSKEYリソー
  スレコードを、子のゾーン頂点に記述します。

2）CSYNC（draft-hardaker-dnsop-csync）

  CSYNC（Child To Parent Synchronization）というリソースレコードを新た
  に定義し、このリソースレコードを用いて更新対象となるNS/グルーレコー
  ドを、子のゾーン頂点に記述します。

  前回のIETF 87以降の調整によりDNSSEC関係のリソースレコードはCSYNCの対
  象から外され、NSとグルーをその対象とすることになりました。

3）Dynamic Update（draft-andrews-dnsop-update-parent-zones）

  レジストリ・レジストラモデルにおいてレジストラが登録者からリソースレ
  コードの書き換えを受け付ける際、Dynamic Updateを使用してリクエストを
  受け付けます。登録者の認証は、レジストラが登録者にTSIG（*2）の鍵を発
  行することで実施します。

（*2）RFC 2845により定義される、共有鍵を使用した認証技術による送信元の
      認証と、通信路における改ざんの検知を可能にするための拡張機能。

会議では、Dynamic Updateが採用しているプッシュ型（登録者から能動的に更
新を伝達）の機構についても議論内容に含めた上で、今後も継続して検討を進
めていくことになりました。

▼バリデーターの増加に伴うDS問い合わせ数の増加とその対応

DNSSECの普及促進を図る際にTLDにおいて特に問題となりうる、バリデーター
の増加に伴うDS問い合わせ数の増加とその対応について、JPRSの藤原が発表を
行いました（draft-fujiwara-ds-query-increased）。

DNSSEC普及の初期段階ではDNSSECに対応しているドメイン名の数が少ないため、
TLDゾーンにおけるDSレコードの登録数も少なくなります。この状況ではTLDの
権威DNSサーバーに到達するDSレコードの問い合わせの多くが不在応答（その
リソースレコードは存在しない）となり、この応答のキャッシュとして、TLD
ゾーンのネガティブキャッシュのTTLが使用されます。

.jpゾーンでは、この値は900（15分）に設定されています（*3）。そのため、

1）DNSSECに対応していない（DSレコードが登録されていない）
2）かつ、頻繁にアクセスされる（例：毎秒1回以上）
3）かつ、A/AAAAレコードのTTLが900よりも短い（例：300）

という三つの条件を満たしたドメイン名の場合、バリデーターからTLDの権威
DNSサーバーへのDSレコードの問い合わせが、最短の場合15分に1回という短い
間隔で発生することになります（*4）。

（*3）■JP DNSの設定変更について（2006年2月20日）
      http://jprs.jp/tech/dnsuis/info001.html

（*4）DNSSECに対応した（DSレコードが登録された）ドメイン名ではDSレコー
      ドのTTLが適用されるため、この間隔はより長いものとなります（.jp
      ゾーンの場合2時間に1回）。

藤原からは、将来のバリデーターの数の増加によりTLDの権威DNSサーバーへの
DSレコードの問い合わせ数が急増し、TLDの権威DNSサーバーの負荷やネット
ワークの帯域が増大する可能性があることを指摘しました。

そして、その対策として

  ・負荷の増大に対応するための回線や機材を増強する
  ・TLDのネガティブキャッシュのTTLを長くする
  ・そのTLD内においてDNSSECに対応したドメイン名の数を増やす

といったもののほか、安全でない委任（unsecure delegation）を明示的に定
義するためにDSレコードにおいて新しいダイジェストタイプを追加する案を示
した上で、有効な対策方法について会場の参加者にコメントを求めました。

会場からは、DNSSEC対応を促進するためにDNSSEC対応／未対応のドメイン名で
価格差をつけるのが有効ではないかというコメントや、Google Public DNSで
は未知のダイジェストタイプを持つDSレコードを設定したドメイン名が
DNSSEC検証エラーになったという報告がありました。

また、WGチェアから藤原に対し、本件については現時点では問題が顕在化して
いないが将来のために文書化しておくことが重要であり、今回コメントを受け
た問題点とその対応策について文書に反映・更新するように、という指示があ
り、今後も文書の更新作業を進めていくことになりました。

▼AS112プロジェクトの改善案

AS112プロジェクト（以下、AS112）は、インターネット上には存在しないプラ
イベートアドレスやリンクローカルなどの逆引きゾーンをルートゾーンから委
任することにより、本来送られるべきではない不正なDNS問い合わせをルート
サーバーから分離するために始められました。

AS112では、IP Anycastを用いたサーバーノードの冗長化が採用されています。
しかし、権威DNSサーバーにおける通常のIP Anycastとは異なり管理対象の
ゾーン情報が構成するノード間で同期されておらず（*5）、対象となるゾーン
が追加された場合に個々のノードにおいて速やかにゾーンを設定・公開するこ
とが難しいという問題点が指摘されていました。

（*5）AS112の運用について記述したRFC 6304において「緩やかに調整され独
      立に運用されている権威DNSサーバーの集合体（a loosely
      coordinated collection of independently operated nameservers）」
      と説明されています。

そこで、親ゾーンにおいて対象のゾーンを委任する代わりにDNAMEレコードを
設定することでこの問題を解決する提案が示され、前回のIETF 87において実
環境への適用を進めていくことが合意されました。この提案が実現された場合
AS112を構成するノードではempty.as112.arpaというゾーンのみが管理され、
対象となるゾーンはこのゾーンへのDNAMEとして設定されます。

会議では前回の合意に従い、提案文書を更新したことが報告されました
（draft-jabley-dnsop-as112-dname）。今後この文書はWGドキュメントとして、
6304bis（RFC 6304の更新版）の名で更新作業を進めていくことになりました。

■dnssd WGにおける話題

前回のIETF 87でdnssdext BOFとして開催されたdnssdが、2013年10月25日付で
正式なWGとして発足しました。

dnssdはExtensions for Scalable DNS Service Discovery（スケーラブルな
DNSサービス発見のための拡張）に由来しており、DNSを用いたservice
discovery（サービス発見：提供可能なサービスを検索・通知する手法、
DNS-SDとしてRFC 6763で定義）の仕様を拡張し、企業や大学などといった大規
模なネットワークにおいても動作可能にするための手法を標準化することを目
的としています。

今回のdnssd WGでは当面の目的であるDNS-SDとRFC 6762で定義される
Multicast DNS（以下、mDNS）を、現在運用されているDNSと共存しうる形で拡
張するために必要な各項目についての議論が進められました。

▼ローカルな名前解決のためのTLDの予約

DNS-SDや組織内におけるローカルな名前解決を円滑に実施するためには、ロー
カルな（インターネット上に存在しないことが保証されている）TLDを使用す
ることが有効な手段となります（*6）。

（*6）現在のDNS-SD（RFC 6763）ではこのためのTLDとして、.localが採用さ
      れています。

会議では今後標準化を進める拡張規格において、このTLDをどのように選択・
決定するかについて議論されました。会場からは、

  ・現在の.localを転用する
  ・新しいTLDを予約する
  ・TLDではなくSLDを使用する

などの候補が挙げられましたが結論には至らず、今後も継続して検討を進める
ことになりました。

▼スケーラブルなDNS-SD／mDNSの拡張

DNS-SD／mDNSを拡張するために必要となる要件定義の項目について発表・議論
されました（draft-lynn-dnssd-requirements）。

発表では、

  ・同一リンク内からインターネットまでの名前解決に対応すること
  ・使いやすいこと（Usability）
  ・スケーラブルであること（Scalability）
  ・段階的な普及、小型デバイスでも動作し、大規模な機器を必要としないと
    いった、普及可能性（Deployability）
  ・使用するにあたっての安全性（Security）

などが項目として示され、その後の議論において、既存のDNS-SD/mDNSに悪影
響を及ぼさないことも要求事項とされました。議論の結果、要件定義について
今後WGとして検討を進めていくことが合意されました。

▼国際化ドメイン名の表現形式

DNS-SDの現在の規格（RFC 6763）では国際化ドメイン名の表現形式として
U-Labelを使用することが推奨されており、DNS問い合わせに対し不在応答が返
された場合、クライアントソフトウェアは当該のU-LabelをASCII互換形式の
A-Labelにより再問い合わせを実行してもよいと定められています（*7）。

（*7）国際化ドメイン名（IDN）において、正規化されたUnicodeによる表現を
      U-Label、ASCII互換形式による表現をA-Labelと呼びます。例えば
      「ドメイン名例.jp」というU-Labelに対応するA-Labelは
      「xn--eckwd4c7cu47r2wf.jp」となります。

この手法を広域ネットワークにおいてそのまま使用した場合、インターネット
上のDNSサーバーに対するU-Labelによる問い合わせが発生し、DNSの運用に悪
影響を及ぼす可能性があります。

会議では、拡張規格において国際化ドメイン名の表現形式をどのように定義す
べきかという問題提起がされました（draft-sullivan-dnssd-label-miprofile）。
会議では、DNS-SDのAPIにおいてU-LabelをA-Labelに変換するなどのアイディ
アが出されましたが結論には至らず、今後も継続して検討を進めることになり
ました。

■後編の内容について

後編となる次回のFROM JPRS増刊号では、DNS関連以外のWGにおいて議論された
注目すべき話題、IETFに併設される形で開催されたIEPG Meetingにおける話題
についてお伝えします。

　　　　　◇　　　　　　　　　　 ◇　　　　　　　　　　 ◇

◎関連URI

　- IETF 88 - Vancouver, BC, Canada
　　http://www.ietf.org/meeting/88/
　　（IETF 88ホームページ）

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

  - WG Action: Formed Extensions for Scalable DNS Service Discovery
　  (dnssd)
    http://www.ietf.org/mail-archive/web/ietf-announce/current/msg12051.html
    （dnssd WG創設のアナウンス）

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

  - Extensions for Scalable DNS Service Discovery (dnssd) - Charter
    http://datatracker.ietf.org/wg/dnssd/charter/
    （dnssd WG公式ページ）

　　　　登録に心当たりのない方、今後配信を希望されない方は
　　　　　下記をクリックしてください。登録が解除されます。
　　　　　　http://from.jprs.jp/d.x?u=382&k=b778AD

━━━━━━━━━━━━━━━━━━━━━━━━━━━【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.