バックナンバー：vol.171

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2017/08/29━
                    ◆ FROM JPRS 増刊号 vol.171 ◆
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
                    第99回IETF Meeting（プラハ）報告
                ～DNS関連WG、及び周辺会合における話題～
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2017年7月16日から21日にかけて、第99回IETF Meeting（以下、IETF 99）が
チェコのプラハで開催されました。

今回のFROM JPRSでは、IETF 99における議論から、FROM JPRS編集局が注目し
た以下の話題をお伝えします。

  ・dnsop WGにおける話題
    - IETF 98以降のRFC発行状況
    - 議論された提案の内容と標準化作業の進行状況
  ・新たなトランスポートプロトコルのDNSへの適用
    - DNS over QUIC
    - DNS over HTTPS
  ・IEPG会合における話題
    - DNSSECの全自動化
    - Root Canary Project
  ・次回のIETF Meetingについて

          ◇                     ◇                     ◇

■dnsop WGにおける話題

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

▼IETF 98以降のRFC発行状況

前回のIETF 98以降に発行されたRFCは、以下の2本です。

  ・RFC 8145: DNSSECバリデーターから権威DNSサーバーへのトラストアン
    カーの伝達
    （Standards Track、draft-ietf-dnsop-edns-key-tag）

    DNSSECバリデーターとなっているリゾルバーが、使用中のトラストアン
    カーの情報（トラストアンカーの鍵タグ、あるいはトラストアンカーで指
    定されるゾーンからのDNS応答により入手したDSレコードの鍵タグ）を、
    対象のゾーンを管理する権威DNSサーバー（通常はルートサーバー）に伝
    達する機能を定義します。

    本機能により、DNSSECバリデーターが使用中のトラストアンカーの情報を
    権威DNSサーバーに定期的に送信する機能が提供されます。権威DNSサー
    バー側で各バリデーターから送られるトラストアンカー情報を調べること
    により、トラストアンカーに対応する鍵署名鍵（KSK）のロールオーバー
    の進行状況を確認できるようになります。

  ・RFC 8198: DNSSEC検証済のキャッシュデータを活用したDNSの性能向上
    （Standards Track、draft-ietf-dnsop-nsec-aggressiveuse）

    DNSSECのプロトコル変更について定めたRFC 4035の内容を一部更新するも
    ので、DNSSECバリデーターとなっているリゾルバーにおいて、DNSSEC検証
    済のキャッシュされた応答を不在応答やワイルドカードによる応答の生成
    に利用することで、名前解決のパフォーマンスの向上や遅延・負荷の減少
    を図るものです。

    このRFC 8198は、JPRSの藤原和典が著者の一人となっています。
    https://jprs.co.jp/topics/2017/170726.html

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

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

▽TSIGの脆弱性をきっかけとしたRFC 2845の改訂着手

2017年6月に、Knot DNSとBINDにおいてTSIG（*1）実装の脆弱性が発表されま
した。

脆弱性対応を進める中で、TSIGのプロトコル仕様を定めたRFC 2845の更新が必
要であると判断され、今後RFC 2845の改訂を進める予定であることが共有され
ました。

（*1）RFC 2845で定義される、DNSの通信（トランザクション）に共有鍵を用
      いた署名を付加し、通信の安全性を高めるための仕組みです。TSIGを利
      用することで、ゾーン転送、DNS NOTIFY、Dynamic Updateなどにおいて
      通信相手を認証し、通信路におけるデータの改ざんを検知できます。

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

本提案はDNS用語集であるRFC 7719を改訂するもので、RFC 7719に引き続き
JPRSの藤原和典が著者の一人となっています。

今回の改定版では、現在異なる二つの文脈で使われている内部名
（in-bailiwick）という用語を、それぞれの意味ごとに「in-domain」と
「sibling domain」の二つに分割して再定義することをはじめとする、いくつ
かの用語の追加・改訂が盛り込まれました。詳細はJPRS用語辞典をご参照くだ
さい。
https://jprs.jp/glossary/index.php?ID=0190

