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

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

ロゴ:JPNIC

WHOIS 検索 サイト内検索 WHOISとは? JPNIC WHOIS Gateway
WHOIS検索 サイト内検索
===================================
    __
    /P▲        ◆ JPNIC News & Views vol.1079【臨時号】2013.4.9 ◆
  _/NIC
===================================
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ News & Views vol.1079 です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

本号では、vol.1078に続き、2013年3月10日から3月15日に、米国フロリダ州
のオーランドにて開催された、第86回IETFミーティングのレポート[第2弾]と
して、DNS関連WGの動向についてお届けします。

第86回IETFの全体報告については、以下URLのバックナンバーもご覧くださ
い。

□第86回IETF報告 特集
  ○[第1弾] 全体会議報告 (vol.1078)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2013/vol1078.html

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第86回IETF報告 [第2弾] DNS関連WG報告
                             JPNIC DNS運用健全化タスクフォースメンバー
                                             東京大学 情報基盤センター
                                                              関谷勇司
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

今回のIETF 86は、米国フロリダ州のオーランドで開催されました。ディズ
ニーワールドの近くであり、カンファレンスセンターはリゾート気分満載で
した。DNS関連WGとしては、dnsop WGが会合を開催しました。dnsop WGの会合
での議論と、dnsop WG、dnsext WGそれぞれのメーリングリストでの議論を元
に、DNS関連WG報告をします。


■dnsop WG報告

dnsop WGの会合は、1時間の枠で開催されました。主な議題は、

(1)DNS in JSON
(2)Negative Trust Anchors
(3)Automating DNSSEC delegation

の三つでした。

これらに先立ち、会合の冒頭に、チェアからドラフトの状況に関する報告が
ありました。前回のIETF 85から現在までに、draft-ietf-dnsop-rfc4641bis
がRFC6781として、draft-ietf-dnsop-dnssec-dps-frameworkがRFC6841として
発行されたとの報告がありました。RFC6781はDNSSEC Operational Practices
の更新版であり、DNSSECに用いる鍵の生成からゾーンの署名、鍵の管理等、
DNSSEC一連の運用に関してガイドラインを示した文章となっています。また、
RFC6841はトップレベルドメインやセカンドレベルドメインの管理者が、
DNSSECの導入や運用に関しての文章を作成するにあたってのフレームワーク
を提供する文章となっています。ドラフトの確認後、アジェンダとして予定
されていた議題に移りました。

まず、(1)のDNS in JSON (JavaScript Object Notation)では、DNSの問い合
わせや応答のフォーマットを、現在のバイナリ形式のワイヤーフォーマット
以外にも定義し、アプリケーション間でDNSデータのやり取りをしやすくしよ
うという意図から提案されました。具体的には、DNS Looking Glassなどから
データを抽出したり、HTTPを用いてDNSデータを交換したりする場合を想定し
ているようです。JSON WGでやるべきでは、との意見も出されましたが、JSON
フォーマットを定義すること自体には大きな反対も無く、議論は続けられる
こととなりました。

次に、(2)のNegative Trust Anchorsに関する議論が行われました。この提案
は、DNSSECを導入したドメインで、ゾーン管理者の設定ミスや管理のミスに
より、ゾーン全体が無効になってしまうなどの事故が発生しても、ユーザー
への被害を最小限にするための手法です。過去にも、ZSK (Zone Signing
Key) やKSK (Key Signing Key)が有効期限切れとなり、ゾーン全体が無効と
なってしまう事故が発生しています。この場合、DNSSECによる検証を有効に
したリゾルバを使っているユーザーは、そのゾーン全体を検索することがで
きなくなってしまいます。これがISPや企業のリゾルバサーバであれば、ユー
ザーはそのゾーンが検索できないことに対するクレームを出し、結局リゾル
バサーバ管理者は、そのリゾルバサーバのDNSSEC検証を無効にせざるを得な
い事態となります。このような場合にも、このNegative Trust Anchorにより
一時的にDNSSEC検証を無効にするドメインを指定することができれば、リゾ
ルバサーバの管理者側で一時的な対応ができることになります。今のところ、
企業やISPのDNSリゾルバサーバーは全体的にDNSSECを使うか、使わないかと
いう二つの選択肢しかありませんが、この提案は、DNSSECを使うかどうかを
ドメインごとに指定できることを目的としています。この提案に対しては前
向きな意見が多く、レビューメンバーが募られ、引き続き議論が続けられる
こととなりました。

