JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト

メールマガジン「FROM JPRS」

バックナンバー：vol.163

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2016/08/09━
                    ◆ FROM JPRS 増刊号 vol.163 ◆
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
                        第96回IETF Meeting報告
                 ～DNS関連／IETF本会議における話題～
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2016年7月17日から22日にかけて、第96回IETF Meeting（以下、IETF 96）がド
イツのベルリンで開催されました。

今回のFROM JPRSでは、IETF 96の模様を以下の項目に沿ってお伝えします。

  ・dnsop WGにおける話題
    - IETF 95以降のRFC発行状況
    - 議論された主な提案の内容と標準化作業の進行状況
    - DNS over TLSの実装状況
  ・ルートゾーンのZSK・KSKロールオーバーに関する話題
  ・「Pecha Kucha」イベントの開催
  ・次回のIETF Meetingについて

          ◇                     ◇                     ◇

■dnsop WGにおける話題

dnsopはDNS Operationsに由来しており、DNSサーバーや登録情報の管理など、
DNSの運用全般に関するガイドラインの作成を目的としています。WGでは、運
用上の課題に着目したDNSプロトコルの拡張・メンテナンスも活動項目として
います。

▼IETF 95以降のRFC発行状況

前回のIETF 95から2016年7月27日までに発行されたRFCは、以下の3本です。

  ・EDNS0によるDNSクライアントのネットワーク情報の伝達
    （draft-ietf-dnsop-edns-client-subnet、RFC 7871：Informational）

    DNSメッセージにネットワーク情報（クライアントのIPアドレス）を含め
    るためのEDNS0オプションを定義し、使い方を記述しています。

    Public DNSサービスなどにおいて、権威DNSサーバーへのクエリにクライ
    アントIPアドレスを追加するために使われます。CDNなどの権威DNSサー
    バーでは追加されたクライアントIPアドレスを参照して、応答するIPアド
    レスを最適なものに設定します。

  ・DNSクッキー
    （draft-ietf-dnsop-cookies、RFC 7873：Standards Track）

    通信路外からの攻撃によるDNSメッセージの偽造防止のために、クライア
    ント側でランダムなクッキーを追加するためのEDNSオプションを定義し、
    使い方を記述しています。

  ・EDNS0によるChain Query機能
    （draft-ietf-dnsop-edns-chain-query、RFC 7901：Experimental）

    フルリゾルバー（キャッシュDNSサーバー）に対しDNSSEC検証に必要な情
    報をまとめて送り返すことを要求するためのEDNS0オプションを定義し、
    使い方を記述しています。

▼議論された主な提案の内容と標準化作業の進行状況

ここでは、FROM JPRS編集局が注目した提案の内容と標準化作業の進行状況に
ついて紹介します。

▽DNS用語の明確化（draft-ietf-dnsop-dns-terminology-bis）

DNS関連のさまざまなRFCで定義された数多くの用語を一つのドキュメントにま
とめた、RFC 7719を改版するための提案です。なお、本提案はJPRSの藤原和典
が共著者となっています。

今回のWGではNSEC3、ワイルドカード関連、正引き・逆引きといった用語の追
加を行ったことの報告と、提案のレビュアーを募集中であることが発表されま
した。

▽NSEC/NSEC3の積極的な活用（draft-ietf-dnsop-nsec-aggressiveuse）

DNSSECの不在証明の仕組みを積極的に活用して、名前解決のパフォーマンス改
善を図る、プロトコル変更のための提案です。なお、本提案はJPRSの藤原和典
が共著者となっています。

前回のIETF 95におけるWGでの議論の結果を受け、GoogleのWallen Kumari氏の
draft-wkumari-dnsop-cheese-shop提案とマージされ、共著者にKumari氏が加
わりました。今回のWGでは、Kumari氏がGoogle Public DNSにおける実装結果
を紹介しています。

▽同一名に対する複数タイプの問い合わせ（draft-bellis-dnsext-multi-
  qtypes）

一つのDNSクエリで同時に複数のクエリタイプ（QTYPE）を問い合わせるEDNS0
の拡張を行う、プロトコル変更のための提案です。

本提案では、一つのクエリ内にクエリタイプを列挙したEDNS0 Optionを追加し
ています。A/AAAA・A/MXなど、現在は複数のクエリを送信する必要のある問い
合わせを、一つのクエリで処理できるようにすることが目的です。

▽複数応答の返答（draft-wkumari-dnsop-multiple-responses）

権威DNSサーバーからの応答のAdditional Sectionに問い合わせされた名前／
タイプ以外のリソースレコード（以下、RR）の追加を行う、プロトコル変更の
ための提案です。

