===================================
__
/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

