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