＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
    __
    /Ｐ▲        ◆ JPNIC News & Views vol.1465【臨時号】2016.12.27 ◆
  _/ＮＩＣ
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ News & Views vol.1465 です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2016年11月13日(日)～18日(金)にかけて、韓国のソウルにて開催された第97
回IETFミーティングの報告を、vol.1455よりお届けしています。本号では連
載の最終回として、DNS関連の動向をご紹介します。

なお、これまでに発行した、全体会議のレポートやIPv6、トランスポート、
セキュリティの各分野の報告については、下記のURLからバックナンバーをご
覧ください。

  □第97回IETF報告

    ○[第1弾] 全体会議報告 (vol.1455)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2016/vol1455.html

    ○[第2弾] IPv6関連WG報告 ～v6ops、sunset4 WGに関して～ (vol.1456)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2016/vol1456.html

    ○[第3弾] トランスポートエリア関連報告 (vol.1457)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2016/vol1457.html

    ○[第4弾] セキュリティエリア関連報告
              ～新しいTLSのバージョンはどうなる？～(vol.1460)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2016/vol1460.html

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第97回IETF報告 [第5弾] DNS関連WG報告
                                    東京大学 情報基盤センター 関谷勇司
                                                 JPNIC 技術部 小山祐司
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

本稿では、韓国・ソウルで開催されたIETF 97におけるDNS関連の動向を、
dnssd WG、dnsop WG、dprive WGでの議論の様子を中心にご紹介します。

■ dnssd WG (Extensions for Scalable DNS Service Discovery WG)報告

dnssd WGの会合は、2016年11月15日(火)の午前中に開催されました。最初に、
チェアからのI-D (Internet-Draft)の状態に関する確認と、今回の会合にお
いて特にポイントとなる議題について確認がありました。ポイントとなる議
題は、Hybrid Proxyに関する議論、DNSシグナリングに関する議論、プライバ
シー保護に関する議論でした。

まずHybrid Proxyに関する議論では、draft-ietf-dnssd-hybridのWGラスト
コール(WGLC)でのコメントを受けて、いくつかの改定がなされたとの報告が
ありました。大きな改定点として、"Hybrid Proxy"から"Discovery Proxy"に
名前を変更してはどうかという提案がなされました。これはdnssdが、
Multicast DNSとUnicast DNSの両方を用いてサービス発見を実現するため
Hybridと呼んでいましたが、方式よりも機能に着目し、代理でサービス発見
に関する応答を行うものであるため、Hybrid ProxyよりもDiscovery Proxyの
方が適切ではないかという観点からの提案です。会場内でハミングによる合
意が取られ、Discovery Proxyへと変更になることが確認されました。

次に、DNSシグナリングに関する議論が行われました。従来はDNSサーバとの
セッションに関するシグナリングと、DNSサーバがキャッシュとして保持する
リソースレコードの更新に関するシグナリングとが、同一のI-Dにて述べられ
ていましたが、前者はdnsop WGのドラフトに分割されることとなりました。
DNSサーバへのセッションに関するシグナリングは、
draft-ietf-dnsop-session-signalというI-Dになり、リソースレコードの更
新に関するシグナリングがPUSHメッセージと定義され、
draft-ietf-dnssd-pushとして継続されることになりました。その後、DNSサー
バへのセッションシグナリングに関する議論が行われ、EDNS0を利用したパ
ケットフォーマットや、PUSHメッセージに対する返答が必要か等の議論が行
われました。

最後に、dnssdのプライバシーに関する議論が行われました。誰がそのサービ
スを問い合わせたのか、また提供しているのかを、同一ネットワークに存在
する隣接ホストにばれないようにするための仕組みです。認証を用いたサー
ビスと、それを利用するデバイスとのペアリング機構の提供や、ハッシュを
用いたメッセージのランダム化等が議論されています。


■  dnsbundled BoF報告

dnsbundledは、あるドメイン名を他のドメイン名に完全にマッピングする手
法について議論するために開催されたBoFです。11月16日(水)の午前中に開催
されました。利用用途としては、通常のアルファベットのTLDと、国際化TLD
を完全にマッピングさせるといった用途が想定されています。

前回のIETF 96においては、Bar BoFとして非公式に開催されており、正式に
dnsbundled BoFが開催されるのは今回が初めてでした。主な事例として、.CN
(中国)や.GR(ギリシャ)、.TR(トルコ)、.CZ(チェコ)といったドメイン名が挙
げられ、これらの国際化TLDと通常のTLDでの登録ドメインを、完全にマッピ
ングさせたいという要求が公開されました。