最後に、(3)のAutomating DNSSEC delegationの議論が行われました。これ
は、DNSSECのKSK rolloverをより簡単にする手法の提案です。現在のDNSSEC
では、子ゾーンの管理者はDSレコードを作成し、それを親ゾーンに対して送
付することで、信頼の連鎖を形成しています。一方、この提案では、現在親
ゾーンに存在しているDSレコードを、CDS (Child DS)レコードで置き換える
ことでDSレコードの更新をほぼ自動化しています。CDSレコードはDNSKEYで署
名されたレコードであり、子ゾーンの中のレコードとして発行されます。つ
まり、子ゾーンの管理者が自身のタイミングで自由に設定し、発行すること
が可能となっています。親ゾーンの管理者は、それを定期的に検証等するこ
とで、CDSが更新されていたらそれを検証し、親ゾーンに存在するDSレコード
と置き換えることで、DSレコードの更新を行います。これによって、子ゾー
ンのKSKの更新時に、新たなDSレコードを親ゾーンに送付し、KSKをrollover
するという手順が簡略化されます。

この提案に対して、既存のツールが子ゾーンのDSレコードを親ゾーンに送付
するという形での署名に対応したものとなっていたり、レジストラのビジネ
スモデルが既に存在したりすること等から、導入は難しいとの意見が出され
ました。その一方で、技術的には必要であるとの意見も出されました。結果
として、レビューメンバーが募られ、引き続き議論が行われることとなりま
した。


■dnsext WG報告

dnsext WGは、特段の事情が無ければIETFにて会合を開催しないことが合意さ
れているため、今回も会合は開催されませんでした。ドラフトも
draft-ietf-dnsext-dnssec-algo-signalがIESG Last Callの段階であり、
draft-ietf-dnsext-dnssec-algo-imp-status、
draft-ietf-dnsext-rfc2671bis-edns0、draft-ietf-dnsext-rfc6195bisの三
つのドラフトがRFCエディタ待ちになっているという状況で、これ以外に
Active WGドラフトは存在しません。着実にWGをクローズする段階に入ってい
ると言えます。メーリングリスト上では、前回のIETF 85から、
draft-ietf-dnsext-dnssec-algo-signalと
draft-ietf-dnsext-dnssec-algo-imp-statusの議論、RFC5155の修正点に関す
る議論が行われた他は、散発的な議論が行われるのみでした。RFC5155の修正
点に関しては、いくつかの指摘がなされ、用語的な指摘と、より間違いの無
い定義をめざした文章への変更でした。どれも新たな提案ではなく、大きな
議論も発生しませんでした。

     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       わからない用語については、【JPNIC用語集】をご参照ください。
             https://www.nic.ad.jp/ja/tech/glossary.html
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃     ◆◇◆◇◆   本号のご感想をお聞かせください   ◆◇◆◇◆     ┃
┃良かった                                                          ┃
┃→ http://feedback.nic.ad.jp/1079/3ff68c31c817b5fd1eca24f11de068c7┃
┃                                                                  ┃
┃悪かった                                                          ┃
┃→ http://feedback.nic.ad.jp/1079/54ec41ad4c603e8c8f3aa0d5252cb46d┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
___________________________________
■■■■■  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.1079 【臨時号】

 @ 発行  一般社団法人 日本ネットワークインフォメーションセンター
          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
      

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

このWebページは役に立ちましたか?
ページの改良点等がございましたら自由にご記入ください。

このフォームをご利用した場合、ご連絡先の記入がないと、 回答を差し上げられません。 回答が必要な場合は、お問い合わせ先をご利用ください。

ロゴ:JPNIC

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