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

2018年11月上旬にタイ・バンコクで開催された第103回IETFミーティングのレ
ポートを、vol.1644より連載にてお届けしています。

連載の最終回となる本号では、バンコク会合におけるDNSに関連した議論の動
向をご紹介します。なお、その他の報告に関しては、下記のURLからバックナ
ンバーをご覧ください。

  □第103回IETF報告

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

    ○[第2弾] SUITとIETF Hackathon ～IoT機器の安全なファームウェア更
              新から～全体会議報告 (vol.1645)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2018/vol1645.html

    ○[第3弾] セキュリティエリア関連報告 ～オペレーション関連技術の動向
              CACAO/SMART～ (vol.1646)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2018/vol1646.html

    ○[第4弾] トランスポートエリア関連報告 ～HTTP over QUICからHTTP/3
              への改称～ (vol.1647)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2018/vol1647.html

    ○[第5弾] ACME WG関連報告 ～Let's Encrypt周辺の標準化動向～
              (vol.1650)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2018/vol1650.html

なお、本号が2018年最後の発行となります。今年もご愛読いただきありがと
うございました。これからもみなさまのお役に立つ情報をお届けできるよう
努力して参りますので、2019年も引き続きJPNIC News & Viewsをよろしくお
願いいたします。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第103回IETF報告 [第6弾]  DNS関連WG報告
                           JPNIC 技術部／インターネット推進部 小山祐司
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

本稿では、タイ・バンコクで開催されたIETF 103におけるDNS関連の動向を、
dnsop WG、dnssd WG、サイドミーティングでの議論の様子を中心にご紹介し
ます。なお、DNSの通信を暗号化することを目的としたdprive WG、および
HTTPSを用いてDNSのメッセージをやりとりするDNS over HTTPSの策定を行う
doh WGについては、IETF 103では会合は開催されませんでした。


■ dnsop WG

DNSに関するプロトコルや運用方法について議論・標準化を行うdnsop WGミー
ティングが、2018年11月5日(月)に開催されました。議論となった主なドラフ
トは、以下の通りです。このうち、標準化の要望が高く議論も活発に行われ
た、draft-ietf-dnsop-serve-staleとdraft-ietf-dnsop-anameについてご紹
介します。

 - draft-ietf-dnsop-serve-stale
 - draft-ietf-dnsop-aname
 - draft-ietf-dnsop-rfc7816bis
 - draft-ietf-dnsop-7706bis
 - draft-mayrhofer-did-dns
 - draft-hoffman-dns-special-labels
 - draft-lhotka-dnsop-iana-class-type-yang

○draft-ietf-dnsop-serve-stale

このドラフトは、権威サーバからの応答がない時に、キャッシュサーバが過
去にキャッシュした、古いデータを再利用するというものです。従来のDNSの
仕様では、リソースレコード内のTTL (Time to live)で示された時間が経過
したキャッシュデータは、破棄することが求められています。

しかし現状として、権威サーバ自身や通信経路となるネットワークの障害、
DoS攻撃などで、権威サーバと通信できなくなることはしばしば発生します。
そうした状況では、権威サーバから新たにデータを取得することができなく
なり、DNSを利用するユーザーにデータを返すことができません。これを、
「古くなったパンでも無いよりはまし」といった考え方から、TTLで設定され
ている時間を越えた古いキャッシュでも利用できるように、TTLの定義を緩
和・再定義して、DNSを利用するサービスに影響がなるべく出ないようにしよ
うとする提案が、このドラフトです。

実は、TTLで設定されている時間を経過した古いキャッシュを利用する機能に
ついては、既にBIND 9やUnbound、OpenDNS等のリゾルバで実装されています。
しかし、各実装で挙動が異なっているのが現状です。
draft-ietf-dnsop-serve-staleが標準化されれば、挙動が統一され、運用上
の負荷軽減が期待されます。会場では、おおよそ好意的に受け止められ、ド
ラフトに書かれていなかったり曖昧だったりする部分について、どうするの
か議論が行われました。上記の通り、既に動作するrunning-codeが存在して
いますので、標準化作業は問題なく進むものと考えられています。

  スライド資料
  https://datatracker.ietf.org/meeting/103/materials/slides-103-dnsop-serve-stale-00.pdf

○draft-ietf-dnsop-aname

ドメイン名の利用方法として、"www.example.com"ではなく、"example.com"
でWebサービスなどを提供するといったことはよく行われます。またそれとは
別に、Webサービスを提供する際に自身でサーバなどを用意するのではなく、
ホスティングサービスを利用するといったことも行われます。こういった運
用形態で使われるDNSのレコードとして、正規名(エイリアス、別名)を設定す
るためのCNAMEがあります。しかし、現在のDNSの仕様ではCNAMEの利用方法に
は制約があり、CNAMEを他のタイプのレコードと同時に利用することは許され
ていません。例えば、

   www.example.com. IN CNAME third-party.cdn.example.net.

