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

ドメイン名関連会議報告

2006年

第67回 IETF Meeting 報告（前編）

2006/11/28

第67回IETF（The Internet Engineering Task Force）Meetingが2006年11月5日から11月10日にかけて、アメリカのサンディエゴで開催されました。

PlenaryではIETF Chairから毎回参加人数が報告されますが、それによると今回のIETF Meetingの参加人数は40カ国から1,200人とのことでした。国別では、開催地アメリカからの参加者が半数以上を占め、次いで日本からの参加者が多いという、これまでと同様の傾向でした。

多くのテーマが議論されるIETFの中から、DNSに関する話題について報告します。

会場の外観
会場の外観

DNSEXT（DNS Extensions） WG


DNSEXT WGは、DNSの各機能の拡張に関する議論を行うためのWGです。今回のWGでは、前回からのDNAMEの改善や継続して進められているDNSSECの標準化、新しい提案についての議論が行われました。

▼DNSSEC（DNSのセキュリティ拡張）

DNSSECについては、従来から報告を行っているNSEC3拡張と、標準化が完了したDNSSECbis標準（RFC 4033,4034,4035）の微修正（DNSSECbis update）について議論されました。NSEC3 については、9月に実施されたワークショップの結果を反映し、ほとんどの問題が解決されたことが報告されましたが、DNAMEとNSEC3の関連についての考察が必要であることが指摘され、MLで議論することとなりました。DNSSECbis updateは、DNSSECbis策定後に判明した技術的な不明点・細かな誤りをまとめ、明確化するものです。このドキュメントには、まだ書ききれていない部分があるため、その部分の追加を待ち、標準化することとなりました。

関連URI



▼DNS cookies

DNS cookies提案は、すべてのDNSパケットに送出側・応答側のcookieを追加し、DNS応答の正当性を簡易に検証するという提案で、フルリゾルバへのIPアドレス偽装攻撃の影響や、キャッシュポイズニングの可能性を減らすことを目的としています。今回は、NATの裏に複数のリゾルバがある場合の問題について指摘されました。しかしながらこの案を運用可能なプロトコルとしてまとめることは有意義であるというコンセンサスが得られ、MLで議論を継続することとなりました。

関連URI



▼DNSSEC Signature Only

DNSSECでは、存在する名前についての検証だけではなく、名前が存在しないことも検証する機能を提供しています。存在する名前の連鎖を用いて不存在を証明する方式が標準化済みであり、存在する名前のハッシュの連鎖を用いる方式が前述のNSEC3方式です。不存在証明を実装するコストは大きいため、その不存在証明をやめ、存在する名前の署名検証のみを実施するという提案が「DNSSEC Signature Only」です。この方式では、存在しない名前を検索した場合に署名を返せないため、存在しない名前に虚偽の応答を返された場合には、署名がない応答との区別がつかないという問題があります。この提案について、激しい議論が行われましたが結論がでず、次回のミーティングまでにMLで議論を行い、結論を出すこととなりました。

関連URI



DNSOP（Domain Name System Operations） WG


DNSOP WGは、DNSを運用するにあたっての問題点や手法を議論し、DNS運用に関する標準的手法を確立するためのWGです。今回は、継続中のドキュメントについてのステータス・議論と、数件の新規案件について議論されました。そのうちいくつかの話題について報告します。

▼SPF DoS Exploitation（SPFがDoSを引き起こす危険性）

メールの送信者認証技術であるSPFは、メール送信元ドメイン名のメールサーバのIPアドレスをSPF情報として送信元ドメイン名のDNSサーバに登録しておき、受信側では送信元ドメイン名のDNS検索を行ってIPアドレスがSPF情報に一致するか確認することで送信者を認証する方式です。SPF情報の登録方法は非常に拡張性が高く、転送、参照、マクロ展開などの機能があり、また多くのIPアドレスやホスト名を登録することができます。結果として、一つのアドレスの確認のために10回以上のSPF情報や、ホスト名の検索が必要なことも起こり得ます。そのため、一通のメールのチェックだけで多数のDNS検索が起きる可能性があります。つまり、送信元を詐称した多量のスパムメールを送信することで、受信側でのSPFチェックを誘発し、詐称した送信元のドメイン名に対し多量のDNS検索を起こす可能性があります。チェックを行うことにより、迷惑メール自体は迷惑メールと判定されますが、その過程で受取り先のメールサーバやDNSサーバ、詐称されたドメイン名のDNSサーバへ重い負荷がかかります。そのため、SPFチェックの実装には十分な注意が必要であると指摘されました。DKIMにも同様の懸念があります。議論の結果、DNSを利用するアプリケーションのガイドラインが必要であるということが合意されました。

関連URI



▼DNS Scoped Data Through Attribute Leaves（"_"で始まるラベル）

アンダースコア（_）で始まるラベル（以下、この文書では属性ラベルとします）には、その親ドメイン名へ付随する情報を保持する特別な役割があり、主にSRVやTXT、SPFなどのリソースレコードを記述するために使われます。ところが、その属性ラベルを一括管理するレジストリは存在しておらず、プロトコルごとに定義しているのが現状です。たとえば、SPFであれば"_spf"という属性ラベルを用いることや、SIPでは"_sip._udp"などの属性ラベルを用いることがそれぞれのRFCで記述されています。現在は、RFC標準化の過程のなかで、同じ属性ラベルが別の意味に使われることを防いでいます。この現状に対し、属性ラベルを管理するレジストリの設立が提案されました。どのようにその機能を実現するかについてはこれから議論が必要ですが、WGで議論していくことになりました。

関連URI



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