増刊号
vol.61

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2006-11-24━
                       ◆ FROM JPRS 増刊号 vol.61 ◆
━！ＪＰ━━━━━━━━━━━━━━━━━━━━━━━━━ＪＰＲＳ━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
                       第67回 IETF Meeting 報告（前編）
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

第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

    NSEC3
    http://www3.ietf.org/proceedings/06nov/slides/dnsext-2.pdf
    http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsec3-08.txt

    DNSSECbis update
    http://www3.ietf.org/proceedings/06nov/slides/dnsext-1.pdf
    http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-bis-updates-04.txt

▼DNS cookies

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

◎関連URI

    http://www3.ietf.org/proceedings/06nov/slides/dnsext-0.ppt
    http://www.ietf.org/internet-drafts/draft-eastlake-dnsext-cookies-01.txt

▼DNSSEC Signature Only

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

◎関連URI

    http://www.ietf.org/internet-drafts/draft-stjohns-dnssec-sigonly-00.txt
    http://www3.ietf.org/proceedings/06nov/slides/dnsext-3.pdf

■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

    http://www3.ietf.org/proceedings/06nov/slides/dnsop-2.ppt
    http://www.ietf.org/internet-drafts/draft-otis-spf-dos-exploit-01.txt

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

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

◎関連URI

    http://www3.ietf.org/proceedings/06nov/slides/dnsop-3.ppt
    http://www.ietf.org/internet-drafts/draft-crocker-dns-attrleaf-02.txt

━！ＪＰ━━━━━━━━━━━━━━━━━━━━━━━━━ＪＰＲＳ━━
              編集・発行：株式会社日本レジストリサービス(JPRS)
                            http://jprs.jp/
                            http://日本レジストリサービス.jp/
                会議報告：  http://jpinfo.jp/event/
  メールニュース配信解除：  http://jpinfo.jp/mail/
          ご意見・ご要望：  from@jprs.jp

当メールマガジンの全文または一部の文章をホームページ、メーリングリスト、
ニュースグループまたは他のメディア等へ許可なく転載することを禁止します。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Copyright(C), 2006 Japan Registry Services Co., Ltd. 2006年11月24日