ニュースレターNo.56/2014年3月発行

DNS関連WG報告

dnsop WG報告

今回のIETF 88はバンクーバにて開催され、dnsop WGの会合が開催されました。会合の時間は90分であるにも関わらず、多くの議題が詰め込まれており、案の定時間が足らず消化不足気味に終了しました。

まず、DNS Prefetchの性能評価に関する報告がなされました。これはdraft-wkumari-dnsop-hammerにて提案されている、Hammer Timeを用いたDNSレコードPrefetch(事前読み込み)の有用性を確認するための性能評価です。SURFnetにて、ユーザーにリゾルバDNSサーバとして提供されているUnboundを用いて、データ収集が行われました。Unboundの設定を変更し、Prefetchが有効な場合と無効な場合とで、ユーザーからのクエリ数の比較と、キャッシュ的中率の比較がなされました。結論としては、Prefetchによる性能向上は、ごく限られた範囲と限られた名前にのみ見られ、全体として大きな性能向上に貢献するものではない、との結果になりました。この結果を踏まえ、draft-wkumari-dnsop-hammerを実データの解析結果を含んだ新たなinternet-draftとすることが合意されました。引き続きDNSレコードPrefetchの有用性は議論されるようです。

次に、draft-hardaker-dnsop-csyncに関する発表と議論が行われました。この文章は、子ゾーンの先頭に存在する親ゾーンを示すNSレコードを、親ゾーンが自動的に取り込むことによって、委譲関係の更新を行うという提案です。従来は、子ゾーンを担当するDNSサーバを変更する場合には、子ゾーンのゾーンファイル先頭にあるNSレコードを更新し、かつ親ゾーン中にある委譲のためのNSレコードとグルーレコードを更新するための依頼を、親ゾーンの管理者に対して行う必要がありました。この提案は、それを自動化するものです。この提案に対しては、レジストラは独自のプロトコルでそれを実現しているので、本当に必要なのかという意見や、レジストラだけではなく通常のゾーン委譲でも有効だとする両方の意見が出され、継続議論となりました。

さらに、draft-kumari-ogud-dnsop-cdsに関する発表と議論が行われました。これは、CDSとCDNSKEYという二つの新たなリソースレコードを用いて、DNSSECの更新鍵を子ゾーンから親ゾーンに対して通知する手法を提案しています。ここ数回のdnsop WGの会合にて議論されてきた話題です。議論では、csyncと混乱しやすいので違いを明確にした方がいいという意見や、新たなリソースレコードを追加するのでdnsop WGの範疇ではないのでは、といった意見が出されました。引き続き議論が行われていくようです。

また、draft-fujiwara-dnsop-ds-query-increaseに関する発表と議論も行われました。これは株式会社日本レジストリサービスの藤原和典氏による発表であり、DNSSECの普及にともないJPゾーンを受け持つDNSサーバに対するDSレコードの問い合わせ数が増加していることを報告したものです。この報告に対して会場からは、仕様通りの動作なのでそれほど大きな問題ではない、といった意見が大勢を占めました。あまり注目されなかったようです。

この他にも、複数のドラフトに関する発表がありました。その中で特に今後の議論に関連すると思われるものを抜粋して紹介します。

まず、draft-jabely-dnsop-as112-dnameですが、通称AS112と呼ばれる、プライベートアドレス空間の逆引きを担当するDNSサーバにおいて、その担当するゾーンを動的に増減させる手法を提案した文章です。この提案に関しても、ここ数回のdnsop WG会合で議論されてきました。APNICにて試験を行った結果、問題なく機能しそうだという報告を受けたため、WGドラフトとして議論が継続されることになりました。

draft-jabley-dnsop-flush-reqsは、リゾルバDNSサーバに対して、保有するリソースレコードのキャッシュを消去するための通知機構を提案したものです。前回のIETF 87にて一度却下された提案であるため、再度その必要性を提案する文章となっています。引き続き議論が行われると思われます。

最後に、edns-tcp-chain-queryならびにedns-tcp-keepaliveに関して報告します。これは、DNSSECの導入によってDNSサーバと通信する回数や、通信のデータサイズが大きくなっているため、名前解決に時間がかかるという問題を解決するための提案です。具体的には、DNSSECに関連する複数のリソースレコードを取得するにあたって、UDPパケットにて複数回通信を行うのではなく、一つのTCPセッションを用いて通信を行うという手法です。これにより、DNSサーバに対するTCPクエリ数は増加しますが、結果として問い合わせにかかる時間を短縮できるという提案です。この提案の有用性については、会場からも賛同する声が複数あったため、今後も議論されていくと思われます。

dnssd WG報告

Extensions for Scalable DNS Service Discovery(dnssd WG)は、このレポートでは初めて取り上げるWGで、DNSでサービスを探し出すスケーラブルな拡張機能を検討するものです。

dnssd WGの会合は、2時間の枠にて開催されました。まず、dnssdのサービスに利用するためのTLDを確保しようという提案がなされました。これに関して、本当にTLDが必要なのかという意見や、TLDとしての.localは既にあるサービス発見と混乱しやすいといった意見、またTLDでなくても.arpaの下のドメインでもいいのではないか、といった議論がなされました。最終的に、急いでTLDを確保する必要はない、という合意が得られました。

次に、draft-lynn-dnssd-requirementsに関する発表がありました。この文章は、dnssd自体の必要性に関して述べた文章です。サービス発見に関して、DNSを用いるのが規模性的に優れているといった意見や、DNSをこういった用途に使うべきなのかといった根本的な意見が交換されました。結論としては、現状のDNSを壊さない限りはいいのではないか、という意見にまとまりました。

その他にも、dnssdのアーキテクチャに関する発表と議論がなされました。ユニキャストのDNS応答を用いて、どのようにサービス発見を行うか、またクライアントにどのように通知するか、といった議論がなされました。dnssd WGはまだ初期段階であり、今後議論が続いていくものと思われます。

dnsext WG報告

dnsext WGは、既にIETFでの会合を開催しないため、今回もメーリングリストでの議論を中心に報告します。前回のIETF 87からの議論としては、SPFレコードの扱いに関する議論が続けて行われました。SPFリソースレコードを用いるのではなく、TXTレコードにSPF情報を書くのが一般的となっているため、SPFリソースレコードを廃止するという提案です。WGの会合が開催されないため、メーリングリスト上の議論だけでは明確な結論は出ませんでしたが、廃止しても良いという意見が多く見られました。

また、draft-wouters-edns-tcp-chain-queryに関する議論もありました。これは、DNSSECなどのサイズの大きなデータをDNSサーバとやり取りする場合、UDPではなくTCPを率先して用いるというEDNSオプションの提案です。さらに、TCPセッションを確保したままにする、draft-wouters-edns-tcp-keepaliveという提案もなされました。この提案に関しては、有用だとする意見が出され、メーリングリストで議論が継続されています。

他には、draft-gieben-auth-denial-of-existence-dnsに関する議論や、ゾーン自体の動的な追加、削除を行うプロトコルを定義してはどうか、などの提案がなされましたが、いずれも散発的な議論で終わりました。

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