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

ドメイン名関連会議報告

2006年

第66回 IETF Meeting 報告（前編）

～DNS関連テーマ報告～

2006/08/01

第66回IETF（The Internet Engineering Task Force） Meetingが2006年7月9日から7月14日にかけて、カナダのモントリオールで開催されました。

PlenaryではIETF Chairから毎回参加人数が報告されますが、それによると今回のIETF Meetingの参加人数は44カ国から1,236人とのことでした。アメリカからの参加者が半数を切り、中国からの参加者が増加していたのが特徴的です。
国別では、アメリカ、日本、カナダに次いで第4位でした。

多くのテーマが議論されるIETFの中から、前編ではDNSに関する話題を、後編ではEAI（Email Address Internationalization）、ENUM（Telephone Number Mapping）に関する話題と、IETFに併設して開催されたIEPG（Internet Engineering Planning Group）の様子をお届けします。

会場の外観
会場の外観

今回のIETFにおけるDNS関連の会議では、後述するようにDNSの再帰的な問い合わせを使ったDDoS攻撃に関する話題がそれぞれ取り上げられていました。参考のために、関連情報を先に示しておきます。

関連ドキュメント



DNSEXT（DNS Extensions） WG


DNSEXT WGは、DNSの各機能の拡張に関する議論を行うためのWGです。本WGでは、DNSのセキュリティ拡張を行うDNSSECの標準化作業を重点的に行っていますが、前回に引き続き実運用に必要となる機能拡張についての話題も議論されました。

・DNSSEC

DNSSECについては、zone enumeration問題（第65回IETF Meeting報告参照）を解決するNSEC3拡張と、DNSSECで用いる信頼鍵の自動更新の議論が行われました。NSEC3についても進展はありましたが、今回は信頼鍵の自動更新について報告します。DNSSECでは、信頼の起点となる鍵をDNSSEC検証を行うすべての検証DNSサーバに登録しておく必要があります。また、DNSSECでは、安全のためにすべてのゾーンの鍵情報を定期的に更新しますが、すべての検証DNSサーバに登録されている信頼の起点となる鍵も例外ではなく定期的に更新されます。
その時に、すべての検証DNSサーバの管理者が手作業で鍵更新を行うことは現実的ではありません。そこで、この鍵更新を自動化することが検討されています。今回、信頼の起点となるゾーンを定期的にチェックして鍵の更新情報を得るというタイマー方式の鍵更新方式を進めることが合意されました。全体として、DNSSECプロトコルの確定にはまだしばらくかかりそうですが、決ればすぐに実用化しようという熱気が感じられました。

関連URI



関連ドキュメント



・DNAME

DNAMEとは、ドメイン名を、そのサブドメイン名空間すべてを含んだ単位で別のドメイン名に対応づけるリソースレコードです。たとえば、example.jpをexample.comに対応づけるDNAMEリソースレコードを記述すると、example.jpに属するドメイン名のtest.example.jpは、DNS検索時にtest.example.comに対応づけられます。それに対し、CNAMEは一つの完全なドメイン名を別の完全なド メイン名に対応づけます。

最近、ICANNにおいて、国際化TLDの議論が行われており、その実装案の一つとしてDNAMEを用いることが提案されています。IETFには、DNAMEの問題点を洗い出し、問題を修正することが要求されています。そこで、今回、その作業を開始することが宣言され、問題点リストの説明が行われました。今後、議論を行い、DNAMEプロトコルの修正を行うこととなりました。

関連ドキュメント



・DNS cookies

DNSの再帰的な問い合わせを使ったDDoS攻撃やキャッシュ汚染の対策案としてDNS cookiesという提案がありました。この提案は、すべてのDNSパケットに検索側のDNSサーバ・応答側のDNSサーバを識別する識別子を挿入し、必要があれば過去の識別子と比較することで、偽造されたDNS検索・DNS応答を検出するというものです。この提案については、多くの人が関心を持っていますが、運用上の問題を解決することを目的としているため、運用者側からのフィードバックを取り入れ、議論を継続することとなりました。

関連ドキュメント



DNSOP（Domain Name System Operations） WG

DNSOP WGは、DNSを運用するにあたっての問題点や手法を議論し、DNS運用に関する標準的手法を確立するためのWGです。

今回の会議では、DNSの再帰的な問い合わせを使ったDDoS攻撃の対策を示す文書、プライベートアドレスのDNS逆引きゾーンを複数の組織でIP Anycast技術を用いて提供しているAS112プロジェクトの運用ガイドライン、DNSの問い合わせ結果を保持する期間であるTTLの推奨値、WGのチャーターなどについて議論されました。

DNSの再帰的な問い合わせを使ったDDoS攻撃の対策文書は、当該攻撃の手口と、攻撃の踏み台として誰でも使用できる状態となっているフルリゾルバDNSサーバが用いられることを述べ、フルリゾルバDNSサーバでの推奨される設定について提案しています。会議では、文書の取り扱う範囲や、招かれざるDNS検索への応答、TSIG/SIG(0)などの認証つきの検索を推奨するかについて議論されました。メーリングリストの議論ののちに、運用ガイドラインとしてのRFC化を素早く進めるということとなりました。

関連ドキュメント



AS112プロジェクトは、Root DNSサーバと似た運用形態のため、Rootと同様の運用ガイドラインが必要かどうかという提案がありました。WGの作業項目とするかはMLで議論して決めることとなりました。

関連ドキュメント



TTLについては、現在いくつかのTLDで例えば0や3600などの短い値を用いて運用を行っていますが、1日や3日、1週間といった長めの値を推奨すべきであるという提案がありました。議論の結果、長いTTLを推奨とすることはできないが、長いTTLのトレードオフについてのドキュメントを作成することが合意されました。

関連ドキュメント



WGのチャーターについては、前回のミーティングでほぼ合意されていましたが、今回、DNSについてのパフォーマンス・ベンチマークについての方法・用語についての議論を追加する提案が行われ、合意されました。

本会議報告は、JPRSのメールマガジン「FROM JPRS」の増刊号として発行した情報に写真などを交えてWebページ化したものです。
「FROM JPRS」にご登録いただいた皆さまには、いち早く情報をお届けしております。ぜひご登録ください。