wdiff draft-kolkman-root-test-delegation-00.txt draft-kolkman-root-test-delegation-01.txt

Network Working Group O. Kolkman G. Huston
Internet-Draft NLnet Labs APNIC
Intended status: Experimental Protocol A. Sullivan O. Kolkman
Expires: March 22, April 20, 2014 NLnet Labs
A. Sullivan
Dyn, Inc.
W. Kumari
Google, Inc.
September 20,
G. Michaelson
APNIC
October 19, 2013

Using Test Delegations from the Root Prior to Full Allocation and
Delegation
draft-kolkman-root-test-delegation-00
draft-kolkman-root-test-delegation-01

Abstract

The delegation of certain strings as TLDs generic Top Level Domains
(gTLDs) will cause stability and security issues if such strings have
been used in private environments prior to their delegation. It is recommended that test Test
delegations can be used to enable empirical research on the extent of
the possible disruption collision prior to actual allocation and delegation of
any label in the root zone. This document describes one such
approach to an empirical testing framework.

Status of this Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 22, April 20, 2014.

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. Code Components
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction and Motivation . . . . . . . . . . . . . . . . . 2
1.1. Search-path interaction. . . . . . . . . . . . . . . . . . 3
1.2. Scire est mensurare . . . . . . . . . . . . . . . . . . . 4 3
2. Terms and Conventions Used in this Memo . . . . . . . . . . . 4
3. Principle of Operation . . . . . . . . . . . . . . . . . . . . 4
3.1. Measurements Servers and Zones . . . . . . . . . . . . . . 5 4
3.2. Query Generation . . . . . . . . . . . . . . . . . . . . . 5
3.3. Sampling . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. The Name Server . . . . . . . . . . . . . . . . . . . . . 7 6
4. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6
5. A Basis for Acceptable Behaviour . . . . . . . . . . . . . . . 9
6. Possible Experiment Extension . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 11 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 8

1. Introduction and Motivation

[[The authors are aware that this first version of the document does is not
fully consistent. However they would value feedback on whether the
idea is worth further pursuance.]]

[Editor not: An appropriate mailinglist for discussion of study.

A mail list to discuss 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. is collisions@lists.dns-oarc.net.]]

While [RFC6761] reserved certain special names have been reserved for internal or
private use, 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 top-
level domains have been used on private internal networks without the
problems caused by trying to reuse ".local." for this purpose:"
.intranet. purpose:

.intranet
.internal.
.private.
.corp.
.home.

.lan.
.lan."
In the event such names are delegated for use in the public DNS,
there will be inevitable consequences for sites that have used those
names. Some of those consequences have implications for security, security implications, with
the potential for leakage of credentials and HTTP cookies
([RFC6265]). Responsible administration of the public namespace
therefore requires great care in permitting public delegation of any
name when there is good reason to suppose it is in widespread use as
a private namespace, even though such private namespaces are (from
the point of view of the DNS) irregular, even if common.

1.1. Search-path interaction.

In many cases a string appears to be used

One form of name collision involves network domains that use selected
names as an "undelegated TLD"
(being used local-use top level domains, as noted in [RFC6762]. In the
case where the rightmost same label is delegated in an name), but this the global DNS as a gTLD,
then hosts in the local domain will be unable to resolve domain names
in the context of the gTLD. This state of name occlusion is simply an
artifact further
compounded by a number of domain search list processing.

For scenarios where the resolution of a name is
performed across multiple name scope domains. This may happen with a
mobile host, or even with applications, such as, for example, suppose mail
delivery (in the Example Widgets corporation uses case where multiple MTAs who are listed as mail
servers for a sub- domain (.corp) reside in different name scope domains, some of their primary domain (example.com) to
which have this name their
employee workstations, servers, printers collision between the domain and similar. They have an
"intranet" server locally defined
pseudo-TLDs).

Name collision opens up the potential for misdirection, where the
named intranet.corp.example.com. In order to allow
their employees to simply type "intranet.corp" to access this server, remote point being contacted by the users' workstations are configured (probably using [RFC3379])
with application may not
necessarily be the search-list set to "corp.example.com, example.com". intended service point for the transaction. When
a user enters "intranet.corp", their workstation will try and
resolve host leaves the intranet environment, the host's applications may
anticipate that the DNS names associated with a label return an RCODE
3 (NXDOMAIN) response, but may encounter an unanticipated response
when the gTLD is deployed with a colliding name. RFC1535 [RFC1535] specifies Similarly, a host
that "in any event 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 "." exists in locally-scoped
pseudo-TLD.

