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

メールマガジン「FROM JPRS」

バックナンバー：vol.155

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2015/08/20━
                    ◆ FROM JPRS 増刊号 vol.155 ◆
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
                    第93回IETF Meeting報告（前編）
                 ～dnsop WG／eppext WGにおける話題～
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2015年7月19日から24日にかけて、第93回IETF Meeting（以下、IETF 93）が
チェコのプラハで開催されました。FROM JPRSでは今回から前編と後編の2回に
わたり、IETF 93の内容について報告します。

今回のFROM JPRSでは、以下の項目に沿ってポイントとなった話題をお伝えし
ます。

（前編）
  ・dnsop WGにおける話題
    - 特殊な名前の取り扱い
    - NSEC/NSEC3の積極的な活用
    - 標準化作業の進行状況
  ・eppext WGにおける話題
    - DNS運用者間におけるDNSSEC鍵の引き継ぎ

（後編）
  ・dprive WGにおける話題
    - DNS over DTLS
    - TLS for DNS
    - パディングオプション
  ・IETF全般における話題
    - エドワード・スノーデン氏の登場
    - ITU事務総局長がTechnical Plenaryに登壇
  ・次回のIETF 94は横浜で開催

          ◇                     ◇                     ◇

■dnsop WGにおける話題

dnsopはDNS Operationsに由来しており、DNSサーバーや登録情報の管理など、
DNSの運用全般に関するガイドラインの作成を目的として設置されました。現
在では、DNSの運用上の課題に着目したプロトコル拡張・メンテナンス全般に
ついても、WGの活動項目の一つとなっています。

▼特殊な名前の取り扱い

今回のdnsop WGでは、例示用ドメイン名のexample.comなど特殊な名前
（special names）の取り扱いが主要な話題の一つとなりました。そのきっか
けとなったのは、前回の第92回IETF Meeting（以下、IETF 92）で議論された
.onion（*1）の予約に関する提案（draft-ietf-dnsop-onion-tld）でした（*2）。

（*1）.onionはTor（トーア）で使われている内部利用名です。

（*2）本件の詳細については、第92回IETF Meeting報告（後編）を参照。
      http://jprs.jp/related-info/event/2015/0424IETF.html

.onionの予約については、IETF 92終了後の2015年5月に開催された関係者によ
る臨時のミーティングで、他の名前とは独立させて作業を進めることが合意さ
れました（影響の大きさを考慮し、特殊用途ドメイン名（Special-Use Domain
Names）の一つとして予約）。本件は既にWGでの作業を完了しており、
Proposed Standard（標準化への提唱）RFCでの標準化が予定されています。

▽RFC 6761の問題点の洗い出し

今回の.onionの件によって、特殊な名前の予約のための標準的な基準・プロセ
スが明確になっていないという問題点が、改めて浮き彫りになりました。そし
て、この問題を集中的に取り扱うため、関係者を集めた少人数のデザインチー
ムが別途組織されることになりました。

インターネット全体で予約される特殊な名前に関する現在の基準・考慮点は、
RFC 6761で定義されています（*3）。今回のWGではデザインチームへのイン
プットとするため、RFC 6761に存在する既存の問題点の洗い出しが進められま
した。

（*3）RFC 6761は米国Apple社が開発したBonjour（*4）の仕様の一部を構成し
      ています。そのため、RFC 6761がBonjourで使われる.localを同社が合
      法的にサイバースクワッティングするための手段として利用されたので
      はないかという批判が一部関係者の間で上がりました（*5）。

（*4）人手による操作を介さず、かつDHCPサーバーやDNSサーバーなどの設定
      用のサーバーを使うことなくIPネットワークに接続された機器に必要な
      情報を設定する、Zeroconfという技術の実装の一つ。

（*5）Report on IETF 93 Prague
      https://centr.org/system/files/share/centr-report-ietf93-20150803_0.pdf

WGでは、今後デザインチームで議論が必要な問題点として、

  ・標準化課程（Standards Track）とすべきか、IESGによる決定とすべきか
  ・誰が評価作業を実行すべきか（IESGか、dnsop WGか、WGを別に作るか）
  ・予約結果を事前に外部に漏らさないことをどう担保するか
  ・RFC 6761で挙げられている考慮すべき七つのカテゴリー（*6）は適切か
  ・予約解除のプロセスは必要か
  ・DNS以外の名前空間（*7）の考慮はどの程度必要か
  ・ICANNとのコーディネーションが必要な項目は何か
  ・RFC 6761はTLD以外の予約も考慮しているが、それはどう扱うのか
  ・IETFがプロトコルの分析以上のことを実行できるのか

