バックナンバー：vol.158

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2015/12/07━
                    ◆ FROM JPRS 増刊号 vol.158 ◆
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
                        第94回IETF Meeting報告
            ～DNS／レジストリ関連／IETF全般における話題～
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2015年11月1日から6日にかけて、第94回IETF Meeting（以下、IETF 94）が横浜
で開催されました。今回のFROM JPRSでは、IETF 94の内容について報告します。

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

  ・dnsop WGにおける話題
    - RFC 6761の問題点に関する議論
    - 標準化作業の進行状況
  ・dprive WGにおける話題
    - RFC 7626がInformational RFCとして発行
    - DNS over TLSとDNS over DTLS
    - 今後のWGの方向性について
  ・eppext WGにおける話題
    - チャーターの改定と今後の作業方針
  ・lager WGにおける話題
    - 背景
    - lager WGの新設
    - 今回の議論の内容
  ・その他の主なDNS・レジストリ関連WGの状況
  ・IETF全般における話題
    - チュートリアル
    - JPRSがBits-N-Bitesに出展
  ・次回のIETF Meeting

          ◇                     ◇                     ◇

■dnsop WGにおける話題

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

▼RFC 6761の問題点に関する議論

今回のdnsop WGでは、特殊用途ドメイン名（Special-Use Domain Name）を定
義する、RFC 6761の問題点に関する議論が行われました（*1）。

（*1）これまでの特殊用途ドメイン名と.onionを含む内部利用名の取り扱い
      についての概要は、過去のドメイン名関連会議報告をご参照ください。
      http://jprs.jp/related-info/event/2015/0424IETF.html
      http://jprs.jp/related-info/event/2015/0820IETF.html

いくつかの特殊用途ドメイン名ではTLDラベルの内容により、参照するシステ
ムや名前空間（name space）が変更されます。例えば、.localではDNSに替え
てmDNS（*2）が参照され、今回予約された.onionではTor（*3）内部で定義さ
れる専用の名前空間が参照されます。

（*2）Multicast DNSとしてRFC 6762/6763で定義され、DNSとは別の名前空間
      が使われます。

（*3）TCP/IPにおける接続経路（どの機器がどのネットワーク経由で接続した
      か）の匿名性を高めるための技術で、米国のTor Project, Inc.により
      開発されています。

このように、TLDラベルによって参照するシステムや名前空間を変更する場合、
そのラベルが特殊なものであり、DNS以外のシステムやインターネット以外の
名前空間を参照する必要があることが広く認識され、かつ適切に対応されてい
る必要があります。そのためにはそのラベルを特殊用途ドメイン名として単に
予約するだけでは不十分であり、正しく機能しないこととなります。

今回、この問題に対応するためのデザインチームがdnsop WG内に組織され、作
業の結果がインターネットドラフト（draft-adpkja-dnsop-special-names-
problem）としてまとめられました。

今回のWGではデザインチームから、現時点において考えている問題解決の方向
性として、以下の五つが示されました。

  ・RFC 6761による予約をやめる
  ・プロトコル変更用として.alt TLDを新設する
  ・ICANNと協働で、新しい予約プロセスを策定する
  ・URIスキームを用いた別の識別子を作る（*4）
  ・その他の方法を考える

（*4）「http-onion://foo」「http:/onion/foo」といった形でURIスキームを
      変更する案が提示されましたが、既存のインターネットへの影響が大き
      く、否定的な意見が多く出ました。

その後、参加者による活発な議論が行われましたが結論には至らず、今後も議
論を継続していくこととなりました。今回の議論にはIETFチェアも参加してお
り、チェアからはこの問題はIESGが決めるものではなく、コミュニティで議論
すべきものであるという発言がありました。

なお、会場からは、これはプロトコルの話ではなく名前空間の利用の話であり、
IETFで議論すべき内容ではないのではないか、という意見もありました（*5）。

（*5）IETF参加者のICANN・TLDに対する認識については、過去のドメイン名関
      連会議報告をご参照ください。
      http://jprs.jp/related-info/event/2014/1224IETF.html

また、今後の特殊用途ドメイン名の予約はこの問題の解決後とすることが、WG
チェアから示されました。

▼標準化作業の進行状況

dnsop WGでは最近、プロトコル変更・拡張に関する活発な提案と標準化作業が
進められています。ここでは、最近の主な提案の内容と標準化作業の進行状況
について、簡単に紹介します。

▽クエリタイプANYのレスポンスサイズの小型化（draft-jabley-dnsop-
  refuse-any）

DNSリフレクター攻撃の防止のため、ANYリソースレコード（RR）に対する応答
の仕様を変更してサイズを小さくする、プロトコル変更の提案です。