また、このマッピングは、DNSのプロトコルを変更することなく実現するべき
との方向性も述べられました。既存技術として、CNAMEやDNAMEといった機能
がありますが、どちらも完全なマッピングは実現できないため、新たなリソー
スレコードとしての、BNAME、CLONEが提案されました。各国のTLDにて実現し
たいこと、現在の問題点が述べられ、議論が行われました。

会場からは、TLDにおける文字的な表現と意味的な表現を一致させようという
ものであり、非常に難しい問題であるとの意見が出されました。また、特定
の商用的な利用に必要となる機能ではないかといった意見も出され、IETFと
して扱っていくべき問題なのかという議論が、dnsbundledがWGとなるために
必要となりそうです。


■ nmrg (Network Management Research Group)報告

直接DNSと関連するWGではありませんが、11月15日(火)の午前に開催された
nmrgの会合において、Root DNSに行われた大規模DoSに関する計測結果が発表
されていたため、報告します。

"Anycast vs. DDoS:Evaluating the November 2015 Root DNS Event"という
タイトルにて、2015年11月30日(月)に発生したRoot DNSサーバへの大規模攻
撃に関して、何が発生していたのかの分析結果が公開されました。Root DNS
は、そのサービス冗長性の確保や攻撃への耐性を高めるため、BGP Anycastを
用いた分散配置が行われています。名前的には、A.root-servers.netから
M.root-servers.netまでの13種類しか存在しませんが、実際にはBGP Anycast
を用いて、世界中の数百拠点にRoot DNSサーバが設置されています。あるRoot
DNSサーバに対して攻撃が発生したとしても、その攻撃は複数拠点に分散され
るか、特定の拠点のみが攻撃を受け、他の拠点のサービスに影響を及ぼさな
いという利点があります。

しかし、2015年11月30日に発生した攻撃では、このBGP Anycastによって、か
えって複数の拠点におけるサービスが不安定になってしまったという報告が
なされました。BGPはそのプロトコル性質上、BGP peeringが切れれば経路が
広告されなくなります。大規模な攻撃によってBGP peeringが切れてしまうこ
とで、ある拠点自体のサービスが停止し、他の拠点のサービスに影響を与え
るという事象が発生していたようです。これを教訓として、さらなる攻撃へ
の耐性強化が望まれます。


■ dnsop WG (Domain Name System Operations WG)報告

DNSに関するプロトコルや運用方法について議論・標準化を行うdnsop WGは、
11月15日(火)に開かれました。はじめに、DNS応答のうち名前不存在の応答短
縮化を図るRFCおよびI-Dについてご紹介します。

まず、RFC 8020が1年足らずで標準化となったことが、称賛されつつ紹介され
ました。RFC 8020は、あるドメイン名の検索結果がNXDOMAINとなった時に、
そのドメインのサブドメインについてすべてNXDOMAINとして取り扱うことに
するというものです。

また併せて、draft-ietf-dnsop-nsec-aggressiveuseについて2度目のWGLCを
しようという呼びかけがありました。draft-ietf-dnsop-nsec-aggressiveuse
は、DNSSECにおいて名前が存在しないという情報を表すNSECレコードを受け
取った場合に、その情報を元にリゾルバが不存在の応答を素早く返すことが
できるようにするというものです。こちらは一度WGLCが完了していましたが、
若干の修正が必要となったため、再度WGLCを行うこととなりました。

次に、DNSSECにおける親ゾーンと子ゾーンの、信頼の連鎖を構成する方法に
関する議論についてご紹介します。信頼の連鎖を自動的に行うことを目的と
したレコードに、CDS (Child DS)、CDNSKEY (Child DNSKEY)がRFC 7344にお
いて標準化されていますが、カテゴリーはInformationalとなっています。こ
のRFCを補足・改良し、カテゴリーをStandards Trackにするものとして、
draft-ogud-dnsop-maintain-dsが提案されています。このI-Dでは、DS
(Delegation Signer)を更新するにあたって必要な、DS、CDS、CDNSKEYの取り
扱い方について説明しており、現在はRFC 7344のカテゴリ変更に向けて作業
中と紹介されました。

その他、議題に挙げられたWGドキュメントについて、簡単にいくつかご紹介
します。

・draft-ietf-dnsop-refuse-any
  ANY問い合わせを拒否あるいは小さなサイズの応答を返す場合のガイダンス