There is a specified subtle form of interaction of names when the same name it should be assumed to be is
placed on a
fully qualified domain local name (FQDN) and SHOULD be tried as a rooted search list. Certain name first." So, the user's workstation will resolver libraries
first try query the original name, and resolve
"intranet.corp.". As there is (currently) no .corp TLD this will
result in if the query returns an NXDOMAIN response. The workstation will NXDOMAIN,
then append
entries in they apply the search-list until it is able local search list to resolve the (now
fully-qualified) original name.

If When
this process occurs in the .corp label were to be delegated as context of a TLD and the sub-domain
"intranet" created within .corp, the first lookup ("intranet.corp")
would no longer generate an NXDOMAIN response. This would stop the
search-list processing, and direct visible gTLD name colliding
with the user somewhere other than
where local name there is the user intended to go -- possibility of the "wrong server", name resolving in
the eyes context of the user, even if right according to the DNS.

It is worth noting that a researcher analyzing DNS queries hitting gTLD, which then bypasses the root servers would see queries before search-list processing
expands them. While this may not change whether or not it is safe to
delegate these names, having an understanding application of the cause is
valuable.

1.2.
local search list.

1.1. Scire est mensurare

The local use of undelegated top-level domain names is troublesome
because it produces may produce different experience user experiences depending on the search path
and location of a given device. That is a normal effect of the
search path mechanism or the roaming of users, but with the advent of
new generic top-level domains (gTLDs),
locally used name, the problem gets more acute,
because many TLDs are intended to be mnemonics that will be intuitive
to humans. Since names higher placed 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
around a static local search list of top-level domains (TLDs), and therefore it
seems reasonable to plan for the possible addition
location of new TLDs whose
use might conflict with deployed search path settings. Yet prudent a given host, and the host's name resolution behaviour.

Prudent operation of the root zone requires that deployment of new
names in the root should not cause widespread untoward effects for
users of the DNS, particularly when those users are relying on features name
resolution outcomes that have always been part of the protocol. name resolution
behaviour up unto this point.

What is needed useful in this context is a mechanism to test whether a
particular delegation from the root zone presents a serious conflict with
widespread local use. This memo presents a methodology for making
such a determination.

The methodology considered here depends on temporary delegation of
the top-level domains in question, and the use of a domain under an
existing TLD in order to capture and compare queries generated by a
large number of querying sources under the control of the experiment.

2. Terms and Conventions Used in this Memo

The mechanism outlined here is intended to complement the analysis
already performed in "Name Collision in the DNS" [namecollision]. We
therefore use the terms defined in section 1.1 of [namecollision]
whenever appropriate.

Note that the evaluation methodology outlined here is intended to be
complementary input to a risk analysis e.g. as found in
[namecollision]; risk tradeofs are likely to include other factors
than the effects measured herewith.

3. Principle of Operation
In order

The goal of the experiment is to assess whether there is significant
existing use of a given candidate string (CandidateTLD), probes will send out sets ("CandidateTLD").

We propose the use of queries
from a software test that is executed by a large
number of random locations. 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 collect statistics. In this section we
describe analyse the query generation, data-collection, received
responses and what the
dedicated servers should answer match them to not interfere with Internet
traffic.

The goal the original set of queries that were
used by the experiment is end host. This will allow us to assess infer whether the lost
is located in an context where there is significant
existing use of a single name collision with the
CandidateTLD. In this section we describe the query generation, data-
collection, and analysis.

This methodology is based on earlier work by APNIC [Method].

3.1. Measurements Servers and Zones
In addition to the candidate string ("CandidateTLD") use of CandidateTLD, the methodology 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
additional name, delegated from a 'common' existing TLD
(ExistingTLD) TLD,
("TestName.ExistingTLD") to the experiment's server.

The experiment's name server has two functions:

First, with one exception detailed below in Section 3.4, if any
request is authoritative for CandidateTLD and
TestName.ExistingTLD. The name server will respond to an A and AAAA
query for any name inside within "TestName.CandidateTLD" with the CandidateTLD IPV4 or
IPv6 address of the TestName
namespace reaches the name server, the experiment's HTTP server. The name server MUST will
respond to queries for any other name within CandidateTLD with RCODE
3 (Name Error or NXDOMAIN) (Note that from a DNS client
perspective the ultimate RCODE 3 response is indistinguishable from
what is returned without the test delegation in place.)

