メインコンテンツへジャンプする

JPNICはインターネットの円滑な運営を支えるための組織です

ロゴ:JPNIC

WHOIS 検索 サイト内検索 WHOISとは? JPNIC WHOIS Gateway
WHOIS検索 サイト内検索

ニュースレターNo.41/2009年3月発行

DNS関連WG報告

dnsext WG(DNS Extensions WG)報告

前回に引き続き、今回の第73回IETFにおいても、dnsextWGの会合が開催されました。まずいつも通りに、Internet-Draftの状態確認が行われました。draft-ietf-dnsext-forgeryresilienceやdraft-ietf-dnsext-dnssec-rsasha256といった文章は、前回のIETF会合の後に更新版が発行されました。その他の文書は特に更新は無く、進捗が無いことの確認が行われただけでした。

今回のdnsext WGの会合にて最も時間をかけて議論されたのは、やはりforgery-resilienceでした。騙されにくくするためのテクニックとして、DNS ping、0x20 entropy、RTTBandingといったものが紹介され、この中でも0x20 entropyの手法が一番害も無く、かつ騙されにくくできるのではという、これまでの議論のまとめがありました。また、キャッシュの上書きを禁止する条件や、CNAME、DNAMEの連鎖のさらなる検証、複数回の試行によるデータの検証といったテクニックも紹介されました。これらは今までの議論の中で出てきたものです。TCPでのDNS応答という提案もありましたが、できるだけ避けるべきと結論付けられました。

また、上記で紹介されたテクニックは、いずれも特効薬となるものではないのに、これらのテクニックを導入したら、ますますDNSSECの普及が阻害されるのではないかという意見も出されました。その一方で、何もしないのは現実的な解決策ではないといった意見も出され、結局まとまることはありませんでした。このInternet-Draft自体は、これらの選択肢をまとめた後に更新され、IETF Last Callが完了した段階となっています。

新たなInternet-Draftとしては、draft-bellis-dnsextdnsproxyの紹介がありました。この文章は、ブロードバンドルータ等にDNS Proxyを実装するにあたっての注意事項や、セキュリティ上留意する点についてまとめられた文章です。会場内でWG draftとすることの合意がとられ、その後draftietf-dnsext-dnsproxyとして発行されました。

また、draft-bagnulo-behave-dns64に関する発表もありました。これは、IPv6/IPv4トランスレータ用DNSの挙動を定義した文章ですが、特に新しい着眼点があるわけでもなく、あまり建設的な意見が出ることなく途中で時間切れとなりました。なお、発表の続きは、dnsop WGの会合にて行われることとなりました。

dnsop WG(Domain Name System Operations WG)報告

dnsop WGの会合は、2時間の枠で開催されました。まずいつも通り、Internet-Draftの状態確認が行われました。前回のIETFからの進捗としては、draft-ietf-dnsop-reflectors-are-evliがRFC5358として発行されました。また、draft-ietf-dnsopdefault-local-zonesやdraft-ietf-dnsop-reverse-mappingconsiderations、draft-ietf-dnsop-name-server-managementreqsもWG Last Callの段階であることが確認されました。

draft-jabley-dnsop-missing-mnameについては、dynamicupdateによってDNS管理者が困っている状況があるか、ということがRoot DNSオペレータに確認されました。その結果、あまり困っているわけではないという回答があったため、特にLast Callをかけること無く、一旦保留することが確認されました。その他、draft-ietf-dnsop-respsizeがWG Last Callされることが決まりました。

dnsop WG自体としては、今回は特に新しい話題はありませんでした。今までのInternet-Draftの確認が主な議題でした。一方、dnsop WG自体の議題ではありませんが、他のWGやその他関連draftとの協調に関する議題がありました。

その一つとして、draft-carpenter-renum-needs-workがあります。これは、リナンバリングの機構は必須ではないにせよ、やはり必要となる場面は多く存在するため、リナンバリングを行うにあたっての技術的な問題点をまとめた文章です。その中でDNSも取り上げられており、レコードのTTLに関する注意点に言及されています。この文章自体、これから先本当に発展していくのかわかりませんが、dnsop WGにもレビューの依頼が来ました。

その他には、draft-bagnulo-behave-dns64に関する議論もありました。これはdnsext WGでも議論が行われたものですが、dnsop WGでは、特にDNSSECの扱いについて議論されました。NAT64トランスレータを利用する場合、DNSの問い合わせクエリ中にあるDO(DNSSEC OK)flagとCD(CheckingDisabled)flagをどう扱うかという議論がなされました。これに関しては、behave WGでも引き続き議論が行われることとなりました。

また、DNSSECに関連して、RootゾーンをDNSSECにて署名する方向で動いているというIABの声明が報告されました。これはKaminsky Attack等でDNSプロトコル自体の脆弱性を指摘する声が高まったことに対応する動きで、NTIA(米国商務省電気通信情報局)が発表した、Rootゾーンへの署名にIABとして協力するという声明でした。NTIAの発表は、下記サイトにまとめられています。

□NTIA Seeks Public Comments Regarding the Deployment of DNSSEC
http://www.ntia.doc.gov/dns/dnssec.html

(JPNIC DNS運用健全化タスクフォースメンバー/東京大学情報基盤センター 関谷勇司)

このページを評価してください

このWebページは役に立ちましたか?
よろしければ回答の理由をご記入ください

それ以外にも、ページの改良点等がございましたら自由にご記入ください。

回答が必要な場合は、お問い合わせ先をご利用ください。

ロゴ:JPNIC

Copyright© 1996-2024 Japan Network Information Center. All Rights Reserved.