Network Working Group A. Sullivan
Internet-Draft Dyn, Inc.
Intended status: Informational October 22, 2012
Expires: April 25, 2013
Asserting DNS Administrative Boundaries Within DNS Zones
draft-sullivan-domain-origin-assert-02
Abstract
Some clients on the Internet make inferences about the administrative
relationships among servers on the Internet based on the domain names
of those servers. Perhaps unfortunately, it is not currently
possible to detect the real administrative boundaries in the DNS, and
therefore such inferences can go wrong in several ways. Mitigation
strategies deployed so far will not scale. The solution to this is
to provide a way to make an explicit assertion about the
relationships between different domain names and perhaps the services
provided at them.
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 April 25, 2013.
Copyright Notice
Copyright (c) 2012 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
Sullivan Expires April 25, 2013 [Page 1]
Internet-Draft Asserting DNS Boundaries October 2012
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. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background, terminology, and organization of this memo . . . . 5
3. Overview of mechanism . . . . . . . . . . . . . . . . . . . . 5
3.1. Identifying names as the scope for policy authority . . . 6
3.2. Identifying names, schemes, and ports as the scope for
policy authority . . . . . . . . . . . . . . . . . . . . . 6
4. The SOPA Resource Record . . . . . . . . . . . . . . . . . . . 7
4.1. Thr SOPA Resource Record only for names . . . . . . . . . 7
4.2. Thr SOPA Resource Record with ports and schemes . . . . . 8
5. Use of the SOPA RRTYPE . . . . . . . . . . . . . . . . . . . . 9
5.1. Special target labels . . . . . . . . . . . . . . . . . . 10
5.1.1. The root target . . . . . . . . . . . . . . . . . . . 10
5.1.2. Wildcards in targets . . . . . . . . . . . . . . . . . 10
5.2. What can be done with an SOPA RR . . . . . . . . . . . . . 11
6. An example case . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Examples of using the SOPA record for determining
boundaries . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1.1. One delegation, eight administrative realms, no
root target . . . . . . . . . . . . . . . . . . . . . 13
6.1.2. One delegation, eight administrative realms, root
targets . . . . . . . . . . . . . . . . . . . . . . . 13
6.1.3. Two delegations, seven or eight policy realms,
root targets . . . . . . . . . . . . . . . . . . . . . 14
7. Limitations of the approach and other considerations . . . . . 15
7.1. Handling truncation . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Discussion Venue . . . . . . . . . . . . . . . . . . 18
Appendix B. Change History . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
Sullivan Expires April 25, 2013 [Page 2]
Internet-Draft Asserting DNS Boundaries October 2012
1. Motivation
Many network resources are accessed primarily by name. DNS names
make up the bulk of those names. As a result, DNS names have become
fundamental elements in building security policies and user agent
behaviour. For example, domain names are used in attempts to
determine the scope for data sharing of HTTP state management cookies
[RFC6265] . The idea is to foil the attempts of attackers in (for
example) attackersite.co.tld from setting cookies for everyone in
co.tld.
Another example policy is a user interface convention that purports
to display the "real" domain name differently from other parts of the
fully-qualified domain name, in an effort to decrease the success of
phishing attacks. In this strategy, for instance, a domain name like
"www.bank.example.com.attackersite.tld" is formatted to highlight
that the name is inside "attackersite.tld", in the hope of thereby
reducing the user's impression of visiting "www.bank.example.com".
Issuers of X.509 certificates make judgements about administrative
boundaries around domains when issuing the certificates. For some
discussion of the relationship between DNS names and X.509
certificates, see [RFC6125].
One way to build a reasonable policy is to treat each different
domain name distinctly. Under this approach, foo.example.org,
bar.example.org, and baz.example.org are all just different domains.
Such an approach can be awkward, however, when (as is often the case)
the real administrative boundary is a shared one (in this example,
example.org). Therefore, clients have attempted to make more
sophisticated policies.
Historically, policies were sometimes based on the DNS tree. Early
policies made a firm distinction between top-level domains and
everything else; but this was too naive, and later attempts were
based on inferences from the DNS names themselves. That did not work
well, because there is no way in the DNS to discover the boundaries
of administrative control around domain names.
Some have attempted to use the boundary of zone cuts (i.e. the
location of the zone's apex, which is at the SOA record; see
[RFC1034] and [RFC1035]). Unfortunately, that boundary is neither
necessary nor sufficient for these purposes: it is possible for a
large site to have many, administratively distinct subdomain-named
sites without inserting an SOA record, and it is also possible that
an administrative entity (like a company) might divide its domain up
into different zones for administrative reasons unrelated to the
purposes of sites named in that domain. It was also, prior to the
Sullivan Expires April 25, 2013 [Page 3]
Internet-Draft Asserting DNS Boundaries October 2012
advent of DNSSEC, difficult to find zone cuts. Regardless, the
location of a zone cut is an administrative matter to do with the
operation of the DNS itself, and not useful for determining
relationships among services offered at names in the DNS.
What appears to be needed is a mechanism to determine administrative
boundaries in the DNS. That is, given services at two domain names,
one needs to be able to answer whether the first and the second are
under the same administrative control and same administrative
policies. We may call this state of affairs "lying within the same
policy realm". We may suppose that, if this information were to be
available, it would be possible to make useful decisions based on the
information.
A particularly important distinction for security purposes is the one
between names that are mostly used to contain other domains, as
compared to those that are mostly used to operate services. The
former are often "delegation-centric" domains, delegating parts of
their name space to others, and are frequently called "public suffix"
domains or "effective TLDs". The term "public suffix" comes from a
site, publicsuffix.org, that publishes a list of domains (henceforth,
the "public suffix list") that are used to contain other domains.
Not all, but most, delegation-centric domains are public suffix
domains; and not all public suffix domains need to do DNS delegation,
although most of them do. The reason for the public suffix list is
to make the distinction between names that must never be treated as
being in the same policy realm as another, and those that might be so
treated. For instance, if "com" is on the public suffix list, that
means that "example.com" lies in a policy realm distinct from that of
com.
Unfortunately, the public suffix list has several inherent
limitations. To begin with, it is a list that is separately
maintained from the list of DNS delegations. As a result, the data
in the public suffix list can diverge from the actual use of the DNS.
Second, because its semantics are not the same as those of the DNS,
it does not capture unusual features of the DNS that are a
consequence of its structure (see [RFC1034] for background on that
structure). Third, as the size of the root zone grows, keeping the
list both accurate and synchronized with the expanding services will
become difficult and unreliable. Perhaps most importantly, it puts
the power of assertion about the operational policies of a domain
outside the control of the operators of that domain, and in the
control of a third party possibly unrelated to those operators.
There have been suggestions for improvements of the public suffix
list, most notably in [I-D.pettersen-subtld-structure]. It is
unclear the extent to which those improvements would help, because
Sullivan Expires April 25, 2013 [Page 4]
Internet-Draft Asserting DNS Boundaries October 2012
they represent improvements on the fundamental mechanism of keeping
metadata about the DNS tree apart from the DNS tree itself.
2. Background, terminology, and organization of this memo
The reader is assumed to be familiar with the DNS ([RFC1034]
[RFC1035]) and DNSSEC ([RFC4033] [RFC4034] [RFC4035] [RFC5155]).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Section 3 describes the mechanism in general terms, outlining two
different possible approaches and outlining the compromises in each
case. Definitions of the new RRTYPE is in Section 4, with two
different definitions to allow for the two different approaches.
There is some general discussion of the use of the RRTYPE is in
Section 5. Then, Section 6 offers an example portion of a DNS tree
that can be used to understand the ways in which the mechanism can be
used to draw inferences about administrative relationships.
Section 7 notes some limitations of the mechanism. Section 8
outlines how the mechanism might be used securely.
3. Overview of mechanism
This memo presents a way to assert a common administrative realm by
placing a resource record (RR) at DNS names within the policy realm.
The mechanism requires a new resource record type (RRTYPE) to enable
these assertions, called SOPA (for Start Of Policy Authority, echoing
the Start Of Authority or SOA record). While there are reported
difficulties in deploying new RRTYPEs, the only RRTYPE that could be
used to express all the necessary variables is the TXT record, and it
is unsuitable because it can also be used for other purposes. The
use of this mechanism does not require "underscore labels" to scope
the interpretation of the RR, in order to make it possible to use the
mechanism where the underscore label convention is already in use.
The SOPA RRTYPE is class-independent.
While many policies of the sort discussed in Section 1 appear to be
based on domain names, they are actually only partly based on them.
Usually, there are implicit rules that come from the destination port
[RFC6335] or scheme [RFC4395] (or both) in use.
It is possible to make those assumptions explicit, but at the cost of
expressing in the resulting record a tighter relationship between the
DNS and the services offered at DNS names. There are arguments to be
Sullivan Expires April 25, 2013 [Page 5]
Internet-Draft Asserting DNS Boundaries October 2012
made for each approach. Section 3.1 and Section 3.2 explore the two
different approaches; this memo does not make a decision about which
strategy to adopt. If there are future developments of this memo,
one strategy will be selected.
It is worth observing that a policy realm relationship ought to be
symmetric: if example.com is in the same policy realm as example.net,
then example.net should be (it would seem) in the same policy realm
as example.com. In principle, then, if a SOPA RR at example.com
provides a target at example.net, there should be a complementary
SOPA RR at example.net with a target of example.com. Because of the
distributed nature of the DNS, and because the other administrative
divisions need not follow the policy realms, the only way to know
whether two names are in the same policy realm is to query at each
name, and to correlate the responses.
3.1. Identifying names as the scope for policy authority
The first approach provides, as the RDATA of a SOPA RR, a target name
that lies in the same policy realm as the owner name in the RR. For
convenience, in what follows this is sometimes called this the
"names-only" strategy. Such an approach is an assertion on the part
of the authoritative DNS server for the owner name in question that
there is a policy relationship between that owner name and the target
name. If a single name lies in the same policy realm as several
other target names, an additional RR is necessary for each such
relationship, with one exception. It is not uncommon for two
different names to have policy relationships among all the children
beneath them. Using the SOPA RR, it is possible to specify that the
target is all the names beneath a name, using a wildcard target.
This approach follows the traditional way that relationships are
expressed in the DNS, which is historically mostly between different
names. Aliases, for instance, redirect names or trees, and not names
or trees for specific RRTYPEs. It has the disadvantage, however,
that it may not provide enough information about the relationship
between two names to make all the inferences one might need about the
relationship. For instance, the relationship between two hosts might
depend on the protocol, port, and scheme in use: two domains might
share policy for the purposes of connections on port 80, but for no
other connections. [[anchor2: Could this be capured by using SRV or
NAPTR records on both sides of the policy relationship? Too slow?
--ajs@anvilwalrusden.com]]
3.2. Identifying names, schemes, and ports as the scope for policy
authority
The second approach provides, as the RDATA of a SOPA RR, a target
Sullivan Expires April 25, 2013 [Page 6]
Internet-Draft Asserting DNS Boundaries October 2012
name that lies in the same policy realm as the owner name in the RR,
but can identify the relationship as pertaining only to certain ports
and schemes. In what follows, for convenience this is sometimes
called the "port-and-scheme" stragegy. It provides a way to cover
ranges of ports with a single resource record, and to cover all
schemes and ports with a single resource record. It does not,
however, permit arbitrary combinations of destination point and
schemes without using more than one RR.
This approach offers a mechanism to express relationships between
services at a domain name instead of merely between names. As a
disadvantage, however, it seems to step outside the usual scope of
the DNS, which concerns itself with names and not services offered at
those names. It might be argued that some RRTYPEs (notably SRV
[RFC2782] and NAPTR [RFC3403]) do relate to services; but in those
cases, it is an expression of services available at an already-named
host. It would be a significant innovation, perhaps in a bad
direction, to attempt to express these relationships in a single RR.
Since the names are under different administration, also, it is
entirely possible that the operators of the two domains do not agree
on the port ranges and schemas to be supported, creating an
intractable comparison problem for a client.
4. The SOPA Resource Record
Because of the two approaches outlined in Section 3.1 and
Section 3.2, this section provides two different outlines of the SOPA
resource record. This arrangement is pending the decision about
which strategy to adopt, at which time the discussion below will be
reduced to reflect that decision.
4.1. Thr SOPA Resource Record only for names
In this case, the SOPA resource record, type number [TBD1], includes
the following fields:
Name: The owner name of the RR.
TTL: The time to live for the RR.
Class: The CLASS for the RR. As of this writing, on the
contemporary Internet this is almost always "IN", but the SOPA RR
is class-independent.
SOPA: The RRTYPE field.
Target: A DNS name relative to the root that is in the same policy
realm as the SOPA RR's owner name. The name MUST be a DNS name
according to the rules in [RFC1034] and [RFC1035], except that the
left-most label of the target MAY be the wildcard character ("*").
In addition, the target may be "."; in that case, the RR asserts
that there are no other names in the same policy realm. For
Sullivan Expires April 25, 2013 [Page 7]
Internet-Draft Asserting DNS Boundaries October 2012
further discussion, see Section 5.1. The target MUST NOT be an
alias [RFC2181], such as the owner name of a CNAME [RFC1034],
DNAME [RFC6672], or other similar such resource records.
The SOPA RRTYPE's wire format is as follows:
[[anchor3: To follow if this idea (and this version of it) turns out
worth pursuing. It can be derived from above, however.
--ajs@anvilwalrusden.com]]
4.2. Thr SOPA Resource Record with ports and schemes
In this case, the SOPA resource record, type number [TBD1], includes
the following fields:
Name: The owner name of the RR.
TTL: The time to live for the RR.
Class: The CLASS for the RR. As of this writing, on the
contemporary Internet this is almost always "IN", but the SOPA RR
is class-independent.
SOPA: The RRTYPE field.
Starting port: The port number that begins the range to which this
SOPA RR applies. This is a 16 bit unsigned integer in network
byte order. The range is 0-65535.
Ending port: The port number that ends the range for which this SOPA
RR applies. This is a 16 bit unsigned integer in network byte
order. The range is 0-65535.
Scheme: The scheme to which the SOPA RR applies. The scheme SHOULD
be listed in the IANA Uniform Resource Identifier (URI) Schemes
registry [1]. [[anchor4: This is "SHOULD" right now, but I think
it should be "MUST". I can't think of a reason why not to make it
MUST. --ajs@anvilwalrusden.com]] Alternatively, the field may
contain the special value "*", in which case the SOPA RR applies
to all schemes, with a limitation: some clients use certain
schemes only for internal operations, and regardless of whether
those schemes are included in an SOPA RR, they MAY be ignored.
Target: A DNS name relative to the root that is in the same policy
realm as the SOPA RR's owner name. The name MUST be a DNS name
according to the rules in [RFC1034] and [RFC1035], except that the
left-most label of the target MAY be the wildcard character ("*").
In addition, the target may be "."; in that case, the RR asserts
that there are no other names in the same policy realm. For
further discussion, see Section 5.1. The target MUST NOT be an
alias [RFC2181], such as the owner name of a CNAME [RFC1034],
DNAME [RFC6672], or other similar such resource records.
The SOPA RRTYPE's wire format is as follows:
[[anchor5: To follow if this idea (and this version of it) turns out
Sullivan Expires April 25, 2013 [Page 8]
Internet-Draft Asserting DNS Boundaries October 2012
worth pursuing. It can be derived from above, however.
--ajs@anvilwalrusden.com]]
5. Use of the SOPA RRTYPE
SOPA RRs may have, in effect, three different functions. The
simplest is to make an assertion that two DNS names are in the same
policy realm. Under the port-and-scheme strategy, if the Starting
Port is 0, the Ending Port is 65535, the Scheme is "*", and the
Target is anything other than ".", then the SOPA record makes a claim
that the owner name and the target name are in the same policy realm
in every case. This is also the claim whenever the names-only
stragey is in use, and the RDATA has a target other than ".".
The second function, available only under the port-and-scheme
strategy, is to make an assertion that two DNS names are in the same
policy realm, but only for some subset of ports or schemes or both.
There is a 1:1 port mapping presumed in the way the SOPA RR is
structured, such that it is not possible to say that port N at the
owner name is related to port M at the target name. This is an
expedient for simplicity. For the same reasons of simplicity, the
SOPA RR permits linking all schemes between names, or else one
scheme; a given RR does not permit listing more than one scheme
without using the wildcard selector.
The third function is to make an assertion that no other name lies in
the same policy realm as the owner name. If there are names beneath
that owner name, this is a way for a DNS operator to assert that the
owner name is a public suffix. For more details, see Section 5.1.
There could be more than one SOPA resource record per owner name in a
response. Each domain name in the RDATA is treated as a part of the
same policy realm as the owner name in the original QNAME (subject to
the qualifications of scheme and port contained in the SOPA RR in the
port-and-scheme strategy). The QNAME from the query might not be the
owner name of the SOPA RR: if the original QNAME was an alias, then
the SOPA owner name will be different.
There are three possible responses to a query for the SOPA RRTYPE at
an owner name that are relevant to determining the policy realm. The
first is Name Error (RCODE=3, also known as NXDOMAIN). In this case,
the owner name itself does not exist, and no further processing is
needed.
The second is a No Data response [RFC2308] of any type. The No Data
response means that the owner name in the QNAME does not recognize
any other name as part of a common policy realm.
Sullivan Expires April 25, 2013 [Page 9]
Internet-Draft Asserting DNS Boundaries October 2012
The final is a response with one or more SOPA resource records in the
Answer section. Each SOPA resource record asserts a relationship
between the owner name and the target name, according to the
functions of the SOPA RRTYPE outlined above.
Any other response is no different from any other sort of response
from the DNS, and is not in itself meaningful for determining the
policy realm of a name (though it might be meaningful for finding the
SOPA record).
5.1. Special target labels
5.1.1. The root target
An SOPA resource record with the single character "." (called the
"root target") in the RDATA is a positive assertion that no other
domain name falls inside the policy realm of the owner name. The
record has a special use: it may be used to bootstrap operation. A
client that has encountered the root target may remember the
existence of the root target even after the expiry of the TTL on the
RRset, until such time as a new query for the owner name may be made
successfully. This rule permits implementations to cache positive
statements of administrative isolation during disconnected periods,
thereby starting a subsequent session with the values of prior
affirmed policy. Apart from this bootstrapping use, and the ability
of such an RR to have a TTL independent of the negative TTL value for
the zone, this mechanism is semantically equivalent to a No Data
response.
It would be absurd for the root target for any given schema to exist
with any other SOPA resource record at that owner name. An
authoritative name server MAY refuse to serve a zone containing such
an inconsistency, MAY refuse to load a zone containing such an
inconsistency, or MAY suppress every SOPA RR at an owner name and
schema except that containing the root target. The name server side
of a recursive resolver MAY discard every SOPA RR at an owner name
except that containing the root target. Conforming servers MUST NOT
serve the root target and any other SOPA RR at the same owner name.
Clients receiving a SOPA RRset that includes the root target MUST
accept that RR, and discard any other RR in the RRset.
5.1.2. Wildcards in targets
The special character "*" in the Target field is used to match any
label, according to the wildcard label rules in section 4.3.3 of
[RFC1034]. Note that, because of the way wildcards work in the DNS,
is it not possible to place a restriction to the left of a wildcard;
so, for instance, example.*.example.com does not work. The effect is
Sullivan Expires April 25, 2013 [Page 10]
Internet-Draft Asserting DNS Boundaries October 2012
maintained in this memo. An authoritative name server MUST NOT serve
an SOPA RR with erroneous wildcards, and clients receiving such an
SOPA RR MUST discard the RR. If the discarded RR is the last RR in
the answer section of the response, then the response is treated as a
No Data response.
5.2. What can be done with an SOPA RR
Use of an SOPA RR enables a site administrator to assert or deny
relationships between names. By the same token, it permits a a
consuming client to detect these assertions and denials.
Some of these relationships are currently impossible to indicate in
the DNS. For example, IDN character variants (see [RFC4290]) result
in situations where multiple labels are sometimes intended to be
treated as though they are the same. Without a mechanism for binding
the names together even loosely, such a goal cannot be achieved.
The use of SOPA RRs could either replace the public suffix list or
(more likely due to some limitations -- see Section 7) simplify and
automate the management of the public suffix list. A client could
use the responses to SOPA queries to refine its determinations about
http cookie Domain attributes. In the absence of SOPA RRs at both
owner names, a client might treat a Domain attribute as though it
were omitted. More generally, SOPA RRs would permit additional steps
similar to steps 4 and 5 in [RFC6265].
SOPA RRs might be valuable for certificate authorities when issuing
certificates, because it would allow them to check whether two names
are related in the way the party requesting the certificate claims
they are.
6. An example case
For the purposes of discussion, it will be useful to imagine a
portion of the DNS, using the domain example.tld. A diagram of the
tree of this portion is in Figure 1. In the example, the domain
example.tld includes several other names: www.example.tld,
account.example.tld, cust1.example.tld, cust2.example.tld,
test.example.tld, cust1.test.example.tld, and cust2.test.example.tld.
Sullivan Expires April 25, 2013 [Page 11]
Internet-Draft Asserting DNS Boundaries October 2012
tld
|
|
------example -----
/ / | \ \
/ / | \ \
/ www account \ cust2
test \
/ \ cust1
cust1 cust2
Figure 1
In the example, the domain tld delegates the domain example.tld.
There are other possible cut points in the example, and depending on
whether the cuts exist there may be implications for the use of the
examples. See Section 6.1, below.
The (admittedly artificial) example permits us to distinguish a
number of different roles. To begin with, there are three parties
involved in the operation of services:
o OperatorV, the operator of example.tld;
o Operator1, the operator of cust1.example.tld;
o Operator2, the operator of cust2.example.tld.
Since there are three parties, there are likely three administrative
boundaries as well; but the example contains some others. For
instance, the names www.example.tld and example.tld are in this case
in the same policy realm. By way of contrast, account.example.tld
might be treated as completely separate, because OperatorV might wish
to ensure that the accounts system is never permitted to share
anything with any other name. By the same token, the names
underneath test.example.tld are actually the test-instance sites for
customers. So cust1.test.example.tld might be in the same policy
realm as cust1.example.tld, but test.example.tld is certainly not in
the same administrative realm as www.example.tld.
Finally, supposing that Operator1 and Operator2 merge their
operations, it seems that it would be useful for cust1.example.tld
and cust2.example.tld to lie in the same policy realm, without
including everything else in example.tld.
6.1. Examples of using the SOPA record for determining boundaries
This section provides some examples of different configurations of
the example tree in Section 6, above. The examples are not
exhaustive, but may provide an indication of what might be done with
the mechanism. [[anchor6: This needs to have examples of using the
Sullivan Expires April 25, 2013 [Page 12]
Internet-Draft Asserting DNS Boundaries October 2012
ports and scheme added to it. Suggestions welcome. Also, I think
some examples could be made longer to make them clearer. Maybe
complete zone files in presentation form in an appendix?
--ajs@anvilwalrusden.com]]
6.1.1. One delegation, eight administrative realms, no root target
In this scenario, the example portion of the DNS name space contains
all and only the following SOPA records for the names-only strategy:
example.tld 86400 IN SOPA www.example.tld
www.example.tld 86400 IN SOPA example.tld
For the scheme-and-port strategy, these are the records instead:
example.tld 86400 IN SOPA 0 65535 * www.example.tld
www.example.tld 86400 IN SOPA 0 65535 * example.tld
Tld is the top-level domain, and has delegated example.tld. The
operator of example.tld makes no delegations. There are four
operators involved: the operator of tld; OperatorV; Operator1, the
operator of the services at cust1.example.tld and
cust1.test.example.tld; and Operator2, the operator of the services
at cust2.example.tld and cust2.test.example.tld.
In this arrangement, example.tld and www.example.tld positively claim
to be within the same policy realm. Every other name stands alone.
A query for an SOPA record at any of those other names will result in
a No Data response, which means that none of them include any other
name in the same policy realm. As a result, there are eight separate
policy realms in this case: tld, {example.tld and www.example.tld},
test.example.tld, cust1.test.example.tld, cust2.test.example.tld,
account.example.tld, cust1.example.tld, and cust2.example.tld.
6.1.2. One delegation, eight administrative realms, root targets
This example mostly works the same way as the one in Section
Section 6.1.1, but there is a slight difference. In this case, in
addition to the records listed in Section 6.1.1, both tld and
test.example.tld publish root targets in their SOPA records. For
names-only:
tld 86400 IN SOPA .
test.example.tld 86400 IN SOPA .
For scheme-and-port:
Sullivan Expires April 25, 2013 [Page 13]
Internet-Draft Asserting DNS Boundaries October 2012
tld 86400 IN SOPA 0 65535 * .
test.example.tld 86400 IN SOPA 0 65535 * .
The practical effect of this is largely the same as the previous
example, except that these expressions of policy last 86,400 seconds
instead of the length of time on the negative TTL in the relevant SOA
for the zone. Many zones have short negative TTLs because of
expectations that newly-added records will show up quickly. This
mechanism permits such names to express their administrative
isolation for predictable periods of time. Moreover, because clients
are permitted to retain these records during periods when DNS service
is not available, a client could go offline for several weeks, and
return to service with the presumption that test.example.tld is still
not in any policy realm with any other name.
6.1.3. Two delegations, seven or eight policy realms, root targets
In this scenario, example.tld delegates the name test.example.tld.
In this case, in addition to the SOPA record at test.example.tld,
there is an SOA record for test.example.tld. So, there are the same
SOPA records as in Section 6.1.2. The addition of the SOA record for
test.example.tld does not affect the relationship between
test.example.tld and example.tld. At this point, there are eight
policy realms.
Next, the Operator1 determines that it is safe to treat the test
instance and production instance as being in the same policy realm.
To begin with, Operator1 asks OperatorV to add the following record
to the test.example.tld zone for the names-only case:
cust1.test.example.tld 86400 IN SOPA cust1.example.tld
And for the scheme-and-port case:
cust1.test.example.tld 86400 IN SOPA 0 65535 * cust1.example.tld
This arrangement is not complete yet. Until a record is also added
at cust1.example.tld, Operator1's intention is only half fulfilled.
The service at cust1.test.example.tld treats cust1.example.tld as
part of a common policy realm, but the converse is not the case.
[[anchor7: I can't decide whether there's anything useful in this
configuration. Thoughts? I also can't decide whether this is still
8 admin realms, 7 admin realms but broken, or 7 admin realms from one
perspective and 8 from another. --ajs@anvilwalrusden.com]]
To complete the process, Operator1 asks OperatorV to add the
following record to the example.tld zone in the names-only case:
Sullivan Expires April 25, 2013 [Page 14]
Internet-Draft Asserting DNS Boundaries October 2012
cust1.example.tld 86400 IN SOPA cust1.test.example.tld
In the scheme-and-port case:
cust1.example.tld 86400 IN SOPA 0 65535 * cust1.test.example.tld
Once this is complete, both names treat the other as part of the same
policy realm. In the end, the example segment of the DNS expresses
the following seven policy realms: tld, {example.tld,
www.example.tld}, test.example.tld, {cust1.test.example.tld,
cust1.example.tld}, cust2.example.tld, account.example.tld,
cust2.test.example.tld.
7. Limitations of the approach and other considerations
There are four significant problems with this proposal, all of which
are related to using DNS to deliver the data.
The first is that new DNS RRTYPEs are difficult to deploy. While
adding a new RRTYPE is straightforward, many provisioning systems do
not have the necessary support and some firewalls and other edge
systems continue to filter RRTYPEs they do not know.
The second is that it is difficult for an application to obtain data
from the DNS. The TTL on an RRset, in particular, is usually not
available to an application, even if the application uses the
facilities of the operating system to deliver other parts of an
unknown RRTYPE.
The third, which is mostly a consequence of the above two, is that
there is a significant barrier to adoption: until browsers have
mostly all implemented this, operations need to proceed as though
nobody has. But browsers will need to support two mechanisms for
some period of time if they are to implement this mechanism at all,
and they are unlikely to want to do that. This may mean that there
is no reason to implement, which also means no reason to deploy.
This is made worse because, to be safe, the mechanism really needs
DNSSEC, and performing DNSSEC validation at end points is still an
unusual thing to do. This limitation may not be as severe for use-
cases that are directed higher in the network (such as using this
mechanism as an automatic feed to keep the public suffix list
updated, or for the use of CAs when issuing certificates.
Finally, in many environments the system hosting the application has
only proxied access to the Internet, and cannot query the DNS
directly. It is not clear how such clients could ever possibly
Sullivan Expires April 25, 2013 [Page 15]
Internet-Draft Asserting DNS Boundaries October 2012
retrieve the SOPA record for a name.
7.1. Handling truncation
It is possible to put enough SOPA records into a zone such that the
resulting response will exceed DNS or UDP protocol limits. This is
especially true in the case where one wishes to take advantage of the
scheme-and-port approach, and one expresses many different such
relationship. In such cases, a UDP DNS response will arrive with the
TC (truncation) bit set. An SOPA response with the TC bit must be
queried again in order to retrieve a complete response, in order to
ensure that there is no missing root target (see Section 5.1.1),
generally using TCP. This increases the cost of the query, increases
the time to being able to use the answer, and may not work at all in
networks where administrators mistakenly block port 53 using TCP.
8. Security Considerations
This mechanism enables publication of assertions about administrative
relationships of different DNS-named systems on the Internet. If
such assertions are accepted without checking that both sides agree
to the assertion, it would be possible for one site to become an
illegitimate source for data to be consumed in some other site. In
general, assertions about another name should never be accepted
without querying the other name for agreement.
Undertaking any of the inferences suggested in this draft without the
use of the DNS Security Extensions exposes the user to the
possibility of forged DNS responses.
9. IANA Considerations
IANA will be requested to register the SOPA RRTYPE if this proceeds.
10. Acknowledgements
The author thanks Adam Barth, Dave Crocker, Jeff Hodges, John
Klensin, Murray Kucherawy, Gervase Markham, Patrick McManus, Henrik
Nordstrom, Yngve N. Pettersen, Eric Rescorla, Thomas Roessler, Peter
Saint-Andre, and Maciej Stachowiak for helpful comments.
11. References
Sullivan Expires April 25, 2013 [Page 16]
Internet-Draft Asserting DNS Boundaries October 2012
11.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, March 2008.
11.2. Informative References
[I-D.pettersen-subtld-structure]
Pettersen, Y., "The Public Suffix Structure file format
and its use for Cookie domain validation",
draft-pettersen-subtld-structure-09 (work in progress),
March 2012.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, March 1998.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Three: The Domain Name System (DNS) Database",
RFC 3403, October 2002.
Sullivan Expires April 25, 2013 [Page 17]
Internet-Draft Asserting DNS Boundaries October 2012
[RFC4290] Klensin, J., "Suggested Practices for Registration of
Internationalized Domain Names (IDN)", RFC 4290,
December 2005.
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 35,
RFC 4395, February 2006.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165,
RFC 6335, August 2011.
[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
DNS", RFC 6672, June 2012.
URIs
[1] <http://www.iana.org/assignments/uri-schemes.html>
Appendix A. Discussion Venue
This Internet-Draft is discussed on the applications area working
group mailing list: apps-discuss@ietf.org.
Appendix B. Change History
00 to 01:
* Changed the mnemonic from BOUND to AREALM
* Added ports and scheme to the RRTYPE
* Added some motivating text and suggestions about what can be
done with the new RRTYPE
* Removed use of "origin" term, because it was confusing. The
document filename preserves "origin" in the name in order that
the tracker doesn't lose the change history, but that's just a
vestige.
Sullivan Expires April 25, 2013 [Page 18]
Internet-Draft Asserting DNS Boundaries October 2012
* Removed references to cross-document information sharing and
ECMAScript. I don't understand the issues there, but Maciej
Stachowiak convinced me that they're different enough that this
mechanism probably won't work.
* Attempted to respond to all comments received. Thanks to the
commenters; omissions and errors are mine.
01 to 02:
* Changed mnemonic again, from AREALM to SOPA. This in response
to observation by John Klensin that anything using
"administrative" risks confusion with the standard
administrative boundary language of zone cuts.
* Add discussion of two strategies: name-only or scheme-and-port.
* Increase prominence of utility to CAs. This use emerged in
last IETF meeting.
Author's Address
Andrew Sullivan
Dyn, Inc.
150 Dow St
Manchester, NH 03101
U.S.A.
Email: asullivan@dyn.com
Sullivan Expires April 25, 2013 [Page 19]