Second, the experiment's server tracks every NXDOMAIN). The name server will respond to A and
AAAA queries in any request it
receives, TestName.ExistingTLD with the time at which IPv4 or IPv6 address of
the experiment's HTTP server.

The experiment's HTTP server will respond with a "200 OK" for a
request arrived, for the RRTYPE and CLASS object "1x1.png" in the request, TestName.CandidateTLD and the source network in
TestName.ExistingTLD. The server will respond with "404 Not Found"
for the request. any other object name.

3.2. Query Generation

Software probes will need

The TestName is a synthetic name with no intentional semantic meaning
,that is generated in such a way to reduce the likliehood of
collision with any existing delegated name. It is suggested that it
be deployed throughout generated by using the Internet
(also see Section 3.3) these probes will send, in parallel, sets hex encoding of
queries. a randomly selected integer
value between 1,000,000,000 and 2,000,000,000. The name must not be
already delegated from the root or in the ExistingTLD.

Each query set comprises constitutes one measurement and consists of three queries (or
even 4, see Section 6). "measurement". A measurement "measurement" is
identified by a unique measurement identifier (<uniqueid>, syntactically a
valid hostname);
the set will include the following:

the QNAME hostname) that is <uniqueid>-a.TestName. uniquely generated for each instance of a
measurement. This ensures that when the QNAME domain name is <uniqueid>-b.TestName.CandidateTLD resolved, and
when the QNAME named object is <uniqueid>-c.TestName.ExistingTLD

The TestName MUST be a randomly chosen name that remains constant for
the duration retrieved there is no occlusion of the experiment, MUST be a syntactically valid label,
SHOULD be semantic nonsense, an MUST NOT be delegated from
interaction with the root experiment's services because of local name or in the ExistingTLD already.

Depending on the environment in which the probe is located
web object caches. The set uses the query
that is send by a stub resolver following URLs:

A: http://<unique_id>-a.TestName.CandidateTLD/1x1.png?
<uniqueid>-a

B: http://<unique_id>-a.TestName.ExistingTLD/1x1.png?
<uniqueid>-b

C: http://results.TestName.ExistingTLD/1x1.png?
<uniqueid>?za=<a_result>&zb=<b_result>

The A URL is handled differently. We
distinguish 4 possibilities.

Local intended to test if CandidateTLD use without Search List: The probe is located
within a network that locally resolves the candidateTLD and there
are no searchlists being used that append CandidateTLD. The query
with a QNAME of <uniqueid>-b.TestName.CandidateTLD will not exit
the name.
In other words, if local network while the queries with a QNAME of
<uniqueid>-c.TestName.ExistingTLD. and QNAME use of
<uniqueid>-a.TestName. will arrive at the authoritative servers
for the respective domains.

Local CandidateTLD and occludes visibility of
CandidateTLD appened Search List: The probe is
located within as a network that locally resolves the candidateTLD
and there are searchlists being used that append CandidateTLD. gTLD. The DNS 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. for
<unique_id>-a.TestName.CandidateTLD will arrive at only be received by the
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.

The query with a QNAME of
<uniqueid>-a.TestName. B URL is subject intended to function as the search algortithm, the
query name will effectively be substitude to
<uniqueid>-a.TestName.CandidateTLD and be resolved localy. The
query control test for <uniqueid>-a.TestName. will therefore not be seen at the authoritative server.

No use of CandidateTLD
experiment, and no the use of Search List: The probe ExistingTLD in B is
located within intended to operate as
a network name that does not resolve collide with a local use context.

As the candidate TLD
and no searchlists being used that append CandidateTLD. All
queries will arrive at experiment uses the authoritative servers for absence of a fetch of the
respective domains.

No use A URL to infer
the name resolution behaviour of CandidateTLD and CandidateTLD appended by Search List: The
probe the location where the measurement
is located within a network being performed, it is necessary to ensure that does not resolve the
candidate TLD but search list processing appends CandidateTLD. In
this case the queries for Lt;uniqueid>-a.TestName. get rewritten measurement
code has run to lt;uniqueid>-a.TestName.CandidateTLD and arrive, together with
lt;uniqueid>-b.TestName.CandidateTLD completion. The measurement code starts a timer at
the authoritative server
for CandidateTLD, while queries for start of its execution. Upon expiration of the QNAME
<uniqueid>-c.TestName.ExistingTLD arrive at timer, or when
both the server
authoritative for TestName.ExistingTLD.