本提案では、あるRRの問い合わせの直後に問い合わせされる可能性の高いRRを
フルリゾルバーに事前投入（pre-populate）することで、名前解決に要するコ
ストを減少させることを目的としています。

提案では、追加する条件を権威DNSサーバー側で記述するためのEXTRA RRを定
義しており、www.example.comのAレコードの応答に、images.example.comのA
レコードやcss.example.comのAレコードを追加する例が紹介されています。

前述したdraft-bellis-dnsext-multi-qtypesでは、クライアントが同一名の別
のタイプをリゾルバーに追加して問い合わせを行います。対して、本提案では
権威DNSサーバーがリゾルバーから受け取った問い合わせに対し、ゾーン管理
者が指定した別の名前／タイプのRRを追加して返すという点が異なります。

今回のWGでは、応答サイズの増大がDoSの原因となりうることや、DNS64やRFC
7871（Client Subnet in DNS Queries）との組み合わせで問題が起きうること
などを懸念する声が上がりました。

▽BULK RRによる拡張（draft-woodworth-bulk-rr）

IPv6の逆引きなどを機械的に記述できるようにDNSのゾーンファイルフォー
マットをアップデートし、BIND 9の$GENERATEディレクティブに機能を追加し
たものを標準化するための提案です。

BIND 9の$GENERATEディレクティブでは、連番のホスト名・IPアドレスのルー
ルを記述すると、ゾーンファイル読み込み時にメモリ上へ個々のRRが展開され
ます。本提案では、個別のRRには展開せず、BULK RRのまま処理を行うことで、
ゾーン転送の帯域やメモリの利用量を最小化すること、IPv6のような非常に広
いネットワーク空間の逆引きを管理可能にすることを目的としています。

今回のWGでは、DNSSECで不在応答の生成を行う場合において、動的に署名する
（オンザフライ）ことの確認などが行われました。

▼DNS over TLSの実装状況

今回のWGでは、TLS（*1）を利用してDNSにプライバシー保護の機能を提供する
DNS over TLS（*2）の実装状況が報告されました。DNS over TLSは、RFC 7858
として標準化されています。

（*1）Transport Layer Securityの略称。
      TCPのようなコネクション型プロトコルにおいて、暗号通信を行うための
      プロトコルです。

（*2）DNS over TLSの詳細は、過去のドメイン名関連会議報告をご参照くださ
      い。
      https://jprs.jp/related-info/event/2015/1207IETF.html

報告では、DNS over TLS専用のポート番号として割り当てられた853/tcpの利
用可否の状況など、各ソフトウェアにおけるDNS over TLSの実装状況がまとめ
られています。

また、テストベッドとして実際にDNS over TLSを試用できる環境についても紹
介されています。

■ルートゾーンのZSK・KSKロールオーバーに関する話題

IETF 96期間中の7月19日に「Upcoming ZSK and KSK Changes to ther Root
Zone」が、IABの支援を受けてVerisign及びICANNから解説されました。

DNSSECで用いられる鍵にはKSK（鍵署名鍵）とZSK（ゾーン署名鍵）の2種類が
存在し、ルートゾーンにおいてKSKはICANNが、ZSKはVerisignが管理していま
す。

KSKのロールオーバーについては、ICANNの担当者から日程の概要が発表されま
した。主なマイルストーンとして、次の予定が公開されています。

  ・2016年10月 新KSKを生成
  ・2017年 2月 IANA Webサイトにおいて新KSKを公開
  ・2017年 7月 ルートサーバーにおいて新KSKを公開
  ・2017年10月 新KSKをDNSKEYとRRの署名に使用
  ・2018年 1月 旧KSKを廃止
  ・2018年 3月 旧KSKを安全に抹消し、KSKロールオーバープロセスを完了

今回のKSKロールオーバーが実行される間、ルートサーバーに対するプライミ
ング（*3）問い合わせの応答サイズが1,139バイトから1,425バイトに増加し
ます。

（*3）プライミング：priming
      フルリゾルバーが名前解決を実行する前にルートゾーンのネームサー
      バー情報（NSレコード）をルートサーバーに問い合わせ、自身のネーム
      サーバー情報を初期化すること。

ICANNでは今回のKSKロールオーバーによる影響の規模として、インターネット
ユーザーの4人に1人、すなわち7.5億人が影響を受ける可能性があると予測し
ています。

対応として、DNSSECバリデーターにおいてRFC 5011のトラストアンカーの自動
更新を有効にする（*4）ことが推奨されています。