▽ANAMEリソースレコードの定義（draft-ietf-dnsop-aname）

ANAME（Address-specific DNS Name Redirection）という、CNAMEレコードと
同様の機能を提供する、他のリソースレコードと共に指定可能な新しいリソー
スレコードを定義するための提案です。

CDNサービスを利用する際、サービス対象のホスト名に対し、CDN事業者のホス
ト名をCNAMEレコードで指定する方式が普及しています。しかし、サービス対
象のホスト名がゾーン頂点の名前であった場合、その名前にはSOAレコードと
NSレコードが必ず存在しており、CNAMEレコードを指定することができません。

そのため、一部のCDNサービスではゾーン頂点のA/AAAAの問い合わせに対し、
CNAMEを返す権威DNSサーバーを実装・運用しています。しかし、この動作は
DNSでは推奨されていません。

本提案は、ANAMEが指定された名前に対しA/AAAAレコードが問い合わされた場
合、権威DNSサーバー側で名前解決と変換を実施し対応するA/AAAAレコードを
応答することで、この問題を解決することを目的としています。

WGでは、仕様が複雑すぎることや、DNSSECに対応する場合、権威DNSサーバー
においてオンライン署名が必須となる点などについて活発な議論が交され、継
続して作業を進めることとなりました。

▽期限切れキャッシュによる名前解決の継続（draft-tale-dnsop-serve-stale）

名前解決においてリゾルバーがすべての権威DNSサーバーに到達できなかった
場合に、期限切れとなったキャッシュを使って名前解決を継続可能にするため
の提案です。

本提案は、DDoS攻撃や事故などで当該ゾーンの権威DNSサーバーに到達できな
い状態が続いた際に、名前解決エラーの発生を回避することを目的としていま
す。Akamai Technologies（以下Akamai）とGoogleの社員が著者となっており、
一部のパブリックDNSサービスにおいて既に実装されています。

発表では、発表者が所属するAkamaiはBIND 9にパッチを当てて本提案を6年間
運用している実績があること、そのパッチを開発元のISCに提供したこと、本
提案の手法はAkamaiとGoogleが特許を保有しているが、無償で利用可能とする
ことを計画していることなどが報告されました。

WGでは、OpenDNSも特許が存在する旨のクレームを出しているのではないかと
いう指摘や、標準化の前に本提案における要求事項の定義から始めるべきであ
るといった意見が出され、継続して作業を進めることとなりました。

▽EDNS0を用いたエラーコードの拡張（draft-wkumari-dnsop-extended-error）

EDNS0（*2）を用いてDNSのエラーコードを拡張するための、プロトコル拡張の
提案です。

RFC 1035で定義されるDNSの応答コード（RCODE）は4ビットであり、0から15ま
での値しか返すことができません。そのため、DNSSEC検証エラーやサーバーの
高負荷時においても通常の名前解決エラーと同じエラーコード（ServFail）し
か返せず、クライアント側から状況を把握できないことが課題となっていまし
た。

本提案は、EDNS0に用意されている8ビットの拡張応答コードを用いてServFail
エラーを拡張し、DNSSEC検証エラーを含むより詳細なエラーコードを返せるよ
うにするもので、DNSSEC Bogus、DNSSEC Indeterminate、Lame、Prohibited、
Too Budyといったエラーコードが新たに定義されています。

WGでは、本提案をサポートする意見が多く、継続して作業を進めることとなり
ました。

（*2）RFC 6891で定義されたDNSの拡張方式で、512バイトよりも大きなメッ
      セージサイズをUDPで扱えるように拡張し、フラグや応答コードも拡張
      します。詳細はJPRS用語辞典をご参照ください。
      https://jprs.jp/glossary/index.php?ID=0147

■新たなトランスポートプロトコルのDNSへの適用

▼DNS over QUIC（draft-huitema-quic-dnsoquic）