As a result, by comparing what arrives at A and B objects have been successfully retrieved, the authoritative servers
one can establish code
will schedule the prevalence retrieval of the various scenarios. Under C URL. The arguments to the
assumption C URL
include the client-side measurement of a broad unbiased sample exclusively observing the 3rd
option (all queries hitting their respective servers) would be a
strong indication that a candidate TLD is not in use. the elapsed time to retrieve
the A and B URLs.

3.3. Sampling

One way to perform this measurement is to embed the evaluation, measurement in
web content, using a names of scripting language. When the form
<uniqueid>.TestName.CandidateTLD and
<uniqueid>.controlname.ExistingTLD are embedded in web content that is
placed around
loaded the web. As people visit web sites, the content script is
processed, yielding attempts at resolution of activated, and the names.

The easiest measurement sequence is
performed.

One way to provide the distribute this content that causes to clients to perform the relevant DNS
lookup test is to use
via an online (ad) campaign. There If the measurement script is enclosed
within the ad itself, then 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 though in order to perform the
independent resolution of both the control and test names. test.
Behavior of this sort is trivially achievable with several a number of
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 also necessary to spread the
significant problem that it can only measure users deliver 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 ad 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
instrumented in particular ways. First, very broad
spectrum of clients, uso the name server must as should be
configurable so that it authoritative for presented across all requests inside the
Candidate TLD. Normally, it will always return RCODE 3 (NXDOMAIN) for time
zones, across all queries inside that Candidate TLD, except that the name server
must also be configurable so that it is the authoritative name server
for the test name. All names underneath the test name, however, also
return RCODE 3. A summary of the behavior is in Table 1.

4. Evaluation

[TODO align with above]

To evaluate the results, it is only necessary to compare the number
of resolution attempts of the test names against we take those measurements that return the resolution
attempts C
URL. The use of the control names. If C URL ensures that we use measurement results
where the test ExistingTLD name is not in wide
private use, then a lookups for being locally occluded. We count
the name unique identifier in number of experiments of 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 of the instrumented name server.

If possible combinations of
retrieving the test name is in widespread private use without a search list,
or is otherwise resolved locally, then we should expect A and B URLs. These combinations are:

Not A and Not B: This result contributes to experimental
uncertainty. (We know that lookups
inside the test namespace will happen less often than lookups inside ExistingTLD is not locally
occluded, so the control namespace. If there failure to retrieve B is no search list due to other factors
that are not being examined in use, then the
test QNAMEs of the "b" form will arrive less often than those context of "a"
form this
measurement.)

A and "c" form. If there Not B: This result indicates that the client is a search list able to
resolve names 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 context of the "a"
form gets global
DNS, but the search list appended).

5. A Basis for Acceptable Behaviour

We assume that there will always be some "stray" queries inability to retrieve the DNS:
queries for names that have a TLD-label that does not exist in B URL contributes to
experimental uncertainty. (The same reasoning about the
root-zone,
ExistingTLD and which were not intended to be sent local occlusion applies to this case).

Not A and B: This result is an indicator that the global DNS.
Therefore, it client's use of
CandidateTLD is necessary to establish probably being occluded by some baseline level form of these
"noise" queries, local
use.

A and then use B: This result indicates that the client is able to evaluate whether some proposed
new name for resolve
names in the DNS presents a problem.

Because of CandidateTLD in the historic prominence context of the .com TLD, it may be
supposed that .com is, like global DNS.

If the root itself, a special zone CandidateTLD is in which
unusual behaviour might be expected. Therefore, names inside widespread private use then we would see
the
.com name space are a poor guide for "normal" behaviour, count of "Not A and it
should not B" be used for making these sorts far in excess 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 level 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
experimental uncertainty, then we can conclude that least-
queried TLD there are a good conservative choice when evaluating.

6. Possible Experiment Extension

A bias to locales
where the measurement CandidateTLD is introduced if in certain environments
lists of existing TLDs are being 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 local context. Analysis of
the experiment:

the QNAME is <uniqueid>-d.TestName.RandomTLD

