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

2015年11月上旬に神奈川県のパシフィコ横浜にて開催された、第94回IETFミー
ティングの様子を、vol.1360より連載にてお届けしています。連載第6弾とな
る本号では、DNS関連WGの動向をご紹介します。

日本では6年振り3回目のIETF会合ということもあり、いつもよりもボリュー
ムアップしてお届けしてきた第94回IETF報告ですが、本号が連載最終回とな
ります。これまでに発行したIETF報告は、下記のURLからバックナンバーをご
覧ください。

  □第94回IETF報告

    ○[第1弾] 全体会議報告 (vol.1360)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2015/vol1360.html
    ○[第2弾] IETF会合に初めて参加して (vol.1361)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2015/vol1361.html
    ○[第3弾] セキュリティ関連報告 (vol.1362)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2015/vol1362.html
    ○[第4弾] IPv6関連WG報告 (vol.1363)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2015/vol1363.html
    ○[第5弾] dhc WG関連報告 (vol.1364)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2015/vol1364.html

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

今回のIETF 94は、横浜にて開催されました。2002年に同じく横浜で開催され
たIETF 54に引き続き、2度目の横浜開催となります。会場となったパシフィ
コ横浜では、WIDE Projectを中心としてスポンサーやコントリビュータ各社
からのボランティアによってNOC(ネットワークオペレーションセンター)メン
バーが構成され、会場内外のネットワーク構築と運用が行われました。

私もNOCメンバーの一員として、少しだけ設営と運営に関わらせていただきま
した。前回の横浜開催であるIETF 54でも、学生としてNOCメンバーボランティ
アに参加していました。その経験をふまえ前回と今回との会場ネットワーク
環境を比較すると、ネットワークを取り巻く環境は格段の進歩を遂げている
ことを、あらためて実感することができました。

さて本号では、DNSに関連するWGとして、dnsop WG、dprive WG、dnssd WGの
動向をご報告します。


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

dnsop WGの会合は、150分枠で開催されました。まずは恒例の、Internet-
Draftの状況確認から行われました。前回の会合から、3本のRFCが発行された
ことが報告されました。RFC7583、RFC7646、RFC7686です。他にもWGラスト
コールが行われているInternet-Draftが6本あり、活発な活動が行われている
ことを感じられました。次に、draft-jabley-dnsop-refuse-anyに関する発表
と議論が行われました。このInternet-Draftは、ANYクエリによってパケット
サイズの大きな返答が返ってしまうことを防ごうという趣旨の提案です。昨
今、DNSを用いた増幅攻撃が問題となっているため、ANY!=ALLの解釈のもと
に、返答パケットのサイズを減らす提案が行われました。WG Internet-Draft
とする方向で議論が行われました。

さらに、RFC6761bisに関する発表と議論が行われました。RFC6761は、
"Special-Use Domain Names"というタイトルであり、ドメイン名の空間をDNS
以外の用途(「従来のドメイン名とIPアドレスの相互変換ではなく、サービス
発見のため」「DNSの仕組みは使いながらも、そのセマンティクスは従来のDNS
ではない」など)に使う場合の注意事項を述べたものです。しかし、この特別
なドメイン名を決定するプロセスや条件に関する記述が不十分だという意見
が出され、文書を改定するためのデザインチームから報告が行われました。
特に、RFC2860にて述べられているIANAの役割定義に関するMoU(覚書)に反す
るのではないかといった意見が出され、議論が続きました。今後も議論が継
続される模様です。

他にも、draft-jabley-dnsop-ordered-answers、
draft-ogud-dnsop-maintain-ds、draft-muks-dnsop-dns-message-checksums、
draft-muks-dns-message-fragments、draft-wessels-edns-key-tagに関する
発表と議論が行われました。それぞれの概要を紹介します。

draft-jabley-dnsop-ordered-answersは、DNSの返答パケットにおけるそれぞ
れのセクションにて、どの順番でRR (Resource Record)を並べるかを提案し
たものです。

draft-ogud-dnsop-maintain-dsは、DSレコードの管理において、DSを初めて
導入する場合とDSを消す場合について、CDSとCDNSKEYレコードを用いて子ゾー
ン側からその意思を示す手法を提案しています。

draft-muks-dnsop-dns-message-checksumsは、UDPパケットのフラグメントを
用いて偽の情報を覚え込ませようとする攻撃を防ぐために、EDNSオプション
としてDNSメッセージのチェックサムを定義しようという提案です。

draft-muks-dns-message-fragmentsは、DNSの返答パケットがフラグメントさ
れる場合の問題点を述べ、DNSメッセージのフラグメントを廃止しようという
提案です。

最後に、draft-wessels-edns-key-tagは、RootゾーンのKSK更新が計画されて
いるため、新しいKSKに更新された際に、リゾルバサーバのトラストアンカー
がどの程度更新されたかを判別できるように、Key IDをつけようという提案
です。

