JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト
JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト
メールマガジン「FROM JPRS」
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2016/12/15━
◆ FROM JPRS 増刊号 vol.166 ◆
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
第97回IETF Meeting（ソウル）報告
～DNS・レジストリ関連WG／IETF本会議及び周辺会合における話題～
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2016年11月13日から18日にかけて、第97回IETF Meeting（以下、IETF 97）が
韓国のソウルで開催されました。
今回のFROM JPRSでは、IETF 97の模様を以下の項目に沿ってお伝えします。
・dnsop WGにおける話題
- IETF 96以降のRFC発行状況
- 議論された主な提案の内容と標準化作業の進行状況
・regext WGにおける話題
- 議論された主な提案の内容と標準化作業の進行状況
・dnsbundled BOFの開催
・IETF全般における話題
- インターネットのアーキテクチャーに対する攻撃
・IEPG会合における話題
- IP AnycastとDDoS
- NSEC/NSEC3の積極的な活用
・次回のIETF Meetingについて
◇ ◇ ◇
■dnsop WGにおける話題
dnsopはDNS Operationsに由来しており、DNSサーバーや登録情報の管理など、
DNSの運用全般に関するガイドラインの作成を目的としています。WGでは、運
用上の課題に着目したDNSプロトコルの拡張・メンテナンスも活動項目として
います。
▼IETF 96以降のRFC発行状況
前回のIETF 96以降に発行されたRFCは、以下の2本です。
・名前不在の取り扱いに関する仕様の明確化と更新
（draft-ietf-dnsop-nxdomain-cut、RFC 8020：Standards Track）
名前不在の取り扱いについてRFC 1034を明確化、RFC 2308を更新し、リゾ
ルバーが名前不在エラー（NXDOMAIN）を受け取った場合にそれをネガティ
ブキャッシュすることと、受け取った名前（例：a.example.jp）が
NXDOMAINであるとき、c.b.a.example.jpなどのように子孫の名前すべてを
NXDOMAINとして扱うよう変更します。
本RFCの発行により、(random).www.example.jpに対する大量のクエリを送
りつけるDDoS攻撃に対し、www.example.jpの情報を一時的に削除する形で
緊急対応した場合、www.example.jpが存在しないことがリゾルバーに
キャッシュされた時点で、(random).www.example.jpは存在しないことに
なります。
これにより、(random).www.example.jpに対するクエリを受信した場合、
リゾルバーから権威DNSサーバーへのクエリの送信を抑制でき、DDoS攻撃
の効果抑制につながります。
・ネットワークインフラにおけるDNSSEC非準拠の検知法と影響の緩和策
（draft-ietf-dnsop-dnssec-roadblock-avoidance、RFC 8027：Best
Current Practice）
EDNS0を制限するミドルボックス（*1）や、UDPフラグメントを正しく取り
扱えない機器が用いられているネットワークにおいて、何が原因になって
いるかの検知と、影響軽減のための手法を記述したものです。
本RFCの発行により、DNSSECに対応できないネットワークインフラをオペ
レーターが効率的に検知することが可能になり、DNSSECの普及に役立てる
ことが期待されています。
（*1）RFC 3234で定義される、通信路の間（middle）に存在する、ルーティン
グ以外の動作をする装置（box）の総称。ミドルボックスの例として、
ファイアーウォールやネットワークアドレス変換（NAT）装置、侵入検
知システム（IDS）などが挙げられます。
▼議論された主な提案の内容と標準化作業の進行状況
FROM JPRS編集局が注目した提案の内容と標準化作業の進行状況について紹介
します。
▽ipv4only.arpaの導入（draft-cheshire-sudn-ipv4only-dot-arpa）
DNS64（*2）の存在と、IPv6・IPv4のプロトコル変換に利用されているIPv6ア
ドレスの検出方法を定義するRFC 7050において利用される「ipv4only.arpa」
を、特殊用途ドメイン名（*3）に登録するための提案です。
（*2）RFC 6147で定義される、AレコードからAAAAレコードを合成するための
仕組み。NAT64と組み合わせることで、IPv4アドレスのみを持つサー
バーへのIPv6ネットワークからのアクセスを実現します。
（*3）Special-Use Domain Names
https://www.iana.org/assignments/special-use-domain-names/
本提案では、同様にRFC 7050において利用される特別なIPアドレスである
「192.0.0.170」、「192.0.0.171」の逆引きに利用される
「170.0.0.192.in-addr.arpa」、「171.0.0.192.in-addr.arpa」の二つも、特
殊用途ドメイン名に登録します。
今回のWGでは、arpaドメイン名の委任の方法と議論を行うべき場について議論
され、ipv4only.arpaはIABが管理するarpaドメイン名における委任でありIETF
の担当ではないこと、ドメイン名の予約自体はIABと交渉すればよいが、TTLな
どの設定パラメータについてはdnsop WGと相談したほうがよいことなどがコメ
ントされました。
▽DNSのパケットキャプチャーフォーマット
（draft-dickinson-dnsop-dns-capture-format）
ネットワークを流れるパケットをキャプチャーする際に、DNSデータをより効
率的な形で交換可能な、記録フォーマットを定義するための提案です。
現在、キャプチャーされたDNSデータを扱うツールとしてDSC、packetq、
dnscap、dnstapなどが使われていますが、記録したデータを交換するための標
準フォーマットは定義されていません。
本提案では、大規模なデータのキャプチャーにおける問題点に注目し、データ
容量を削減し、かつデータ交換が可能な標準フォーマットとしてCBOR（*4）形
式を使うというものです。
（*4）CBOR:Concise Binary Object Representation
https://tools.ietf.org/html/rfc7049
発表では、クエリと対応する応答を組み合わせて格納する、複数のクエリ／応
答をまとめてブロック化するなど、DNSの特性を考慮したデータの配置にして
保存するデータ量を最小限とした上で圧縮することにより、PCAPデータを圧縮
しただけの場合と比べ30％程度のサイズになることが示され、多くの感心が集
まりました。
本提案はWG draftとして採択され（draft-ietf-dnsop-dns-capture-format）、
WGで検討されることになりました。
▽リゾルバーアルゴリズムの更新（draft-fujiwara-dnsop-resolver-update）
JPRSの藤原和典が著者として作成している提案で、リゾルバーの名前解決アル
ゴリズムの一部を変更するものです。
DNSの仕様を定義したRFC 1034では、新しい委任／ゾーンは親側に設定される
NSレコードによって作られると定義しており、子ゾーンの権威DNSサーバーに
アクセスするためのすべての情報は、親側に存在するとしています。
しかし、親側に設定されるNSレコードは権威を持つデータではなく、権威を持
つデータは子側に存在しています。リゾルバーが権威DNSサーバーから受信し
た応答の取り扱いについてRFC 1034/1035の仕様を明確化したRFC 2181では、
権威を持たないデータは権威を持つデータで上書きすべきであるとしており、
結果として名前解決の際に親から応答されたNSレコードは、子から応答された
NSレコードで上書きされます。
提案では、このことがフルリゾルバーの実装の複雑さや幽霊ドメイン名脆弱性
（*5）の要因となっていることを指摘し、DNSの名前構造をたどる場合には親
側で設定されるNSレコードとグルーレコードが重要であり、それらのみが利用
されるべきであるとしています。
（*5）「ghost domain names（幽霊ドメイン名）」脆弱性について
https://jprs.jp/tech/notice/2012-02-17-ghost-domain-names.html
今回のWGでは、本件はリゾルバーにおける大きなアルゴリズムの変更であり、
親子それぞれのNS・TTLの取り扱いについては慎重に議論すべきであるといっ
た意見や、NSレコードについてはそもそも子側のデータを使うべきであると
いった主張が強く、継続して議論を進めていくことになりました。
また、本提案に記述されたフルリゾルバーのキャッシュを二つに分離する実装
方式については、特許が存在する旨の指摘が寄せられています（*6）。
（*6）IPR Details - Andreas Gustafsson's Statement about IPR related
to draft-fujiwara-dnsop-resolver-update belonging to Nominum,
Inc
https://datatracker.ietf.org/ipr/2907/
■regext WGにおける話題
regext WGは、RDAPの標準化と機能拡張を検討したweirds WGとEPP（*7）の機
能拡張のために組織されたeppext WGの活動を一つにまとめ、RDAPなどレジス
トリ関連のプロトコルも扱うよう再編成されたWGです。
（*7）Extensible Provisioning Protocolの略称。ドメイン名の登録情報をレ
ジストリとレジストラの間で交換するために設計されたプロトコルです。
拡張性の高さを特長としており、ドメイン名だけでなくIPアドレスなど、
他の情報のレジストリにおける利用も考慮されています。
▼議論された主な提案の内容と標準化作業の進行状況
FROM JPRS編集局が注目した提案の内容と標準化作業の進行状況について紹介
します。
▽EPPを用いたDNSSEC鍵の中継（draft-ietf-eppext-keyrelay）
EPPを拡張し、DNSオペレーター間におけるDNSSECの鍵情報中継の機能を定義し、
鍵交換を実現可能にするための提案です。
DNSSECを維持した状態でDNSオペレーターを変更する場合、変更元と変更先の
DNSオペレーター間でDNSSEC鍵情報を交換する必要があります。しかし、変更
元と変更先のDNSオペレーターの関係が非協力的（Non-Cooperating）である場
合、円滑なDNSSEC鍵情報の交換ができないことがあります（*8）。
（*8）DNSSECの運用ガイドラインについて記述したRFC 6781の「4.3.5.2.
Non-Cooperating DNS Operators」に、詳細な記述があります。
本提案では、あるレジストラが持つDNSSEC鍵情報をレジストリ経由で別のレジ
ストラに中継できるようにEPPを拡張し、DNSSEC環境におけるDNSオペレーター
の変更を円滑に実行可能にするための機能を提供します。
本提案については旧eppext WGで標準化作業が進められましたが、2014年7月に
Verisignから同社の知的財産権を侵害している旨のクレームが寄せられ
たため、標準化作業が一時中断していました（*9）。
（*9）IPR Details - Verisign Inc.'s Statement about IPR related to
draft-ietf-eppext-keyrelay
https://datatracker.ietf.org/ipr/2393/
今回のWGでは本提案についての取り扱いが議論され、同社から知的財産権に対
する追加の情報が得られなかったため影響はないものと判断し、RFC化を推進
していくこととなりました。その後、12月6日にIESGが本提案をStandards
Track RFCとして発行することを承認し、RFC発行待ち（RFC Ed Queue）の状態
となっています。
▽データエスクローの標準化（draft-arias-noguchi-registry-data-escrow、
draft-arias-noguchi-dnrd-objects-mapping）
JPRSの野口昇二が共著者として作成している提案で、ドメイン名レジストリの
データエスクローのための、データ形式と内容を規定するものです。
レジストリやレジストラが何らかの理由により業務を継続できなくなった場合
に備え、ドメイン名の登録情報を第三者組織に預託することをデータエスク
ローと言います。
データエスクローの標準化については上記のドキュメントが発行されています
が、現在は期限切れ（expire）の状態となっています。
今回のWGで、データエスクローの標準化提案をregext WGの作業項目とするこ
とについて共著者が提案しました。regext WGチェアからは、WGのリチャー
ターが必要とのコメントがあり、メーリングリストで確認する他、エリアディ
レクターにも相談の上、作業を進めることとなりました。
■dnsbundled BOFの開催
国際化ドメイン名における「中国」と「中國」など、異なるラベルを同一の名
前として取り扱うための仕組みを検討するWGの設立を目指して、dnsbundled
BOFが開催されました。前回のIETF 96では非公式なSide BOFとして開催されま
したが、IETF 97では正式なBOFとして開催されています。
今回のBOFでは、CNNICのJiankang Yao氏らから提案された問題提起文書
（problem statement）の説明、いくつかのレジストリ・レジストラにおける
ユースケースの紹介の後、今後の進め方についての議論が進められました。
会場からは、
・この問題は、IDNの標準化が進められた2002年にも議論されている
・現在の問題提起文書は不十分であり、問題点を明確に定義していない
・問題の解決にはDNSの名前解決のみでは不十分であり、インターネット識
別子の根本的な作り直しが必要になる
・本件においては、DNSのゾーン管理と利用者のアクセスの双方について考
慮する必要があるが、この場では対象をゾーン管理に絞るべきである
などといった意見が寄せられました。
結果として、今回のBOFではWG設立の合意には至らず、当面はメーリングリス
トで問題提起文書における問題点を明確化する作業を進めることとなりました。
■IETF全般における話題
▼インターネットのアーキテクチャーに対する攻撃
今回のIETF Operations, Administration, and Technical Plenaryでは、
「インターネットのアーキテクチャーに対する攻撃（Attacks Against the
Architecture）」というテーマで、講演と議論が行われました。
まず、CloudFlareのNick Sullivan氏から「How to stay online」というタイ
トルで、現在のDDoS攻撃の傾向と代表的な影響緩和策が講演され、IABチェア／
DynのAndrew Sullivan氏から「The Internet's Architecture is Under
Attack (Ironically)」というタイトルで、2016年10月に発生した米国のDNSプ
ロバイダー大手企業のDynに対するDDoS攻撃を題材とした講演が行われました。
既報の通り、今回のDynに対する攻撃ではセキュリティ上の考慮が不十分な大
量のIoT機器が悪用され、極めて大規模な攻撃が行われました。
Andrew Sullivan氏の講演では、IoT機器が悪用されたことは本件の一面の事実
に過ぎず、根本原因にはインターネットのアーキテクチャーそのものの脆弱さ
があるとし、問題解決のためにはより強固なインターネットアーキテクチャー
の構築が必要であり、そのためにはどのようなことが可能であるか、どのよう
な取り組みが必要であるかについて、会場の参加者を交えた議論が行われまし
た。
会場からは、
・問題解決のためにはプロトコル設計者・製品開発者・運用者・行政執行者
など、それぞれの立場の人が何をすべきかを知らなければならない。そし
て、IABはそれを知らせることができる立場にいる
・プロトコル設計の段階から、オペレーターの観点を加味したセキュリティ
上の対策を考慮すべきである
・IoT機器の製造者や政府など、さまざまな関係者を交えた総合的な取り組
みが必要である
などのコメントが寄せられ、活発な議論が行われました。
■IEPG会合における話題
▼IP AnycastとDDoS
2015年11月30日に発生したルートサーバーに対して大量のクエリが送られた出
来事（*10）について、IP Anycast（*11）がどのように機能したかを評価した
レポートが発表されました。
（*10）Events of 2015-11-30
http://www.root-servers.org/news/events-of-20151130.txt
（*11）IP Anycastの詳細は、用語辞典をご参照ください。
https://jprs.jp/glossary/index.php?ID=0108
この出来事では、A～Mまで13系列存在するルートサーバーの各系列ごとに1秒
間に500万クエリが観測され、13系列のうち10系列が影響を受けました。
発表では、現在のIP Anycastを利用した防御手法は合理的と考えているものの、
大陸をまたぐ規模の地理的な多様性と、長期的な視点での研究継続が必要であ
ることが報告されました。
▼NSEC/NSEC3の積極的な活用
APNICのGeoff Huston氏から"DDOS and the DNS"というタイトルで発表が行わ
れ、その中でJPRSの藤原和典らが提案している、DNSSECの不在証明の仕組みを
より積極的に活用することで負荷軽減を図る
draft-ietf-dnsop-nsec-aggressiveuse（*12）が、有用な対策の一つとなるこ
とが紹介されました。
（*12）NSEC/NSEC3の積極的な活用の詳細は、過去のドメイン名関連会議報告
をご参照ください。
https://jprs.jp/related-info/event/2016/0809IETF.html
この発表の後、Google Public DNSにおける本提案の活用事例が、共著者の一
人であるGoogleのWallen Kumari氏から急遽紹介されました。
2016年5月に発生したk.root-servers.net（K-Root）に対するGoogle Public
DNSからの大量クエリが導入のきっかけになったこと、導入によりGoogle
Public DNSからルートサーバーへのクエリ数が減少し、効果を発揮したことが
報告されました。
■次回のIETF Meetingについて
次回の第98回IETF Meeting（IETF 98）は2017年3月26日から31日にかけ、米国
のシカゴで開催されます。
◇ ◇ ◇
◎関連URI
- 97 Meeting Index
https://www.ietf.org/meeting/97/
（IETF 97公式ページ）
- IETF 97 meeting materials
https://datatracker.ietf.org/meeting/97/materials.html
（IETF 97発表資料一覧）
- 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公式ページ）
- Bundled Domains (dnsbundled)
https://datatracker.ietf.org/wg/dnsbundled/charter/
（dnsbundled BOF公式ページ）
- Attacks Against the Architecture
https://www.ietf.org/blog/2016/10/attack-against-the-architecture/
（IETF Operations, Administration, and Technical Plenaryの
Andrew Sullivan氏の講演の背景）
- How to stay online
https://www.ietf.org/proceedings/97/slides/slides-97-ietf-sessb-how-to-stay-online-harsh-realities-of-operating-in-a-hostile-network-nick-sullivan-01.pdf
（IETF Operations, Administration, and Technical Plenaryの
Nick Sullivan氏の講演の背景）
- The Internet's Architecture is Under Attack (Ironically)
https://www.ietf.org/proceedings/97/slides/slides-97-ietf-sessb-the-internets-architecture-is-under-attack-ironically-andrew-sullivan-00.pdf
（IETF Operations, Administration, and Technical Plenaryの
Andrew Sullivan氏の講演資料）
- IEPG Meeting - November 2016
http://iepg.org/2016-11-13-ietf97/index.html
（IEPG公式ページ）
━━━━━━━━━━━━━━━━━━━━━━━━━━━【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.
Copyright©2001-2024 Japan Registry Services Co., Ltd.