Whereby RandomTLD is a short TLD with source IP addresses of the same properties as clients that fetch "Not A and B", and
the
candidate TLD. e.g. BGP Origin AS of these addresses and their geolocation may
indicate if the CandidateTLD is U-Label then the
RandomTLD such local use is clustered in 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 particular network or
group or networks, or clustered in a baseline for the transparency of the querying
environment for non-delegated TLDs.

7. particular geography or language
region.

5. Security Considerations

The delegation of the Proposed TLD (CandidateTLD) and control TLD
(TestName) comes with some
risk of interference with existing deployments. The risks for name collision for the TestName is under
the control of In the experimenter case where a
local system queries a name, and can be minimized by taking random
strings without semantic value.

The risk of name collision with the CandidateTLD is minimized reduced
by having the experiment's server returning RCODE=3. Under the
assumption of regular DNS implementations that response is
indistinguishable from query returns a direct root-response for applications that
receive such answer from NXDOMAIN
response, then local system then queries further name forms where
each entry on a stub resolver. The authors have no reason local name search list is appended to believe that there are DNS implementations that would hand the
applications original
name in turn, searching for a different name response if a that is not NXDOMAIN.
The delegation of CandidateTLD for this experiment may interfere this
this behaviour.

However, two observations mitigate this concern. The first is part that
this situation of potential collision arises in the
resolution process.

The authors would advise against signing case where the various delegated
domains,
local system is querying for the CandidateTLD name as a "dotless"
name (as the introduction of DNSSEC only delegated subdomain in the CandidateTLD zone is likely
TestName, which is intended to bias have no semantic meaning in any
language). The second observation is that for such "dotless" names,
the
experiment. At currently widely deployed name resolver libraries no not
initially query the root "dotless" domain and ExistingTLDs, regular signing
practices, including name then apply the inclusion of an NSEC or NSEC3 RR proving search list
is the
non-existence of a DS record should continue.

The experiment can be biased by 3rd parties through sending queries 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 properties like the ones specified herein. The
experimentor SHOULD carefully control and record the <uniqueid>
values used in the experiment and discard non-expected and non-unique been observed to perform such queries that arrive at
(Windows XP, Linux, FreeBSD) perform them after using the nameserver.

8. local
search name list, rather then before.

6. References

[NETBIOS] IBM Corporation, "LAN Technical Reference: 802.2 and
NetBIOS APIs

[Method] APNIC, "APNIC Labs IPv6 Measurement System ", Doc. number
SC30-3587-01, April 1996.

[RFC0822] Crocker, D.H., "Standard for the format of ARPA Internet
text messages", STD 11, RFC 822, August 1982.

[RFC1535] Gavron, E., "A Security Problem and Proposed Correction
With Widely Deployed DNS Software", RFC 1535, October
1993.

[RFC3379] Pinkas, D. and R. Housley, "Delegated Path Validation and
Delegated Path Discovery Protocol Requirements", RFC 3379,
September 2002. May 2013.

[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011.

[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
RFC 6761, February 2013.

[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
February 2013.

[SAC45] ICANN Security and Stability Advisory Committee, "Invalid
Top Level Domain Queries at the Root Level of the Domain
Name System", 11 2010, <http://www.icann.org/en/groups/
ssac/documents/sac-045-en.pdf>.

[namecollision]
Interisle Consulting Group, "Name Collision in the DNS",
August 2013.

Appendix A. Acknowledgements

This draft is a follow-up of, an borrows heavily from, our earlier
(abbandonded) work on "A Procedure for Cautious Delegation of a DNS
Names". Discussion of that document in various hallways lead to
inspiration for this document and we want to thank those that gave us
feed-back.

The idea of using different names to trigger events in a DNS server
is due to Geoff Huston.

Authors' Addresses

Geoff Huston
APNIC
6 Cordelia St
South Brisbane, QLD 4101
Australia

Email: gih@apnic.net

Olaf Kolkman
NLnet Labs
Science Park 400
Amsterdam, 1098 XH
The Netherlands

Email: olaf@NLnetLabs.nl
Andrew Sullivan
Dyn, Inc.
150 Dow St
Manchester, NH 03101
U.S.A.

Email: asullivan@dyn.com

Warren Kumari
Google, Inc.
1600 Amphitheatre Pkwy
Mountain View, CA 94043
U.S.A.

Email: warren@kumari.net

George Michaelson
APNIC
6 Cordelia St
South Brisbane, QLD 4101
Australia

Email: ggm@apnic.net