JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト
JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト
メールマガジン「FROM JPRS」
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2017/04/21━
◆ FROM JPRS 増刊号 vol.168 ◆
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
第98回IETF Meeting（シカゴ）報告
～DNS・レジストリ関連WG／IETF本会議及び周辺会合における話題～
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2017年3月26日から31日にかけて、第98回IETF Meeting（以下、IETF 98）が米
国のシカゴで開催されました。
今回のFROM JPRSでは、IETF 98の模様を以下の項目に沿ってお伝えします。
・dnsop WGにおける話題
- IETF 97以降のRFC発行状況
- 議論された提案の内容と標準化作業の進行状況
・homenet WGにおける話題
- 議論された提案の内容と標準化作業の進行状況
・regext WGにおける話題
- データエスクローの標準化
- WGチャーターの改訂に向けた動き
・IETF全般における話題
- IETFチェアの交代
・IEPG会合における話題
- DNS Violations Project
・次回のIETF Meetingについて
◇ ◇ ◇
■dnsop WGにおける話題
dnsopはDNS Operationsに由来しており、DNSサーバーや登録情報の管理など、
DNSの運用全般に関するガイドラインの作成を目的としています。WGでは、運
用上の課題に着目したDNSプロトコルの拡張・メンテナンスも活動項目として
います。
▼IETF 97以降のRFC発行状況
前回のIETF 97以降に発行されたRFCは、以下の3本です。
・ネットワークインフラにおけるDNSSEC非準拠の検知法と影響の緩和策
（draft-ietf-dnsop-dnssec-roadblock-avoidance、RFC 8027：Best
Current Practice）
EDNS0（*1）を制限するミドルボックス（*2）や、UDPフラグメントを正し
く取り扱えない機器が用いられているネットワークにおいて、原因の検知
と、影響軽減のための手法を記述したものです。
本RFCの発行により、これまでの運用でオペレーターが培ったDNSSECに対
応できないネットワークインフラを効率的に検知するための手法が、現状
における最良の慣行（Best Current Practice: BCP）としてまとめられま
した。
（*1）EDNSは、RFC 6891で定義されるDNSの拡張方式で、バージョン番号を示
すためにEDNS0またはEDNS(0)と呼ばれます。詳細は、以下の解説をご参
照ください。
https://jprs.jp/glossary/index.php?ID=0147
（*2）RFC 3234で定義される、通信路の間（middle）に存在する、ルーティン
グ以外の動作をする装置（box）の総称。ミドルボックスの例として、
ファイアウォールやネットワークアドレス変換（NAT）装置、侵入検知
システム（IDS）などが挙げられます。
・CDS/CDNSKEYによる親のDSレコードの管理
（draft-ietf-dnsop-maintain-ds、RFC 8078：Standards Track）
DNSSECにおいて親ゾーンに設定されるDSレコードを、子ゾーンで設定する
CDS/CDNSKEYレコード経由で自動更新するための手法は、RFC 7344として
定義されています。
その中で、親ゾーンの管理者がDNS問い合わせで子ゾーンのCDS/CDNSKEYの
存在をチェックし、設定されていた場合に対応する自分のレコードを自動
更新するという運用形態が想定されています。
しかし、RFC 7344ではDSレコードを最初に設定する場合と削除する場合の
手法が提供されていませんでした。本RFCではこれらの手法を提供します。
また、CDS/CDNSKEYレコードは、RFC 7344ではInformationalでしたが、本
RFCによりStandards Trackとなりました。
本RFCではユースケースの一つとして、DNSオペレーターの変更において移
転元と移転先が非協力的（non-cooperative）であった場合に、移転に先
立って子の側から親ゾーンのDSレコードを自動的に削除し、DNSSEC検証失
敗を回避することが想定されています。
・プライミングクエリによるDNSリゾルバーの初期化
（draft-ietf-dnsop-resolver-priming、RFC 8109：Best Current
Practice）
フルリゾルバー（キャッシュDNSサーバー）がキャッシュを初期化するため
に送信する、プライミングクエリ（priming query）について記述したもの
です。フルリゾルバーはプライミングクエリにより、ルートゾーンの現在
のNS RRSetと、ルートサーバーへのアクセスに必要なIPアドレスの一覧を
取得します。
BINDやUnboundなど、現在普及しているフルリゾルバーは最初の名前解決に
先立ち、プライミングクエリを実行するように実装されています。
本RFCは、既存のフルリゾルバーに実装されているプライミングクエリの方
式を現状における最良の慣行（BCP）として文書化したものです。EDNS0を
使用すべきである、DNSSEC OK（DO）ビットを設定してもよいなど、これま
で明確にされていなかった項目についても記述されています。
▼議論された提案の内容と標準化作業の進行状況
FROM JPRS編集局が注目した提案の内容と、標準化作業の進行状況について紹介
します。
▽DNS用語の明確化（draft-ietf-dnsop-dns-terminology-bis）
今回のWGでは若干の用語の追加と、ドメイン名（domain name）の項目の記述
を変更したことが報告され、内容のレビューが依頼されました。
RFC 7719ではドメイン名の項目に、ラベルの長さがゼロから63オクテット（*3）
であること、ラベルの長さの合計が255オクテットに制限されることが記述さ
れていました。提案では、これらの制限は新設された「Global DNS」の項目に
移され、ドメイン名は「ゼロ個以上のラベルの順序付きリスト（An ordered
list of zero or more labels）」という、DNS以外のシステムも含む、より一
般的な定義に変更されています。
（*3）情報通信の分野で、8ビット（bit）を示す単位のこと。1オクテットは、
8ビットを表します。
この変更は影響が大きいと考えられるものでしたが、会場からはその部分につ
いてのコメントはなく、今後も継続して作業を進めることとなりました。
▽DNS Response Policy Zones（draft-ietf-dnsop-dns-rpz）
DNS Response Policy Zones（DNS RPZ）は、フルリゾルバーがクライアントに
返す応答内容を、そのフルリゾルバーの運用者のポリシーにより制御可能にす
る機能を提供するための提案です。本提案はBIND、Knot DNS、PowerDNSなど、
既存のDNSサーバーソフトウェアに実装されています。
https://dnsrpz.info/
今回のWGでは、DNS RPZは新しい機能ではなく、WGで議論するものではないと
いう意見が出ましたが、既に実装・運用されている機能であることから、
Informational RFCとして文書化を目指すこととなりました。
▽アンダースコア名のレジストリ（draft-ietf-dnsop-attrleaf）
SRVリソースレコード（*4）における「_tcp」や「_udp」、DKIM（*5）におけ
る「_domainkey」など、アンダースコア（_）で始まるラベルを特定の用途で
使っているプロトコルがあります。現在、それらのラベルの仕様は、それぞれ
のプロトコルを定義するRFCで定められています。
（*4）RFC 2782で定義される、指定したプロトコルとドメインにサービスを提
供するサーバーの場所を示すためのリソースレコードです。詳細につい
ては、JPRS寄稿の以下の解説をご参照ください。
http://www.atmarkit.co.jp/fnetwork/dnstips/042.html
（*5）DKIM: DomainKeys Identified Mail
RFC 6376で定義される、電子署名を利用して電子メールの送信元の認証
を行うプロトコルです。
https://www.ietf.org/rfc/rfc6376.txt
本提案の背景として、「_」で始まるラベルはインターネットのホスト名とし
ては使用できないものであり、DNSにおけるホスト名の規則とは別に管理すべ
きであるという点が挙げられています。
そうした「_」で始まるラベルを登録する「DNS Global Underscore Scoped
Entry Registry」をIANAに設立し、対象となるリソースレコードとその用途を
集中管理するための提案です。
WGでは、提案の背景と状況が再確認され、RFC 2782が発行された2000年当時に
はレジストリによる管理はされなかったが、現在は管理されるプロトコルが増
えてレジストリが必要とされていること、SSL/TLSで用いられるTLSA RR（*6）
でも必要になることなどの確認が行われ、作業を継続することになりました。
（*6）TLSA RRの詳細は、過去のドメイン名関連会議報告をご参照ください。
https://jprs.jp/related-info/event/2012/0831IETF.html
▽DNSSEC推奨アルゴリズムの更新
（draft-wouters-sury-dnsop-algorithm-update、
draft-arends-dnsop-dnssec-algorithm-update）
DNSSECの電子署名とハッシュを生成するために用いられるアルゴリズムの一覧
は、IANAのレジストリに登録・管理されています（*7）。本提案ではSHA-1の
利用終了に向け（*8）、登録情報の一部を更新することを提案しています。
（*7）Domain Name System Security (DNSSEC) Algorithm Numbers
https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml
（*8）SHA-1は米国NISTにより、2011年に非推奨とされています。
Secure Hashing - Approved Algorithms
http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html
（米国国立標準技術研究所（NIST）による勧告）
本文書では、現在利用可能とされているアルゴリズムのうちSHA-1を用いるも
のの取り扱いを、RFC 6944で定められている「Must Implement（実装必須）」
から「Recommended to Implement（実装を推奨）」に変更し、RSASHA256を新
たに「実装必須」とすることを提案しています。
今回のWGでは、取り扱いの変更にはレジストリの更新という手段もあること、
提案中の「提案必須」「提案を推奨」といった表現が明確でないなどのコメン
トがあり、引き続き検討を進めることになりました。
■homenet WGにおける話題
homenet WGは「Home Networking」に由来する、家庭内LANなどの比較的小規模
なネットワーク内、及びネットワーク間におけるさまざまな技術課題について
取り扱うWGです。
▼議論された提案の内容と標準化作業の進行状況
今回のhomenet WGでは、.homenet TLDの予約に関する検討が進められました。
▽.homeに替わる特殊用途名（draft-ietf-homenet-dot）
homenet WGで標準化された家庭内ネットワークを制御するプロトコル（*9）
において、名前衝突を回避するためにICANNが委任を保留した.homeの予約・利
用が標準化されてしまったことが問題となりました。
（*9）Home Networking Control Protocol（HNCP）。2016年4月にRFC 7788と
して標準化。
この問題を解決するため、WGでは.homeに替わる新たなドメイン名を決定する
ための議論と検討が進められることとなりました。その結果、.homeに替えて
.homenetを予約することについての検討が、dnsop WGと共同で進められました。
今回のWGでは、問題解決に向けたいくつかの選択肢が示され、.homenetを
AS112プロジェクト（*10）で管理した場合にDNSSEC検証ができなくなる問題や、
安全でない（insecure）委任をルートゾーンに追加することの是非などが議論
され、継続して検討を進めることとなりました。
（*10）AS112の詳細は、過去のドメイン名関連会議報告をご参照ください。
https://jprs.jp/related-info/event/2013/1206IETF.html
その後、IETF 98終了後の2017年3月30日に、IAB（*11）が以下の文書を発表し
ました（*12）。文書には、RFC 3172で定義される技術インフラのために必要
な特殊用途名（special use names）を、.arpaに登録するための条件が記述さ
れています。
（*11）Internet Architecture Boardの略称。IABはIETFに設置された委員会
であり、ISOCの諮問機関の役割も担っています。
（*12）Internet Architecture Board statement on the registration of
special use names in the ARPA domain
https://www.iab.org/documents/correspondence-reports-documents/2017-2/iab-statement-on-the-registration-of-special-use-names-in-the-arpa-domain/
これを受ける形で2017年4月6日にインターネットドラフトが改訂され、
.homenetに替えて.home.arpaを予約する形で、作業が継続されています。
■regext WGにおける話題
regext WGはRDAP（*13）の標準化と機能拡張を検討したweirds WGとEPP（*14）
の機能拡張のために組織されたeppext WGの活動を一つにまとめ、RDAPなどレジ
ストリ関連のプロトコルも扱うよう再編成されたWGです。
（*13）Registration Data Access Protocolの略称。
登録情報にアクセスするためのプロトコル。URIによりデータが渡され、
JSON（JavaScript Object Notation：JavaScriptのオブジェクト表記
方法に由来する簡便なデータ記述法）の形式で応答が返されます。
（*14）Extensible Provisioning Protocolの略称。
ドメイン名の登録情報をレジストリとレジストラの間で交換するため
に設計されたプロトコルです。拡張性の高さを特長としており、ドメ
イン名だけでなくIPアドレスなど、他の情報のレジストリにおける利
用も考慮されています。
▼データエスクローの標準化
（draft-arias-noguchi-registry-data-escrow、
draft-arias-noguchi-dnrd-objects-mapping）
JPRSの野口昇二が共著者として作成している提案で、ドメイン名レジストリの
データエスクロー（*15）のための、データ形式と内容を定義するものです。
（*15）レジストリやレジストラが何らかの理由により業務を継続できなく
なった場合に備え、ドメイン名の登録情報を第三者組織に預託するこ
とを、データエスクローと言います。
今回のWGで、本提案をWGの作業項目にしたいという提案があり、賛成意見が多
かったことから、WGのチャーター改訂時に追加する方向となりました。
▼WGチャーターの改訂に向けた動き
また、WGチャーターの改訂については、既にWGの作業項目数が多く、チャー
ターで定めたマイルストーンの通りに進行していない状況を受け、インター
ネット標準とする意思がある提案や、実装が既に存在する提案の優先順位をよ
り高くする方針であることが、WGチェアから示されました。
なお、regext WGは会期中に2回ミーティングが開催され、1回目のグループ
ワークセッションは、既存ドキュメントの集中的なレビューにあてられました。
この方式はWGミーティングにおける新しい試みとして注目されました。
■IETF全般における話題
▼IETFチェアの交代
今回、2013年から4年間にわたってIETFチェアを務めたJari Arkko氏に代わり、
Alissa Cooper氏がIETFチェアに就任しました（*16）。同氏は、女性初のIETF
チェアとなります。
同氏は長年にわたってIETFで活動しており、Applications and Real-Time
Area（ART）のエリアディレクター、IABメンバーを歴任しました。また、IANA
監督権限の移管提案について検討するIANA監督権限移管調整グループ（IANA
Stewardship Coordination Group、ICG）の議長を務めるなど、インターネッ
トガバナンスの場でも活躍しています。
（*16）Profile for Alissa Cooper
https://datatracker.ietf.org/person/Alissa%20Cooper
■IEPG会合における話題
IEPG（Internet Engineering and Planning Group）は、IETF会合に先立って
日曜日午前に開催される会合で、インターネットの運用に関連するさまざまな
テーマを取り扱っています。
▼DNS Violations Project
CZ.NICのOndrej Sury氏が、DNSプロトコル違反の事例を集めて公開する「DNS
Violations」プロジェクトを始めたことと、これまでに発見された主な事例の
概要について紹介しました（*17）。
（*17）GitHub - dns-violations/dns-violations:
List of DNS violations by implementations, software and/or
systems
https://github.com/dns-violations/dns-violations
同氏はこのプロジェクトを始めた目的として、
・DNSプロトコルに関する理解促進
・インターネットのDNS全体の改善
・知見の共有
・権威DNSサーバーの実装者向けに、よくある実装上の落とし穴の回避
・リゾルバーの実装者向けに、各種プロトコル違反を処理できるかの確認
の五つを挙げ、CDN（*18）の権威DNSサーバーでプロトコル違反が特に多いこ
と、違反の具体例として、不必要な情報の応答、0x20（*19）の処理の不具合、
不正な応答パケットの生成などを紹介し、具体的な違反事例に関するコミュニ
ティからの投稿の受け付けを開始したことを紹介しました。
（*18）Content Delivery Networkの略称。
コンテンツにアクセスするエンドユーザーに近いサーバーから、効率
的なコンテンツの配信を行うためのものです。サーバーの選択や配信
効率を上げる手段として、DNSが用いられることがあります。
（*19）フルリゾルバーが、DNSの応答が偽装されていないかどうかを確認する
手法の一つです。問い合わせ名（QNAME）の大文字／小文字をランダム
に変換（例：ns.example.jpを、Ns.eXAmPLe.jPとする）し、応答に含
まれるQNAMEが問い合わせと一致していることを確認するものです。
会場からは、RFCにまとめるとよい、テストスイートを作るとよいといった意
見や、違反事例を実名付きで公開することに関する懸念などが寄せられました。
■次回のIETF Meetingについて
次回の第99回IETF Meeting（IETF 99）は2017年7月16日から21日にかけ、チェ
コのプラハで開催されます。
◇ ◇ ◇
◎関連URI
- 98 Meeting Index
https://www.ietf.org/meeting/98/
（IETF 98公式ページ）
- IETF 98 meeting materials
https://datatracker.ietf.org/meeting/98/materials.html
（IETF 98発表資料一覧）
- Domain Name System Operations (dnsop)
https://datatracker.ietf.org/wg/dnsop/charter/
（dnsop WG公式ページ）
- Registration Protocols Extensions (regext)
https://datatracker.ietf.org/group/regext/charter/
（regext WG公式ページ）
- IETF Profile: Alissa Cooper | IETF Blog
https://www.ietf.org/blog/2017/03/profile-alissa-cooper/
（IETFブログから、新チェアの紹介）
- IEPG Meeting - March 2017
https://iepg.org/2017-03-27-ietf98/
（2017年3月のIEPG Meeting公式ページ）
━━━━━━━━━━━━━━━━━━━━━━━━━━━【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.
Copyright©2001-2024 Japan Registry Services Co., Ltd.