ドメイン名関連会議報告
2014年
第90回IETF Meeting報告(前編)
~dnsop WGにおける話題~
2014/08/12
第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)。
dnsop WGで発表するJPRS藤原
提案では、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における話題を中心にお伝えします。
本会議報告は、JPRSのメールマガジン「FROM JPRS」の増刊号として発行した情報に写真などを交えてWebページ化したものです。
「FROM JPRS」にご登録いただいた皆さまには、いち早く情報をお届けしております。ぜひご登録ください。