今回のdprive WG（*3）において、DNSのトランスポートプロトコルとしてQUIC
（*4）を使用するための提案（DNS over QUIC）が発表されました。

本提案はquic WGにおいて発表されたものですが、今回、dprive WGにも持ち込
まれました。

その背景として、QUICが通信路の暗号化機能を備えておりDNS over TLSと同様
の機密性を提供すること、最初にスタブリゾルバーとフルリゾルバー（キャッ
シュDNSサーバー）の間の通信への適用、続いてフルリゾルバーと権威DNSサー
バー間の通信への適用という、DNS over TLSと同様の形での普及が見込めるこ
とが挙げられました。

WGでは、関心を持つ人が多かったものの、dprive WGで本件を取り扱うために
はチャーターの改訂が必要になるため、標準化活動の開始には時間を要するこ
とが見込まれます。

（*3）dpriveはDNS PRIVate Exchangeに由来しており、DNSトランザクション
      における機密性（confidentiality）の提供を目的としています。

（*4）Googleが開発を進めている通信プロトコルです。仕様が公開されており、
      軽量な通信プロトコルであるUDPをベースとしながら、従来のTCPと同等
      の信頼性や、TLSと同等のセキュリティの実現を目指しています。

▼DNS over HTTPS（draft-hoffman-dispatch-dns-over-https）

また、今回のdispatch WG（*5）において、DNSの通信をHTTPSの通信路で実現
するための提案（DNS over HTTPS）が発表されました。

提案では、HTTPS通信のメッセージ本体にDNSのワイヤーフォーマット（ビット
列形式のバイナリフォーマット）をそのまま用いる、もしくはDNS問い合わせ・
応答をJSON（*6）で表現することで、DNSの通信をHTTPS上で実現可能にしてい
ます。

本提案により、現在HTTPSで使われているさまざまな技術を、DNSの通信にその
まま適用できるようになります。

WGでは、Webブラウザーベンダーの担当者が好意的な意見を述べていた一方、
DNSプライバシーの議論に発展し、今後の進め方については改めてdprive WGと
調整することになりました。

なお、dprive WGとdispatch WGの後で開催されたdnsop WGの2回目のセッショ
ンでDNS over QUICとDNS over HTTPSの提案が紹介された際、WGチェアが「DNS
Over New Transport（DONT）」という、類似の提案が相次いで出されている状
況を若干の皮肉を込めた略称で紹介し、参加者の笑いを取っていました。

（*5）dispatchは、ART（Applications and Real-Time Area）エリアにおける
      新提案の作業方針を検討するために設立されたWGです。

（*6）JavaScript Object Notationの略称。JavaScriptのオブジェクト表記方
      法に由来する簡便なデータ記述法。

■IEPG会合における話題

IEPG（Internet Engineering and Planning Group）は、IETF会合に先立って
開催される会合で、インターネットの運用に関連するさまざまなテーマを取り
扱っています。

▼DNSSECの全自動化

チェコのccTLDレジストリであるCZ.NICのOndrej Sury氏が、DNSSECの全自動化
の試みと、.czにおける実装状況について発表しました。

同氏からは、レジストリシステムにCZ.NICが開発・公開しているFREDを用い、
DNSSEC署名にKnot DNSを用いることで、.czにおいてCDS/CDNSKEYレコード（*7）
を用いたKSKロールオーバーの自動化を実装したことが発表されました。

この実装では、.czに登録済みのすべてのドメイン名のCDNSKEYをTCPによる問
い合わせで入手した後にDNSSEC検証を実施し、それらが置き換わった場合に
RFC 7344とRFC 8078（*8）の仕組みによって.czのDSを自動的に書き換え、当
該ドメイン名の技術連絡担当者とレジストラに連絡する仕組みとなっています。

また、今後実装する予定の機能として、登録者・レジストラ以外のDNSオペ
レーターによるDSレコードの自動更新（*9）のためのAPIと、アルゴリズム
ロールオーバーの全自動化が示されました。