などが挙げられ、検討が進められることとなりました。しかし、.onionに続く
TLDの予約をWGとして進めることについては、会場は否定的な雰囲気でした。

（*6）RFC 6761では、予約を考慮する際に考慮すべきカテゴリーとして以下
      の七つを挙げています。
      1. 利用者（Users）
      2. アプリケーションソフトウェア（Application Software）
      3. 名前解決のAPI・ライブラリ（Name Resolution APIs and Libraries）
      4. リゾルバー（キャッシュDNSサーバー）（Caching DNS Servers）
      5. 権威DNSサーバー（Authoritative DNS Servers）
      6. DNSサーバー運用者（DNS Server Operators）
      7. レジストリ・レジストラ（DNS Registries/Registrars）

（*7）.localはDNSとは別の名前空間・別のポート番号を持つ、Multicast
      DNS（RFC 6762）での使用を目的として予約されています。

▼NSEC/NSEC3の積極的な活用

JPRSの藤原が、DNSSECの不在証明の仕組みをより積極的に活用することで、
DNS水責め攻撃（*8）の影響緩和を図る提案を発表しました（draft-
fujiwara-dnsop-nsec-aggressiveuse）。

（*8）DNS水責め攻撃の詳細についてはJPRSトピックス&コラム No.21
      「Bot経由でDNSサーバーを広く薄く攻撃 ～DNS水責め攻撃の概要と対
      策～」を参照。
      http://jprs.jp/related-info/guide/021.pdf

本提案では、応答されたNSEC/NSEC3レコードのキャッシュをより積極的に活用
することで権威DNSサーバーへの問い合わせ数を減らすと共に、リゾルバーの
処理コストを軽減させ、DNS水責め攻撃の影響緩和を図っています。

今回の提案は前回のIETF 92で藤原が発表したものの更新版となっており、WG
では更新部分（問い合わせにおけるAN（Aggressive Negative caching）フラ
グの追加、CDビットの取り扱いに関する考慮の追加）の内容を中心に議論され
ました。

本提案については、今後も継続して議論を進めていくことになりました。

▼標準化作業の進行状況

dnsop WGではここ数年間に数多くの提案と標準化作業が進められ、その一部に
ついてはWGでの作業を完了しています。ここでは、最近の提案の内容と標準化
作業の進行状況について、簡単に紹介します。

▽DNSSECの鍵更新（ロールオーバー）のタイミングに関する諸問題（draft-
  ietf-dnsop-dnssec-key-timing）

DNSSECの鍵更新（ロールオーバー）では、それぞれの手法・段階ごとに細心の
注意を払った操作・運用が必要になります。実際、これまでにTLDを含むいく
つかのドメイン名において、ロールオーバーの失敗による運用ミスの発生が報
告されています。

本提案はDNSSECの鍵更新（ロールオーバー）の各形式について、手法・タイム
ライン・アルゴリズムなどの考慮点についてまとめ、考察したものです。

本提案はInformational（情報提供）RFCとして、発行待ち（RFC Ed Queue）の
状態となっています。

▽ネガティブトラストアンカー（draft-ietf-dnsop-negative-trust-anchors）

DNSSEC署名されたゾーンにおいて運用上の事故や設定ミスが発生した場合、
DNSSEC検証を有効に設定しているリゾルバーでは、そのゾーンを含むすべての
ドメイン名の名前検索ができなくなってしまう場合があります。

ネガティブトラストアンカーは、特定のドメイン名配下のDNSSEC検証をリゾル
バー側で一時的に無効にすることで、こうした事故が発生した場合に該当する
名前が検索できなくなってしまうことを防止するための仕組みです。

本提案はInformational（情報提供）RFCとして、発行待ち（RFC Ed Queue）の
状態となっています。なお、ネガティブトラストアンカーの機能は主要なリゾ
ルバーには既に実装されており、現在の提案文書にはUnbound、BIND（*9）、
Nominum Vantioにおける設定例が記述されています。