というCNAMEレコードを定義した場合、"www.example.com"ドメイン名に、IPv4
アドレスを設定するAレコードや、メール配送に関する設定を行うMXレコード
といった、他のレコードを記述してはならない、ということになっています。

こうした制約があるため、ゾーンの頂点にCNAMEを書くことができません。な
ぜなら、ゾーンの頂点には当該ゾーンの権威開始を表すSOAや、権威サーバの
指定を行うNSなどのレコードがあるためです。

例:
   example.com. IN SOA   ...
   example.com. IN NS    ...
   example.com. IN CNAME third-party.cdn.example.net.  (←不可)

しかし、上述の通り"example.com"のようなドメイン名でwebサービス等の提
供を行い、かつホスティングを他者に依頼したい、すなわちゾーンの頂点で
CNAMEのような機能を使いたいという要望があります。それを解決するために
提案されたのが、draft-ietf-dnsop-anameです。draft-ietf-dnsop-anameで
は、新たにAおよびAAAAレコードのみの別名を記述できる"ANAME"というレコー
ドを新設し、ゾーン頂点のIPアドレスの名前解決を、第三者の管理するDNS
サーバに振り向けられるようにしようという内容です。

例:
   example.com. IN ANAME third-party.cdn.example.net.

会場では、CNAMEとDNAMEを組み合わせれば解決できないかというコメントや、
それでは解決できないというさらなるコメント、また、当該ドメイン名で提
供しているサービスの場所を記述できる、SRVレコードを用いてはどうかとい
う議論などが出されました。会場での結論としては、根強い仕様拡張の要望
があり解決すべき問題であるため、今後も継続して議論することなどが確認
されました。

  スライド資料
  https://datatracker.ietf.org/meeting/103/materials/slides-103-dnsop-aname-etc-00.pdf


■ dnssd WG

dnssd WG (Extensions for Scalable DNS Service Discovery WG)は、DNSを
用いて、プリンターやWebカメラのようなネットワークに接続された機器の
サービスを、特別な設定なし(zero configuration)で、検索(ディスカバリー)
するプロトコルを策定するWGです。そのようなサービスディスカバリーとし
て利用できるプロトコルとしては、これまでにDNS-SD (RFC 6763)やmDNS
(RFC 6762)が標準化されています。しかし、いずれもマルチキャストを用い
た同一リンク・同一セグメント内のサービスディスカバリーを目的としてお
り、セグメントをまたいだ検索には対応していません。dnssd WGでは、これ
らを拡張する形で、複数のネットワークでもサービスディスカバリーができ
るように、新たにプロトコルを策定しようと議論が行われています。

今回のIETFで議論が行われた主なドラフトは、以下の通りです。このうち、
標準化目前のdraft-ietf-dnssd-hybridと、draft-ietf-dnssd-pushについて
ご紹介します。

 - draft-ietf-dnssd-hybrid
 - draft-cheshire-dnssd-roadmap
 - draft-ietf-dnssd-push
 - draft-ietf-dnssd-srp

○draft-ietf-dnssd-hybrid

draft-ietf-dnssd-hybridは、マルチキャストDNSと通常のユニキャストDNSと
を仲立ち(proxy)するプロトコルであり、"Discovery Proxy"と呼ばれ、dnssd
の中核となるものです。主な機能としては、クライアントはDiscovery Proxy
に通常のユニキャストを用いて名前解決を要求し、要求を受けたDiscovery
Proxyは接続されているセグメントに対して、mDNSやDNS-SDを用いてサービス
を探索し、得られた結果をクライアントに回答するというものです。こうす
ることで、セグメントをまたいだサービス探索が実現できるようになります。
このdraft-ietf-dnssd-hybridは、RFCとして発行目前となっており、まもな
く標準化される予定です。

○draft-ietf-dnssd-push

draft-ietf-dnssd-pushは、DNSのデータ変更について、サーバからクライア
ントに対して通知を行う機能を追加しようというドラフトです。

通常のDNSでは、クライアントからサーバに対して問い合わせを行い、サーバ
が結果を回答するという「クライアントプル」の動作を行います。これに対
して、データの変更があった場合に、サーバからクライアントに対して通知
する「サーバプッシュ」の仕組みを作ろうというものです。DNS上のデータの
変更が頻繁にある場合、クライアントプルでは短時間に何度も変更があった
かどうか問い合わせて、確認する必要が出てきます。これを、サーバプッシュ
を使用できるようにして、効率化を図ろうとするものです。会場では、提案
内容を元にして、running-codeを実装したという報告がありました。
draft-ietf-dnssd-pushは、2018年11月4日(日)時点でWGLC (Working Group
Last Call)の状態となっており、最終コメントの募集が行われています。

  スライド資料
  https://datatracker.ietf.org/meeting/103/materials/slides-103-dnssd-b3-cheshire-push-00