・draft-wkumari-dnsop-alt-tld
  "ALT"という特殊な目的(special-use)のTLDの導入(RFC 6761では"test."や
  "localhost." などが定義されています)。IETFから提案されるドメイン名
  をこのTLDに集約しようとするものです。

・draft-ietf-dnsop-session-signal
  dnssd WGでも議論になったシグナルに関するI-Dです。EDNS0は一つのメッ
  セージごとに利用されるDNSの拡張プロトコルですが、複数のメッセージで
  共有できるようにし、「セッション」のような機能を付けられるようにし
  ようというものです。

さらにセッション中では、WGドキュメントに提案中のI-Dが各提案者によって
発表され、活発な議論が行われました。


■ dprive WG (DNS Private Exchange WG)報告

DNSのメッセージのやり取りに暗号化等の技術を導入し、盗聴や監視などから
DNSを保護するプロトコルを標準化することを目的としたWGです。

はじめにチェアのTim Wicinski氏とWarren Kumari氏から、WGのステータス
アップデートの発表がありました。

・RFC 7626 (DNS Privacy Considerations)
・RFC 7830 (The EDNS(0) Padding Option)
・RFC 7858 (Specification for DNS over Transport Layer Security (TLS))

の3本がRFCとなったこと、WGドラフトとして

・draft-ietf-dprive-dnsodtls
 (Specification for DNS over Datagram Transport Layer Security (DTLS))
・draft-ietf-dprive-dtls-and-tls-profiles
 (Authentication and (D)TLS Profile for DNS-over-(D)TLS)

があり、前者がIESG (Internet Engineering Steering Group)に提出、後者
がWGLCとなったものの、コメントが少ないので議論しようということが紹介
されました。

はじめにdraft-ietf-dprive-dtls-and-tls-profilesの紹介と、議論が行われ
ました。RFC 7626で議論され、RFC 7858で標準化されたDNS over TLSでは、
主に「クライアント←→キャッシュサーバ」間の暗号化に主題が置かれてい
ます。これに追加する形で、draft-ietf-dprive-dtls-and-tls-profilesで
は、「キャッシュサーバ←→権威サーバ」間でも、上記RFCでの手法が利用で
きるようプロトコルを拡張しようとするものです。主な内容としては、
"opportunistic(日和見)"と"strict(厳格)"と呼ばれる二つのモード(プロファ
イル)を追加し、利用する状況について使い分けができるようにするというも
のです。議論の中では、"opportunistic"を選択した時に"hard-fail(通信断)"
となるケースを入れるべきかなどが議論されました。

次に、RFC 7830の実装方法について発表がありました。RFC 7830は、暗号化
されたパケットの解読を困難にするため、padding(隙間)をメッセージ中に入
れるという技術ですが、それをどのように行えばよいかという意見募集です。
この発表に対しては、調査や研究が必要なこと、暗号に詳しい人からのコメ
ントを貰うべきだという意見などが出されました。

セッションの後半ではBoFが開催され、今後WGでは何をすべきかということが
議論されました。dprive WGのチャーターでは、DNSクライアントとキャッシュ
サーバの間で機密を保持するメカニズムを開発することが目的とされていま
すが、RFC 7858および上記のdraft-ietf-dprive-dtls-and-tls-profilesに
よって目的は達成されつつあります。ただ、キャッシュサーバ←→権威サー
バ間で必要となる認証については複数の手法があり、どれを採用するかの議
論が足りていないという問題提起がありました。そのため、今後どうするか
が議論され、より多くのI-Dを書くべきであること、チャーターを更新するこ
と、WGはクローズすべきでないことなどが合意となりました。

              ◇                ◇                ◇

次回の第98回は、2017年3月26日(日)から31日(金)にかけて、米国のシカゴで
開催されます。


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

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃     ◆◇◆◇◆   本号のご感想をお聞かせください   ◆◇◆◇◆     ┃
┃良かった                                                          ┃
┃  http://feedback.nic.ad.jp/1465/38eb918b35ab04529dbfb9686733b38c ┃
┃                                                                  ┃
┃悪かった                                                          ┃
┃  http://feedback.nic.ad.jp/1465/4c8b61efe474ca29a8acc2348587fdc8 ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
■■■■■  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.1465 【臨時号】

 ＠ 発行  一般社団法人 日本ネットワークインフォメーションセンター
          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), 2016 Japan Network Information Center