[要約] RFC 8023は、名前の衝突の根本原因と緩和策に関するワークショップと賞に関する報告書です。このRFCの目的は、名前の衝突に関する問題を理解し、解決策を見つけるための情報を提供することです。
Independent Submission M. Thomas
Request for Comments: 8023
Category: Informational A. Mankin
ISSN: 2070-1721 Salesforce
L. Zhang
UCLA
November 2016
Report from the Workshop and Prize on Root Causes and Mitigation of Name Collisions
根本的な原因と名前の衝突の軽減に関するワークショップと賞の報告
Abstract
概要
This document provides context and a report on the workshop on "Root Causes and Mitigation of Name Collisions", which took place in London, United Kingdom, from March 8 to 10, 2014. The main goal of the workshop was to foster a discussion on the causes and potential mitigations of domain name collisions. This report provides a small amount of background and context; then, it provides a summary of the workshop's discussions.
このドキュメントは、2014年3月8〜10日にイギリスのロンドンで開催された「名前の衝突の根本的な原因と緩和」に関するワークショップに関するコンテキストとレポートを提供します。ワークショップの主な目的は、ドメイン名の衝突の原因と潜在的な緩和。このレポートは、少量の背景とコンテキストを提供します。次に、ワークショップのディスカッションの概要を示します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8023.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8023で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................2
2. Background and Context ..........................................4
2.1. Brief Update ...............................................6
3. Workshop Structure ..............................................7
3.1. Research Findings ..........................................8
3.2. System Analysis ............................................9
3.3. Frameworks: Modeling, Analysis, and Mitigation ............9
3.4. Conclusions and Next Steps ................................11
4. Security Considerations ........................................11
5. Informative References .........................................12
Appendix A. Program Committee .....................................16
Appendix B. Workshop Material .....................................16
Appendix C. Workshop Participants .................................17
Acknowledgments ...................................................17
Authors' Addresses ................................................17
It has been well known within the Internet research and engineering community that many installed systems in the Internet query the domain name system (DNS) root for names under a wide range of top-level domains (TLDs). Many of these TLDs are not delegated, which results in a response indicating that the name queried does not exist (commonly called an NXDOMAIN response [RFC7719]). In the Internet Corporation for Assigned Names and Numbers (ICANN) community, it was observed as early as November 2010 by the Security and Stability Advisory Committee (SSAC) report [SAC045] that the addition of new TLDs in the DNS root could result in so-called name collisions for names used in environments other than the global Internet. Some installed systems, following established (albeit not vetted) operational practices, generate queries to the global DNS with name suffixes that, under seemingly reasonable assumptions at the time the systems were designed or configured, were not expected to be delegated as TLDs. Many of these installed systems depend explicitly or implicitly on the indication from the global DNS that the domain name suffix does not exist. After a new TLD is delegated, the global DNS may give a different response to the query involving the TLD than it did prior to the TLD's delegation.
インターネットにインストールされている多くのシステムがドメインネームシステム（DNS）のルートに幅広いトップレベルドメイン（TLD）の名前を照会することは、インターネットの研究およびエンジニアリングコミュニティ内でよく知られています。これらのTLDの多くは委任されていないため、照会された名前が存在しないことを示す応答が返されます（一般にNXDOMAIN応答[RFC7719]と呼ばれます）。 Internet Corporation for Assigned Names and Numbers（ICANN）コミュニティでは、セキュリティおよび安定性諮問委員会（SSAC）のレポート[SAC045]により、2010年11月にDNSルートに新しいTLDを追加すると、 -グローバルインターネット以外の環境で使用される名前の名前の衝突。一部のインストール済みシステムは、確立された（吟味されていませんが）運用慣行に従って、システムが設計または構成された時点では一見妥当な仮定の下で、TLDとして委任されていないことが予想される名前サフィックスを持つグローバルDNSへのクエリを生成します。これらのインストールされたシステムの多くは、ドメイン名サフィックスが存在しないというグローバルDNSからの指示に明示的または暗黙的に依存しています。新しいTLDが委任された後、グローバルDNSは、TLDが委任される前とは異なる応答をTLDに関連するクエリに与える場合があります。
A name collision occurs when an attempt to resolve a name used in a private namespace results in a query to the public DNS, and the response indicates that the name is in the global DNS [NCRI]. In other words, the overlap of public and private namespaces may result in potential unintended (and, therefore, potentially harmful) resolution results. The impact of the global change on installed systems will be varied; risks to installed systems introduced by name collisions may arise due to varied causes.
名前の衝突は、プライベート名前空間で使用されている名前を解決しようとした結果、パブリックDNSへのクエリが発生し、応答がその名前がグローバルDNS [NCRI]にあることを示している場合に発生します。つまり、パブリック名前空間とプライベート名前空間が重複すると、意図しない（したがって、潜在的に有害な）解決結果が生じる可能性があります。インストールされたシステムに対するグローバルな変更の影響はさまざまです。名前の衝突によって導入されたインストール済みシステムに対するリスクは、さまざまな原因により発生する可能性があります。
In a globally distributed system, such as the Internet, it is difficult, yet critical, to agree on policies for demarking boundaries of ownership and autonomy. Name space governance is critical to ensure predictable use of names in the global DNS.
インターネットなどのグローバルに分散されたシステムでは、所有権と自律性の境界を定めるためのポリシーに合意することは困難ですが、重要です。名前空間のガバナンスは、グローバルDNSでの名前の予測可能な使用を保証するために重要です。
In order to help ensure this uniqueness and interoperability, ICANN, through its coordination of the IANA functions, is responsible for administration of certain responsibilities associated with Internet DNS root zone management, such as generic and country code Top-Level Domains (gTLDs and ccTLDs). Prior to ICANN's creation in 1998, seven generic TLDs were defined in the early development of the Internet [RFC1591]. Since the formation of ICANN, the delegations of generic, internationalized and country code TLDs have been administered and delegated by ICANN. During these delegations, it quickly became apparent within the IETF community that there was a need to reserve name spaces that can be used for creating limited sets of internal names without fear of conflicts with current or future TLD name spaces in the global DNS [RFC2606].
この一意性と相互運用性を確保するために、ICANNはIANA機能の調整を通じて、汎用および国コードトップレベルドメイン（gTLDおよびccTLD）などのインターネットDNSルートゾーン管理に関連する特定の責任の管理を担当します。 。 ICANNが1998年に作成する前は、インターネットの初期開発で7つの汎用TLDが定義されていました[RFC1591]。 ICANNの設立以来、ジェネリック、国際化、および国別コードTLDの代表団がICANNによって管理および委託されてきました。これらの委任中に、グローバルDNSの現在または将来のTLD名前空間との競合を心配せずに、限られた内部名のセットを作成するために使用できる名前空間を予約する必要があることがIETFコミュニティ内ですぐに明らかになりました[RFC2606] 。
While the reserved TLDs [RFC2606] aimed to enable operators to use them only as a small set of reserved names internally, with limited uses, educational awareness and operational best practices did not achieve the goal of reserving special-use domain names [RFC6761]; other suffixes, not reserved though at the time not in conflict, were often employed instead. Faulty assumptions, or encouragement in some cases by vendor documentation, of "we only use this name internally and there is no possibility of leakage to the global DNS" were made by numerous operators or administrators. Numerous reports and findings have clearly disproved these faulty assumptions by showing substantial "DNS leakage" into the global DNS through mechanisms such as search lists.
予約済みのTLD [RFC2606]は、オペレーターが内部で予約済みの名前の小さなセットとしてのみ使用できるようにすることを目的としたもので、用途は限られていましたが、教育意識と運用のベストプラクティスは、特別な用途のドメイン名を予約するという目的を達成しませんでした[RFC6761]。当時は競合していないが予約されていない他の接尾辞が代わりに使用されることがよくありました。 「この名前は内部でのみ使用され、グローバルDNSに漏洩する可能性はない」という誤った仮定、または場合によってはベンダーのドキュメントによる推奨が、多数のオペレーターまたは管理者によって行われました。多数のレポートと調査結果が、検索リストなどのメカニズムを通じてグローバルDNSへの実質的な「DNS漏洩」を示すことにより、これらの誤った仮定を明らかに反証しています。
In 2012, ICANN created a new gTLD program to add a potentially unlimited number of new gTLDs to the root zone as a mechanism to enhance competition, innovation, and consumer choice. With the potential of many new gTLDs becoming delegated in the global DNS, operators or administrators who elected to use a non-delegated name space internally may face potential "name collision" problems.
2012年、ICANNは新しいgTLDプログラムを作成し、無制限の数の新しいgTLDをルートゾーンに追加して、競争、革新、および消費者の選択を強化するメカニズムとして追加しました。多くの新しいgTLDがグローバルDNSで委任される可能性があるため、委任されていない名前空間を内部で使用することを選択したオペレーターまたは管理者は、「名前の衝突」の問題に直面する可能性があります。
This document is primarily a report on the March 2014 workshop that set out to examine the causes and mitigation of such name collisions and their associated risks. It is a companion to the Workshop and Prize on Root Causes and Mitigation of Name Collisions proceedings [WPNC], and it also provides some additional background and context.
このドキュメントは、主に2014年3月のワークショップに関するレポートで、このような名前の衝突とそれに関連するリスクの原因と緩和策を調査することを目的としています。これは、根本原因と名前衝突の軽減に関するワークショップおよび賞のプロシーディング[WPNC]の仲間であり、追加の背景とコンテキストも提供します。
When the workshop was convened, the context and status of the work around name collisions could be described as follows.
ワークショップが開催されたとき、名前の衝突に関する作業のコンテキストとステータスは次のように説明できます。
Since early 2008, there had been numerous lengthy discussions within the ICANN community about the ability of the DNS root to scale to accommodate new gTLDs and the impact of making those changes on the DNS ecosystem. In March 2008, the Internet Architecture Board (IAB) observed that the introduction of suffixes in use in a number of environments could lead to instability [IAB2008]. In December 2010, the Security and Stability Advisory Committee (SSAC) issued their report on root scaling in which the committee formalized several recommendations based on "actual measurement, monitoring, and data-sharing capabilities of root zone performance" to help determine the feasibility of root scaling [SAC046]. Separately, the Root Server System Advisory Committee [RSSAC] agreed in late 2010 on the need to establish standard metrics to be collected and reported by all operators. This effort would provide the community with a baseline measure of the entire root server system's performance. With such an established baseline, any possible negative effect from additional TLDs within the root could potentially be identified. In late 2012, the ICANN Board affirmed the need to work with the root server operators via RSSAC to complete the documentation of the interactions between ICANN and the root server operators with respect to root zone scaling [IR2012].
2008年の初めから、ICANNコミュニティ内では、新しいgTLDに対応するためにDNSルートを拡張できるかどうか、およびそれらの変更をDNSエコシステムに加えることの影響について、多くの長い議論がありました。 2008年3月、インターネットアーキテクチャボード（IAB）は、多くの環境で使用されているサフィックスの導入が不安定になる可能性があることを確認しました[IAB2008]。 2010年12月、セキュリティと安定性に関する諮問委員会（SSAC）は、ルートスケーリングに関するレポートを発行しました。この委員会は、「ルートゾーンパフォーマンスの実際の測定、監視、およびデータ共有機能」に基づくいくつかの推奨事項を公式化し、ルートスケーリング[SAC046]。これとは別に、ルートサーバーシステム諮問委員会（RSSAC）は2010年後半に、すべてのオペレーターが収集および報告する標準的なメトリックを確立する必要性について合意しました。この取り組みにより、コミュニティはルートサーバーシステム全体のパフォーマンスの基準となる基準を提供します。このように確立されたベースラインがあれば、ルート内の追加のTLDから起こり得る悪影響を特定できる可能性があります。 2012年後半、ICANN理事会は、ルートゾーンのスケーリングに関するICANNとルートサーバーオペレーター間の相互作用の文書化を完了するために、RSSACを介してルートサーバーオペレーターと協力する必要性を確認しました[IR2012]
In March 2013, SSAC published an advisory titled "SSAC Advisory on Internal Name Certificates," which identified a Certificate Authority (CA) practice that, if widely exploited, "could pose a significant risk to the privacy and integrity of secure Internet communications" [SAC057]. The ICANN Board acknowledged the issues identified in the advisory report on internal name certificates [SAC057] as part of a more general category of issues. These issues included installed systems utilizing a namespace in a private network that includes a non-delegated TLD that is later delegated into the root. In May 2013, the ICANN Board commissioned a study on the use within private name spaces of TLDs that are not currently delegated at the root level of the global DNS [ISTUDY]. This study was focused on potential name collision events between applied-for new gTLDs and non-delegated TLDs potentially used in private namespaces. The study also examined the potential possibility of name collisions arising from the use of digital certificates referenced in the SSAC report on internal name certificates [SAC057].
2013年3月、SSACは「内部名証明書に関するSSACアドバイザリ」というタイトルのアドバイザリを公開しました。これは、広く利用されている場合、「安全なインターネット通信のプライバシーと整合性に重大なリスクをもたらす可能性がある」認証局（CA）の慣行を特定しました。 SAC057]。 ICANN理事会は、内部名証明書に関するアドバイザリレポート[SAC057]で特定された問題を、より一般的なカテゴリの問題の一部として認めました。これらの問題には、後でルートに委任された非委任TLDを含むプライベートネットワークのネームスペースを利用するインストール済みシステムが含まれます。 2013年5月、ICANN理事会は、現在グローバルDNS [ISTUDY]のルートレベルで委任されていないTLDのプライベート名前空間内での使用に関する調査を委託しました。この調査は、新しいgTLDの適用対象と、非公開名前空間で使用される可能性のある非委任TLDとの間の潜在的な名前衝突イベントに焦点を当てました。この調査では、内部名前証明書に関するSSACレポート[SAC057]で参照されているデジタル証明書の使用から生じる名前の衝突の潜在的な可能性も調べました。
Between the RSSAC's and SSAC's advisory statements ([RSSAC] [SAC046]) and the ICANN commissioning of a study in May 2013, there was significant progress on establishing formalized, coordinated monitoring and measurement of the root. RSSAC approached its finalization of the specific metrics that each root operator will collect and initiated discussions about where the operators will send their data for analysis once collected. To properly gauge the risks of new gTLD delegations to the root, an established baseline of normal performance of the system would be required to start sufficiently ahead of the new delegations. The execution of these RSSAC and SSAC recommendations was timed poorly with the commissioned study, resulting in a limited pool of data repositories from which any baseline and risk measurements could be established.
RSSACおよびSSACのアドバイザリステートメント（[RSSAC] [SAC046]）とICANNが2013年5月に調査を委託したところ、正式に調整された根の監視と測定の確立に大きな進展がありました。 RSSACは、各ルートオペレーターが収集する特定のメトリックの最終化に取り組み、収集されたオペレーターが分析のためにデータを送信する場所についての議論を開始しました。ルートへの新しいgTLD委任のリスクを適切に測定するには、システムの通常のパフォーマンスの確立されたベースラインが、新しい委任よりも十分に先に開始する必要があります。これらのRSSACとSSACの推奨の実行は委託された調査では不十分なタイミングで行われたため、ベースラインとリスク測定を確立できるデータリポジトリのプールが制限されていました。
It is common practice for each root operator to monitor its own root server, and some operators report the status and performance of their services publicly. As of ICANN's study commissioned in May 2013 [ISTUDY], there was no mechanism in place to allow a detailed view of the entire root system, short of the annual "Day in the Life" ([DITL]) data repository, which contains root DNS data over a short coordinated time period from a varying subset of root operators and was intended to be used for research purposes, not to provide overall monitoring and an operational view of system health. Due to the lack of a more comprehensive and desirable data repository for baseline and collision analysis DITL has become the de facto referential dataset for root traffic analysis.
各ルートオペレーターが独自のルートサーバーを監視することは一般的であり、一部のオペレーターはサービスのステータスとパフォーマンスを公に報告します。 2013年5月に委託されたICANNの調査[ISTUDY]の時点で、ルートを含む年次「Day in the Life」（[DITL]）データリポジトリを除き、ルートシステム全体の詳細なビューを許可するメカニズムはありませんでしたルートオペレーターのさまざまなサブセットからの調整された短い期間のDNSデータであり、研究目的で使用することを目的としており、システム全体の監視と運用ビューの提供を目的としていません。ベースラインと衝突分析のためのより包括的で望ましいデータリポジトリがないため、DITLはルートトラフィック分析の事実上の参照データセットになりました。
The commissioned study, conducted by the Interisle Consulting Group, was published in August of 2013. Their report "Name Collisions in the DNS" [INTERISLE], based on [DITL] measurements, addressed name collisions in the DNS and also recommended options to mitigate the various name collision risks. The study identified categories of strings according to the risk they represent: low risk (80 percent of applied-for strings), uncalculated risk (20 percent of applied-for strings), and high risk (2 applied-for strings).
Interisle Consulting Groupが実施した委託調査は2013年8月に公開されました。彼らのレポート「DNSでの名前の衝突」[INTERISLE]は、[DITL]の測定に基づいて、DNSでの名前の衝突に対処し、緩和するための推奨オプションも示しましたさまざまな名前の衝突リスク。この調査では、文字列のカテゴリを、それらが表すリスクに従って識別しました。低リスク（適用された文字列の80％）、計算されていないリスク（適用された文字列の20％）、および高リスク（2つの適用された文字列）。
At the same time as the [INTERISLE] study, ICANN published a proposal, titled "New gTLD Collision Occurrence Management Plan" [NGCOMP], to manage the risk of name collisions within the applied-for gTLDs. Based on measurements, ICANN deemed two strings, .home and .corp, to be high risk because of their widespread use within internal networks and would indefinitely delay their delegation [INTERISLE]. Those strings within the uncalculated-risk classification would be delayed 2 to 3 months in their application process while ICANN conducted more research into whether the string is of high- or low-risk classification. Those in the low-risk classification would face a delay in activating domains until 120 days after contracting with ICANN to allow for the change in certificate authority practices recommended in the SSAC report on internal name certificates [SAC057].
[INTERISLE]の調査と同時に、ICANNは「新しいgTLD衝突発生管理計画」[NGCOMP]というタイトルの提案を発行し、申請されたgTLD内での名前の衝突のリスクを管理しました。測定に基づいて、ICANNは.homeと.corpの2つの文字列が内部ネットワーク内で広く使用されているため高リスクであり、委任を無期限に遅らせると判断しました[INTERISLE]。計算されていないリスク分類内のこれらの文字列は、ICANNが文字列が高リスク分類であるか低リスク分類であるかについてより多くの調査を行っている間、申請プロセスで2〜3か月遅れます。内部リスク証明書のSSACレポート[SAC057]で推奨されている認証局の慣行の変更を可能にするために、ICANNとの契約後120日まで、リスクの低い分類のドメインはドメインのアクティブ化が遅れます。
Within the ICANN proposal [NGCOMP], an approach termed the "alternative path to delegation" was outlined, in which a registry operator could elect to proceed with delegation, provided it initially blocked all second-level domains (SLDs) that appeared in the certain DITL datasets pending the completion of the assessment. The majority of new gTLD applicants that were eligible elected this alternative path once otherwise approved for delegation. The plan also outlined an outreach campaign to educate system administrators, software developers, and other engineers about the name collision issue and possible mitigation measures.
ICANNの提案[NGCOMP]内で、「委任への代替パス」と呼ばれるアプローチが概説されました。レジストリオペレーターは、特定の評価が完了するまでDITLデータセット。適格だった新しいgTLD申請者の大多数は、委任が承認されると、この代替パスを選択しました。この計画では、システム管理者、ソフトウェア開発者、およびその他のエンジニアに、名前の衝突の問題と考えられる緩和策について教育するためのアウトリーチキャンペーンについても概説しました。
As a further provision, the "New gTLD Collision Occurrence Management Plan" called for a follow-up study that would develop a "Name Collision Occurrence Management Framework" [NCOMF]. In February 2014, the document, "Mitigating the Risk of DNS Namespace Collisions: Phase One Report," was published by the ICANN-contracted group JAS Global Advisors [MRDNC]. The report provides a number of recommendations for addressing the name collision issue focusing on a technique termed "controlled interruption," in which a registry would temporarily resolve all SLDs (or all SLDs present in the block list) to a specific IP: 127.0.53.53. The report also makes provisions to implement an emergency plan and strategy in case name collisions had a "clear danger to human life."
さらなる規定として、「新しいgTLD衝突発生管理計画」は、「名前衝突発生管理フレームワーク」[NCOMF]を開発するフォローアップ調査を求めました。 2014年2月、ドキュメント「DNS名前空間衝突のリスクの軽減：フェーズ1レポート」は、ICANNと契約しているグループJAS Global Advisors [MRDNC]によって発行されました。このレポートは、レジストリが一時的にすべてのSLD（またはブロックリストに存在するすべてのSLD）を特定のIPに解決する「制御された中断」と呼ばれる手法に焦点を当てた名前の衝突の問題に対処するためのいくつかの推奨事項を提供します：127.0.53.53 。また、名前の衝突が「人命への明らかな危険」を生じた場合に備えて、緊急時の計画と戦略を実施するための規定も作成しています。
In the time frame after the workshop, a final version of the Phase One Report was released in June 2014 [MRDNC].
ワークショップ後の時間枠で、フェーズ1レポートの最終版が2014年6月にリリースされました[MRDNC]。
In July 2014, after a community review phase, a final recommendation was issued by ICANN [NCOMFINAL]; this has been followed by the publication of management documents for the implementation of a controlled interrupt for new gTLD delegations [NOCA] [NCSLDCIV] [ADDNOCA].
2014年7月、コミュニティレビューフェーズの後、ICANN [NCOMFINAL]によって最終的な勧告が出されました。これに続いて、新しいgTLD委任[NOCA] [NCSLDCIV] [ADDNOCA]の制御された割り込みを実装するための管理ドキュメントが公開されました。
Much of the framework called for in the Name Collision Occurrence Management Framework [NCOMF] was not released by the time of writing this document, and the Phase One Report [MRDNC] indicated that its publication was delayed due to a security vulnerability [JASBUG] identified during the course of the work.
Name Collision Occurrence Management Framework [NCOMF]で要求されたフレームワークの多くは、このドキュメントの執筆時点ではリリースされておらず、フェーズ1レポート[MRDNC]は、特定されたセキュリティ脆弱性[JASBUG]により公開が遅れていることを示しました作業の過程で。
Broad community efforts to measure the impact of name collisions were not included in the final recommendation issued by ICANN [NCOMFINAL]. At the time of this writing, RSSAC has just published its specification of common measurements to be collected by root operators, meeting one part of the needs for measurements of the root server system [RSSAC002].
名前の衝突の影響を測定するための広範なコミュニティの取り組みは、ICANN [NCOMFINAL]によって発行された最終的な勧告には含まれていませんでした。この記事の執筆時点で、RSSACは、ルートオペレーターによって収集される一般的な測定の仕様を公開したばかりであり、ルートサーバーシステム[RSSAC002]の測定のニーズの一部を満たしています。
The Workshop and Prize on Root Causes and Mitigation of Name Collisions [WPNC], sponsored by Verisign, took place March 8-10, 2014 in London, United Kingdom. The WPNC was open to the public, and it gathered subject-area specialists, researchers, and practitioners to discuss and present their views, concerns, and ideas surrounding the name collision issue. Proceedings are published at the workshop's website [WPNC].
Verisignが後援する、根本原因と名前の衝突の軽減に関するワークショップと賞[WPNC]は、2014年3月8〜10日にイギリスのロンドンで開催されました。 WPNCは一般に公開されており、サブジェクトエリアのスペシャリスト、研究者、実務家が集まり、名前の衝突の問題に関する彼らの見解、懸念、アイデアを議論して提示しました。議事録はワークショップのウェブサイト[WPNC]で公開されています。
The workshop focused on studies of name collision risks and mitigations with the expectation to advance the global community's insight into operational uses of name suffixes that can result in name collisions and to gain a stronger understanding of the potential risks for the users of the installed systems. Additional emphasis and attention was given to discussions that might advance the state of knowledge about the architecture and impacts of DNS namespaces with multiple scopes or resolution contexts and the utilization of new methods of monitoring and understanding the needs and methods for mitigating emerging Internet risks around name collisions. A technical program committee, whose members spanned a variety of organizations and universities, was assembled. The committee issued a call for papers and evaluated all submissions to ensure the highest level of quality.
ワークショップでは、名前の衝突を引き起こす可能性のある名前のサフィックスの運用上の使用法に関するグローバルコミュニティの洞察を高め、インストールされたシステムのユーザーの潜在的なリスクをより深く理解することを期待して、名前の衝突のリスクと軽減策の研究に焦点を当てました。複数のスコープまたは解決コンテキストを持つDNS名前空間のアーキテクチャと影響に関する知識の状態を進歩させる可能性のあるディスカッションと、名前に関する新たなインターネットリスクを軽減および軽減するためのニーズと方法を監視および理解する新しい方法の利用に関する議論に、さらに重点が置かれました。衝突。さまざまな組織や大学にまたがる技術プログラム委員会が編成されました。委員会は論文募集を行い、すべての提出物を評価して最高レベルの品質を確保しました。
A synthesis of the accepted papers and conference proceedings is captured in the subsections below. Another informal synopsis of the workshop combined with individual statements and observations is available online [COMMENTARY].
採択された論文と会議の議事録は、以下のサブセクションにまとめられています。ワークショップの別の非公式な概要と個々のステートメントおよび観察を組み合わせたものは、オンラインで入手できます[コメント]。
Many of the research papers focused on the analysis of DITL data to better understand various aspects of the root NXDOMAIN traffic ([TECHNIQUES], [RARDBITS], [BLOCKLISTS], [MODELING], and [SEARCHLISTS]). Note: all workshop contributions are listed in Appendix B; full papers and slides are available at the website [WPNC].
ルートNXDOMAINトラフィックのさまざまな側面をよりよく理解するためにDITLデータの分析に焦点を当てた多くの研究論文（[TECHNIQUES]、[RARDBITS]、[BLOCKLISTS]、[MODELING]、および[SEARCHLISTS]）。注：ワークショップの貢献はすべて付録Bに記載されています。完全な論文とスライドは、ウェブサイト[WPNC]で入手できます。
While the DITL data has become the de facto referential dataset for root traffic analysis, some presenters echoed concerns that the dataset may have become biased or polluted with "artificial" queries after the ICANN "Reveal Day," in which the list of applied-for gTLD strings was publicly disclosed. No conclusive or empirical evidence of tampering was presented; however, concerns about the integrity and reliability of future DITL collections and analysis for purposes related to new gTLDs were echoed by some panelists [IESCPANEL]. Furthermore, the statistical accuracy and completeness of DITL data -- used to draw inferential conclusions or more specifically create SLD block lists -- was examined. The efficacy of blocking domains based on sampled DNS data, e.g., DITL, was investigated by comparing measurements of SLDs within DITL and that of a multi-month root NXDOMAIN collection at the A and J roots [BLOCKLISTS]. The findings provided insights into SLD-root affinities, SLD temporal query patterns and occurrence frequencies that demonstrated the ineffectiveness of block listing domains based on sampled DNS data such as [DITL].
DITLデータはルートトラフィック分析の事実上の参照データセットになりましたが、一部の発表者は、データセットがICANNの「公開日」の後に「人工的な」クエリでバイアスまたは汚染されている可能性があるという懸念を繰り返しました。 gTLD文字列は公開されました。改ざんの決定的または経験的な証拠は提示されていません。ただし、一部のパネリスト[IESCPANEL]は、新しいgTLDに関連する目的での将来のDITLコレクションおよび分析の整合性と信頼性に関する懸念を表明しました。さらに、推論的な結論を導き出すため、またはより具体的にはSLDブロックリストを作成するために使用されるDITLデータの統計的正確性と完全性が調査されました。 DITLなどのサンプリングされたDNSデータに基づいてドメインをブロックすることの有効性を、DITL内のSLDの測定値と、AおよびJルートでの複数月のルートNXDOMAINコレクションの測定値を比較することによって調査しました[ブロックリスト]。この調査結果は、SLDルートアフィニティ、SLD時間クエリパターン、および発生頻度についての洞察を提供し、[DITL]などのサンプリングされたDNSデータに基づくブロックリストドメインの非有効性を実証しました。
Measurements of queries specifying the recursion desired (RD) bit to the roots in DITL were quantified to identify the level and nature of naive DNS clients and to determine and assess potential impacts that could arise from the proposed SLD blocking technique to these naive clients [RARDBITS]. A substantial proportion of the root server request traffic contained queries with the RD bit specified. Both in absolute and relative terms, requests specifying the RD bit for applied-for gTLDs were found to be significantly lower when compared to existing TLDs. The root cause determination of what system or mechanism is responsible for generating the queries was inconclusive and only speculative explanations of faulty implementations of a DNS resolving server were hypothesized. However, the analysis was also not able to identify instances of actual or potential harm resulting from these naive clients, suggesting if SLD blocking techniques were to be utilized, it is unlikely there would be any negative impact to these naive clients.
DITLのルートに必要な再帰（RD）ビットを指定するクエリの測定値を定量化して、ナイーブDNSクライアントのレベルと性質を特定し、提案されたSLDブロッキングテクニックがこれらのナイーブクライアントにもたらす可能性のある影響を特定および評価しました[RARDBITS ]。ルートサーバーの要求トラフィックのかなりの部分に、RDビットが指定されたクエリが含まれていました。絶対的な意味でも相対的な意味でも、適用されるgTLDのRDビットを指定するリクエストは、既存のTLDと比較すると大幅に低いことがわかりました。どのシステムまたはメカニズムがクエリの生成に関与しているかの根本原因の決定は決定的ではなく、DNS解決サーバーの誤った実装の推測的な説明のみが仮定されました。ただし、分析ではこれらのナイーブクライアントに起因する実際のまたは潜在的な害のインスタンスを特定することもできなかったため、SLDブロッキングテクニックを利用する場合、これらのナイーブクライアントに悪影響が及ぶ可能性は低いと考えられます。
Comparison of elements can often help us to understand a system as a whole. A passive study of the DNS traffic in a provisioned domain such as "corp.com" may elucidate certain name collision parallels [CORPCOM]. Such measurements were presented as a proxy for the ".corp" potential new gTLD. According to the study, significant DNS traffic volume was directed at a variety of third-level domains under "corp.com". This prompted a series of questions surrounding how name collisions can be identified, as most end-users won't recognize that problems may be due to a name collision. How will users know that the problem they are experiencing is a result of a new, colliding gTLD? Will support groups be able to diagnose a name collision event from reported symptom(s)? Will a collision-based security hole be detectable?
要素の比較は、システム全体を理解するのに役立ちます。 「corp.com」などのプロビジョニングされたドメインでのDNSトラフィックのパッシブな調査は、特定の名前の衝突の類似点を明らかにする可能性があります[CORPCOM]。そのような測定値は、「。corp」の潜在的な新しいgTLDのプロキシとして提示されました。この調査によると、「corp.com」の下のさまざまなサードレベルドメインに大量のDNSトラフィックが向けられていました。ほとんどのエンドユーザーは問題が名前の衝突が原因である可能性があることを認識していないため、これは名前の衝突を識別する方法を取り巻く一連の質問を促しました。ユーザーは、発生している問題が、新しいgTLDの衝突の結果であることをどのようにして知るのでしょうか。サポートグループは、報告された症状から名前の衝突イベントを診断できますか？衝突ベースのセキュリティホールは検出されますか？
These questions, upon which underpinnings rely on communication and educational awareness, may find recommendations or parallels from other system references during the workshop [JASFRAMEWORK] -- such as the postal and telephone system. Most telephone and postal systems have evolved over time, requiring individuals to alter the way they address their parcels or place their calls. Both systems implemented their changes in such a way that prior to the change, educational material is distributed and communicated and for a period of time and after the change, compliance of the previous standard is temporarily accepted. While the telephone and postal system operate in a very different way than the DNS, these parallels of "advanced notification, education and communication, and a grace period" were insightful for how other similar systems transitioned.
これらの質問は、その根拠がコミュニケーションと教育意識に依存しているため、ワークショップ[JASFRAMEWORK]中に他のシステムリファレンス（郵便や電話システムなど）からの推奨事項や類似点を見つける可能性があります。ほとんどの電話システムと郵便システムは時間とともに進化してきており、小包への対処方法や電話をかける方法を個人が変更する必要があります。どちらのシステムも、変更前に教育資料が配布および伝達され、変更後しばらくの間、以前の標準への準拠が一時的に受け入れられるように変更を実装しました。電話と郵便のシステムはDNSとは非常に異なる方法で動作しますが、これらの「高度な通知、教育、通信、および猶予期間」のこれらの類似点は、他の同様のシステムの移行方法に洞察を与えました。
Statements from several TLD operators during the conference reverberated a theme for the need of improved tooling, education, and communication surrounding name collisions. The delegation of new gTLDs is an ongoing event, and there is a clear and immediate need for these operators to have visibility to monitor and measure the effects of these new gTLD delegations. A lack of tools, shared data, communication, and education surrounding name collisions has handicapped operators in their ability to quantitatively measure and proactively provide any steps for mitigation of risks. To this end, numerous techniques, frameworks, and models that focused on the concepts of analyzing, detecting, and measuring various name collision risk factors were presented and reviewed with the hope of understanding these underlying concerns and issues ([TECHNIQUES] [MODELING] [SEARCHLISTS] [DNSENDUSER] [ENTNETWORK]).
会議中のいくつかのTLDオペレーターの発言は、名前の衝突を取り巻くツール、教育、およびコミュニケーションの改善の必要性についてのテーマを反響させました。新しいgTLDの委任は継続的なイベントであり、これらのオペレーターがこれらの新しいgTLD委任の影響を監視および測定するための可視性を持っていることは明らかで緊急の必要性があります。名前の衝突を取り巻くツール、共有データ、コミュニケーション、および教育の欠如により、オペレーターは、リスクを軽減するためのあらゆる手順を定量的に測定し、予防的に提供する能力に障害を抱えています。この目的のために、さまざまな名前の衝突リスク要因の分析、検出、および測定の概念に焦点を当てた多数の手法、フレームワーク、およびモデルが提示され、これらの根本的な懸念事項と問題を理解することを期待してレビューされました（[テクニック] [モデリング] [検索リスト] [DNSENDUSER] [ENTNETWORK]）。
Data-driven analysis and mitigation require operators to be versed and skilled with data analysis techniques to better understand the contextual intent and ownership of DNS queries. An overview of various DNS analysis techniques in which ways of decomposing names, measuring temporal distributions between queries, and detecting organizational/geographical affinities was presented [TECHNIQUES]. More-specific techniques were also showcased, such as a systematic way of observing and characterizing the impact of search lists within root DNS traffic allowing operators to quantify the number of unique entities that may be reliant on a particular name space [SEARCHLISTS]. While not exhaustive, the techniques presented have been proven to elucidate patterns within root DNS traffic data and could serve as the potential building blocks of a DNS analysis framework.
データ主導の分析と軽減には、DNSクエリのコンテキストの意図と所有権をよりよく理解するために、オペレーターがデータ分析技術に精通し、熟練している必要があります。名前を分解する方法、クエリ間の時間的分布を測定する方法、および組織的/地理的な類似性を検出するさまざまなDNS分析手法の概要が提示されました[テクニック]。ルートDNSトラフィック内の検索リストの影響を体系的に観察して特徴付ける方法など、より具体的な手法も紹介されました。これにより、オペレーターは特定の名前空間に依存する可能性のある一意のエンティティの数を定量化できます[検索リスト]。網羅的ではありませんが、提示された手法は、ルートDNSトラフィックデータ内のパターンを解明することが証明されており、DNS分析フレームワークの潜在的なビルディングブロックとして機能する可能性があります。
Most of the previously published work focused on name collisions has produced various quantitative analyses based on observations of Internet traffic and data, including DNS queries and web content, in which behavior and associated risks have been inferred. An understanding of the inverse of the process by starting with a fundamental model of name resolution at the client was proposed as an alternative means to define risk [MODELING]. This model deconstructed the process of name resolution at the resolver library of a client system and formalized a model from which derived metrics could be used to define and quantify associated risks. While the model presented is only a piece of the greater name collision puzzle, it provides potentially new insights into what may otherwise be considered a missing piece.
以前に公開された名前の衝突に焦点を当てた研究のほとんどは、DNSクエリやWebコンテンツを含む、インターネットトラフィックとデータの観測に基づいて、動作と関連するリスクが推定されたさまざまな定量分析を生み出しています。リスクを定義するための代替手段として、クライアントでの名前解決の基本モデルから始めることにより、プロセスの逆を理解することが提案されました[モデリング]。このモデルは、クライアントシステムのリゾルバーライブラリでの名前解決のプロセスを分解し、派生メトリックを使用して関連するリスクを定義および定量化できるモデルを正式化しました。提示されたモデルは、より大きな名前の衝突パズルの一部にすぎませんが、それがなければ欠落している部分と見なされる可能性のあるものに対する潜在的に新しい洞察を提供します。
Just as important as understanding the root causes of name collisions, providing effective mitigation strategies is a critical piece of the name collision puzzle. Mitigation can be achieved from both higher levels, such as ICANN, as well as the enterprise level. Proposed strategies for mitigating name collisions at both of these levels were presented. While the technical details for each proposed strategy varies, underlying dependencies in both strategies require operators to monitor and educate/train their users.
名前衝突の根本的な原因を理解するのと同じくらい重要であるので、効果的な緩和戦略を提供することは、名前衝突パズルの重要な部分です。緩和策は、ICANNなどの上位レベルとエンタープライズレベルの両方から達成できます。これらのレベルの両方で名前の衝突を緩和するための提案された戦略が提示されました。提案された各戦略の技術的な詳細は異なりますが、両方の戦略の基本的な依存関係により、オペレーターはユーザーを監視および教育/トレーニングする必要があります。
In their concluding statement [NEXTSTEPS], the workshop committee stated:
ワークショップ委員会は、結論書[NEXTSTEPS]で次のように述べています。
It occurs to the program committee that the analysis of the interactions between the different uses of domain names within local or global context is almost a nonexistent topic of research. This may have to do with the lack of accessible data, lack of theory of root causes, a lack of interest, or a bias in the participation of the workshop. We think that this is evidence that this study of the global centrally important technical system needs to be ramped up.
プログラム委員会は、ローカルコンテキストまたはグローバルコンテキスト内でのドメイン名のさまざまな使用法間の相互作用の分析は、ほとんど存在しない研究トピックであることに気付きます。これは、アクセス可能なデータの欠如、根本原因の理論の欠如、関心の欠如、またはワークショップへの参加における偏見と関係がある可能性があります。これは、地球規模で重要な技術システムに関するこの研究を強化する必要があることの証拠であると考えています。
Follow-on commentary [NEXTSTEPS] from the attendees reaffirmed this opinion with recurring messages of a need to understand the root causes of name collision and the need to overcome shortcomings within our shared data collection, monitoring, and analysis of the DNS.
参加者による後続の解説[NEXTSTEPS]は、名前の衝突の根本的な原因を理解する必要性、およびDNSの共有データ収集、監視、分析内の欠点を克服する必要性の繰り返しのメッセージでこの意見を再確認しました。
Many name collision unknowns still exist. What are the root causes of these queries? What is going on within a recursive name server? What vulnerabilities or subtle attack vectors do these new gTLD delegations enable? The limited datasets available to researchers and operators are not sufficient to draw baseline measurements for these questions, forcing the community to make inferences and rank guesses as to what is going on within the DNS. Using these suboptimal data repositories to create solutions such as block lists is only dealing with the symptoms of the problem and not addressing the root cause. To properly answer these questions, the community needs to address the issue of a shortage of funding and data collection/analysis. Communication and educational outreach programs need to be improved in order raise the awareness of impacted parties and broaden participation and sharing.
多くの名前衝突の未知数がまだ存在しています。これらのクエリの根本的な原因は何ですか？再帰的なネームサーバーでは何が起こっていますか？これらの新しいgTLD委任によって、どのような脆弱性または微妙な攻撃ベクトルが可能になりますか？研究者やオペレーターが利用できるデータセットは限られているため、これらの質問のベースライン測定を行うには不十分であり、コミュニティはDNS内で何が行われているのかを推測してランク付けを推測する必要があります。これらの次善のデータリポジトリを使用してブロックリストなどのソリューションを作成することは、問題の症状のみを処理し、根本的な原因には対処しません。これらの質問に適切に回答するには、コミュニティは資金不足とデータ収集/分析の問題に対処する必要があります。影響を受ける当事者の意識を高め、参加と共有を拡大するために、コミュニケーションと教育のアウトリーチプログラムを改善する必要があります。
Workshop participants discussed security aspects related to root cause analysis and mitigation techniques of potential name collision events. As noted in several papers and presentations, security concerns may both arise and be addressed with name collision mitigation techniques. Follow-on measurement-based research is important to security considerations for name collisions.
ワークショップの参加者は、潜在的な名前の衝突イベントの根本原因分析および軽減技術に関連するセキュリティの側面について議論しました。いくつかの論文やプレゼンテーションで述べられているように、セキュリティ上の問題が発生する可能性があり、名前の衝突を軽減する技術で対処することができます。後続の測定ベースの調査は、名前の衝突に関するセキュリティの考慮事項にとって重要です。
[ADDNOCA] ICANN, "Addendum To Name Collision Occurrence Assessment", November 2014, <http://newgtlds.icann.org/sites/default/files/ agreements/name-collision-assessment-addendum-14nov14-en.htm>.
[ADDNOCA] ICANN、「衝突発生評価に名前を付ける補遺」、2014年11月、<http://newgtlds.icann.org/sites/default/files/ Agreements / name-collision-assessment-addendum-14nov14-en.htm> 。
[BLOCKLISTS] Thomas, M., Labrou, Y., and A. Simpson, "The Effectiveness of Block Lists in Preventing Collisions", March 2014, <http://namecollisions.net/program/index.html>.
[ブロックリスト]トーマス、M。、ラブルー、Y。、およびA.シンプソン、「衝突防止におけるブロックリストの有効性」、2014年3月、<http://namecollisions.net/program/index.html>。
[COMMENTARY] Kaliski, B., "Proceedings of Name Collisions Workshop Available", March 2014, <http://www.circleid.com/posts/20140326_proceedings_ of_name_collisions_workshop_available/>.
[解説] Kaliski、B。、「Proceedings of Name Collisions Workshop Available」、2014年3月、<http://www.circleid.com/posts/20140326_proceedings_of_name_collisions_workshop_available/>。
[CORPCOM] Strutt, C., "Looking at corp.com as a proxy for .corp", March 2014, <http://namecollisions.net/program/index.html>.
[CORPCOM] Strutt、C。、「corp.comを.corpのプロキシとして見る」、2014年3月、<http://namecollisions.net/program/index.html>。
[DITL] Center for Applied Internet Data Analysis, "A Day in the Life of the Internet (DITL)", July 2011, <http://www.caida.org/projects/ditl/>.
[DITL] Center for Applied Internet Data Analysis、「A Day in the Life of the Internet（DITL）」、2011年7月、<http://www.caida.org/projects/ditl/>。
[DNS-OARC] Mitchell, K., "DNS-OARC", March 2014, <http://namecollisions.net/program/index.html>.
[DNS-OARC] Mitchell、K。、「DNS-OARC」、2014年3月、<http://namecollisions.net/program/index.html>。
[DNSENDUSER] Huston, G., "Measuring DNS Behaviors from the End User Perspective", March 2014, <http://namecollisions.net/program/index.html>.
[DNSENDUSER] Huston、G。、「Measuring DNS Behaviors from the End User Perspective」、2014年3月、<http://namecollisions.net/program/index.html>。
[ENTNETWORK] Hoffman, P., "Name Collision Mitigation for Enterprise Networks", March 2014, <http://namecollisions.net/program/index.html>.
[ENTNETWORK]ホフマン、P。、「エンタープライズネットワークの名前衝突の軽減」、2014年3月、<http://namecollisions.net/program/index.html>。
[IAB2008] IAB, "The IAB's response to ICANN's solicitation on DNS stability", March 2008, <https://www.iab.org/documents/correspondence-reports-documents/docs2008/2008-03-07-icann-new-gtlds/>.
[IAB2008] IAB、「DNSの安定性に関するICANNの要請に対するIABの対応」、2008年3月、<https://www.iab.org/documents/correspondence-reports-documents/docs2008/2008-03-07-icann-new -gtlds />。
[IESCPANEL] Woolf, S., Koch, P., Kolkman, O., Kumari, W., and J. Levine, "Internet Engineering and Standards Considerations", March 2014, <http://namecollisions.net/program/index.html>.
[IESCPANEL] Woolf、S.、Koch、P.、Kolkman、O.、Kumari、W.、J。Levine、「インターネットエンジニアリングと標準の考慮事項」、2014年3月、<http://namecollisions.net/program/ index.html>。
[INTERISLE] ICANN, "Name Collision in the DNS", Version 1.5, August 2013, <https://www.icann.org/en/about/staff/security/ ssr/name-collision-02aug13-en.pdf>.
[INTERISLE] ICANN、「DNSでの名前の衝突」、バージョン1.5、2013年8月、<https://www.icann.org/en/about/staff/security/ ssr / name-collision-02aug13-en.pdf> 。
[IR2012] ICANN, "Preliminary Report | Regular Meeting of the ICANN Board", September 2012, <http://www.icann.org/en/groups/ board/documents/prelim-report-13sep12-en.htm>.
[IR2012] ICANN、「暫定レポート| ICANN理事会の定例会議」、2012年9月、<http://www.icann.org/en/groups/board/documents/prelim-report-13sep12-en.htm>。
[ISTUDY] ICANN, "Security Studies on the Use of Non-Delegated TLDs, and Dotless Names", May 2013, <https://www.icann.org/en/news/announcements/ announcement-28may13-en.htm>.
[ISTUDY] ICANN、「委任されていないTLDとドットレス名の使用に関するセキュリティ調査」、2013年5月、<https://www.icann.org/en/news/announcements/announcement-28may13-en.htm> 。
[JASBUG] Common Vulnerabilities and Exposures, "Group Policy Remote Code Execution Vulnerability", CVE-2015-0008, February 2015, <http://www.cve.mitre.org/cgi-bin/ cvename.cgi?name=CVE-2015-0008>.
[JASBUG]一般的な脆弱性と露出、「グループポリシーのリモートコード実行の脆弱性」、CVE-2015-0008、2015年2月、<http://www.cve.mitre.org/cgi-bin/ cvename.cgi？name = CVE -2015-0008>。
[JASFRAMEWORK] Schmidt, J., "Name Collisions Management Framework", March 2014, <http://namecollisions.net/program/index.html>.
[JASFRAMEWORK] Schmidt、J。、「Name Collisions Management Framework」、2014年3月、<http://namecollisions.net/program/index.html>。
[KEEPEYE] Schneier, B., "Keeping an Eye on Name Collisions", March 2014, <http://namecollisions.net/program/index.html>.
[KEEPEYE] Schneier、B。、「Keeping an Eye On Name Collisions」、2014年3月、<http://namecollisions.net/program/index.html>。
[MODELING] Deccio, C. and D. Wessels, "What's in a Name (Collision): Modeling and Quantifying Collision Potential", March 2014, <http://namecollisions.net/program/index.html>.
[モデリング] Deccio、C。およびD. Wessels、「What's in a Name（Collision）：Modeling and Quantifying Collision Potential」、2014年3月、<http://namecollisions.net/program/index.html>。
[MRDNC] ICANN, "Mitigating the Risk of DNS Namespace Collisions: A Study on Namespace Collisions in the Global Internet DNS Namespace and a Framework for Risk Mitigation", February 2014, <https://www.icann.org/en/about/staff/ security/ssr/name-collision-mitigation-26feb14-en.pdf>.
[MRDNC] ICANN、「DNS名前空間の衝突のリスクの軽減：グローバルインターネットDNS名前空間での名前空間の衝突とリスク軽減のフレームワークに関する研究」、2014年2月、<https://www.icann.org/en/about / staff / security / ssr / name-collision-mitigation-26feb14-en.pdf>。
[NCOMF] ICANN, "ICANN Selects Lead for Development of Name Collision Occurrence Management Framework", November 2013, <http://www.icann.org/en/news/announcements/ announcement-2-11nov13-en.htm>.
[NCOMF] ICANN、「ICANNが名前衝突発生管理フレームワークの開発のリードを選択」、2013年11月、<http://www.icann.org/en/news/announcements/announcement-2-11nov13-en.htm>。
[NCOMFINAL] ICANN, "Name Collision Occurrence Management Framework", July 2014, <https://www.icann.org/en/system/files/files/ name-collision-framework-30jul14-en.pdf>.
[NCOMFINAL] ICANN、「Name Collision Occurrence Management Framework」、2014年7月、<https://www.icann.org/en/system/files/files/ name-collision-framework-30jul14-en.pdf>。
[NCRI] ICANN, "Name Collision Resources & Information", <http://www.icann.org/en/help/name-collision>.
[NCRI] ICANN、「Name Collision Resources＆Information」、<http://www.icann.org/en/help/name-collision>。
[NCSLDCIV] ICANN, "Name Collision SLD Controlled Interruption Variations", September 2014, <http://newgtlds.icann.org/sites/default/files/ agreements/name-collision-sld-controlled-interruption-12sep14-en.htm>.
[NCSLDCIV] ICANN、「Name Collision SLD Controlled Interruption Variations」、2014年9月、<http://newgtlds.icann.org/sites/default/files/ Agreements / name-collision-sld-control-interruption-12sep14-en。 htm>。
[NEXTSTEPS] Kaliski, B., "Workshop Wrap-Up and Next Steps", March 2014, <http://namecollisions.net/program/index.html>.
[NEXTSTEPS] Kaliski、B。、「ワークショップのまとめと次のステップ」、2014年3月、<http://namecollisions.net/program/index.html>。
[NGCOMP] ICANN, "New gTLD Collision Risk Mitigation", August 2013, <https://www.icann.org/en/about/staff/security/ssr/ new-gtld-collision-mitigation-05aug13-en.pdf>.
[NGCOMP] ICANN、「新しいgTLD衝突リスク軽減」、2013年8月、<https://www.icann.org/en/about/staff/security/ssr/ new-gtld-collision-mitigation-05aug13-en.pdf >。
[NOCA] ICANN, "Name Collision Occurrence Assessment", August 2014, <http://newgtlds.icann.org/sites/default/files/ agreements/name-collision-assessment-04aug14-en.htm>.
[NOCA] ICANN、「名前衝突の発生の評価」、2014年8月、<http://newgtlds.icann.org/sites/default/files/ Agreements / name-collision-assessment-04aug14-en.htm>。
[RARDBITS] Reid, J., "Analysing the Use of the RA and RD bits in Queries to Root Servers", March 2014, <http://namecollisions.net/program/index.html>.
[RARDBITS] Reid、J。、「Analysing the RA and RD bits in Queries to Root Servers」、2014年3月、<http://namecollisions.net/program/index.html>。
[RFC1591] Postel, J., "Domain Name System Structure and Delegation", RFC 1591, DOI 10.17487/RFC1591, March 1994, <http://www.rfc-editor.org/info/rfc1591>.
[RFC1591] Postel、J。、「ドメインネームシステムの構造と委任」、RFC 1591、DOI 10.17487 / RFC1591、1994年3月、<http://www.rfc-editor.org/info/rfc1591>。
[RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, <http://www.rfc-editor.org/info/rfc2606>.
[RFC2606] Eastlake 3rd、D。およびA. Panitz、「予約済みトップレベルDNS名」、BCP 32、RFC 2606、DOI 10.17487 / RFC2606、1999年6月、<http://www.rfc-editor.org/info/ rfc2606>。
[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, DOI 10.17487/RFC6761, February 2013, <http://www.rfc-editor.org/info/rfc6761>.
[RFC6761] Cheshire、S。およびM. Krochmal、「特殊用途ドメイン名」、RFC 6761、DOI 10.17487 / RFC6761、2013年2月、<http://www.rfc-editor.org/info/rfc6761>。
[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 7719, DOI 10.17487/RFC7719, December 2015, <http://www.rfc-editor.org/info/rfc7719>.
[RFC7719] Hoffman、P.、Sullivan、A。、およびK. Fujiwara、「DNS用語」、RFC 7719、DOI 10.17487 / RFC7719、2015年12月、<http://www.rfc-editor.org/info/rfc7719 >。
[RSSAC] Murai, J., "RSSAC response to the root scaling report", November 2010, <http://www.icann.org/en/news/ correspondence/murai-to-board-25nov10-en.pdf>.
[RSSAC] Murai、J。、「RSSAC response to the root scaling report」、2010年11月、<http://www.icann.org/en/news/communication/murai-to-board-25nov10-en.pdf> 。
[RSSAC002] ICANN Root Server System Advisory Committee, "Advisory on Measurements of the Root Server System", November 2014, <https://www.icann.org/en/system/files/files/ rssac-002-measurements-root-20nov14-en.pdf>.
[RSSAC002] ICANNルートサーバーシステム諮問委員会、「ルートサーバーシステムの測定に関する助言」、2014年11月、<https://www.icann.org/en/system/files/files/ rssac-002-measurements-root -20nov14-en.pdf>。
[SAC045] ICANN Security and Stability Advisory Committee, "Invalid Top Level Domain Queries at the Root Level of the Domain Name System", SAC 045, November 2010, <https://www.icann.org/en/groups/ssac/documents/ sac-045-en.pdf>.
[SAC045] ICANNセキュリティおよび安定性諮問委員会、「ドメインネームシステムのルートレベルでの無効なトップレベルドメインクエリ」、SAC 045、2010年11月、<https://www.icann.org/en/groups/ssac/ドキュメント/ sac-045-en.pdf>。
[SAC046] ICANN Security and Stability Advisory Committee, "Report of the Security and Stability Advisory Committee on Root Scaling", SAC 046, December 2010, <https://www.icann.org/en/groups/ssac/documents/ sac-046-en.pdf>.
[SAC046] ICANNセキュリティおよび安定性諮問委員会、「ルートスケーリングに関するセキュリティおよび安定性諮問委員会の報告」、SAC 046、2010年12月、<https://www.icann.org/en/groups/ssac/documents/ sac -046-en.pdf>。
[SAC057] ICANN Security and Stability Advisory Committee, "SSAC Advisory on Internal Name Certificates", SAC057, March 2013, <http://www.icann.org/en/groups/ssac/documents/ sac-057-en.pdf>.
[SAC057] ICANNセキュリティおよび安定性諮問委員会、「SSAC Advisory on Internal Name Certificates」、SAC057、2013年3月、<http://www.icann.org/en/groups/ssac/documents/ sac-057-en.pdf >。
[SEARCHLISTS] Simpson, A., "Detecting Search Lists in Authoritative DNS", March 2014, <http://namecollisions.net/program/index.html>.
[検索] Simpson、A。、「Detecting Search Lists in Authoritative DNS」、2014年3月、<http://namecollisions.net/program/index.html>。
[TECHNIQUES] Thomas, M. and A. Simpson, "Analysis Techniques for Determining Cause and Ownership of DNS Queries", March 2014, <http://namecollisions.net/program/index.html>.
[テクニック]トーマス、M.、A。シンプソン、「DNSクエリの原因と所有権を特定するための分析手法」、2014年3月、<http://namecollisions.net/program/index.html>。
[WPNC] Verisign, "Workshop and Prize on Root Causes and Mitigation of Name Collisions (WPNC)", June 2014, <http://namecollisions.net/>.
[WPNC] Verisign、「根本的な原因と名前の衝突の軽減に関するワークショップと賞（WPNC）」、2014年6月、<http://namecollisions.net/>。
This workshop program committee consisted of Geoff Huston, Burt Kaliski, Olaf Kolkman, John Levine, Allison Mankin, Lixia Zhang, Anne-Marie Eklund Loewinder, and Andrew Sullivan.
このワークショッププログラム委員会は、Geoff Huston、Burt Kaliski、Olaf Kolkman、John Levine、Allison Mankin、Lixia Zhang、Anne-Marie Eklund Loewinder、Andrew Sullivanで構成されました。
Main Workshop Page: <http://namecollisions.net/>
Name Collision Invited and Submitted Papers, Panels, and Videos:
<http://namecollisions.net/program/index.html>
The peer-reviewed papers were:
査読済みの論文は次のとおりです。
o "Analysis Techniques for Determining Cause and Ownership of DNS Queries" [TECHNIQUES],
o "DNSクエリの原因と所有権を特定するための分析テクニック" [テクニック]、
o "Analysing the Use of the RA and RD bits in Queries to Root Servers" [RARDBITS],
o "ルートサーバーへのクエリでのRAおよびRDビットの使用の分析" [RARDBITS]、
o "The Effectiveness of Block Lists in Preventing Collisions" [BLOCKLISTS],
o "衝突防止におけるブロックリストの有効性" [BLOCKLISTS]、
o "What's in a Name (Collision): Modeling and Quantifying Collision Potential" [MODELING], and
o 「名前（衝突）の内容：衝突の可能性のモデリングと定量化」[モデリング]、および
o "Detecting Search Lists in Authoritative DNS" [SEARCHLISTS].
o 「権限のあるDNSでの検索リストの検出」[SEARCHLISTS]。
The invited talks were:
招待された講演は次のとおりです。
o "Keeping an Eye on Name Collisions" [KEEPEYE],
o "名前の衝突を監視する" [KEEPEYE]、
o "Looking at corp.com as a proxy for .corp" [CORPCOM],
o "corp.comを.corpのプロキシとして見る" [CORPCOM]、
o "Measuring DNS Behaviors from the End User Perspective" [DNSENDUSER],
o "エンドユーザーの観点からのDNS動作の測定" [DNSENDUSER]、
o "DNS-OARC" [DNS-OARC], and
o 「DNS-OARC」[DNS-OARC]、および
o "Name Collision Mitigation for Enterprise Networks" [ENTNETWORK].
o 「エンタープライズネットワークの名前衝突の軽減」[ENTNETWORK]。
The panels and discussions were:
パネルとディスカッションは次のとおりです。
o "Internet Engineering and Standards Considerations" [IESCPANEL],
o "インターネットエンジニアリングと標準に関する考慮事項" [IESCPANEL]、
o "Name Collisions Management Framework" [JASFRAMEWORK], and
o 「名前衝突管理フレームワーク」[JASFRAMEWORK]、および
o "Workshop Wrap-Up and Next Steps" [NEXTSTEPS].
o 「ワークショップのまとめと次のステップ」[NEXTSTEPS]。
A list of workshop participants is provided at [WPNC].
ワークショップ参加者のリストは[WPNC]にあります。
Acknowledgments
謝辞
We would like to thank both the program committee (Appendix A) and the workshop participants (Appendix C), with equal appreciation to those who spoke formally and those who joined in the lively discussions.
プログラム委員会（付録A）とワークショップ参加者（付録C）の両方に感謝します。正式に話をした人と活発な議論に参加してくれた人に平等に感謝します。
Additionally, we would like to thank the following people for their review comments: Burt Kaliski, Olaf Kolkman, Ed Lewis, Nevil Brownlee, Tim Wicinski, and Danny McPherson.
また、レビューコメントを提供してくれたBurt Kaliski、Olaf Kolkman、Ed Lewis、Nevil Brownlee、Tim Wicinski、Danny McPhersonにも感謝いたします。
Authors' Addresses
著者のアドレス
Matthew Thomas Email: mthomas@verisign.com
マシュー・トーマスEメール：mthomas@verisign.com
Allison Mankin Salesforce Email: allison.mankin@gmail.com
あっぃそん まんきん さぇｓふぉｒせ えまいｌ： あっぃそん。まんきん＠ｇまいｌ。こｍ
Lixia Zhang UCLA Email: lixia@cs.ucla.edu
lチャンUCLAメールをダウンロード：Lixia@this.UCLA.Amount