（*4）Internet Week 2015「今日から始めるDNSSECバリデーション」で東京大
      学の石原知洋氏が発表した、BINDとUnboundにおけるトラストアンカーの
      自動更新の設定方法と設定後の動作を解説した資料が公開されています。
      Root KSK更新に対応する方法
      https://www.nic.ad.jp/ja/materials/iw/2015/proceedings/t5/t5-ishihara.pdf

KSKロールオーバー計画の詳細は、「Operational Plans」として5本のドキュ
メントにまとめられています。また、KSKロールオーバーの概要とよくある質
問が2本のドキュメント「KSK Rollover at a Glance」、「KSK Rollover:
Questions and Answers」に簡潔にまとめられています。

これらのドキュメントは、ICANNのKSKロールオーバー公式ページで公開されて
います（関連URIを参照）。

ZSKのロールオーバーについては、Verisignが2016年4月1日の24回目のOARC
Workshopで発表した内容と、5月6日に公式ブログで公開した内容（*5）につい
て、Verisignの担当者から改めて説明がなされました。

（*5）ルートゾーンにおけるZSKサイズの拡大予定の詳細は、過去のドメイン
      名関連会議報告をご参照ください。
      https://jprs.jp/related-info/event/2016/0520IETF.html

■「Pecha Kucha」イベントの開催

IETF 96期間中の7月21日に「Pecha Kucha」という、非公式なイベントが開催
されました（*6）。Pecha Kuchaは日本語の「ぺちゃくちゃ」に由来しており、
ライトニングトーク（*7）の形で、1枚につき20秒で自動的に切り替わる画像
イメージで構成された20枚の資料を使って、自分の制作物やアイディアなどを
連続的に紹介していく発表形式を表しています（*8）。

（*6）今回の発表は、IETF 96参加者のメーリングリスト上で募集されました。
      [96attendees] Bad Attitude Pecha Kucha
      https://ietf.org/mail-archive/web/96attendees/current/msg00047.html

（*7）現在進行中のさまざまな事柄について、限られた時間で状況報告を連続
      的に行う発表形式です。

（*8）一人あたりの発表時間は6分40秒ということになります。

今回のPecha Kuchaは、その日の会議が終了した22:30から始められましたが、
80名ほどを収容する会場で立ち見が出るほどの人数が参加しており、話題を集
めていました。発表者にはIAB Chairを務めるAndrew Sullivan氏をはじめ、イ
ンターネットのさまざまな分野で長年にわたって活動している著名人も参加し
ており、「Bad Attitude」と題されている通りジョークや皮肉などが多用され
たさまざまな発表が行われ、会場は笑いと称賛にあふれていました（*9）。

（*9）当日の発表資料と動画が、以下のページで公開されています。
      Bad Attitude Pecha Kucha
      http://snaggletooth.akam.ai/

■次回のIETF Meetingについて

次回の第97回IETF Meeting（IETF 97）は2016年11月13日から18日にかけ、韓
国のソウルで開催されます。

          ◇                     ◇                     ◇

◎関連URI

  - 96 Meeting Index
    https://www.ietf.org/meeting/96/
    （IETF 96公式ページ）

  - IETF 96 meeting materials
    https://datatracker.ietf.org/meeting/96/materials.html
    （IETF 96発表資料一覧）

  - Domain Name System Operations (dnsop)
    https://datatracker.ietf.org/wg/dnsop/charter/
    （dnsop WG公式ページ）

  - Root Zone KSK Rollover - ICANN
    https://www.icann.org/resources/pages/ksk-rollover
    （KSKロールオーバー公式ページ（ICANN））

━━━━━━━━━━━━━━━━━━━━━━━━━━━【FROM JPRS】━
■会議報告：https://jprs.jp/related-info/event/
■配信先メールアドレスなどの変更：https://jprs.jp/mail/henkou.html
■バックナンバー：https://jprs.jp/mail/backnumber/
■ご意見・ご要望：from@jprs.jp

当メールマガジンは、Windowsをお使いの方はMSゴシック、Macをお使いの方は
Osaka等幅などの「等幅フォント」で最適にご覧いただけます。

当メールマガジンの全文または一部の文章をWebサイト、メーリングリスト、
ニュースグループ、他のメディアなどへ許可なく転載することを禁止します。
また、当メールマガジンには第三者のサイトへのリンクが含まれていますが、
リンク先のサイトの内容などについては、JPRSの責任の範囲外であることに
ご注意ください。
その他、ご利用に当たっての注意事項は読者登録規約にてご確認ください。
https://jprs.jp/mail/kiyaku.html
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
編集・発行：株式会社日本レジストリサービス（JPRS）
https://jprs.jp/
Copyright (C), 2016 Japan Registry Services Co., Ltd.

※更新履歴
2016/08/10　一部修正