（*7）CDS/CDNSKEYレコードの詳細は、過去のドメイン名関連会議報告をご参
      照ください。
      https://jprs.jp/related-info/event/2017/0421IETF.html

（*8）CDS/CDNSKEYの定義と、それらを用いてDSレコード書き換えを自動化す
      るための手法が記述されています。詳細につきましては、過去のドメイ
      ン名関連会議報告をご参照ください。
      https://jprs.jp/related-info/event/2017/0421IETF.html

（*9）regext WGに、draft-ietf-regext-dnsoperator-to-rrr-protocolとして
      提案されています。

▼Root Canary Project

NLnet LabsのWillem Toorop氏が、2017年7月から2018年3月にかけてルート
サーバーで実施されるルートゾーンKSKロールオーバー（*10）の影響について、
計測と監視により、状況を早期に把握するために始められた「Root Canary
Project」の概要について紹介しました。本プロジェクトは、オランダの5組織
（SURFnet、the University of Twente、Northeastern University、
NLnet Labs、SIDN Labs）及びthe RIPE NCCとICANNの7者による合同プロジェ
クトとなっています。

プロジェクト名のCanary（カナリア）は「炭鉱のカナリア（Canary in the
coalmine）」に由来しており、炭鉱で発生する酸欠や有害ガスを、人間よりも
敏感なカナリアを使って早期発見していることと同様、ルートゾーンKSKロー
ルオーバーによる影響を早期に検知・把握することを目指しています。

同氏からは今後、ルートゾーンKSKロールオーバーによる異常や影響について、
本プロジェクトの公式サイトで情報提供を進めていくことが発表されました。

なお、同プロジェクトの公式ページでは、使用中のフルリゾルバーがどのよう
なDSアルゴリズムとDNSSEC署名アルゴリズムの検証をサポートしているかを確
認可能なテストページを公開しており、トップページから「Algorithm Test」
→「Start Test」で実行できます。
https://rootcanary.org/

（*10）ルートゾーンで用いている二種類のDNSSEC署名鍵のうち、鍵署名鍵
       （KSK）を新しいものに更新することで、2016年から2017年にかけて実
       施されます。
       本件による影響とその確認方法につきましては、JPRSが公開した以下
       の注意喚起をご参照ください。
       https://jprs.jp/tech/notice/2017-07-10-root-zone-ksk-rollover.html

■次回のIETF Meetingについて

次回の第100回IETF Meeting（IETF 100）は2017年11月11日から17日にかけて、
シンガポールで開催されます。

          ◇                     ◇                     ◇

◎関連URI

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

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

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

  - Knot DNS
    https://www.knot-dns.cz/
    （チェコのccTLDレジストリであるCZ.NICが開発・公開している、オープン
      ソースの権威DNSサーバー）

  - （緊急）BIND 9.xの脆弱性（TSIG認証の迂回によるゾーンデータの操作）
    について（CVE-2017-3143）
    https://jprs.jp/tech/security/2017-06-30-bind9-vuln-circumvent-tsig-auth-dynamic-update.html
    （BINDにおけるTSIG実装の脆弱性についてのJPRSからの注意喚起）

  - BIND 9.xの脆弱性（TSIG認証の迂回によるゾーンデータの流出）について
    （CVE-2017-3142）
    https://jprs.jp/tech/security/2017-06-30-bind9-vuln-circumvent-tsig-auth-axfr.html
    （BINDにおけるTSIG実装の脆弱性についてのJPRSからの注意喚起）

  - Dispatch (dispatch)
    https://datatracker.ietf.org/wg/dispatch/charter/
    （dispatch WG公式ページ）

  - IEPG Meeting - July 2017
    https://iepg.org/2017-07-16-ietf99/
    （2017年7月のIEPG Meeting公式ページ）

  - Introducing FRED - fred
    https://fred.nic.cz/
    （FRED公式ページ）

  - Root Canary
    https://rootcanary.org/
    （Root Canary Project公式ページ）

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

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

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