今回のWGではANY RRに対する応答として、知っているRRをできるだけ返すとい
う現在の仕様に替え、サイズの小さい別のRR（*6）を返すようにするという仕
様が提案され、今後WGとして標準化作業を進めていくこととなりました（*7）。

（*6）インターネットドラフトでは応答を生成する際、HINFO RRを返す方法が
      提案されています。

（*7）2015年11月4日に更新版のインターネットドラフトがWG Draftとして発
      行されました（draft-dnsop-refuse-any-00）。

▽DNSメッセージへのハッシュの付加（draft-muks-dnsop-dns-message-
  checksums）

第一フラグメント便乗攻撃（*8）への対策、及びキャッシュポイズニング攻撃
への耐性強化（DNSメッセージのエントロピーの増加）のため、DNSメッセージ
にnonce（*9）を付加した上でEDNS0により全体のハッシュを付加する、プロト
コル拡張のための提案です。

今回のWGでは提案内容や効果について興味を持つ人がいる反面、IPv6であれば
必要ない、プロトコルが複雑になり過ぎるといった意見もあり、今後議論を継
続することとなりました。

（*8）第一フラグメント便乗攻撃の内容については、以下の資料をご参照くださ
      い。
      http://jprs.jp/tech/material/iw2013-lunch-L3-01.pdf

（*9）nonce：number used only onceに由来し、一度しか使われない（毎回
      変更される）番号や文字列を意味しています。

▽EDNS0のオプションフォーマットへの鍵タグ追加（draft-wessels-edns-
  key-tag）

EDNS0に新しいオプションを追加し、鍵タグ（*10）の情報をクライアント側か
らサーバー側に伝えられるようにする、プロトコル拡張のための提案です。

これを利用することで、トラストアンカーの自動更新（*11）における新しい
トラストアンカーの利用状況を把握できます。今回のWGでは主に動作について
の確認が行われ、今後WGとして標準化作業を進めていくこととなりました。

（*10）DNSSECの公開鍵を効率的に選択・特定するために付けられる数値です。

（*11）RFC 5011で定義され、DNSSEC運用の負荷を軽減することを目的として
       います。

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

JPRSの藤原和典が提案している、DNSSECの不在証明の仕組みを積極的に活用す
ることでDNS水責め攻撃（*12）の影響緩和を図る、プロトコル変更のための提
案です。

本提案では、応答されたNSEC/NSEC3レコードのキャッシュを積極的に活用する
ことで権威DNSサーバーへの問い合わせ数を減らすと共にリゾルバーの処理コ
ストを軽減させ、DNS水責め攻撃の影響緩和を図っています。

（*12）DNS水責め攻撃の概要については、以下の資料をご参照ください。
       http://jprs.jp/tech/material/iw2014-lunch-L3-01.pdf

今回のWGではこの提案に関する議論は行われませんでしたが、WG Draftとして採
択される候補（candidate for WG adoption）となりました。

■dprive WGにおける話題

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

▼RFC 7626がInformational RFCとして発行

DNSにおけるプライバシーに関する考慮事項をまとめたRFC 7626（DNS Privacy
Considerations）が、Informational RFCとして発行されました。

RFC 7626ではDNSにおけるプライバシーのリスクについて、問い合わせ名の最
小化（qname minimisation）（*13）とDNSの通信の暗号化の必要性、その考慮
事項について記述しています。

（*13）qname minimisationの詳細は、過去のドメイン名関連会議報告をご参
       照ください。
       http://jprs.jp/related-info/event/2015/0421IETF.html

▼DNS over TLSとDNS over DTLS

dprive WGではDNSの通信を暗号化するための提案として、DNS over TLS（*14）
とDNS over DTLSの二つの方式の標準化が進められています。

（*14）IETF 93終了後に、それまでのTLS for DNSから、用いている仕組みを
       より明確に反映したDNS over TLSに、名称が変更されています。

DNS over TLSはHTTPSで用いられているTLS（*15）をDNSに適用する提案であり、
TCPでの通信が前提となっています。一方、DNS over DTLSはTLSをUDPに対応さ
せたDTLS（*16）をDNSに適用する提案です。

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

（*16）Datagram Transport Layer Securityの略称。
       UDPのようなデータグラムプロトコル（配送の成功・到達時間・到達順
       序が保証されないプロトコル）において、暗号通信を行うためのプロ
       トコルです。

今回のWGでは前回から継続して、それぞれの問題点の確認と標準化に関する議
論が進められました。

▽DNS over TLS

DNS over TLS（draft-ietf-dprive-dns-over-tls）では、DNSメッセージをや
り取りする前に暗号を用いるかどうかの確認を実施する機構（STARTTLS）はプ
ロトコルが複雑になることから削除され、DNS over TLS専用のポート番号とし
て、853/tcpがIANAから割り当てられることとなりました（*17）。