（*9）次のメジャーバージョンであるBIND 9.11で実装予定。

▽ルートゾーンのコピーの配布と設定（draft-ietf-dnsop-root-loopback）

よりスケーラブルなルートゾーンの運用を実現する手法の一つとして、各リゾ
ルバーのループバックアドレスでルートゾーンのコピーを保持する権威DNS
サーバーを動作させ、名前解決に利用する提案です。

本提案はIETF 92終了後の2015年6月26日にWGでの作業を終了し、
Informational RFCとして、発行に向けた作業が進められています。

▽DNS用語の明確化（draft-ietf-dnsop-dns-terminology）

これまでに発行されたDNS関連のRFCで定義されたさまざまな用語を一つのド
キュメントにまとめ、明確化するための提案です。なお、本提案はJPRSの藤原
が共著者となっています。

本提案はIETF 92終了後の2015年6月24日にWGでの作業を終了し、
Informational RFCとして、発行に向けた作業が進められています。

▽問い合わせ名の最小化（draft-ietf-dnsop-qname-minimisation）

フルリゾルバーが非再帰問い合わせを実行する際のアルゴリズムを変更するこ
とで権威DNSサーバーに送信する情報量を減らし、利用者がどんな名前を問い
合わせたかを外部から推測されにくくするための提案です。

本提案はIETF 93直前の2015年7月13日にWG内の合意事項となり、WG Last Call
で出されたコメントを反映する作業が進められています。なお、本提案は
Experimental（実験仕様）RFCとして発行される予定です。

■eppext WGにおける話題

eppextはEPP Extensionsに由来しており、レジストリ・レジストラ間の登録情
報のやりとりに用いられるEPP（Extensible Provisioning Protocol）の機能
拡張を目的として組織されています。

▼DNS運用者間におけるDNSSEC鍵の引き継ぎ

DNSSECによる保護を維持しながらドメイン名のDNS運用者を変更する場合、変
更元と変更先のDNS運用者が協力・連携する形でDNSSECに用いる鍵（以下、
DNSSEC鍵）の引き継ぎを含む、所定の手順を実施する必要があります。

しかし、実際のインターネットにおけるレジストラ間のドメイン名の移転（い
わゆるドメイン名の引っ越し）では、変更元と変更先のDNS運用者は直接のや
りとりを実施しない、いわゆる「非協力的なDNS運用者（Non-Cooperating DNS
Operators）」の関係にあることが多く、DNSSECの円滑な運用と普及を妨げる
要因の一つとなっていました。

そのため、EPPを拡張してレジストラ間でのDNSSEC鍵の引き継ぎをレジストリ
経由で実現することで、この問題を解決する提案が発表されました（draft-
ietf-eppext-keyrelay）。

本提案は2013年1月に初版が発表され、オランダ（.nl）のccTLDレジストリで
あるSIDNにおいて、レジストリシステムへの実装と運用実験が進められました
（*10）。その後、2014年1月にWG Draftとなり、SIDNでの運用経験やWG参加者
からのフィードバックを取り入れる形で改良が続けられました。

（*10）SIDN Labsからホワイトペーパーとして公開されています（関連URIを
       参照）。

その結果、IETF 93終了後の2015年7月24日にWGでの作業完了に向けたWG Last
Callが開始されました。本提案はProposed Standardでの標準化が予定されて
います。

          ◇                     ◇                     ◇

◎関連URI

  - 93 Meeting Index
    https://www.ietf.org/meeting/93/
    （IETF 93公式ページ）

  - IETF 93 meeting materials
    https://datatracker.ietf.org/meeting/93/materials.html
    （IETF 93発表資料一覧）

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

  - Extensible Provisioning Protocol Extensions (eppext)
    https://datatracker.ietf.org/wg/eppext/charter/
    （eppext WG公式ページ）

  - EPP keyrelay: solving the last obstacle for DNSSEC deployment
    https://www.sidn.nl/downloads/whitepapers/wp_2013_EPP-keyrelay_v1.en.pdf
    （SIDN Labsのホワイトペーパー、EPP keyrelayの実装について記述）

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

当メールマガジンは、Windowsをお使いの方はMSゴシック、Macをお使いの方は
Osaka等幅などの「等幅フォント」で最適にご覧いただけます。

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

※更新履歴
2015/8/25　一部修正