ニュースレターNo.58/2014年11月発行

第90回IETF報告　DNS関連WG報告

dnsop WG(Domain Name System Operations WG)

dnsop WGの会合は、7月22日(火)の午前中に開催されました。今回は多くの議題があり、時間いっぱい議論が行われ、まず、I-D(Internet Draft)の状態確認が行われました。

draft-ietf-dnsop-dnssec-key-timingについての報告が行われ、一つ前の版である、03版が公開されたのが2年前であり、今回久しぶりに更新されて04版として公開されました。2012年8月にWGラストコールまでは行われていましたが、その後何も動きがなく今日に至っていました。多くの編集が行われましたが、中身は基本的に変わりはなく、再度WGラストコールを行うことが確認されました。

次に、draft-ietf-dnsop-dnssec-roadblock-avoidanceに関する議論が行われました。このI-Dは、DNSSECを導入するにあたって、障害となるインフラ上やネットワーク上の問題点に関して、注意事項を述べた文章となっています。ファイアウォールやブロードバンドルータなどのミドルボックス、EDNS0や最大UDPパケットサイズによるパケットフラグメント問題等、DNSSECを導入する際に起こりがちな問題について述べています。問題発見とともに、どう対処するかの議論が行われ、少し発散気味になりました。

今回、最も長い時間をとって議論されたのが、Root DNSサーバの分散に関する議題です。draft-wkumari-dnsop-dist-rootとdraft-lee-dnsop-scalingrootがこの議題に関連する発表でした。

draft-wkumari-dnsop-dist-rootは、Recursive DNSサーバにRoot zoneのキャッシュを持たせることで、Root DNSサーバに不必要な問い合わせが行くことを防ぎ、Root DNSサーバの規模性を確保しようという提案です。また、キャッシュとして保持するRoot zoneはDNSSECで署名されているため、リソースレコードの偽装はできないからRecursive DNSサーバがキャッシュを保持しても問題ない、という主張です。

次に、draft-lee-dnsop-scalingrootは、現在13あるRoot DNSサーバそのものを増やそうというものです。IPv4 UDPメッセージの最大サイズである512バイトは、IPv6が普及するにつれ問題にならなくなるため、IPv6パケットのMinimum MTUである1280バイトから考えれば、20個のRoot DNSサーバアドレスをUDP 1パケット中に入れることができる、という試算です。そして新たに追加するアドレスはすべてエニーキャストアドレスとして扱えば、より多くのRoot DNSサーバを世界中に展開できるという提案でした。

その他にも、draft-mekking-dnsop-kasp、draft-fujiwara-dnsop-poisoning-measures、draft-howard-dnsop-ip6rdns、draft-jabley-multicast-ptrの発表が行われました。Root DNS分散の議論が終わった時点で、会合の残り時間が少なくなっていたため、議論はメーリングリストに持ち越されました。

dane WG(DNS-based Authentication of Named Entities WG)

daneは、DNS-based Authentication of Named Entitiesの略で、2011年3月のIETF 80から活動を開始しているWGとなります。アプリケーションやトランスポートレイヤーが認証や暗号化に用いる証明書に関連する情報を、DNSを用いて配布する仕組みを標準化するためのWGです。本IETF DNS関連WG紹介で取り上げるのは初めてですが、最近活発に議論が行われているWGとなっています。

今回のIETF 90では、このdaneについても、7月22日(火)の夕方に、2時間の会合が開催されました。まず始めに、SRVレコードとSMTP通信へのDANE TLSA DNSレコードの適用に関する、I-Dの状況確認が行われました。I-Dとしては、draft-ietf-dane-srv、draft-ietf-dane-smtp-with-daneとなります。どちらもWGラストコールに入る前の修正段階であることが確認されました。

次に、OpenPGPとS/MIMEへのDANE TLSA DNSレコードの適用に関するI-Dの状況が確認されました。draft-ietf-dane-openpgp、draft-ietf-dane-openpgpkey-usage、draft-ietf-dane-smimeの三つのI-Dとなります。実際の普及や使用例も含めた文章となっているため、その辺りを増強するとともに、文章をまとめるかどうかの議論がなされました。引き続きメーリングリストで議論が行われます。

さらに、DANEbis and operational guidance(draft-ietf-dane-ops)に関する発表と議論が行われました。DANEとPKIX(Public Key Infrastructure WG)との関連性や使い分け、RFC6698(The DNA-Based Authentication of Named Entities Transport Layer Security Protocol : TLSA)の更新に関する議論が主であり、PKIXとDANEの管理モデルの違いやそれぞれの使い分け、もしくはPKIXにDANEを付加的に用いる方法等が議論されていました。

他にも、TLSA Raw Keys(draft-ietf-dane-rawkeys)に関する議論が行われました。これは、TLSAリソースレコードに直接公開鍵を入れてしまう手法を提案したものです。これによって、アプリケーションやプロトコル毎にTLSAをどう使うかを定義せずとも、利用することが可能になります。この提案に関しては、TLS以外の用途にも適用可能なので、TLSAとは別のレコードにした方が良いのではないか等の議論が行われました。

dnssd WG(Extensions for Scalable DNS Service Discovery WG)

dnssd WGの会合は、7月24日(木)の午後に開催されました。まず、draft-ietf-dnssd-requirementsに関する議論が行われました。WGラストコールが完了し、寄せられた質問やコメントに基づく回答が行われました。VPNを用いた場合のサービス発見等、WGチャーターにも関連する部分の指摘があり、引き続き改訂が行われる模様です。

次に、draft-rafiee-dnssd-mdns-threatmodelに関する議論が行われました。dnssdを用いた場合のセキュリティ的な懸念に関して述べた文章であり、requirements文章とは別に作成されることが確認されました。

さらに、ULAs for scaling DNS-SDに関する議論が行われました。DNS-SDに用いるアドレスにIPv6 ULAを用いることで、ファイアウォールの設定もしやすくなるため、セキュリティの向上やPrivacy ExtensionによるグローバルIPv6アドレス変更にも対応できるという提案です。IPv6のみの対応となるため、引き続きメーリングリストでの議論となりました。

他にも、draft-cheshire-dnssd-hybridに関する議論が行われました。オンリンクでのサービス発見に用いられているMulticast DNSの名前解決を、通常の名前解決に用いられているUnicast DNSがProxy動作することで、外部からも解決できるようにするという提案です。実際に動く実装の提案として、WGドラフトとして引き続き議論していくことが合意されました。

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