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

メールマガジン「FROM JPRS」

バックナンバー：vol.144

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2014/08/12━
　　　　　　　　　　◆ FROM JPRS 増刊号 vol.144 ◆
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

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

第90回IETF Meeting（以下、IETF 90）が、2014年7月20日から7月25日にかけ
てカナダのトロントで開催されました。FROM JPRSでは今回から2回にわたり、
IETF 90及びそれに合わせて開催された会議における話題について報告します。

前編では、dnsop WGにおける話題のうち、FROM JPRS編集局が特に注目したも
のを中心にお伝えします。

　　　　　◇　　　　　　　　　　 ◇　　　　　　　　　　 ◇

■dnsop WGにおける話題

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

▼チャーターの改定

2014年6月27日付で、dnsop WGのチャーターが改定されました。今回の改定で
は、これまでdnsext WG（*1）で取り扱っていたプロトコル拡張の一部をdnsop
WGで取り扱えるようにするため、「運用上の課題に着目したプロトコルの拡張・
メンテナンス（to address operational issues with the DNS protocols by
extending or performing protocol maintenance on them）」が活動項目に追
加されています。

（*1）DNSSECの標準化作業の完了に伴い、dnsext WGは2013年7月24日に終了し
      ました。ドメイン名関連会議報告「第87回IETF Meeting報告（前編）」
      を参照。
      http://jprs.jp/related-info/event/2013/0905IETF.html

▼ルートゾーンのスケーリング

今回のIETF 90において、よりスケーラブルなルートゾーンの運用を実現する
ための手法（ルートゾーンのスケーリング）に関する次の二つの提案が発表・
議論されました。

▽ルートゾーンの配布（draft-wkumari-dnsop-dist-root）

この提案は、キャッシュDNSサーバーにおいてルートゾーンのコピーを入手・
設定することにより、クライアントへの応答、特に存在しないTLDに対する不
在応答の高速化と、ルートサーバーの負荷軽減を図ろうというものです。

提案でも説明されているように、このコンセプトは目新しいものではなく、イ
ンターネットの黎明期から知られている手法の一つであり、現在でもICANNが
運用しているゾーン転送用サーバー（*2）やルートサーバーの一つである
F-Root（*3）からのゾーン転送を設定し、利用することができます。しかし、
この方法では遅滞なく大規模にルートゾーンを配布することは困難であり、よ
り良い運用技術の導入が必要になります。

（*2）Zone transfer | ICANN DNS Operations
      http://www.dns.icann.org/services/axfr/

（*3）F-Rootでは外部からのゾーン転送を意図的に許可している旨が、運用を
      担当するISCから発表されています。
      https://lists.isc.org/pipermail/bind-users/2004-December/054218.html

そのため、提案ではこの手法を実際のインターネットにおいて、安全かつ実現
可能性のあるものにするための検討を目的としており、文書が議論の出発点で
あること（This document is largely a discussion starting point）が示さ
れています。

会場からは、リフレッシュ（再読み込み）の時間が重要である、問題提起文書
（problem statement）の作成から始めるのはどうか、などのコメントが寄せ
られ、今後も継続して議論を進めていくことになりました。

▽ルートサーバーの再構築（draft-lee-dnsop-scalingroot）

この提案はCNNICのXiaodong Lee氏らから出されたもので、現在のルートゾー
ンの管理手法を変更・再構築することで、よりスケーラブルなルートゾーンの
運用を実現しようというものです。

提案ではその背景として、最初に決められた13のルートサーバーの配置は不平
等（uneven）であること、現在のIP Anycastを用いた分散化ではそれぞれの国／
地域／組織における特殊な要求事項を十分に満たせないことが挙げられている
こと、動機として、IPv6トランスポートの環境ではEDNS0やTCPフォールバック
を用いることなくルートサーバーの数を13から20に増やすことができ、残り七
つのルートサーバーを誰が保持すべきかという問題が解決されるべきであるこ
とが挙げられています。

そして、具体的な手法として、現在のルートサーバーとは別のNSレコードを設
定した「追加版（additional version）」のルートゾーンをIANAが作成し、そ
れを用いたルートサーバーをそれぞれの国／地域／組織がIP Anycastで運用で
きるようにする案、現在のルートサーバーのNSレコードを保持した上で、その
一部を国／地域／組織のルートサーバー用に使う案の二つが示されています。
後者の案では、現在の運用形態との下位互換性が保たれます。いずれの提案も、
ルートゾーンの改ざんや誤用はDNSSECで防御することを前提としています。

この提案は、現在のルートサーバーの運用形態を大幅に変更するものであり、
会場からは多くの反対意見や懸念点が寄せられました。

なお、Lee氏はCNNICのCEO兼CTOを務めており、ccNSO（*4）を代表する立場と
してIANA機能の移行に関する調整のためにICANNに組織されたThe IANA
Stewardship Transition Coordination Group（ICG）のメンバーを務めるなど
（*5）、インターネットガバナンスにおいても重要な役割を担当しています。
このため、提案の背後にある政治的意図を指摘する声も、一部関係者の間で上
がっています（*6）。

