< draft-kolkman-root-test-delegation-00.txt		draft-kolkman-root-test-delegation-01.txt >
	Network Working Group O. Kolkman		Network Working Group G. Huston
	Internet-Draft NLnet Labs		Internet-Draft APNIC
	Intended status: Experimental Protocol A. Sullivan		Intended status: Experimental Protocol O. Kolkman
	Expires: March 22, 2014 Dyn, Inc.		Expires: April 20, 2014 NLnet Labs
			A. Sullivan
			Dyn, Inc.
	W. Kumari		W. Kumari
	Google, Inc.		Google, Inc.
	September 20, 2013		G. Michaelson
			APNIC
			October 19, 2013
	Using Test Delegations from the Root Prior to Full Allocation and		Using Test Delegations from the Root Prior to Full Allocation and
	Delegation		Delegation
	draft-kolkman-root-test-delegation-00		draft-kolkman-root-test-delegation-01
	Abstract		Abstract
	The delegation of certain strings as TLDs will cause stability and		The delegation of certain strings as generic Top Level Domains
	security issues if such strings have been used in private		(gTLDs) will cause stability and security issues if such strings have
	environments prior to their delegation. It is recommended that test		been used in private environments prior to their delegation. Test
	delegations be used to enable empirical research on the extent of the		delegations can be used to enable empirical research on the extent of
	possible disruption prior to actual allocation and delegation of any		the possible collision prior to actual allocation and delegation of
	label in the root zone.		any label in the root zone. This document describes one such
			approach to an empirical testing framework.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
			This Internet-Draft will expire on April 20, 2014.
	This Internet-Draft will expire on March 22, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (http://trustee.ietf.org/		Provisions Relating to IETF Documents (http://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Simplified BSD License text
	as described in Section 4.e of the Trust Legal Provisions and are		as described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction and Motivation . . . . . . . . . . . . . . . . . 2		1. Introduction and Motivation . . . . . . . . . . . . . . . . . 2
	1.1. Search-path interaction. . . . . . . . . . . . . . . . . . 3		1.1. Scire est mensurare . . . . . . . . . . . . . . . . . . . 3
	1.2. Scire est mensurare . . . . . . . . . . . . . . . . . . . 4
	2. Terms and Conventions Used in this Memo . . . . . . . . . . . 4		2. Terms and Conventions Used in this Memo . . . . . . . . . . . 4
	3. Principle of Operation . . . . . . . . . . . . . . . . . . . . 4		3. Principle of Operation . . . . . . . . . . . . . . . . . . . . 4
	3.1. Measurements Servers and Zones . . . . . . . . . . . . . . 5		3.1. Measurements Servers and Zones . . . . . . . . . . . . . . 4
	3.2. Query Generation . . . . . . . . . . . . . . . . . . . . . 5		3.2. Query Generation . . . . . . . . . . . . . . . . . . . . . 5
	3.3. Sampling . . . . . . . . . . . . . . . . . . . . . . . . . 7		3.3. Sampling . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.4. The Name Server . . . . . . . . . . . . . . . . . . . . . 7		4. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 8		5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	5. A Basis for Acceptable Behaviour . . . . . . . . . . . . . . . 9		6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	6. Possible Experiment Extension . . . . . . . . . . . . . . . . 9		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 8
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction and Motivation		1. Introduction and Motivation
	[[The authors are aware that this first version of the document does		[[The authors are aware that this version of the document is not
	is not fully consistent. However they would value feedback on		fully consistent. However they would value feedback on whether the
	whether the idea is worth further pursuance.]]		idea is worth further study.
	[Editor not: An appropriate mailinglist for discussion of this draft
	has not yet been identified]
	DNS names have always co-existed with other namespaces that are
	virtually indistinguishable from the DNS. The DNS was itself deployed
	alongside the host [RFC0822] table. NetBIOS [NETBIOS] names, though
	only one label long, could always interact with the DNS search path
	mechanism to generate DNS names. Additionally, mDNS [RFC6762] names
	often look just like DNS names. Because different naming systems are
	usually linked together in the user interface, from an end user's
	point of view these name spaces are all one -- even though they
	function differently on the Internet.
	While [RFC6761] reserved certain special names for internal or
	private use, there is evidence [SAC45] that various sites connected
	to the Internet have used other names for internal purposes. In
	fact, [RFC6762] advises not to use .local for private use and
	observes: "the following top-level domains have been used on private
	internal networks without the problems caused by trying to reuse
	".local." for this purpose:"
	.intranet.
	.internal.
	.private.
	.corp.
	.home.		A mail list to discuss this draft is collisions@lists.dns-oarc.net.]]
	.lan.		While certain special names have been reserved for internal or
			private use [RFC6761], there is evidence [SAC45] that various sites
			connected to the Internet have used other names for internal
			purposes. In fact, the Multicast DNS specification [RFC6762] advises
			not to use .local for private use and observes: "the following top-
			level domains have been used on private internal networks without the
			problems caused by trying to reuse ".local." for this purpose:
			.intranet
			.internal.
			.private.
			.corp.
			.home.
			.lan."
	In the event such names are delegated for use in the public DNS,		In the event such names are delegated for use in the public DNS,
	there will be inevitable consequences for sites that have used those		there will be inevitable consequences for sites that have used those
	names. Some of those consequences have implications for security,		names. Some of those consequences have security implications, with
	with the potential for leakage of credentials and HTTP cookies		the potential for leakage of credentials and HTTP cookies
	([RFC6265]). Responsible administration of the public namespace		([RFC6265]). Responsible administration of the public namespace
	therefore requires great care in permitting public delegation of any		therefore requires great care in permitting public delegation of any
	name when there is good reason to suppose it is in widespread use as		name when there is good reason to suppose it is in widespread use as
	a private namespace, even though such private namespaces are (from		a private namespace, even though such private namespaces are (from
	the point of view of the DNS) irregular, even if common.		the point of view of the DNS) irregular, even if common.
	1.1. Search-path interaction.		One form of name collision involves network domains that use selected
			names as local-use top level domains, as noted in [RFC6762]. In the
	In many cases a string appears to be used as an "undelegated TLD"		case where the same label is delegated in the global DNS as a gTLD,
	(being used as the rightmost label in an name), but this is simply an		then hosts in the local domain will be unable to resolve domain names
	artifact of domain search list processing.		in the context of the gTLD. This state of name occlusion is further
			compounded by a number of scenarios where the resolution of a name is
	For example, suppose the Example Widgets corporation uses a sub-		performed across multiple name scope domains. This may happen with a
	domain (.corp) of their primary domain (example.com) to name their		mobile host, or even with applications, such as, for example, mail
	employee workstations, servers, printers and similar. They have an		delivery (in the case where multiple MTAs who are listed as mail
	"intranet" server named intranet.corp.example.com. In order to allow		servers for a domain reside in different name scope domains, some of
	their employees to simply type "intranet.corp" to access this server,		which have this name collision between the domain and locally defined
	the users' workstations are configured (probably using [RFC3379])		pseudo-TLDs).
	with the search-list set to "corp.example.com, example.com".
	When a user enters "intranet.corp", their workstation will try and
	resolve the name. RFC1535 [RFC1535] specifies that "in any event
	where a "." exists in a specified name it should be assumed to be a
	fully qualified domain name (FQDN) and SHOULD be tried as a rooted
	name first." So, the user's workstation will first try and resolve
	"intranet.corp.". As there is (currently) no .corp TLD this will
	result in an NXDOMAIN response. The workstation will then append
	entries in the search-list until it is able to resolve the (now
	fully-qualified) name.
	If the .corp label were to be delegated as a TLD and the sub-domain		Name collision opens up the potential for misdirection, where the
	"intranet" created within .corp, the first lookup ("intranet.corp")		named remote point being contacted by the application may not
	would no longer generate an NXDOMAIN response. This would stop the		necessarily be the intended service point for the transaction. When
	search-list processing, and direct the user somewhere other than		a host leaves the intranet environment, the host's applications may
	where the user intended to go -- the "wrong server", in the eyes of		anticipate that the DNS names associated with a label return an RCODE
	the user, even if right according to the DNS.		3 (NXDOMAIN) response, but may encounter an unanticipated response
			when the gTLD is deployed with a colliding name. Similarly, a host
			that has an association with a named service point within the gTLD
			may encounter unanticipated responses when the host is placed into an
			intranet environment where the same name exist as a locally-scoped
			pseudo-TLD.
	It is worth noting that a researcher analyzing DNS queries hitting		There is a subtle form of interaction of names when the same name is
	the root servers would see queries before search-list processing		placed on a local name search list. Certain name resolver libraries
	expands them. While this may not change whether or not it is safe to		first query the original name, and if the query returns an NXDOMAIN,
	delegate these names, having an understanding of the cause is		then they apply the local search list to the original name. When
	valuable.		this process occurs in the context of a visible gTLD name colliding
			with the local name there is the possibility of the name resolving in
			the context of the gTLD, which then bypasses the application of the
			local search list.
	1.2. Scire est mensurare		1.1. Scire est mensurare
	The local use of undelegated top-level domain names is troublesome		The local use of undelegated top-level domain names is troublesome
	because it produces different experience depending on the search path		because it may produce different user experiences depending on the
	and location of a given device. That is a normal effect of the		locally used name, the names placed in a local search list and the
	search path mechanism or the roaming of users, but with the advent of		location of a given host, and the host's name resolution behaviour.
	new generic top-level domains (gTLDs), the problem gets more acute,
	because many TLDs are intended to be mnemonics that will be intuitive
	to humans. Since names higher in the DNS tree are likely also to use
	those same intuitive labels, there is potential for user confusion
	and information leakage.
	At the same time, it is not clear that the DNS protocol was designed		Prudent operation of the root zone requires that deployment of new
	around a static list of top-level domains (TLDs), and therefore it		names in the root should not cause widespread untoward effects for
	seems reasonable to plan for the possible addition of new TLDs whose		users of the DNS, particularly when those users are relying on name
	use might conflict with deployed search path settings. Yet prudent		resolution outcomes that have always been part of the name resolution
	operation of the root zone requires that deployment of new names in		behaviour up unto this point.
	the root should not cause widespread untoward effects for users of
	the DNS, particularly when those users are relying on features that
	have always been part of the protocol.
	What is needed is a mechanism to test whether a particular delegation		What is useful in this context is a mechanism to test whether a
	from the root zone presents a serious conflict with widespread use.		particular delegation from the root zone presents a conflict with
	This memo presents a methodology for making such a determination.		widespread local use. This memo presents a methodology for making
			such a determination.
	The methodology depends on temporary delegation of the top-level		The methodology considered here depends on temporary delegation of
	domains in question, and the use of a domain under an existing TLD in		the top-level domains in question, and the use of a domain under an
	order to capture and compare queries generated by a large number of		existing TLD in order to capture and compare queries generated by a
	querying sources under the control of the experiment.		large number of querying sources under the control of the experiment.
	2. Terms and Conventions Used in this Memo		2. Terms and Conventions Used in this Memo
	The mechanism outlined here is intended to complement the analysis		The mechanism outlined here is intended to complement the analysis
	already performed in "Name Collision in the DNS" [namecollision]. We		already performed in "Name Collision in the DNS" [namecollision]. We
	therefore use the terms defined in section 1.1 of [namecollision]		therefore use the terms defined in section 1.1 of [namecollision]
	whenever appropriate.		whenever appropriate.
	Note that the evaluation methodology outlined here is intended to be		Note that the evaluation methodology outlined here is intended to be
	complementary input to a risk analysis e.g. as found in		complementary input to a risk analysis e.g. as found in
	[namecollision]; risk tradeofs are likely to include other factors		[namecollision]; risk tradeofs are likely to include other factors
	than the effects measured herewith.		than the effects measured herewith.
	3. Principle of Operation		3. Principle of Operation
	In order to assess whether there is significant use of a given
	candidate string (CandidateTLD), probes will send out sets of queries
	from a large number of random locations. The queries are answered by
	dedicated servers that collect statistics. In this section we
	describe the query generation, data-collection, and what the
	dedicated servers should answer to not interfere with Internet
	traffic.
	The goal of the experiment is to assess whether there is significant		The goal of the experiment is to assess whether there is significant
	existing use of a single CandidateTLD.		existing use of a given candidate string ("CandidateTLD").
	3.1. Measurements Servers and Zones		We propose the use of a software test that is executed by a large
			number of end hosts drawn from across the entire Internet. The
			execution of this test will cause the end host to attempt to retrieve
			a small set of URLs. This will trigger a set of DNS queries to
			resolve the domain name part of each URL, and subsequent HTTP queries
			to retrieve the object in the case that the DNS name is successfully
			resolved to an IP address. Both the DNS queries and the HTTP
			requests are answered by dedicated servers that analyse the received
			responses and match them to the original set of queries that were
			used by the end host. This will allow us to infer whether the lost
			is located in an context where there is name collision with the
			CandidateTLD. In this section we describe the query generation, data-
			collection, and analysis.
	In addition to the candidate string ("CandidateTLD") the methodology		This methodology is based on earlier work by APNIC [Method].
	uses a specific sting "TestName". During an experiment the Proposed
	TLD under evaluation ("CandidateTLD") and a control TLD ("TestName")
	are delegated from the root zone to a special DNS name server, the
	experiment's server. Further, a second control name
	(TestName.ExistingTLD) is delegated from a 'common' existing TLD
	(ExistingTLD) to the experiment's server.
	The experiment's server has two functions:		3.1. Measurements Servers and Zones
			In addition to the use of CandidateTLD, the methodology uses an
			additional name, delegated from a 'common' existing TLD,
			("TestName.ExistingTLD") to the experiment's server.
	First, with one exception detailed below in Section 3.4, if any		The experiment's name server is authoritative for CandidateTLD and
	request for any name inside the CandidateTLD or the TestName		TestName.ExistingTLD. The name server will respond to an A and AAAA
	namespace reaches the name server, the name server MUST respond with		query for any name within "TestName.CandidateTLD" with the IPV4 or
	RCODE 3 (Name Error or NXDOMAIN) (Note that from a DNS client		IPv6 address of the experiment's HTTP server. The name server will
	perspective the ultimate RCODE 3 response is indistinguishable from		respond to queries for any other name within CandidateTLD with RCODE
	what is returned without the test delegation in place.)		3 (Name Error or NXDOMAIN). The name server will respond to A and
			AAAA queries in TestName.ExistingTLD with the IPv4 or IPv6 address of
			the experiment's HTTP server.
	Second, the experiment's server tracks every name in any request it		The experiment's HTTP server will respond with a "200 OK" for a
	receives, the time at which the request arrived, the RRTYPE and CLASS		request for the object "1x1.png" in TestName.CandidateTLD and in
	in the request, and the source network for the request.		TestName.ExistingTLD. The server will respond with "404 Not Found"
			for any other object name.
	3.2. Query Generation		3.2. Query Generation
	Software probes will need to be deployed throughout the Internet		The TestName is a synthetic name with no intentional semantic meaning
	(also see Section 3.3) these probes will send, in parallel, sets of		,that is generated in such a way to reduce the likliehood of
	queries.		collision with any existing delegated name. It is suggested that it
			be generated by using the hex encoding of a randomly selected integer
	Each set comprises one measurement and consists of three queries (or		value between 1,000,000,000 and 2,000,000,000. The name must not be
	even 4, see Section 6). A measurement is identified by a unique		already delegated from the root or in the ExistingTLD.
	measurement identifier (<uniqueid>, syntactically a valid hostname);
	the set will include the following:
	the QNAME is <uniqueid>-a.TestName.
	the QNAME is <uniqueid>-b.TestName.CandidateTLD
	the QNAME is <uniqueid>-c.TestName.ExistingTLD
	The TestName MUST be a randomly chosen name that remains constant for		Each query set constitutes one "measurement". A "measurement" is
	the duration of the experiment, MUST be a syntactically valid label,		identified by a measurement identifier (<uniqueid>, syntactically a
	SHOULD be semantic nonsense, an MUST NOT be delegated from the root		valid hostname) that is uniquely generated for each instance of a
	or in the ExistingTLD already.		measurement. This ensures that when the domain name is resolved, and
			when the named object is retrieved there is no occlusion of the
			interaction with the experiment's services because of local name or
			web object caches. The set uses the following URLs:
	Depending on the environment in which the probe is located the query		A: http://<unique_id>-a.TestName.CandidateTLD/1x1.png?
	that is send by a stub resolver is handled differently. We		<uniqueid>-a
	distinguish 4 possibilities.
	Local CandidateTLD use without Search List: The probe is located		B: http://<unique_id>-a.TestName.ExistingTLD/1x1.png?
	within a network that locally resolves the candidateTLD and there		<uniqueid>-b
	are no searchlists being used that append CandidateTLD. The query
	with a QNAME of <uniqueid>-b.TestName.CandidateTLD will not exit
	the local network while the queries with a QNAME of
	<uniqueid>-c.TestName.ExistingTLD. and QNAME of
	<uniqueid>-a.TestName. will arrive at the authoritative servers
	for the respective domains.
	Local CandidateTLD and CandidateTLD appened Search List: The probe is		C: http://results.TestName.ExistingTLD/1x1.png?
	located within a network that locally resolves the candidateTLD		<uniqueid>?za=<a_result>&zb=<b_result>
	and there are searchlists being used that append CandidateTLD. The
	query with a QNAME of <uniqueid>-b.TestName.CandidateTLD will not
	exit the local network while the queries with a QNAME of
	lt;uniqueid>-c.TestName.ExistingTLD. will arrive at the
	authoritative server for the domain. The query with a QNAME of
	<uniqueid>-a.TestName. is subject to the search algortithm, the
	query name will effectively be substitude to
	<uniqueid>-a.TestName.CandidateTLD and be resolved localy. The
	query for <uniqueid>-a.TestName. will therefore not be seen at
	the authoritative server.
	No use of CandidateTLD and no use of Search List: The probe is		The A URL is intended to test if CandidateTLD is a locally used name.
	located within a network that does not resolve the candidate TLD		In other words, if local use of CandidateTLD occludes visibility of
	and no searchlists being used that append CandidateTLD. All		CandidateTLD as a gTLD. The DNS query for
	queries will arrive at the authoritative servers for the		<unique_id>-a.TestName.CandidateTLD will only be received by the
	respective domains.		authoritative name server for this name if there is no local name
			resolution function that uses the CandidateTLD name as a locally
			defined pseudo-top level domain.
	No use of CandidateTLD and CandidateTLD appended by Search List: The		The B URL is intended to function as the control test for the
	probe is located within a network that does not resolve the		experiment, and the use of ExistingTLD in B is intended to operate as
	candidate TLD but search list processing appends CandidateTLD. In		a name that does not collide with a local use context.
	this case the queries for Lt;uniqueid>-a.TestName. get rewritten
	to lt;uniqueid>-a.TestName.CandidateTLD and arrive, together with
	lt;uniqueid>-b.TestName.CandidateTLD at the authoritative server
	for CandidateTLD, while queries for the QNAME
	<uniqueid>-c.TestName.ExistingTLD arrive at the server
	authoritative for TestName.ExistingTLD.
	As a result, by comparing what arrives at the authoritative servers		As the experiment uses the absence of a fetch of the A URL to infer
	one can establish the prevalence of the various scenarios. Under the		the name resolution behaviour of the location where the measurement
	assumption of a broad unbiased sample exclusively observing the 3rd		is being performed, it is necessary to ensure that the measurement
	option (all queries hitting their respective servers) would be a		code has run to completion. The measurement code starts a timer at
	strong indication that a candidate TLD is not in use.		the start of its execution. Upon expiration of the timer, or when
			both the A and B objects have been successfully retrieved, the code
			will schedule the retrieval of the C URL. The arguments to the C URL
			include the client-side measurement of the elapsed time to retrieve
			the A and B URLs.
	3.3. Sampling		3.3. Sampling
	To perform the evaluation, a names of the form		One way to perform this measurement is to embed the measurement in
	<uniqueid>.TestName.CandidateTLD and		web content, using a scripting language. When the web content is
	<uniqueid>.controlname.ExistingTLD are embedded in content that is		loaded the script is activated, and the measurement sequence is
	placed around the web. As people visit web sites, the content is		performed.
	processed, yielding attempts at resolution of the names.
	The easiest way to provide the content that causes the relevant DNS
	lookup is to use an online (ad) campaign. There is no reason for the
	campaign actually to cause users to click though, so it should be as
	boring as possible. However, the campaign must result in the
	independent resolution of both the control and test names. Behavior
	of this sort is trivially achievable with several available online
	advertising systems.
	It is critical that the sampling be as representative of the Internet
	population as possible. This sort of sample already has the
	significant problem that it can only measure users of the web. And
	there may be sampling effects that might prevent measurements from
	taking place in those environments that need to be reached. For
	instance, add-blocking or different web surfing behavior in corporate
	environements.
	The measurements should be unbiased with respect to temporal behavior
	like sleep-wake and work-rest cycles.
	[[The sampling biases probably deserve their own section with much
	more elaboration and more possible biases]]
	3.4. The Name Server
	This procedure rests on a name server that is configured and		One way to distribute this content to clients to perform the test is
	instrumented in particular ways. First, the name server must be		via an online (ad) campaign. If the measurement script is enclosed
	configurable so that it authoritative for all requests inside the		within the ad itself, then there is no reason for the campaign
	Candidate TLD. Normally, it will always return RCODE 3 (NXDOMAIN) for		actually to cause users to click though in order to perform the test.
	all queries inside that Candidate TLD, except that the name server		Behavior of this sort is trivially achievable with a number of
	must also be configurable so that it is the authoritative name server		available online advertising systems.
	for the test name. All names underneath the test name, however, also
	return RCODE 3. A summary of the behavior is in Table 1.
	+-----------------------------+------------+-----------+------------+		It is also necessary to spread the deliver of the ad to a very broad
	| Domain Name | RRTYPE | RCODE | Actions if |		spectrum of clients, uso the as should be presented across all time
	| | queried | returned | any |		zones, across all language bases, and across all geographic regions.
	+-----------------------------+------------+-----------+------------+
	| CandidateTLD | anything | 3 | |
	| | except NS | | |
	| CandidateTLD | NS | 0 | return |
	| | | | server in |
	| | | | answer |
	| | | | section |
	| | | | RDATA |
	| TestName | anything | 3 | |
	| | except NS | | |
	| TestName | NS | 0 | return |
	| | | | server in |
	| | | | answer |
	| | | | section |
	| | | | RDATA |
	| TestName.CandidateTLD | NS | 0 | return |
	| | | | server in |
	| | | | answer |
	| | | | section |
	| | | | RDATA |
	| TestName.CandidateTLD | anything | 3 | |
	| | except NS | | |
	| *.TestName.CandidateTLD | ANY | 3 | Queries to |
	| | | | be |
	| | | | measured |
	| *.controlname.ExistingTLD | ANY | 3 | Queries to |
	| | | | be |
	| | | | measured |
	| *.TestName | ANY | 3 | Queries to |
	| | | | be |
	| | | | measured |
	+-----------------------------+------------+-----------+------------+
	4. Evaluation		4. Evaluation
	[TODO align with above]		To evaluate the results, we take those measurements that return the C
			URL. The use of the C URL ensures that we use measurement results
	To evaluate the results, it is only necessary to compare the number		where the ExistingTLD name is not being locally occluded. We count
	of resolution attempts of the test names against the resolution		the number of experiments of each of the possible combinations of
	attempts of the control names. If the test name is not in wide		retrieving the A and B URLs. These combinations are:
	private use, then a lookups for the name unique identifier in each
	name space will arrive nearly as often and at the same time (modulo
	the difference in the recursive nameserver following the delegation
	chain) at the instrumented name server.
	If the test name is in widespread private use without a search list,
	or is otherwise resolved locally, then we should expect that lookups
	inside the test namespace will happen less often than lookups inside
	the control namespace. If there is no search list in use, then the
	test QNAMEs of the "b" form will arrive less often than those of "a"
	form and "c" form. If there is a search list in use, then the "a"
	form will also not arrive at the authoritative server. If the
	CandidateTLD is in a search list, we can expect to see duplicated
	queries of the "b" form on the authoritative server (because the "a"
	form gets the search list appended).
	5. A Basis for Acceptable Behaviour
	We assume that there will always be some "stray" queries to the DNS:
	queries for names that have a TLD-label that does not exist in the
	root-zone, and which were not intended to be sent to the global DNS.
	Therefore, it is necessary to establish some baseline level of these
	"noise" queries, and then use that to evaluate whether some proposed
	new name for the DNS presents a problem.
	Because of the historic prominence of the .com TLD, it may be
	supposed that .com is, like the root itself, a special zone in which
	unusual behaviour might be expected. Therefore, names inside the
	.com name space are a poor guide for "normal" behaviour, and it
	should not be used for making these sorts of evaluations. The best
	guide will likely come from using TLDs that are themselves
	statistically normal.
	In addition, overwhelming conservatism suggests that using
	comparisons with the TLD that is queried least often provides a great
	margin of safety. As of this writing, a string that is queried less
	often than that least-queried TLD seems likely not to be in
	widespread real use, and therefore comparisons with that least-
	queried TLD are a good conservative choice when evaluating.
	6. Possible Experiment Extension
	A bias to the measurement is introduced if in certain environments
	lists of existing TLDs are used in access lists of, for instance,
	firewalls. In that case queries for the QNAME
	<uniqueid>-b.TestName.CandidateTLD might be blocked. To calibrate
	that behavior an additional non-existent TLD could be delegated for
	the duration of the experiment:
	the QNAME is <uniqueid>-d.TestName.RandomTLD
	Whereby RandomTLD is a short TLD with the same properties as the
	candidate TLD. e.g. if the CandidateTLD is U-Label then the
	RandomTLD is a U-Label from the same script.
	If the measurement servers receive queries where the QNAME is neither
	<uniqueid>-d.TestName.RandomTLD nor
	<uniqueid>-b.TestName.CandidateTLD then it is likely that all non-
	delegated domains are blocked. An alternative way of interpreting
	this is that the queries where the QNAME is
	<uniqueid>-d.TestName.RandomTLD that arrive at the measurement
	servers provide a baseline for the transparency of the querying
	environment for non-delegated TLDs.
	7. Security Considerations		Not A and Not B: This result contributes to experimental
			uncertainty. (We know that ExistingTLD is not locally
			occluded, so the failure to retrieve B is due to other factors
			that are not being examined in the context of this
			measurement.)
	The delegation of the Proposed TLD (CandidateTLD) and control TLD		A and Not B: This result indicates that the client is able to
	(TestName) comes with some risk of interference with existing		resolve names in the CandidateTLD in the context of the global
	deployments. The risks for name collision for the TestName is under		DNS, but the inability to retrieve the B URL contributes to
	the control of the experimenter and can be minimized by taking random		experimental uncertainty. (The same reasoning about the
	strings without semantic value.		ExistingTLD and local occlusion applies to this case).
	The risk of name collision with the CandidateTLD is minimized reduced		Not A and B: This result is an indicator that the client's use of
	by having the experiment's server returning RCODE=3. Under the		CandidateTLD is probably being occluded by some form of local
	assumption of regular DNS implementations that response is		use.
	indistinguishable from a direct root-response for applications that
	receive such answer from a stub resolver. The authors have no reason
	to believe that there are DNS implementations that would hand the
	applications a different response if a delegation is part of the
	resolution process.
	The authors would advise against signing the various delegated		A and B: This result indicates that the client is able to resolve
	domains, as the introduction of DNSSEC is likely to bias the		names in the CandidateTLD in the context of the global DNS.
	experiment. At the root domain and ExistingTLDs, regular signing
	practices, including the inclusion of an NSEC or NSEC3 RR proving the
	non-existence of a DS record should continue.
	The experiment can be biased by 3rd parties through sending queries		If the CandidateTLD is in widespread private use then we would see
	that have properties like the ones specified herein. The		the count of "Not A and B" be far in excess of the level of
	experimentor SHOULD carefully control and record the <uniqueid>		experimental uncertainty, then we can conclude that there are locales
	values used in the experiment and discard non-expected and non-unique		where the CandidateTLD is being used in local context. Analysis of
	queries that arrive at the nameserver.		the source IP addresses of the clients that fetch "Not A and B", and
			the BGP Origin AS of these addresses and their geolocation may
			indicate if such local use is clustered in a particular network or
			group or networks, or clustered in a particular geography or language
			region.
	8. References		5. Security Considerations
	[NETBIOS] IBM Corporation, "LAN Technical Reference: 802.2 and		The delegation of the Proposed TLD (CandidateTLD) comes with some
	NetBIOS APIs ", Doc. number SC30-3587-01, April 1996.		risk of interference with existing deployments. In the case where a
			local system queries a name, and that query returns a NXDOMAIN
			response, then local system then queries further name forms where
			each entry on a local name search list is appended to the original
			name in turn, searching for a name response that is not NXDOMAIN.
			The delegation of CandidateTLD for this experiment may interfere this
			this behaviour.
	[RFC0822] Crocker, D.H., "Standard for the format of ARPA Internet		However, two observations mitigate this concern. The first is that
	text messages", STD 11, RFC 822, August 1982.		this situation of potential collision arises in the case where the
			local system is querying for the CandidateTLD name as a "dotless"
			name (as the only delegated subdomain in the CandidateTLD zone is
			TestName, which is intended to have no semantic meaning in any
			language). The second observation is that for such "dotless" names,
			the currently widely deployed name resolver libraries no not
			initially query the "dotless" domain name then apply the search list
			is the first query results in an RCODE 3 response. Many name
			resolver libraries do not query for "dotless" domain names at all,
			while those libraries that have been observed to perform such queries
			(Windows XP, Linux, FreeBSD) perform them after using the local
			search name list, rather then before.
	[RFC1535] Gavron, E., "A Security Problem and Proposed Correction		6. References
	With Widely Deployed DNS Software", RFC 1535, October
	1993.
	[RFC3379] Pinkas, D. and R. Housley, "Delegated Path Validation and		[Method] APNIC, "APNIC Labs IPv6 Measurement System ", Doc. number
	Delegated Path Discovery Protocol Requirements", RFC 3379,		SC30-3587-01, May 2013.
	September 2002.
	[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,		[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
	April 2011.		April 2011.
	[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",		[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
	RFC 6761, February 2013.		RFC 6761, February 2013.
	[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,		[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
	February 2013.		February 2013.
	skipping to change at page 11, line 36 ¶		skipping to change at page 8, line 36 ¶
	(abbandonded) work on "A Procedure for Cautious Delegation of a DNS		(abbandonded) work on "A Procedure for Cautious Delegation of a DNS
	Names". Discussion of that document in various hallways lead to		Names". Discussion of that document in various hallways lead to
	inspiration for this document and we want to thank those that gave us		inspiration for this document and we want to thank those that gave us
	feed-back.		feed-back.
	The idea of using different names to trigger events in a DNS server		The idea of using different names to trigger events in a DNS server
	is due to Geoff Huston.		is due to Geoff Huston.
	Authors' Addresses		Authors' Addresses
			Geoff Huston
			APNIC
			6 Cordelia St
			South Brisbane, QLD 4101
			Australia
			Email: gih@apnic.net
	Olaf Kolkman		Olaf Kolkman
	NLnet Labs		NLnet Labs
	Science Park 400		Science Park 400
	Amsterdam, 1098 XH		Amsterdam, 1098 XH
	The Netherlands		The Netherlands
	Email: olaf@NLnetLabs.nl		Email: olaf@NLnetLabs.nl
	Andrew Sullivan		Andrew Sullivan
	Dyn, Inc.		Dyn, Inc.
	150 Dow St		150 Dow St
	Manchester, NH 03101		Manchester, NH 03101
	U.S.A.		U.S.A.
	Email: asullivan@dyn.com		Email: asullivan@dyn.com
	Warren Kumari		Warren Kumari
	Google, Inc.		Google, Inc.
	1600 Amphitheatre Pkwy		1600 Amphitheatre Pkwy
	Mountain View, CA 94043		Mountain View, CA 94043
	U.S.A.		U.S.A.
	Email: warren@kumari.net		Email: warren@kumari.net
			George Michaelson
			APNIC
			6 Cordelia St
			South Brisbane, QLD 4101
			Australia
			Email: ggm@apnic.net
End of changes. 54 change blocks.
	380 lines changed or deleted		238 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/