（*17）853/udpが割り当てられたDNS over DTLSと共に、2016年10月8日までの
       期限付きの割り当てとなっています（2015年12月2日現在）。

DNS over TLSには既にいくつかの実装があり（*18）、また、今回のIETF
Hackathon（*19）でも実装作業が進められました。

（*18）今回のWGの発表の中で、Unboundの1.4.14以降、ldns/drill/NSDに対す
       るパッチ、digit、getdns APIで実装されていると紹介されました。

（*19）Hackathon（ハッカソン）はエンジニアが集中的に共同作業をする場を
       意味しています。IETFではIETF 92からHackathonが実施されており、
       新しく標準化された、あるいは標準化作業中のプロトコルの実験実装
       の試作が集中的に行われています。

WGでは、現在のインターネットドラフトはサーバーの認証部分のプロファイル
（Profile）（*20）の定義のみとし、プロファイルの内容は別ドキュメントと
する方向で、継続して検討を進めることとなりました。

（*20）暗号通信を確立する際に必要な情報を記述するファイル。

▽DNS over DTLS

DNS over DTLS（draft-ietf-dprive-dnsodtls）では、DNSメッセージのフラグ
メントの問題が指摘されました。DTLSはフラグメントを扱う仕組みを持たない
ため、UDPのDNSメッセージをDTLS化する場合、DTLS上にフラグメントを扱うた
めの仕組みが別途必要になり、プロトコルが複雑になることが指摘・共有され
ました。

また、フラグメントされたDNSメッセージには前述した第一フラグメント便乗
攻撃を始めとするセキュリティ上の問題が見つかっていることが問題提起さ
れ、それを解決するためにメッセージの分割をDNSレベルで実現するための提
案（draft-muks-dns-message-fragments）や、DNS over TLSへのフォールバッ
クを用いたフラグメントの回避について議論が行われました。

DNS over DTLSの標準化にはこの課題の解決が必要であり、また、dprive WGで
の議論においてDNS over TLSの標準化を先に進める流れがあることから、DNS
over DTLSの標準化には時間を要することが見込まれます。

▼今後のWGの方向性について

前述の通り、クライアントとフルリゾルバーの間の暗号化はDNS over TLSで進
めようという流れがありますが、DNS over TLS／DNS over DTLSのどちらか、
あるいは両方を標準化するかどうかについては、今後も継続して議論を進めて
いくこととなりました。

また、今回のWGでは標準化作業完了後のWGの方向性について議論が行われ、フ
ルリゾルバーと権威DNSサーバーの間の暗号化に進む、運用・実装についての
文書化を進める、いったん終了するなどの案がWGチェアから提示されましたが、
結論は出されず、継続して議論を進めることとなりました。

■eppext WGにおける話題

eppextはEPP Extensionsに由来しており、レジストリ・レジストラ間の登録情
報のやりとりに用いられるEPP（Extensible Provisioning Protocol）の機能
拡張を目的として組織されています。

▼チャーターの改定と今後の作業方針

eppext WGでは今後の方向性として対象をEPPの拡張に限定せず、登録情報の検
索サービスとしてWhoisを置き換えるために開発されたRDAP（*21）の拡張も対
象とすることとし、WGのチャーターの改定（リチャーター）を議論しています。

（*21）Registration Data Access Protocolの略称。
       登録情報にアクセスするためのプロトコル。URIによりデータが渡され、
       JSON（JavaScript Object Notation：JavaScriptのオブジェクト表記
       方法に由来する簡便なデータ記述法）の形式で応答が返されます。

これを受け、これまでRDAPの標準化と機能拡張を検討してきたweirds WGと
eppext WGの活動を一つにまとめたregext WG（仮称）を設立する方向で検討が
進められています。

また、今後のWGの作業方針について、IETFとしてはレジストリが取り扱うプロ
トコルの標準化作業に集中すべきであるという意見が寄せられ、2016年1月に
予定されているリチャーターに向け検討を進めることとなりました。

■lager WGにおける話題

▼背景

新gTLDの登場により、ルートゾーンでも非ASCII文字を含むさまざまな言語が
利用されるようになりました。しかし、今回の新gTLDプログラムでは、使用文
字列（ラベル）の人手による審査に多くの時間と労力を要しました。

そのため、次回以降の新gTLDプログラムに向け、TLDラベルとして使用可能な
文字と異体字を機械的に生成できるようにするためのルートゾーンラベルの生
成ルール（Root Zone Label Generation Rules、以下、Root Zone LGR）の作
成が進められています。

Root Zone LGRの作成に向け、各言語コミュニティにおいてそれぞれの言語の
ルール案の作成が進められています。日本では専門家有志により、日本語ラベ
ルに関するルールを検討するパネルとして日本語生成パネル（Japanese
Generation Panel：JGP）が設立され、活動を続けています（*22）。

