Asserting DNS Administrative Boundaries Within DNS Zones
draft-sullivan-domain-origin-assert-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Author | Andrew Sullivan | ||
| Last updated | 2012-07-16 | ||
| Replaced by | draft-sullivan-domain-policy-authority, draft-sullivan-domain-policy-authority | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-sullivan-domain-origin-assert-01
Network Working Group A. Sullivan
Internet-Draft Dyn, Inc.
Intended status: Informational July 16, 2012
Expires: January 17, 2013
Asserting DNS Administrative Boundaries Within DNS Zones
draft-sullivan-domain-origin-assert-01
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 services provided at different domain names.
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 January 17, 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
to this document. Code Components extracted from this document must
Sullivan Expires January 17, 2013 [Page 1]
Internet-Draft Asserting DNS Boundaries July 2012
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
4. The AREALM Resource Record . . . . . . . . . . . . . . . . . . 6
5. Use of the AREALM RRTYPE . . . . . . . . . . . . . . . . . . . 6
5.1. Special target labels . . . . . . . . . . . . . . . . . . 8
5.1.1. The root target . . . . . . . . . . . . . . . . . . . 8
5.1.2. Wildcards in targets . . . . . . . . . . . . . . . . . 8
5.2. What can be done with an AREALM RR . . . . . . . . . . . . 8
6. An example case . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Examples of using the AREALM record for determining
boundaries . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1.1. One delegation, eight administrative realms, no
root target . . . . . . . . . . . . . . . . . . . . . 10
6.1.2. One delegation, eight administrative realms, root
targets . . . . . . . . . . . . . . . . . . . . . . . 11
6.1.3. Two delegations, seven or eight administrative
realms, root targets . . . . . . . . . . . . . . . . . 11
7. Limitations of the approach and other considerations . . . . . 12
7.1. Handling truncation . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Discussion Venue . . . . . . . . . . . . . . . . . . 15
Appendix B. Change History . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Sullivan Expires January 17, 2013 [Page 2]
Internet-Draft Asserting DNS Boundaries July 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 January 17, 2013 [Page 3]
Internet-Draft Asserting DNS Boundaries July 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
administrative 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 administrative 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 an administrative 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 January 17, 2013 [Page 4]
Internet-Draft Asserting DNS Boundaries July 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. The formal
definition of the new RRTYPE is in Section 4, and 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 administrative
realm. The mechanism requires a new resource record type (RRTYPE) to
enable these assertions, called AREALM (for Administrative REALM).
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 AREALM 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. The mechanism
described in this memo makes those assumptions explicit. 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.
Sullivan Expires January 17, 2013 [Page 5]
Internet-Draft Asserting DNS Boundaries July 2012
4. The AREALM Resource Record
The AREALM 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 AREALM
RR is class-independent.
AREALM: The RRTYPE field.
Starting port: The port number that begins the range to which this
AREALM 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
AREALM RR applies. This is a 16 bit unsigned integer in network
byte order. The range is 0-65535.
Scheme: The scheme to which the AREALM RR applies. The scheme
SHOULD be listed in the IANA Uniform Resource Identifier (URI)
Schemes registry [1]. [[anchor2: 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 AREALM 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 AREALM RR, they MAY be
ignored.
Target: A DNS name relative to the root that is in the same
administrative realm as the AREALM 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
administrative 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 AREALM RRTYPE's wire format is as follows:
[[anchor3: To follow if this idea turns out worth pursuing. It can
be derived from above, however. --ajs@anvilwalrusden.com]]
5. Use of the AREALM RRTYPE
AREALM RRs have, in effect, three different functions. The simplest
is to make an assertion that two DNS names are in the same
administrative realm. If the Starting Port is 0, the Ending Port is
Sullivan Expires January 17, 2013 [Page 6]
Internet-Draft Asserting DNS Boundaries July 2012
65535, the Scheme is "*", and the Target is anything other than ".",
then the AREALM record makes a claim that the owner name and the
target name are in the same administrative realm in every case.
The second is to make an assertion that two DNS names are in the same
administrative realm, but only for some subset of ports or schemes or
both. There is a 1:1 port mapping presumed in the way the AREALM 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
AREALM 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 administrative 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 AREALM resource record per owner name in
a response. Each domain name in the RDATA is treated as a part of
the same administrative realm as the owner name in the original
QNAME, subject to the qualifications of scheme and port contained in
the AREALM RR. The QNAME from the query might not be the owner name
of the AREALM RR: if the original QNAME was an alias, then the AREALM
owner name will be different.
There are three possible responses to a query for the AREALM RRTYPE
at an owner name that are relevant to determining the administrative
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 administrative realm.
The final is a response with one or more AREALM resource records in
the Answer section. Each AREALM resource record asserts a
relationship between the owner name and the target name, according to
the functions of the AREALM 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
administrative realm of a name (though it might be meaningful for
finding the AREALM record).
Sullivan Expires January 17, 2013 [Page 7]
Internet-Draft Asserting DNS Boundaries July 2012
5.1. Special target labels
5.1.1. The root target
An AREALM 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 administrative 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 AREALM 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 AREALM RR at an owner name and
schema except that containing the root target. The name server side
of a recursive resolver MAY discard every AREALM RR at an owner name
except that containing the root target. Conforming servers MUST NOT
serve the root target and any other AREALM RR at the same owner name.
Clients receiving a AREALM 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
maintained in this memo. An authoritative name server MUST NOT serve
an AREALM RR with erroneous wildcards, and clients receiving such an
AREALM 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 AREALM RR
Use of an AREALM RR enables a site administrator to assert or deny
relationships between names. By the same token, it permits a a
Sullivan Expires January 17, 2013 [Page 8]
Internet-Draft Asserting DNS Boundaries July 2012
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 AREALM 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 AREALM queries to refine its determinations
about http cookie Domain attributes. In the absence of AREALM RRs at
both owner names, a client might treat a Domain attribute as though
it were omitted. More generally, AREALM RRs would permit additional
steps similar to steps 4 and 5 in [RFC6265].
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.
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:
Sullivan Expires January 17, 2013 [Page 9]
Internet-Draft Asserting DNS Boundaries July 2012
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 administrative 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
administrative 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 administrative realm,
without including everything else in example.tld.
6.1. Examples of using the AREALM 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. [[anchor4: This needs to have examples of using the
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 AREALM records:
example.tld 86400 IN AREALM 0 65535 * www.example.tld
www.example.tld 86400 IN AREALM 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
Sullivan Expires January 17, 2013 [Page 10]
Internet-Draft Asserting DNS Boundaries July 2012
to be within the same administrative realm. Every other name stands
alone. A query for an AREALM 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 administrative realm. As a result, there
are eight separate administrative 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 AREALM records:
tld 86400 0 65535 * IN AREALM .
test.example.tld 86400 0 65535 * IN AREALM .
The practical effect of this is largely the same, 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
administrative realm with any other name.
6.1.3. Two delegations, seven or eight administrative realms, root
targets
In this scenario, example.tld delegates the name test.example.tld.
In this case, in addition to the AREALM record at test.example.tld,
there is an SOA record for test.example.tld. So, there are the same
AREALM 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
administrative realms.
Next, the Operator1 determines that it is safe to treat the test
instance and production instance as being in the same administrative
realm. To begin with, Operator1 asks OperatorV to add the following
record to the test.example.tld zone:
Sullivan Expires January 17, 2013 [Page 11]
Internet-Draft Asserting DNS Boundaries July 2012
cust1.test.example.tld 86400 IN AREALM 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 administrative realm, but the converse is not the
case. [[anchor5: 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:
cust1.example.tld 86400 IN AREALM 0 65535 * cust1.test.example.tld
Once this is complete, both names treat the other as part of the same
administrative realm. In the end, the example segment of the DNS
expresses the following seven administrative 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.
Sullivan Expires January 17, 2013 [Page 12]
Internet-Draft Asserting DNS Boundaries July 2012
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.
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
retrieve the AREALM record for a name.
7.1. Handling truncation
It is possible to put enough AREALM records into a zone such that the
resulting response will exceed DNS or UDP protocol limits. In such
cases, a UDP DNS response will arrive with the TC (truncation) bit
set. An AREALM 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).
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.
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 AREALM RRTYPE if this
proceeds.
10. Acknowledgements
The author thanks Adam Barth, Dave Crocker, Jeff Hodges, 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 January 17, 2013 [Page 13]
Internet-Draft Asserting DNS Boundaries July 2012
11.1. Normative References
[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.
[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.
[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.
[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.
Sullivan Expires January 17, 2013 [Page 14]
Internet-Draft Asserting DNS Boundaries July 2012
[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.
* 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.
Sullivan Expires January 17, 2013 [Page 15]
Internet-Draft Asserting DNS Boundaries July 2012
Author's Address
Andrew Sullivan
Dyn, Inc.
150 Dow St
Manchester, NH 03101
U.S.A.
Email: asullivan@dyn.com
Sullivan Expires January 17, 2013 [Page 16]