=================================== __ /P▲ ◆ JPNIC News & Views vol.1155【臨時号】2013.12.20 ◆ _/NIC =================================== ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ◆ News & Views vol.1155 です ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 本号では、vol.1152、vol.1153、vol.1154に続いて、カナダのバンクーバー で開催された第88回IETFレポート[第4弾]として、DNS関連WGの動向をご報告 します。 昨日までに発行した、全体会議報告、IPv6関連WG報告、セキュリティ関連WG 報告については、下記の通りです。 □第88回IETF報告 特集 ○[第1弾] 全体会議報告 (vol.1152) https://www.nic.ad.jp/ja/mailmagazine/backnumber/2013/vol1152.html ○[第2弾] IPv6関連WG報告 ~6man WG、v6ops WGについて~ (vol.1153) https://www.nic.ad.jp/ja/mailmagazine/backnumber/2013/vol1153.html ○[第3弾] セキュリティ関連WG報告 ~RPKIの動向~ (vol.1154) https://www.nic.ad.jp/ja/mailmagazine/backnumber/2013/vol1154.html また本日、この第88回IETFの報告会が、本日ISOC Japan ChapterとJPNICの共 催で、東京・神田神保町の株式会社インターネットイニシアティブ本社会議 室にて開催されています。18時までUSTREAMで中継もされていますので、ご興 味のある方はご覧ください。 ■ IETF報告会ストリーミング(USTREAM) http://www.ustream.tv/channel/ietf-mtg ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ◆ 第88回IETF報告 [第4弾] DNS関連WG報告 JPNIC DNS運用健全化タスクフォースメンバー 東京大学 情報基盤センター 関谷勇司 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ IETF 88におけるDNS関連の動きとして、dnsop WG、dnssd WG、dnsext WGの概 要を報告します。dnsext WGは、メーリングリスト(ML)での議論の報告になり ます。 ■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サーバに対して、保有する リソースレコードのキャッシュを消去するための通知機構を提案したもので す。前回のIETF87にて一度却下された提案であるため、再度その必要性を提 案する文章となっています。引き続き議論が行われると思われます。 最後に、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での会合を開催しないため、今回もメーリングリスト での議論を中心に報告します。前回のIETF87からの議論としては、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用語集】をご参照ください。 https://www.nic.ad.jp/ja/tech/glossary.html ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ┃ ◆◇◆◇◆ 本号のご感想をお聞かせください ◆◇◆◇◆ ┃ ┃良かった ┃ ┃→ http://feedback.nic.ad.jp/1155/2706da5366808142aaa9d73ab9e36bef┃ ┃ ┃ ┃悪かった ┃ ┃→ http://feedback.nic.ad.jp/1155/4198bcbd87da735f255d373e51f28356┃ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛ ___________________________________ ■■■■■ JPNICの活動はJPNIC会員によって支えられています ■■■■■ ::::: 会員リスト ::::: https://www.nic.ad.jp/ja/member/list/ :::: 会員専用サイト :::: https://www.nic.ad.jp/member/ (PASSWORD有) □┓ ━━━ N e w s & V i e w s への会員広告無料掲載実施中 ━━━┏□ ┗┛ お問い合わせは jpnic-news@nic.ad.jp まで ┗┛  ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ =================================== JPNIC News & Views vol.1155 【臨時号】 @ 発行 一般社団法人 日本ネットワークインフォメーションセンター 101-0047 東京都千代田区内神田3-6-2 アーバンネット神田ビル4F @ 問い合わせ先 jpnic-news@nic.ad.jp =================================== ___________________________________ 本メールを転載・複製・再配布・引用される際には https://www.nic.ad.jp/ja/copyright.html をご確認ください  ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ 登録・削除・変更 https://www.nic.ad.jp/ja/mailmagazine/ バックナンバー https://www.nic.ad.jp/ja/mailmagazine/backnumber/ ___________________________________ ■■■■■ News & ViewsはRSS経由でも配信しています! ■■■■■ ::::: https://www.nic.ad.jp/ja/mailmagazine/backnumber/index.xml :::::  ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ■■◆ @ Japan Network Information Center ■■◆ @ https://www.nic.ad.jp/ ■■ Copyright(C), 2013 Japan Network Information Center