< draft-sullivan-domain-policy-authority-01.txt   draft-sullivan-domain-policy-authority-02.txt >
IETF A. Sullivan IETF A. Sullivan
Internet-Draft Dyn, Inc. Internet-Draft Dyn, Inc.
Intended status: Standards Track J. Hodges Intended status: Standards Track J. Hodges
Expires: September 5, 2014 PayPal Expires: August 21, 2016 PayPal
March 4, 2014 February 18, 2016
Asserting DNS Administrative Boundaries Within DNS Zones Asserting DNS Administrative Boundaries Within DNS Zones
draft-sullivan-domain-policy-authority-01 draft-sullivan-domain-policy-authority-02
Abstract Abstract
Some Internet client entities on the Internet make inferences about Some entities on the Internet make inferences about the
the administrative relationships among services on the Internet based administrative relationships among Internet services based on the
on the domain names at which they are offered. At present, it is not domain names at which those services are offered. At present, it is
possible to ascertain organizational administrative boundaries in the not possible to ascertain organizational administrative boundaries in
DNS, therefore such inferences can be erroneous in various ways. the DNS; therefore such inferences can be erroneous. Mitigation
Mitigation strategies deployed so far will not scale. The solution strategies deployed so far will not scale. This memo provides a
offered in this memo is to provide a means to make explicit means to make explicit assertions regarding certain kinds of
assertions regarding the administrative relationships between domain administrative relationships between domain names.
names.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 5, 2014. This Internet-Draft will expire on August 21, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction and Motivation . . . . . . . . . . . . . . . . . 2 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3
2. Prerequisites, Terminology, and Organization of this Memo . . 5 1.1. Organization of This Memo . . . . . . . . . . . . . . . . 3
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Overview of Start Of Policy Authority (SOPA) . . . . . . . . 6 3. Overview of Start Of Policy Authority (SOPA) . . . . . . . . 4
4.1. Identifying a Target Name for Policy 3.1. Identifying a Target Name for Policy
Authority . . . . . . . . . . . . . . . . . . . . . . . . 7 Authority . . . . . . . . . . . . . . . . . . . . . . . . 6
5. The SOPA Resource Record . . . . . . . . . . . . . . . . . . 7 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. The Relation Field . . . . . . . . . . . . . . . . . . . 8 4.1. Where SOPA Works Well . . . . . . . . . . . . . . . . . . 7
5.2. The Target Field . . . . . . . . . . . . . . . . . . . . 8 4.2. Where SOPA Works Less Well . . . . . . . . . . . . . . . 8
6. Expressing Different Policies with the SOPA RRTYPE . . . . . 9 5. The SOPA Resource Record . . . . . . . . . . . . . . . . . . 8
6.1. The Exclusion Relation . . . . . . . . . . . . . . . . . 9 5.1. The Relation Field . . . . . . . . . . . . . . . . . . . 9
6.2. The Inclusion Relation . . . . . . . . . . . . . . . . . 10 5.2. The Target Field . . . . . . . . . . . . . . . . . . . . 9
6.3. Interpreting DNS Responses . . . . . . . . . . . . . . . 10 6. Expressing Different Policies with the SOPA RRTYPE . . . . . 10
6.4. Wildcards in Targets . . . . . . . . . . . . . . . . . . 11 6.1. The Exclusion Relation . . . . . . . . . . . . . . . . . 11
6.5. TTLs and SOPA RRs . . . . . . . . . . . . . . . . . . . . 12 6.2. The Inclusion Relation . . . . . . . . . . . . . . . . . 11
7. What Can be Done With a SOPA RR . . . . . . . . . . . . . . . 12 6.3. Interpreting DNS Responses . . . . . . . . . . . . . . . 12
7.1. Exclusion has Priority . . . . . . . . . . . . . . . . . 12 6.4. Wildcards in Targets . . . . . . . . . . . . . . . . . . 12
8. An Example Case . . . . . . . . . . . . . . . . . . . . . . . 13 6.5. TTLs and SOPA RRs . . . . . . . . . . . . . . . . . . . . 14
7. What Can be Done With a SOPA RR . . . . . . . . . . . . . . . 14
7.1. Exclusion has Priority . . . . . . . . . . . . . . . . . 14
8. An Example Case . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Examples of Using the SOPA Record for Determining 8.1. Examples of Using the SOPA Record for Determining
Boundaries . . . . . . . . . . . . . . . . . . . . . . . 14 Boundaries . . . . . . . . . . . . . . . . . . . . . . . 16
8.1.1. Declaring a Public Suffix . . . . . . . . . . . . . . 14 8.1.1. Declaring a Public Suffix . . . . . . . . . . . . . . 16
8.1.2. One Delegation, Eight Administrative 8.1.2. One Delegation, Eight Administrative
Realms, Wildcard Exclusions . . . . . . . . . . . . . 14 Realms, Wildcard Exclusions . . . . . . . . . . . . . 16
8.1.3. One Delegation, Eight Administrative 8.1.3. One Delegation, Eight Administrative
Realms, Exclusion Wildcards . . . . . . . . . . . . . 15 Realms, Exclusion Wildcards . . . . . . . . . . . . . 17
9. Limitations of the approach and other considerations . . . . 15 9. Limitations of the approach and other considerations . . . . 17
9.1. Handling truncation . . . . . . . . . . . . . . . . . . . 16 9.1. Handling truncation . . . . . . . . . . . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 11. Internationalization Considerations . . . . . . . . . . . . . 19
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
13. Informative References . . . . . . . . . . . . . . . . . . . 17 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
Appendix A. Discussion Venue . . . . . . . . . . . . . . . . . . 19 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
Appendix B. Change History . . . . . . . . . . . . . . . . . . . 19 14.1. Normative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 14.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Discussion Venue . . . . . . . . . . . . . . . . . . 22
Appendix B. Change History . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction and Motivation 1. Introduction and Motivation
Many Internet resources and services, especially at the application Many Internet resources and services, especially at the application
layer, are identified primarily by DNS domain names [RFC1034]. As a layer, are identified primarily by domain names [RFC1034]. As a
result, domain names have become fundamental elements in building result, domain names have become fundamental elements in building
security policies and also in affecting user agent behaviour. For security policies and also in affecting user agent behaviour.
example, domain names are used for defining the scope of HTTP state Discussion of several of these uses, and some of the associated
management "cookies" [RFC6265]. issues can be found in [I-D.sullivan-dbound-problem-statement].
Another example is a user interface convention that purports to Historically, attempts to build the security policies have relied on
display an "actual domain name" differently from other parts of a the public suffix list (see discussion in
fully-qualified domain name, in an effort to decrease the success of [I-D.sullivan-dbound-problem-statement]). We proceed from the view
phishing attacks. In this strategy, for instance, a domain name like that some uses of the public-suffix list never were going to achieve
"www.bank.example.com.attackersite.tld" is formatted to highlight their goal, and that the public/private distinction may be a poor
that the actual domain name ends in "attackersite.tld", in the hope proxy for the kinds of relationships that are actually needed. At
of reducing user's potential impression of visiting the same time, it will be necessary to continue to use something like
"www.bank.example.com". a public suffix list for some important classes of behaviour (both to
achieve acceptable performance characteristics and to deal with
deployed software). Therefore, the proposal below does not attempt
to address all the issues in [I-D.sullivan-dbound-problem-statement],
but offers a way to solve one important class of problems -- the
"orphan type" policies.
Issuers of X.509 certificates make judgements about administrative 1.1. Organization of This Memo
boundaries around domains when issuing the certificates. For some
discussion of the relationship between domain names and X.509
certificates, see [RFC6125].
The simplest policy, and the one most likely to work, is to treat [[CREF1: I find this section awkward here. Ditch it?
each different domain name distinctly. Under this approach, --ajs@anvilwalrusden.com]]
foo.example.org, bar.example.org, and baz.example.org are all just
different domains. Unfortunately, this approach is too naive to be
useful. Often, the real policy control is the same in several names
(in this example, example.org and its children). Therefore, clients
have attempted to make more sophisticated policies around some idea
of such shared control. We call such an area of shared control a
"policy realm", and the control held by the administrator the "policy
authority".
Historically, policies were sometimes based on the DNS tree. Early Necessary terminology is established in Section 2. Section 3
policies made a firm distinction between top-level domains and provides an overview of what the mechanism is supposed to do. Then,
everything else; but this was also too naive, and later attempts were Section 4 discusses the conditions where the technique outlined here
based on inferences from the domain names themselves. That did not may be useful, and notes some cases that the technique is not
work well, because there is no way in the DNS to discover the intended solve. A definition of a new RRTYPE to support the
boundaries of policy control around domain names. technique is in Section 5. There is some discussion of the use of
the RRTYPE in Section 6. Section 7 attempts to show how the
mechanism is generally useful. Then, Section 8 offers an example
portion of a DNS tree in an effort to illustrate how the mechanism
can be useful in certain example scenarios. Section 9 notes some
limitations of the mechanism. Section 10 outlines how the mechanism
might be used securely, and Section 11 addresses the
internationalization consequences of the SOPA record. Finally,
Section 12 includes the requests to IANA for registration.
Some have attempted to use the boundary of zone cuts (i.e. the 2. Terminology
location of the zone's apex, which is at the SOA record; see
[RFC1034] and [RFC1035]). 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
names in that domain. It was also, prior to the 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.
These different issues often appear to be different kinds of The reader is assumed to be familiar with the DNS ([RFC1034]
problems. The issue of whether two names may set cookies for one [RFC1035]) and the Domain Name System Security Extensions (DNSSEC)
another appears to be a different matter from whether two names get ([RFC4033] [RFC4034] [RFC4035] [RFC5155]). A number of DNS terms can
the same highlighting in a browser's address bar, or whether a be found in [RFC7719].
particular name "owns" all the names underneath it. But the problems
all boil down to the same fundamental problem, which is that of
determining whether two different names in the DNS are under the
control of the same entity and ought to be treated as having an
important administrative relationship to one another.
What appears to be needed is a mechanism to determine policy The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
boundaries in the DNS. That is, given two domain names, one needs to "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
be able to answer whether the first and the second are under the same document are to be interpreted as described in [RFC2119].
administrative control and same administrative policies. We may call
this state of affairs "being 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 The terms "policy realm" and "policy authority" are defined in
between names that are mostly used to contain other domains, as [I-D.sullivan-dbound-problem-statement]. For the purposes of
compared to those that are mostly used to operate services. The discussion here, it is important to remember that it is a matter of
former are often "delegation-centric" domains, delegating parts of fact as to whether two domains lie in the same policy realm. The
their name space to others, and are frequently called "public suffix" point of the mechanism here is not to create such facts, but merely
domains or "effective TLDs". The term "public suffix" comes from a to expose them. The terms "inheritance type" and "orphan type" are
site, [publicsuffix.org], that publishes a list of domains -- which also defined in [I-D.sullivan-dbound-problem-statement]. The text
is also known as the "effective TLD (eTLD) list", and henceforth in below attempts to apply the categories when they seem useful.
this specification as 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 3. Overview of Start Of Policy Authority (SOPA)
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 When an application is attempting to make security decisions based on
list, most notably in [I-D.pettersen-subtld-structure]. It is domain names, it needs to answer questions about the relation between
unclear the extent to which those improvements would help, because those names. Suppose that the question to be answered is, "Given any
they represent improvements on the fundamental mechanism of keeping two domain names, do they lie in the same policy realm appropriate
metadata about the DNS tree apart from the DNS tree itself. for a given application?" In order to answer this, there are two
pieces of information needed: first, does the application need an
inheritance or orphan type of policy? Second do the two names lie in
the same policy realm? For orphan types of policy, the best way to
determine whether two names lie in the same policy realm is to look
for assertions about the two domain names. A good place to look for
assertions about domain names is in the DNS.
2. Prerequisites, Terminology, and Organization of this Memo This memo presents a way to assert that two domains lie in the same
policy realm by placing a resource record (RR) at the affected domain
names in the DNS. The mechanism requires a new resource record type
(RRTYPE). It is called SOPA, for "Start Of Policy Authority" and
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 (so it needs to be covered itself). 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.
The reader is assumed to be familiar with the DNS ([RFC1034] The use of SOPA records can do one of two things: it can confirm that
[RFC1035]) and the omain Name System Security Extensions (DNSSEC) two names are in the same policy realm, or it can refute a claim that
([RFC4033] [RFC4034] [RFC4035] [RFC5155]). they are. In order to learn whether a.long.example.com and
b.example.com are in the same policy realm, perform a DNS query for
the SOPA record for a.long.example.com. If the answer's RDATA
contains b.example.com, that is an assertion from the nameservers for
a.long.example.com that it is in the same policy realm as
b.example.com. Next, make a DNS query for the SOPA record for
b.example.com. If the answer's RDATA contains a.long.example.com,
then the two names are in the same policy realm. A positive 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 a.long.example.com provides a target at
b.example.com, there should be a complementary SOPA RR at
b.example.com with a target of a.long.example.com. Because of the
distributed nature of the DNS, and because other DNS administrative
divisions need not be congruent to policy realms, the only way to
know whether two domain names are in the same policy realm is to
query at each domain name, and to correlate the responses. If any of
the forgoing conditions fails, then the two names are not in the same
policy realm.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", [[CREF2: Something that could be useful here is a transitivity bit in
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this the SOPA record. That would allow SOPAs between a.example.com and
document are to be interpreted as described in RFC 2119 [RFC2119]. example.com, and b.example.com and example.com, to mean that
a.example.com and b.example.com are also in the same realm (but you
could shut it off by clearing the bit). I'm leery of this because of
the potential for abuse and also because I doubt it saves very much.
Might be useful for administrative saving, but it won't save lookups.
--ajs@anvilwalrusden.com]]
To begin, Section 3 discusses the cases where this technique might be It is also possible for a SOPA record to contain the explicit
useful. Section 4 describes the mechanism in general terms. A statement that other names do not lie in the same policy authority as
definition of the new RRTYPE is in Section 5. There is some it. This negative assertion permits processing to stop. If the
discussion of the use of the RRTYPE is in Section 6. Section 7 assertion is about all other names, then the capability is
attempts to show how the mechanism can address the use cases in functionally equivalent to declaring a name to be a public suffix.
general terms. Then, Section 8 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 9 notes some limitations of the mechanism. Section 10
outlines how the mechanism might be used securely.
3. Use Cases In operation where latency is an important consideration (such as in
a web browser), it is anticipated that the above correlations could
happen in advance of the user connection (that is, roughly the way
the existing public suffix list is compiled), and then additional
queries could be undertaken opportunistically. This would allow the
detection of changes in operational policy and make maintenance of
the installed list somewhat easier, but not require additional DNS
lookups while a user is waiting for interaction.
While many policies of the sort discussed in
[I-D.sullivan-dbound-problem-statement] appear to be based on domain
names, they are actually often only partly based on them. Often,
there are implicit rules that stem from associated components of
composite names such as URIs [RFC3986], e.g., the destination port
[RFC6335] or URI scheme [RFC4395] (or both). It is possible to make
those assumptions explicit, but at the cost of expressing in the
resulting resource record a tighter relationship between the DNS and
the services offered at domain names. SRV [RFC2782] records offer a
mechanism for expressing such relationships, and a SOPA record in
conjunction with an SRV record appears to provide the necessary
mechanism to express such relationships. (SRV records use underscore
labels, and this is an example of why underscore labels themselves
need to be coverable by SOPA records.)
3.1. Identifying a Target Name for Policy Authority
The RDATA of a SOPA RR contains a "target name" that either lies in
the same policy realm as the owner name of the RR, or that lies
outside of that policy realm. The SOPA record is therefore an
assertion, on the part of the authoritative DNS server for the given
owner name, that there is some policy relationship between the owner
name and the target name. If a given owner 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 a name to have policy relationships with all the
children beneath it. Using the SOPA RR, it is possible to specify
that the policy target is all the names beneath a given owner name,
by using a wildcard target.
4. Use Cases
In the most general sense, this memo presents a mechanism that can be In the most general sense, this memo presents a mechanism that can be
used either as a replacement of the public suffix list used either as a replacement of the public suffix list
[publicsuffix.org], or else as a way to build and maintain such a <publicsuffix.org>, or else as a way to build and maintain such a
list. The mechanism outlined here is explicitly restricted to names list. Performance characteristics may make the mechanism impractical
having ancestor-descendant or sibling relationships, but only as a as a full replacement, in which case a list will likely need to be
practical matter; nothing about the mechanism makes that restriction built and maintained. In the latter case, this mechanism is still
a requirement. preferable because it aligns the policy assertions with the operation
of the domains themselves, and allows maintenance to be distributed
in much the way the operation of the DNS is (instead of being
centralized).
HTTP state management cookies It is worth noting that the mechanism outlined here could be used for
names that are not along the same branch of the DNS tree (i.e. it
could permit the statement that the policy authority of
some.example.com and some.other.example.net is the same). Such uses
are unlikely to work in practice and probably should not be used for
general purposes. Most deployed code implicitly uses ancestor-
descendent relations as part of understanding the policy, and such
code will undoubtedly ignore cross-tree dependencies. [[CREF3: This
relaxes a restriction that was in previous versions, which officially
specified the use only for ancestor-descendent uses. It seems better
to make that a deployment consideration so that the restriction could
be relaxed in some circumstances where it would be appropriate.
--ajs@anvilwalrusden.com]]
The mechanism can be used to determine the scope for data sharing By and large, the mechanism is best suited to "orphan" types of
of HTTP state management cookies [RFC6265]. Using this mechansim, policy. Where inheritance types of policy can use this, it is mostly
it is possible to determine whether a service at one name may be by treating the mechanism as a generator for public suffix
permitted to set a cookie for a service at a different name. boundaries.
(Other protocols use cookies, too, and those approaches could 4.1. Where SOPA Works Well
benefit similarly.)
HTTP state management cookies The mechanism can be used to determine
the scope for data sharing of HTTP state management cookies
[RFC6265]. Using this mechanism, it is possible to determine
whether a service at one name may be permitted to set a cookie for
a service at a different name. (Other protocols use cookies, too,
and those approaches could benefit similarly.) Because handling
of state management cookies often happens during user interaction,
this use case probably requires a cached copy of the relevant
list. In that case, the mechanism can be used to maintain the
list.
User interface indicators User interfaces sometimes attempt to User interface indicators User interfaces sometimes attempt to
indicate the "real" domain name in a given domain name. A common indicate the "real" domain name in a given domain name. A common
use is to highlight the portion of the domain name believed to be use is to highlight the portion of the domain name believed to be
the "real" name -- usually the rightmost three or four labels in a the "real" name -- usually the rightmost three or four labels in a
domain name string. domain name string. This has similar performance needs as HTTP
state management cookies.
Setting the document.domain property The DOM same-origin policy Setting the document.domain property The DOM same-origin policy
might be helped by being able to identify a common policy realm. might be helped by being able to identify a common policy realm.
This case again has a need for speedy determination of the
Email authentication mechanisms Mail authentication mechanisms such appropriate policy and would benefit from a cached list. It is
as DMARC [I-D.kucherawy-dmarc-base] need to be able to find policy likely that the SOPA record on its own is inadequate for this
documents for a given domain name given a subdomain. case, but the combination of SOPA and SRV records might be
helpful.
SSL and TLS certificates Certificate authorities need to be able to SSL and TLS certificates Certificate authorities need to be able to
discover delegation-centric domains in order to avoid issuance of discover delegation-centric domains in order to avoid issuance of
certificates at or above those domains. certificates at or above those domains. More generally, a CA
needs to decide whether, given a request, it should sign a
HSTS and Public Key Pinning with includeSubDomains flag set particular domain. This can be especially tricky in the case of
wildcards.
Linking domains together for reporting purposes
4. Overview of Start Of Policy Authority (SOPA)
This memo presents a way to assert that two domains lie in the same
policy realm by placing a resource record (RR) at the domain names.
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 often only partly based on
them. Often, there are implicit rules that stem from associated
components of composite names such as URIs [RFC3986], e.g., the
destination port [RFC6335] or URI scheme [RFC4395] (or both). It is
possible to make those assumptions explicit, but at the cost of
expressing in the resulting resource record a tighter relationship
between the DNS and the services offered at domain names. SRV
[RFC2782] records offer a mechanism for expressing such HSTS and Public Key Pinning with includeSubDomains flag
relationships, and a SOPA record in conjunction with an SRV record set
appears to provide the necessary mechanism to express such Clients that are using HSTS and public key pinning using
relationships. (SRV records use underscore labels, and this is an includeSubDomains need to be able to determine whether a subdomain
example of why underscore labels themselves need to be available for is properly within the policy realm of the parent. An application
SOPA records.) performing this operation must answer the question, "Should I
accept the rules for using X as valid for Y.X?" This use case
sounds like an inheritance type, but it is in fact an orphan type.
It is worth observing that a positive policy realm relationship ought Linking domains together for reporting purposes It can
to be symmetric: if example.com is in the same policy realm as be useful when preparing reports to be able to count different
example.net, then example.net should be (it would seem) in the same domains as "the same thing". This is an example where special use
policy realm as example.com. In principle, then, if a SOPA RR at of SOPA even across the DNS tree could be helpful.
a.example.com provides a target at b.example.com, there should be a
complementary SOPA RR at b.example.com with a target of
a.example.com. Because of the distributed nature of the DNS, and
because other DNS administrative divisions need not be congruent to
policy realms, the only way to know whether two domain names are in
the same policy realm is to query at each domain name, and to
correlate the responses.
4.1. Identifying a Target Name for Policy Authority 4.2. Where SOPA Works Less Well
The RDATA of a SOPA RR contains a "target name", lying either in the Email authentication mechanisms Mail authentication mechanisms such
same policy realm as the owner name of the RR, that lies outside of as DMARC [RFC7489] need to be able to find policy documents for a
that policy realm. The SOPA record is therefore an assertion, on the domain name given a subdomain. This use case is an inheritance
part of the authoritative DNS server for the given owner name, that type. Because the point of mechanisms like DMARC is to prevent
there is some policy relationship between the owner name and the abuse, it is not possible to rely on the candidate owner name to
target name. If a given target name lies in the same policy realm as report accurately its policy relationships. But some ancestor is
several other target names, an additional RR is necessary for each possibly willing to make assertions about the policy under which
such relationship, with one exception. It is not uncommon for two that ancestor permits names in the name space. This sort of case
different names to have policy relationships among all the children can only use SOPA indirectly, via a static list that is composed
beneath them. Using the SOPA RR, it is possible to specify that the over time by SOPA queries. Other mechanisms will likely better
policy target is all the names beneath a given owner name, by using a satisfy this need.
wildcard target.
5. The SOPA Resource Record 5. The SOPA Resource Record
The SOPA resource record, type number [TBD1], contains two fields in The SOPA resource record, type number [TBD1], contains two fields in
its RDATA: its RDATA:
Relation: A one-octet field used to indicate the relationship Relation: A one-octet field used to indicate the relationship
between the owner name and the target. between the owner name and the target.
Target: A field used to contain a domain name, relative to the Target: A field used to contain a fully-qualified domain name
root, that is in some relationship with the owner name. that is in some relationship with the owner name. This
field is a maximum of 255 octets long, to match the
possible length of a fully-qualified domain name.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Relation | / | Relation | /
+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+ /
/ Target / / Target /
/ / / /
/ / / /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 26 skipping to change at page 9, line 14
5.1. The Relation Field 5.1. The Relation Field
The relation field is REQUIRED and contains an indicator of the The relation field is REQUIRED and contains an indicator of the
relationship between the owner name and the target name. This memo relationship between the owner name and the target name. This memo
specifies two possible values: specifies two possible values:
+-------+----------+------------------------------------------------+ +-------+----------+------------------------------------------------+
| Value | Setting | Meaning | | Value | Setting | Meaning |
+-------+----------+------------------------------------------------+ +-------+----------+------------------------------------------------+
| 1 | Excluded | The target is not in the same policy realm as | | 0 | Excluded | The target is not in the same policy realm as |
| | | the owner name | | | | the owner name |
| 2 | Included | The target is in the same policy realm as the | | 1 | Included | The target is in the same policy realm as the |
| | | owner name | | | | owner name |
+-------+----------+------------------------------------------------+ +-------+----------+------------------------------------------------+
Table 1 Table 1
Additional values may be defined in future, according to the rules
set out in Section 12.
5.2. The Target Field 5.2. The Target Field
The target field contains a (fully-qualified) domain name, and is The target field contains a fully-qualified domain name, and is
REQUIRED to be populated. The name MUST be a domain name according REQUIRED to be populated. The name MUST be a domain name according
to the rules in [RFC1034] and [RFC1035], except that the left-most to the rules in [RFC1034] and [RFC1035], except that the any label of
label of the target MAY be the wildcard character ("*"). The target the target MAY be the wildcard character ("*"; further discussion of
MUST be sent in uncompressed form [RFC1035] [RFC3597]. The target wildcards is in Section 6.4). The target MUST be sent in
MUST NOT be an alias [RFC2181], such as the owner name of a CNAME RR uncompressed form [RFC1035], [RFC3597]. The target MUST NOT be an
[RFC1034], DNAME RR [RFC6672], or other similar such resource alias [RFC2181], such as the owner name of a CNAME RR [RFC1034],
records. DNAME RR [RFC6672], or other similar such resource records. Note
that this is a fully-qualified domain name, so the trailing null
label is required. [[CREF4: This is a change from previous versions;
previously, the target was a root-relative domain name. So it's now
example.com. and used to be example.com (no trailing dot) when in
presentation format. The new form makes this a domain name, whereas
before it could really have been a text field. Not sure which is
better. --ajs@anvilwalrusden.com]]
The target name MUST be either an ancestor, a descendent, or a The target name SHOULD be either an ancestor, a descendent, or a
sibling of the owner name in the record. This requirement is sibling of the owner name in the record. This requirement is
intended to limit the applicability of the SOPA RR to names in the intended to limit the applicability of the SOPA RR to names in the
same DNS hierarchy, thereby avoiding possible negative side effects same DNS hierarchy, thereby avoiding possible negative side effects
of unbounded linkages across disparate DNS subtrees, including those of unbounded linkages across disparate DNS subtrees, including those
subtrees rooted close to, or immediately below, the DNS root. subtrees rooted close to, or immediately below, the DNS root. In
special uses, however, it may be desirable to link across the DNS
tree. General-purpose clients MAY ignore target names that are
neither an ancestor, nor a descendent, nor a sibling of the owner
name in the record (and abort processing) in order to avoid the
aforementioned negative side-effects.
Targets MAY contain any series of octets, in order to accommodate
labels other than LDH labels [RFC6365]. No processing of labels
prior to matching targets is to be expected, however, and therefore
internationalized domain name targets use whatever form they appear
in the DNS. In particular, IDNA labels [RFC5890], [RFC5891],
[RFC5892], [RFC5893], [RFC5894] SHOULD appear in A-label form. A
SOPA-using client that receives a target containing octets outside
LDH MUST NOT treat the affected labels as U-labels, because there is
no way to discover whether the affected label is encoded as UTF-8 or
something else.
6. Expressing Different Policies with the SOPA RRTYPE 6. Expressing Different Policies with the SOPA RRTYPE
A SOPA RR has one of three different functions. The first is to A SOPA RR has one of three different functions. The first is to
claim that two domain names are not in the same policy realm claim that two domain names are not in the same policy realm
("exclusion"). The second is to claim that two domain names are in ("exclusion"). The second is to claim that two domain names are in
the same policy realm ("inclusion"). In both of these cases, it is the same policy realm ("inclusion"). In both of these cases, it is
possible to make the assertion over groups of DNS names. possible to make the assertion over groups of DNS names.
The third function describes a portion of the tree that would be The third function describes a portion of the tree that would be
covered by targets containing a wildcard, but where the policy is the covered by targets containing a wildcard, but where the policy is the
opposite of that expressed with the wildcard. This is expressed opposite of that expressed with the wildcard. This is expressed
simply by including the relevant specific exception. For example, simply by including the relevant specific exception. For example,
all the subdomains under example.com could be indicated in a target all the subdomains under example.com could be indicated in a target
"*.example.com". To express a different policy for "*.example.com". To express a different policy for
exception.example.com than for the rest of the names under exception.example.com than for the rest of the names under
example.com requires two SOPA RRs, one with the target example.com requires two SOPA RRs, one with the target
"*.example.com" and he other with the target "exception.example.com". "*.example.com" and the other with the target
The most-specific match to a target always wins. "exception.example.com". The most-specific match to a target always
wins.
Is is important to note that any given fully-qualified domain name Is is important to note that the default setting is "exclusion". A
does not lie in any given other name's policy realm unless there is domain name does not lie in any other name's policy realm unless
an explicit statement by appropriate SOPA resource record(s) to the there is an explicit statement by appropriate SOPA resource record(s)
contrary. If a candidate target name does not appear in the target to the contrary. If a candidate name does not appear in the target
of any SOPA record for some owner name, then that candidate target of any SOPA record for some owner name, then that candidate target
does not lie in the same policy realm as that owner name. does not lie in the same policy realm as that owner name.
It is acceptable for there to be more than one SOPA resource record It is acceptable for there to be more than one SOPA resource record
per owner name in a response. Each domain name, in the RDATA of each per owner name in a response. Each RR in the returned RRset is
returned SOPA record, is treated as a separate policy statement about treated as a separate policy statement about the original queried
the original QNAME (query name). Note, however, that the QNAME from name (QNAME). Note, however, that the QNAME might not be the owner
the query might not be the owner name of the SOPA RR: if the original name of the SOPA RR: if the QNAME is an alias, then the actual SOPA
QNAME was an alias, then the actual SOPA owner name in the DNS owner name in the DNS database will be different than the QNAME. In
database will be different. In other words, even though a SOPA other words, even though a SOPA target field is not allowed to be an
target name is not allowed to be an an alias, statements about an an alias, when resolving the SOPA RR aliases are followed; and SOPA
alias are followed and are accepted transitively from the alias to records are accepted transitively from the canonical name back to the
the canonical name. QNAME.
6.1. The Exclusion Relation 6.1. The Exclusion Relation
A SOPA record with a relation field with value 1 states that the A SOPA record where the relation field has value 0 states that the
owner name and the target name are not in the same policy realm. owner name and the target name are not in the same policy realm.
While this would seem not to be obviously useful (given that positive While this might seem useless (given the default of exclude), a SOPA
declarations are required for two names to be in the same policy record with a relation field value of 0 can be useful in combination
realm), a SOPA record with a relation field value of 1 can be useful with a long TTL field, in order to ensure long term caching of the
in combination with a long TTL field, in order to ensure long term policy.
caching of the policy.
In addition, an important function of SOPA is to enable the explicit In addition, an important function of SOPA is to enable the explicit
assertion that no other name lies in the same policy realm as the assertion that no other name lies in the same policy realm as the
owner name (or, what is equivalent, that the owner name should be owner name (or, what is equivalent, that the owner name should be
treated as a public suffix). In order to achieve this, the operator treated as a public suffix). In order to achieve this, the operator
of the zone may use a wildcard target together with a relation field of the zone may use a wildcard target together with a relation field
value of 1. See Section 6.4. value of 0. See Section 6.4.
In addition, an exclusion relation can be used to override a more In addition, an more-specific target can be used to override a more
general inclusion relation (i.e. with a wildcard in the target) at general target (i.e. with a wildcard in the target) at the same owner
the same owner name. For example, name. For example,
example.tld 86400 IN SOPA 2 *.example.tld example.tld 86400 IN SOPA 0 *.example.tld
www.example.tld 86400 IN SOPA 1 example.tld example.tld 86400 IN SOPA 1 www.example.tld
A SOPA-using client that receives a SOPA resouce record with a A SOPA-using client that receives a SOPA resource record with a
relation value of 1 MUST treat the owner name and the target name as relation value of 0 MUST treat the owner name and the target name as
lying in different policy realms. lying in different policy realms.
6.2. The Inclusion Relation 6.2. The Inclusion Relation
A SOPA record with a relation field set to 2 is an indicator that the A SOPA record with a relation field set to 1 is an indicator that the
target name lies in the same policy realm as the owner name. In target name lies in the same policy realm as the owner name. In
order to limit the scope of security implications, the target name order to limit the scope of security implications, the target name
and the owner name MUST stand in some ancestor-decendant or sibling and the owner name SHOULD stand in some ancestor-descendant or
relationship to one another. sibling relationship to one another. A SOPA-using client that is not
prepared for inclusion relationships outside the same branch of the
DNS MAY ignore such relationships and treat them as though they did
not exist.
The left-most label of a target may be a wildcard record, in order to The left-most label of a target may be a wildcard record, in order to
indicate that all descendant or sibling names lie in the same policy indicate that all descendant or sibling names lie in the same policy
realm as the owner name. See Section 6.4. realm as the owner name. See Section 6.4.
A SOPA-using client that receives a SOPA resouce record where A SOPA-using client that receives a SOPA resource record where
relation is set to 2 SHOULD treat the owner name and the target name relation is set to 1 SHOULD treat the owner name and the target name
as lying in the same policy realm. If a client does not, it is as lying in the same policy realm. If a client does not, it is
likely to experience unexpected failures because the client's policy likely to experience unexpected failures because the client's policy
expectations are not aligned with those of the service operator. expectations are not aligned with those of the service operator.
6.3. Interpreting DNS Responses 6.3. Interpreting DNS Responses
There are three possible responses to a query for the SOPA RRTYPE at 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 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, 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 the owner name itself does not exist, and no further processing is
needed. needed.
The second is a No Data response [RFC2308] of any type. The No Data 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 response means that the owner name in the QNAME does not recognize
any other name as part of a common policy realm. That is, a No Data any other name as part of a common policy realm. That is, a No Data
response is to be interpreted as though there were a SOPA resource response is to be interpreted as though there were a SOPA resource
record with relation value 1 and a wildcard target. The TTL on the record with relation value 0 and a wildcard target. The TTL on the
policy in this case is the negative TTL from the SOA record, in case policy in this case is the negative TTL from the SOA record, in case
it is available. it is available.
The final is a response with one or more SOPA resource records in the The final is a response with one or more SOPA resource records in the
Answer section. Each SOPA resource record asserts a relationship Answer section. Each SOPA resource record asserts a relationship
between the owner name and the target name, according to the between the owner name and the target name, according to the
functions of the SOPA RRTYPE outlined above. functions of the SOPA RRTYPE outlined above.
Any other response is no different from any other sort of response Any other response is no different from any other sort of response
from the DNS, and is not in itself meaningful for determining the 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 policy realm of a name (though it might be meaningful for finding the
SOPA record). SOPA record).
6.4. Wildcards in Targets 6.4. Wildcards in Targets
The special character "*" in the target field is used to match any 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 label, but not according to the wildcard label rules in section 4.3.3
[RFC1034]. Note that, because of the way wildcards work in the DNS, of [RFC1034]. Note that, because of the way wildcards work in the
is it not possible to place a restriction to the left of a wildcard; DNS, is it not possible to place a restriction to the left of a
so, for instance, example.*.example.com does not work. The effect is wildcard; so, for instance, example.*.example.com. does not work. In
maintained in this memo. An authoritative name server SHOULD NOT a SOPA target, it is possible to place such a restriction. In such
serve a SOPA RR with erroneous wildcards when it is possible to use, a wildcard label matches exactly one label:
suppress them, and clients receiving such a SOPA RR MUST discard the example.*.example.com. matches the target example.foo.example.com.
RR. If the discarded RR is the last RR in the answer section of the and example.bar.example.com., but not example.foo.bar.example.com.
response, then the response is treated as a No Data response. To match the latter, it would be necessary also to include
example.*.*.example.com, which is also permitted in a target. This
use of the wildcard is consistent with the use in
<https://publicsuffix.org/list/>.
If a SOPA target's first label is a wildcard label, the wildcard then
matches any number of labels. Therefore, a target of *.example.com.
matches both onelabel.example.com. and two.labels.example.com.; the
second match would not be a match in the DNS. This use of the
wildcard label does not match the public suffix list, but is included
for brevity of RRsets for certain presumed-common cases. This rule
is subject to more-specific matching (as discussed in Section 6.1 and
Section 6.2). To simplify implementation, more-specific matches
cannot have internal wildcards as described above.
The reason for these differences in wildcard-character handling is
because of the purpose of the wildcard character. In DNS matching,
processing happens label by label proceeding down the tree, and the
goal is to find a match. But in the case of SOPA, the candidate
match is presumed available, because the application would not
perform a SOPA look up if there were not a different target domain at
hand. Therefore, strict conformance with the DNS semantics of the
wildcard is not necessary. It is useful to be able to express
potential matches as briefly as possible, to keep DNS response sizes
small.
Multiple leading wildcard labels (e.g. *.*.example.com.) is an error.
An authoritative name server SHOULD NOT serve a SOPA RR with
erroneous wildcards when it is possible to suppress them, and clients
receiving such a 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.
It is possible for the wildcard label to be the only label in the It is possible for the wildcard label to be the only label in the
target name. In this case, the target is "every name". This makes target name. In this case, the target is "every name". This makes
it trivial for an owner name to assert that there are no other names it trivial for an owner name to assert that there are no other names
in its policy realm. in its policy realm.
Because it would be absurd for there to be more than one SOPA RR with Because it would be absurd for there to be more than one SOPA RR with
the same wildcard target in a SOPA RRset, a server encountering more the same target (including wildcard target) in a SOPA RRset, a server
than one such wildcard target SHOULD only serve the RR for the encountering more than one such target SHOULD only serve the RR for
exclusion relation, discarding others when possible. Discarding the exclusion relation, discarding others when possible. Discarding
other RRs in the RRset is not possible when serving a signed RRset. other RRs in the RRset is not possible when serving a signed RRset.
A client receiving multiple wildcard targets in the RRset MUST use A client receiving multiple wildcard targets in the RRset MUST use
only the RR with relation set to 1. only the RR with relation set to 0.
When a SOPA RR with a wildcard target appears in the same RRset as a As already noted, when a SOPA RR with a wildcard target appears in
SOPA RR with a target that would be covered by the wildcard, the the same RRset as a SOPA RR with a target that would be covered by
specific (non-wildcard) RR expresses the policy for that specific the wildcard, the specific (non-wildcard) RR expresses the policy for
owner name/target pair. This way, exceptions to a generic policy can that specific owner name/target pair. This way, exceptions to a
be expressed. generic policy can be expressed.
6.5. TTLs and SOPA RRs 6.5. TTLs and SOPA RRs
The TTL field in the DNS is used to indicate the period (in seconds) The TTL field in the DNS is used to indicate the period (in seconds)
during which an RRset may be cached after first encountering it (see during which an RRset may be cached after first encountering it (see
[RFC1034]). As is noted in Section 3, however, SOPA RRs could be [RFC1034]). As is noted in Section 4, however, SOPA RRs could be
used to build something like the public suffix list, and that list used to build something like the public suffix list, and that list
would later be used by clients that might not themselves have access would later be used by clients that might not themselves have access
to SOPA DNS RRsets. In order to support that use as reliably as to SOPA DNS RRsets. In order to support that use as reliably as
possible, a SOPA RR MAY continue to be used even after the TTL on the possible, a SOPA RR MAY continue to be used even after the TTL on the
RRset has passed, until the next time that a SOPA RRset from the DNS RRset has passed, until the next time that a SOPA RRset from the DNS
for the owner name (or a No Data response) is available. It is for the owner name (or a No Data response) is available. It is
preferable to fetch the more-current data in the DNS, and therefore preferable to fetch the more-current data in the DNS, and therefore
if such DNS responses are available, a SOPA-aware client SHOULD use if such DNS responses are available, a SOPA-aware client SHOULD use
them. Note that the extension of the TTL when DNS records are not them. Note that the extension of the TTL when DNS records are not
available does not extend to the use of the negative TTL field from available does not extend to the use of the negative TTL field from
No Data responses. No Data responses.
7. What Can be Done With a SOPA RR 7. What Can be Done With a SOPA RR
Use of a SOPA RR enables a site administrator to assert or deny Use of a SOPA RR enables a site administrator to assert or deny
relationships between names. By the same token, it permits a a relationships between names. By the same token, it permits a a
consuming client to detect these assertions and denials. consuming client to detect these assertions and denials.
The use of SOPA RRs could either replace the public suffix list or The use of SOPA RRs could either replace the public suffix list or
(more likely due to some limitations -- see Section 9) simplify and (often more likely due to some limitations -- see Section 9) simplify
automate the management of the public suffix list. A client could and automate the management of the public suffix list. A client
use the responses to SOPA queries to refine its determinations about could use the responses to SOPA queries to refine its determinations
http cookie Domain attributes. In the absence of SOPA RRs at both about http cookie Domain attributes. In the absence of SOPA RRs at
owner names, a client might treat a Domain attribute as though it both owner names, a client might treat a Domain attribute as though
were omitted. More generally, SOPA RRs would permit additional steps it were omitted. More generally, SOPA RRs would permit additional
similar to steps 4 and 5 in [RFC6265]. steps similar to steps 4 and 5 in [RFC6265].
SOPA RRs might be valuable for certificate authorities when issuing SOPA RRs might be valuable for certificate authorities when issuing
certificates, because it would allow them to check whether two names certificates, because it would allow them to check whether two names
are related in the way the party requesting the certificate claims are related in the way the party requesting the certificate claims
they are. they are.
7.1. Exclusion has Priority 7.1. Exclusion has Priority
In order to minimize the chance of policy associations where none In order to minimize the chance of policy associations where none
exist, this memo always assumes exclusion unless there is an explicit exist, this memo always assumes exclusion unless there is an explicit
skipping to change at page 14, line 23 skipping to change at page 16, line 23
the example tree in Section 8, above. The examples are not the example tree in Section 8, above. The examples are not
exhaustive, but may provide an indication of what might be done with exhaustive, but may provide an indication of what might be done with
the mechanism. the mechanism.
8.1.1. Declaring a Public Suffix 8.1.1. Declaring a Public Suffix
Perhaps the most important function of the SOPA RR is to identify Perhaps the most important function of the SOPA RR is to identify
public suffixes. In this example, the operator of TLD publishes a public suffixes. In this example, the operator of TLD publishes a
single SOPA record: single SOPA record:
tld. 86400 IN SOPA 1 * tld. 86400 IN SOPA 0 *.
8.1.2. One Delegation, Eight Administrative Realms, Wildcard Exclusions 8.1.2. One Delegation, Eight Administrative Realms, Wildcard Exclusions
In this scenario, the example portion of the domain name space In this scenario, the example portion of the domain name space
contains all and only the following SOPA records: contains all and only the following SOPA records:
example.tld. 86400 IN SOPA 2 www.example.tld example.tld. 86400 IN SOPA 1 www.example.tld.
www.example.tld. 86400 IN SOPA 2 example.tld www.example.tld. 86400 IN SOPA 1 example.tld.
Tld is the top-level domain, and has delegated example.tld. The Tld is the top-level domain, and has delegated example.tld. The
operator of example.tld makes no delegations. There are four operator of example.tld makes no delegations. There are four
operators involved: the operator of tld; OperatorV; Operator1, the operators involved: the operator of tld; OperatorV; Operator1, the
operator of the services at cust1.example.tld and operator of the services at cust1.example.tld and
cust1.test.example.tld; and Operator2, the operator of the services cust1.test.example.tld; and Operator2, the operator of the services
at cust2.example.tld and cust2.test.example.tld. at cust2.example.tld and cust2.test.example.tld.
In this arrangement, example.tld and www.example.tld positively claim In this arrangement, example.tld and www.example.tld positively claim
to be within the same policy realm. Every other name stands alone. to be within the same policy realm. Every other name stands alone.
skipping to change at page 15, line 13 skipping to change at page 17, line 13
account.example.tld, cust1.example.tld, and cust2.example.tld. account.example.tld, cust1.example.tld, and cust2.example.tld.
8.1.3. One Delegation, Eight Administrative Realms, Exclusion Wildcards 8.1.3. One Delegation, Eight Administrative Realms, Exclusion Wildcards
This example mostly works the same way as the one in This example mostly works the same way as the one in
Section Section 8.1.2, but there is a slight difference. In this Section Section 8.1.2, but there is a slight difference. In this
case, in addition to the records listed in Section 8.1.2, both tld case, in addition to the records listed in Section 8.1.2, both tld
and test.example.tld publish exclusion of all names in their SOPA and test.example.tld publish exclusion of all names in their SOPA
records: records:
tld. 86400 IN SOPA 1 * tld. 86400 IN SOPA 0 *.
test.example.tld. 86400 IN SOPA 1 * test.example.tld. 86400 IN SOPA 0 *.
The practical effect of this is largely the same as the previous The practical effect of this is largely the same as the previous
example, except that these expressions of policy last (at least) example, except that these expressions of policy last (at least)
86,400 seconds instead of the length of time on the negative TTL in 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 the relevant SOA for the zone. Many zones have short negative TTLs
because of expectations that newly-added records will show up because of expectations that newly-added records will show up
quickly. This mechanism permits such names to express their quickly. This mechanism permits such names to express their
administrative isolation for predictable minimum periods of time. administrative isolation for predictable minimum periods of time. In
Moreover, because clients are permitted to retain these records addition, because clients are permitted to retain these records
during periods when DNS service is not available, a client could go during periods when DNS service is not available, a client could go
offline for several weeks, and return to service with the presumption 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 that test.example.tld is still not in any policy realm with any other
name. name.
9. Limitations of the approach and other considerations 9. Limitations of the approach and other considerations
There are four significant problems with this proposal, all of which There are four significant problems with this proposal, all of which
are related to using DNS to deliver the data. are related to using DNS to deliver the data.
skipping to change at page 17, line 5 skipping to change at page 19, line 5
such assertions are accepted without checking that both sides agree such assertions are accepted without checking that both sides agree
to the assertion, it would be possible for one site to become an 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 illegitimate source for data to be consumed in some other site. In
general, assertions about another name should never be accepted general, assertions about another name should never be accepted
without querying the other name for agreement. without querying the other name for agreement.
Undertaking any of the inferences suggested in this draft without the Undertaking any of the inferences suggested in this draft without the
use of the DNS Security Extensions exposes the user to the use of the DNS Security Extensions exposes the user to the
possibility of forged DNS responses. possibility of forged DNS responses.
11. IANA Considerations 11. Internationalization Considerations
There is some discussion of how to treat targets that appear to have
internationalized data in Section 5.2. Otherwise, this memo raises
no internationalization considerations.
12. IANA Considerations
IANA will be requested to register the SOPA RRTYPE if this proceeds. IANA will be requested to register the SOPA RRTYPE if this proceeds.
12. Acknowledgements IANA will be requested to create a SOPA relation registry if this
proceeds. The initial values are to be found in the table in
Section 5.1. Registration rules should require a high bar, because
it's a one-octet field. Maybe RFC required?
13. Acknowledgements
The authors thank Adam Barth, Dave Crocker, Brian Dickson, Phillip The authors thank Adam Barth, Dave Crocker, Brian Dickson, Phillip
Hallam-Baker, John Klensin, Murray Kucherawy, John Levine, Gervase Hallam-Baker, John Klensin, Murray Kucherawy, John Levine, Gervase
Markham, Patrick McManus, Henrik Nordstrom, Yngve N. Pettersen, Eric Markham, Patrick McManus, Henrik Nordstrom, Yngve N. Pettersen, Eric
Rescorla, Thomas Roessler, Peter Saint-Andre, and Maciej Stachowiak Rescorla, Thomas Roessler, Peter Saint-Andre, and Maciej Stachowiak
for helpful comments. for helpful comments.
13. Informative References 14. References
[I-D.kucherawy-dmarc-base] 14.1. Normative References
Kucherawy, M., "Domain-based Message Authentication,
Reporting and Conformance (DMARC)", draft-kucherawy-dmarc-
base-00 (work in progress), March 2013.
[I-D.pettersen-subtld-structure] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Pettersen, Y., "The Public Suffix Structure file format Requirement Levels", BCP 14, RFC 2119,
and its use for Cookie domain validation", draft- DOI 10.17487/RFC2119, March 1997,
pettersen-subtld-structure-09 (work in progress), March <http://www.rfc-editor.org/info/rfc2119>.
2012.
14.2. Informative References
[I-D.sullivan-dbound-problem-statement]
Sullivan, A., Hodges, J., and J. Levine, "DBOUND: DNS
Administrative Boundaries Problem Statement", draft-
sullivan-dbound-problem-statement-01 (work in progress),
July 2015.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997. Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
<http://www.rfc-editor.org/info/rfc2181>.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, March 1998. NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
<http://www.rfc-editor.org/info/rfc2308>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. DOI 10.17487/RFC2782, February 2000,
<http://www.rfc-editor.org/info/rfc2782>.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, September 2003. (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September
2003, <http://www.rfc-editor.org/info/rfc3597>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66,
3986, January 2005. RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC Rose, "DNS Security Introduction and Requirements",
4033, March 2005. RFC 4033, DOI 10.17487/RFC4033, March 2005,
<http://www.rfc-editor.org/info/rfc4033>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005. RFC 4034, DOI 10.17487/RFC4034, March 2005,
<http://www.rfc-editor.org/info/rfc4034>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005. Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<http://www.rfc-editor.org/info/rfc4035>.
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 35, RFC Registration Procedures for New URI Schemes", RFC 4395,
4395, February 2006. DOI 10.17487/RFC4395, February 2006,
<http://www.rfc-editor.org/info/rfc4395>.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, March 2008. Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
<http://www.rfc-editor.org/info/rfc5155>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC5890] Klensin, J., "Internationalized Domain Names for
Verification of Domain-Based Application Service Identity Applications (IDNA): Definitions and Document Framework",
within Internet Public Key Infrastructure Using X.509 RFC 5890, DOI 10.17487/RFC5890, August 2010,
(PKIX) Certificates in the Context of Transport Layer <http://www.rfc-editor.org/info/rfc5890>.
Security (TLS)", RFC 6125, March 2011.
[RFC5891] Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", RFC 5891,
DOI 10.17487/RFC5891, August 2010,
<http://www.rfc-editor.org/info/rfc5891>.
[RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and
Internationalized Domain Names for Applications (IDNA)",
RFC 5892, DOI 10.17487/RFC5892, August 2010,
<http://www.rfc-editor.org/info/rfc5892>.
[RFC5893] Alvestrand, H., Ed. and C. Karp, "Right-to-Left Scripts
for Internationalized Domain Names for Applications
(IDNA)", RFC 5893, DOI 10.17487/RFC5893, August 2010,
<http://www.rfc-editor.org/info/rfc5893>.
[RFC5894] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Background, Explanation, and
Rationale", RFC 5894, DOI 10.17487/RFC5894, August 2010,
<http://www.rfc-editor.org/info/rfc5894>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011. DOI 10.17487/RFC6265, April 2011,
<http://www.rfc-editor.org/info/rfc6265>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA) Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165, RFC Transport Protocol Port Number Registry", BCP 165,
6335, August 2011. RFC 6335, DOI 10.17487/RFC6335, August 2011,
<http://www.rfc-editor.org/info/rfc6335>.
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in
Internationalization in the IETF", BCP 166, RFC 6365,
DOI 10.17487/RFC6365, September 2011,
<http://www.rfc-editor.org/info/rfc6365>.
[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
DNS", RFC 6672, June 2012. DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012,
<http://www.rfc-editor.org/info/rfc6672>.
[publicsuffix.org] [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Mozilla Foundation, "Public Suffix List", also known as: Message Authentication, Reporting, and Conformance
Effective TLD (eTLD) List, . (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<http://www.rfc-editor.org/info/rfc7489>.
[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", RFC 7719, DOI 10.17487/RFC7719, December
2015, <http://www.rfc-editor.org/info/rfc7719>.
Appendix A. Discussion Venue Appendix A. Discussion Venue
This Internet-Draft is discussed on the applications area working This Internet-Draft is discussed in the dbound working group:
group mailing list: apps-discuss@ietf.org. dbound@ietf.org.
Appendix B. Change History Appendix B. Change History
00 to 01: 00 to 01:
* Changed the mnemonic from BOUND to AREALM * Changed the mnemonic from BOUND to AREALM
* Added ports and scheme to the RRTYPE * Added ports and scheme to the RRTYPE
* Added some motivating text and suggestions about what can be * Added some motivating text and suggestions about what can be
skipping to change at page 20, line 21 skipping to change at page 23, line 31
* Renamed file to get rid of "origin", which caused confusion. * Renamed file to get rid of "origin", which caused confusion.
* Added Jeff as co-author * Added Jeff as co-author
* Remove exception relation; instead, more than one RR is * Remove exception relation; instead, more than one RR is
allowed. allowed.
* Added discussion of SRV records * Added discussion of SRV records
00 to 01:
* Failed to include change control entry
* Modest rearrangement of text, little improvement
01 to 02:
* Significant rearrangement of sections
* Large removal of text (moved to problem statement document)
* Considerably more detail in specification, including more
rigorous description of RRTYPE
* Altered handling of wildcard targets
* Attempt to improve overview to make it plainer what the system
does
* Clarify what use cases really work
* Reversion to permit cross-tree use, with deployment warnings
that it won't be useful
Authors' Addresses Authors' Addresses
Andrew Sullivan Andrew Sullivan
Dyn, Inc. Dyn, Inc.
150 Dow St 150 Dow St
Manchester, NH 03101 Manchester, NH 03101
U.S.A. U.S.A.
Email: asullivan@dyn.com Email: asullivan@dyn.com
 End of changes. 96 change blocks. 
361 lines changed or deleted 541 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/