○dnssd におけるプライバシー

dnssd WGミーティングの最後に、dnssdで懸念されているプライバシーに関す
る議論が行われました。現在のmDNSやDNS-SDでは、マルチキャストによる問
い合わせを何の制限もなく行うことができ、また応答する側の機器やサービ
スも、無制限に応答する仕組みになっています。そのため、同じセグメント
に接続されているデバイス等が、すべて分かってしまうという特徴がありま
す。

これに対し、個人用スマートフォンのようなプライベートなデバイスなどは、
特定のデバイスに対してだけ応答したいという要望があります。しかし、こ
れまで根本的な解決策はなく、ディスカバリーで行われるパケットを暗号化
するなどの提案はいくつか行われていますが、それぞれに長所・短所があり、
採用に至っていません。今回の議論では、何らかの方法でデバイス情報を暗
号化し、サーバに登録する手法ではどうか、といった意見が出されました。
議論の結果として、WGドキュメントのdraft-ietf-dnssd-privacyを更新し、
方針等のとりまとめを行うことになりました。

  Privacy Extensions for DNS-SD
  https://tools.ietf.org/html/draft-ietf-dnssd-privacy-05


■ サイドミーティング

サイドミーティングは、特定のトピックについて興味のある人たちが集まっ
て、議論や意見交換を行う非公式なミーティングです。今回のIETFでも、複
数のサイドミーティングが開かれました。その中から、DNSに関係するサイド
ミーティングについてご紹介します。

○Resolverless DNS

DNSの名前解決で使われるリゾルバは、通常ネットワーク管理者等の指定する
DNSサーバを利用します。しかし、昨今の検閲やプライバシー問題から、それ
以外のDNSサーバを利用したいという要望があります。その解決策の一つとし
て、DNS over HTTPS (DoH)が標準化されています。

Resolverless DNSサイドミーティングでは、DoHの使い方や実装方法について
議論が行われました。主なトピックとしては、HTTPSを使うため名前解決の速
度低下が懸念されるがどのように解決するか、DoHのサーバから送られるデー
タの信頼性をどのように担保するか、ロードバランサやCDN (Content
Delivery Network)等の負荷分散・地域分散との相性問題をどうするか、など
がありました。

それぞれきちんとした結論が出たわけではありませんが、今後も継続して議
論する必要のある課題として、問題が参加者の間で共有されました。

○KSK RO future

2018年10月に行われた、ルートゾーンKSKロールオーバー(KSK RO)についての
振り返りや、将来のKSK ROについての意見交換が、KSK RO futureサイドミー
ティングで行われました。おおよそざっくばらんな意見の表明がミーティン
グでの主な流れでしたが、トピックとしては、KSK ROの実施による障害は小
規模なものを除き、発生しなかったことが参加者の間で確認されました。

また、今後のKSK ROについても、以下のようなトピックの議論や意見交換が
行われました。

 - 次のKSK ROをいつ行うか。「5年後」「1年後」「危殆化するまでやらな
   い」など。
 - 暗号アルゴリズムを変更するか。「ECDSA (Elliptic Curve Digital
   Signature Algorithm)」「EDDSA (Edwards-Curve Digital Security
   Algorithm)」など。
 - KSK RO対応が遅れた原因は、リゾルバの更新にコストがかかるからではな
   いか。アウトリーチ活動が必要。
 - 鍵の利用状況など、詳細な調査ができる新しいシグナリングの実装が欲し
   い。
 - 次のKSK ROに向けた詳しい調査が必要。今回のデータの収集やリサーチを
   する。


■ 最後に

本稿は、DNSを中心としたトピックについてご紹介しました。本稿以外でも、
ご紹介している通り、IETFにはDNS以外にも多岐にわたる分野のWGがあり、そ
れぞれ活発に議論が行われています。すべての分野についてご紹介するには
あまりにも多いためここでは割愛しますが、もしご興味がありましたら各WG
へのML参加、IETF会合への現地もしくはリモート参加をご検討いただければ
と思います。


     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
          まわりの方にもぜひNews & Viewsをオススメください！
      転送にあたっての注意や新規登録については文末をご覧ください。
                  ◇              ◇              ◇
       わからない用語については、【JPNIC用語集】をご参照ください。
             https://www.nic.ad.jp/ja/tech/glossary.html
     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～

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

 ＠ 発行  一般社団法人 日本ネットワークインフォメーションセンター
          101-0047 東京都千代田区内神田3-6-2 アーバンネット神田ビル4F
 ＠ 問い合わせ先  jpnic-news@nic.ad.jp
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
            本メールを転載・複製・再配布・引用される際には
        https://www.nic.ad.jp/ja/copyright.html をご確認ください
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
   ◇ JPNIC Webにも掲載していますので、情報共有にご活用ください ◇
登録・削除・変更   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), 2018 Japan Network Information Center