（*22）JGPの概要については、日本語生成パネルの公式ページをご参照ください。
       http://j-gp.jp/

▼lager WGの新設

こうした動きを受け、ラベル生成ルール（LGR）を記述するための共通の形式
を作成することを目的とした、lager WGが新設されました。WGでは記述ファイ
ルの形式として、XMLを採用しています。

▼今回の議論の内容

今回のWGではRoot Zone LGRにおける経験から、セカンドレベルドメイン
（2LD）などTLD以外のラベルにおいても起こり得るユースケース（*23）につ
いても検討課題とすべきではないかという問題提起がありました。本件につい
ては課題であることが共有されつつも、まずは当初の目的であるLGRのプロト
コルの策定を進める方向で検討が進められることとなりました。

（*23）例えば、各言語間で共有されるスクリプト（言語を書き表すのに使用
       する文字の種類：ひらがな、漢字、ギリシア文字、キリル文字など）
       の異体字の統合など。

また、LGRの内容を記述するXMLスキーマの定義そのものについては大きな議論
はなく、実装からのフィードバックを反映しながら、WG Last Callに向けた作
業を進めていくこととなりました。

LGR用のXMLスキーマが標準化された後、現在IANAに登録されているIDNテーブ
ル（*24）のLGR化が進められていくこととなります。

（*24）Repository of IDN Practices
       https://www.iana.org/domains/idn-tables

■その他の主なDNS・レジストリ関連WGの状況

dbound WGは、ドメイン名の境界、すなわち管理レベルの判定に使われている
Public Suffix List（*25）を置き換える仕組みの標準化を進めるために設立
されたWGです。

（*25）現在のPublic Suffix ListはWebブラウザーFirefoxを開発している
       Mozilla Foundationが管理しています。このリストは10,000行以上の
       テキストファイルであり、保守性の悪さ、各TLDにおけるドメイン名管
       理構造の変化への追随など、いくつかの要改善・懸念事項が指摘され
       ています。

今回のdbound WGでは活発な議論が行われましたが、WGとして何が問題であり、
何を解決したいのかが明確に定義されておらず、結論は出ませんでした。

また、homenet・mif・dnssdの各WGにおいてもDNS関連の話題が上がったものの
関連する標準化作業は減速気味であり、作業完了には時間を要すると見込まれ
ます。

■IETF全般における話題

▼チュートリアル

IETF Meetingでは会議初日の日曜日に、参加者を対象としたチュートリアルが
開催されます。チュートリアルでは新規参加者向けのオリエンテーションやイ
ンターネットドラフトを書く際に有用なツールの紹介、特定の技術分野の概要
を紹介するものなどが開催されています。

今回のチュートリアルでは特定の技術分野の概要を紹介するものとして国際化
（PRECIS（*26）and i18n）が取り上げられ、JPRSの米谷嘉朗が講師を担当し
ました。

（*26）Unicode文字を使用したアプリケーションで適切に文字列を処理するた
       めのフレームワークとして、RFC 7564で定義されています。

▼JPRSがBits-N-Bitesに出展

Bits-N-Bitesは、IETFで標準化されている技術を採用した製品や新技術のデモ
ンストレーション・活動紹介などが行われる、IETF参加者が数百人規模で集う
場です。会場では食事や飲み物が無料で提供され、参加しやすい雰囲気が作ら
れています。

今回は横浜での開催であることもあり、日本からJPRSを含む6組織がブースを
出展しました。JPRSでは、JPドメイン名とJPRSにおける標準化技術の採用・実
装状況を紹介し、参加者との情報交換を行いました。

■次回のIETF Meeting

次回の第95回IETF Meeting（IETF 95）は2016年4月3日から8日にかけ、アルゼ
ンチンのブエノスアイレスで開催されます。

          ◇                     ◇                     ◇

◎関連URI

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

  - 94th IETF | YOKOHAMA JAPAN
    http://ietf94.jp/
    （IETF 94実行委員会 公式ページ）

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

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

  - RFC 6761 - Special-Use Domain Names
    https://tools.ietf.org/html/rfc6761
    （特殊用途ドメイン名を定義したRFC）

  - RFC 7686 - The ".onion" Special-Use Domain Name
    https://tools.ietf.org/html/rfc7686
    （.onionを特殊用途ドメイン名として予約したRFC）

  - DNS PRIVate Exchange (dprive) - Charter
    https://datatracker.ietf.org/wg/dprive/charter/
    （dprive WG公式ページ）

  - Extensible Provisioning Protocol Extensions (eppext)
    https://datatracker.ietf.org/wg/eppext/charter/
    （eppext WG公式ページ）

  - Label Generation Rules (lager)
    https://datatracker.ietf.org/wg/lager/charter/
    （lager WG公式ページ）

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

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

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