他にもいくつかの発表と議論が行われ、時間いっぱい会合が行われました。
dnsop WGは、引き続き活発な議論が行われていくと思われます。


■ dprive WG (DNS Private Exchange WG)報告

dprive WGの会合は、120分の枠で開催されました。まず、Internet-Draftの
状況が確認され、続いてdraft-ietf-dprive-dnsodtlsに関する議論が行われ
ました。この文書は、DTLS (Datagram Transport Layer Security)をDNSに用
いるという提案です。今回は、DTLSでのパケットサイズ増加による、フラグ
メントの問題に関して議論が行われました。どのようにフラグメントを防ぐ
か、という意見が交換されましたが、DNSに限らずDTLSを利用した場合に発生
する問題であるため、フラグメント自体を発生しないようにする手法を提案
する方向になりました。

次に、draft-ietf-dprive-dns-over-tlsに関する発表と議論が行われました。
DNS-over-TLSのドラフトは、WGラストコールに向けて問題点を改善しており、
その経過報告が行われました。この文書は、TLSを用いたDNSサーバの認証を
提案しており、その実装の進捗状況についても報告されました。ポート番号
としては、853番が割り当てられています。

さらに、draft-krecicki-dprive-dnsencについての発表と議論が行われまし
た。これは、トランスポート層プロトコルとは独立させて、DNSのトランザク
ションを暗号化しようという提案です。NSK RRという新しいリソースレコー
ドで、サーバの公開鍵を公開することで、DNSトランザクションを暗号化しま
す。当然、DNSSECとの併用が必要となります。この提案に対して、サーバに
対してのDDoSを容易に行うことができるのではないか、またアプリケーショ
ンレベルで暗号化を再度定義するのは冗長なのではないか、といった意見が
出されました。引き続き議論が行われます。

この他にも、draft-wing-dprive-profile-and-msg-flows、
draft-am-dprive-evalといった文書に関して、発表と議論が行われました。
drpive WGでは、DNS over DTLS、DNS over TLSといった提案を基本とし、DNS
のプライバシー問題解決という重要かつ困難な問題を解決するため、引き続
き議論が行われます。


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

dnssd WGは、DNSを用いたサービス発見を、さまざまな範囲にて行うプロトコ
ルを実現するためのWGです。まず、Internet-Draftの確認が行われました。
draft-ietf-dnssd-hybridならびにdraft-ietf-dnssd-pushがWGラストコール
直前であること、またdraft-ietf-dnssd-mdns-dns-interopのWGラストコール
が終了し、IESG (Internet Engineering Steering Group)レビューに回す前
の修正段階であることが報告されました。

会合では、draft-otis-dnssd-scalable-dns-sd-threatsについての発表と議
論が行われました。これはdnssdを実現するにあたっての、セキュリティ脅威
を分析した文書です。dnssdにおけるサービス発見範囲はマルチキャストによ
って限定されているため、いくつかのセキュリティ的な懸念点が存在するこ
とを述べています。まだ広く理解を得られる文書となってはいないといった
指摘があり、引き続き議論が行われます。

次に、draft-ietf-dnssd-pushと、draft-ietf-dnssd-hybridに関する発表と
議論が行われました。

draft-ietf-dnssd-pushは、DNSのレコードが変更された場合にその更新を動
的に通知する仕組みを提案した文章です。今までのDNSでは、たとえ権威DNS
サーバにおいてレコードが更新された場合でも、リゾルバDNSサーバにおいて
キャッシュの保持時間が残っている間は、再度権威DNSサーバへの問い合わせ
を行わない仕様となっています。そのため、ユーザには古いレコード情報が
返答される結果となります。この提案では、限られた範囲内のリゾルバDNS
サーバに対してレコードの更新を通知することで、頻繁なレコード更新に追
従できるサービス発見を実現することを目的としています。

またdraft-ietf-dnssd-hybridは、Multicast DNSによるサービス発見の結果
を、Unicast DNSの名前空間にマッピングする手法を提案しているものです。

どちらの発表も、前回会合からの改善点についてのまとめでした。また、大
きな問題点の指摘も無く、WGラストコールが行われることが確認されました。

最後に、draft-aggarwal-dnssd-optimize-queryに関する発表と議論が行われ
ました。この文書は、dnssdの規模性を危惧し、その規模性を向上させるため
に、TXT RRにAllJoynに従ったkey/valueペアの情報を入れることで、クライ
アントに検索のためのヒントを与え、検索回数を減らすという提案です。
AllJoynは、AllseanアライアンスによってIoTのために制定された規格であ
り、機器のプロファイルや、機器と機器の連携に関する情報などを提供する
フレームワークです。このAllJoynをどうdnssdに組み込んでいくのか、今回
の発表と文章からでは、まだはっきりと理解できませんでした。


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

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

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