（*4）Country Code Names Supporting Organisationの略称。
      ICANNの活動を支える支持組織の一つです。ccTLDの連合体としてICANN
      の他の支持組織や委員会などと協調しながら、ccTLD全体にまたがるグ
      ローバルな課題についてポリシー案を策定し、ICANN理事会に勧告を行
      う役割を担います。

（*5）IANA Stewardship Transition Coordination Group Members
      https://www.icann.org/resources/pages/coordination-group-2014-06-17-en

（*6）Report on IETF 90 Toronto - CENTR
      https://centr.org/system/files/agenda/attachment/centr-report-ietf90-20140801.pdf

▼キャッシュポイズニング攻撃対策

JPRSの藤原和典が、NSレコードを標的とするキャッシュポイズニング攻撃と、
その対策について提案・発表しました（draft-fujiwara-dnsop-poisoning-
measures）。

提案では、NSレコードを標的とするキャッシュポイズニング攻撃の概要を示し
た上で、攻撃中にキャッシュDNSサーバーに多数の偽造応答が到達するため、
その検知が対策に有用であること、攻撃対象を把握するため、それらの偽造応
答のauthority sectionとadditional sectionの内容が重要であることを示し
ました。

そして、対策としてDNSトランスポートにTCPを用いることが有用であるが、問
題点として応答時間の増加とパフォーマンスへの影響が考えられること、その
影響を最小限にとどめるための手法として、攻撃を検知した場合にのみトラン
スポートをTCPに自動的に変更することが有用であることを挙げています。

また、今後提案に追加する予定の項目として、攻撃を検知した際の適切な対応
方法と考えうる追加の対策方法を示し、追加記述すべき有用な対策を集めたい
こと、共著者となる協力者を望んでいることを示しました。

会場からは、DNSSECでも守れること、しかし実際には署名されていないドメイ
ン名が多く、効果は限定的であることなどがコメントされ、今後もメーリング
リストで継続して作業を進めていくことになりました。

▼親ゾーンのレコードの自動更新

前回のIETF 89で合意された、親子関係の構築のために子が親に登録するリ
ソースレコード（DS/DNSKEY、NS/グルー）を、子ゾーンにおいて記述・公開で
きるようにするための提案は、それぞれのレコードの種別ごとに、

  ・DNSSEC関係のレコード（DS/DNSKEY）のためのCDS/CDNSKEYレコード
    （draft-ietf-dnsop-delegation-trust-maintainance）
  ・DNSSEC関係以外のレコード（NS/グルー）のためのCSYNCレコード
    （draft-ietf-dnsop-child-syncronization）

の二つにより標準化され、RFC発行に向けた作業が進められています。現在、
前者はRFC発行待ち（RFC Ed Queue）、後者はIESGによる評価中（IESG
Evaluation）の状態となっています。

いずれも、親側がDNS問い合わせによって子ゾーンにおけるレコードの存在を
チェックし、設定されていた場合に対応する自分のレコードを自動更新すると
いう運用形態が想定されています。

▼AS112プロジェクトの改善

同じく前回のIETF 89で合意された、AS112プロジェクト（*7）の運用をDNAME
レコードで効率化するための提案（draft-ietf-dnsop-as112-dname及び
draft-ietf-dnsop-rfc6304bis）の標準化作業が完了し、RFC発行に向けた作業
が進められています。現在、双方ともIESGによる評価中（IESG Evaluation）
の状態となっています。

（*7）プライベートアドレスやリンクローカルアドレスなど、逆引きゾーンを
      ルートゾーンから委任することでルートサーバーへのDNS問い合わせの
      数を減らし、負荷軽減を図るために始められました。AS112の名前は、
      使われているAS番号に由来しています。

DNAMEレコード（RFC 2672で定義）は、あるドメイン名を、そのサブドメイン
を含めた形で別のドメイン名に対応付けるためのリソースレコードです。
CNAMEレコードでは指定されたドメイン名のみが別のドメイン名に対応付けら
れますが、DNAMEではサブドメイン名の階層構造を保存した形で対応付けられ
ます。例えば、example.jpをexample.comに対応付けるDNAMEレコードが記述さ
れた場合、test.example.jpはtest.example.comに、test.sub.example.jpは
test.sub.example.comにそれぞれ対応付けられることになります。

この方式での運用が開始された場合、AS112を構成する各サーバーノードは
empty.as112.arpaというゾーンのみを管理することとなり（従来は対象となる
各ゾーンを個別管理）、管理対象となる各ゾーンはこのゾーンへのDNAMEとし
て設定されることになります。

■後編の内容について

後編となる次回のFROM JPRS増刊号では、dnsop以外のWG・BOFの状況と、IETF
に併設される形で開催されたIEPG Meetingにおける話題を中心にお伝えします。

　　　　　◇　　　　　　　　　　 ◇　　　　　　　　　　 ◇

◎関連URI

　- IETF 90 - Toronto, Ontario, Canada
　　http://www.ietf.org/meeting/90/
　　（IETF 90公式ページ）

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

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

　- WG Action: Rechartered Domain Name System Operations (dnsop)
　　http://www.ietf.org/mail-archive/web/ietf-announce/current/msg12966.html
　　（dnsop WGチャーター変更のアナウンス）

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

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

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