Network Working Group O. Kolkman
Internet-Draft NLnet Labs
Intended status: Experimental Protocol A. Sullivan
Expires: March 22, 2014 Dyn, Inc.
W. Kumari
Google, Inc.
September 20, 2013
Using Test Delegations from the Root Prior to Full Allocation and
Delegation
draft-kolkman-root-test-delegation-00
Abstract
The delegation of certain strings as TLDs will cause stability and
security issues if such strings have been used in private
environments prior to their delegation. It is recommended that test
delegations be used to enable empirical research on the extent of the
possible disruption prior to actual allocation and delegation of any
label in the root zone.
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, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
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
Kolkman, Sullivan & KumarExpires March 22, 2014 [Page 1]
Internet-Draft Test Delegations From the Root September 2013
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
2. Terms and Conventions Used in this Memo . . . . . . . . . . . 4
3. Principle of Operation . . . . . . . . . . . . . . . . . . . . 4
3.1. Measurements Servers and Zones . . . . . . . . . . . . . . 5
3.2. Query Generation . . . . . . . . . . . . . . . . . . . . . 5
3.3. Sampling . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. The Name Server . . . . . . . . . . . . . . . . . . . . . 7
4. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. A Basis for Acceptable Behaviour . . . . . . . . . . . . . . . 9
6. Possible Experiment Extension . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
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 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:"
Kolkman, Sullivan & KumarExpires March 22, 2014 [Page 2]
Internet-Draft Test Delegations From the Root September 2013
.intranet.
.internal.
.private.
.corp.
.home.
.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,
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 as an "undelegated TLD"
(being used as the rightmost label in an name), but this is simply an
artifact of domain search list processing.
For example, suppose the Example Widgets corporation uses a sub-
domain (.corp) of their primary domain (example.com) to name their
employee workstations, servers, printers and similar. They have an
"intranet" server named intranet.corp.example.com. In order to allow
their employees to simply type "intranet.corp" to access this server,
the users' workstations are configured (probably using [RFC3379])
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
"intranet" created within .corp, the first lookup ("intranet.corp")
would no longer generate an NXDOMAIN response. This would stop the
Kolkman, Sullivan & KumarExpires March 22, 2014 [Page 3]
Internet-Draft Test Delegations From the Root September 2013
search-list processing, and direct the user somewhere other than
where the user intended to go -- the "wrong server", in the eyes of
the user, even if right according to the DNS.
It is worth noting that a researcher analyzing DNS queries hitting
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 of the cause is
valuable.
1.2. Scire est mensurare
The local use of undelegated top-level domain names is troublesome
because it produces different experience 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), 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
around a static list of top-level domains (TLDs), and therefore it
seems reasonable to plan for the possible addition of new TLDs whose
use might conflict with deployed search path settings. Yet 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 that
have always been part of the protocol.
What is needed is a mechanism to test whether a particular delegation
from the root zone presents a serious conflict with widespread use.
This memo presents a methodology for making such a determination.
The methodology 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
Kolkman, Sullivan & KumarExpires March 22, 2014 [Page 4]
Internet-Draft Test Delegations From the Root September 2013
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
existing use of a single CandidateTLD.
3.1. Measurements Servers and Zones
In addition to the candidate string ("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 delegated from a 'common' existing TLD
(ExistingTLD) to the experiment's server.
The experiment's server has two functions:
First, with one exception detailed below in Section 3.4, if any
request for any name inside the CandidateTLD or the TestName
namespace reaches the name server, the name server MUST respond 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 name in any request it
receives, the time at which the request arrived, the RRTYPE and CLASS
in the request, and the source network for the request.
3.2. Query Generation
Software probes will need to be deployed throughout the Internet
(also see Section 3.3) these probes will send, in parallel, sets of
queries.
Each set comprises one measurement and consists of three queries (or
even 4, see Section 6). A measurement is identified by a unique
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
Kolkman, Sullivan & KumarExpires March 22, 2014 [Page 5]
Internet-Draft Test Delegations From the Root September 2013
the QNAME is <uniqueid>-c.TestName.ExistingTLD
The TestName MUST be a randomly chosen name that remains constant for
the duration of the experiment, MUST be a syntactically valid label,
SHOULD be semantic nonsense, an MUST NOT be delegated from the root
or in the ExistingTLD already.
Depending on the environment in which the probe is located the query
that is send by a stub resolver is handled differently. We
distinguish 4 possibilities.
Local 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 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
located within a network that locally resolves the candidateTLD
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
located within a network that does not resolve the candidate TLD
and no searchlists being used that append CandidateTLD. All
queries will arrive at the authoritative servers for the
respective domains.
No use of CandidateTLD and CandidateTLD appended by Search List: The
probe is located within a network 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
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
one can establish the prevalence of the various scenarios. Under the
Kolkman, Sullivan & KumarExpires March 22, 2014 [Page 6]
Internet-Draft Test Delegations From the Root September 2013
assumption 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.
3.3. Sampling
To perform the evaluation, a names of the form
<uniqueid>.TestName.CandidateTLD and
<uniqueid>.controlname.ExistingTLD are embedded in content that is
placed around the web. As people visit web sites, the content is
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
instrumented in particular ways. First, the name server must be
configurable so that it authoritative for all requests inside the
Candidate TLD. Normally, it will always return RCODE 3 (NXDOMAIN) for
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.
Kolkman, Sullivan & KumarExpires March 22, 2014 [Page 7]
Internet-Draft Test Delegations From the Root September 2013
+-----------------------------+------------+-----------+------------+
| Domain Name | RRTYPE | RCODE | Actions if |
| | queried | returned | any |
+-----------------------------+------------+-----------+------------+
| 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
[TODO align with above]
To evaluate the results, it is only necessary to compare the number
of resolution attempts of the test names against the resolution
attempts of the control names. If the test name is not in wide
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.
Kolkman, Sullivan & KumarExpires March 22, 2014 [Page 8]
Internet-Draft Test Delegations From the Root September 2013
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.
Kolkman, Sullivan & KumarExpires March 22, 2014 [Page 9]
Internet-Draft Test Delegations From the Root September 2013
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
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 the experimenter 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 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
domains, as the introduction of DNSSEC is likely to bias the
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
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
queries that arrive at the nameserver.
8. References
[NETBIOS] IBM Corporation, "LAN Technical Reference: 802.2 and
NetBIOS APIs ", 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.
Kolkman, Sullivan & KumarExpires March 22, 2014 [Page 10]
Internet-Draft Test Delegations From the Root September 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
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
Kolkman, Sullivan & KumarExpires March 22, 2014 [Page 11]
Internet-Draft Test Delegations From the Root September 2013
Warren Kumari
Google, Inc.
1600 Amphitheatre Pkwy
Mountain View, CA 94043
U.S.A.
Email: warren@kumari.net
Kolkman, Sullivan & KumarExpires March 22, 2014 [Page 12]