Asserting Administrative Boundaries of Origin Using DNS Zones

Many network resources are accessed primarily by name. DNS names make up a fundamental part of the name by which people or other systems access those network resources. As a result, DNS names have become fundamental elements in building security policies and user agent behaviour. Some such policies attempt to determine the scope for data sharing of things like HTTP state management cookies and cross-document information sharing in ECMAScript DOM. The idea is to foil the attempts of attackers in (for example) attackersite.co.tld from setting cookies for everyone in co.tld. Another use of the policy is a user interface convention that attempts 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", thereby hopefully reducing the user's impression that the user is visiting "www.bank.example.com". 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, these policies were based on the DNS names themselves. Early policies (for instance, in the earliest HTTP cookie specifications) just made a 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 and SOA record; see and ). Unfortunately, that boundary is neither necessary nor sufficient for these purposes: it is possible for a large site to have many, completely 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 advent of DNSSEC, difficult to find zone cuts. 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. The term "public suffix" comes from a site, publicsuffix.org, which publishes a list of domains 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 this service is to make the distinction between names that must never be treated as being in the same adminsitrative boundary, and those that may be so treated. 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, such as the empty non-terminal name. 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.

The reader is assumed to be familiar with the DNS ( ) and DNSSEC ( ).

The basic mechanism uses resource records in the DNS to provide names through which the administrative boundary extends. The resource record is called OADMINB (for Origin ADMINistrative Boundary), RRTYPE TBD. This could as easily be a NAPTR or friends record with underscore conventions on the name, except that then I don't see how to make it extend well to underscore names themselves. Ideas? The OADMINB resource record contains in its RDATA either one fully-qualified domain name, or one domain name where the leftmost label is the wildcard label, or the special label "_". Should this be a set of labels? There may be more than one OADMINB resource record per name in the response. Each domain name in the RDATA is treated as though it is able to assert cookie (and similar) policy on behalf of the owner name in the original QNAME. There are four possible responses to a query for the OADMINB RRTYPE at an owner name. The first is Name Error (RCODE=3, also known as NXDOMAIN). In this case, the name itself does not exist, and no further processing is needed. The second is an empty Answer section, and an SOA record in the Authority section where the owner name of the SOA is not the same as the QNAME of the target name. In this case, there is no OADMINB record at that owner name, and also the owner name is not the apex of the zone. This means that the name itself does not include any other name in its administrative boundary, regardless of what is asserted at other names (including the parent name). The third is an empty Answer section, and an SOA record in the Authority section where the owner name of the SOA is the same as the QNAME in the original query (or an alias of that name, such as the target of a CNAME or a DNAME). In this case, the QNAME in the original query (or its alias) is also the apex of a zone, and the empty Answer means that the parent zone of all the zones beneath does not recognize the child zones as part of a common administrative boundary; neither does it recognize any other zone as part of that common administrative boundary. The final is a response with one or more OADMINB resource records in the Answer section. Each OADMINB resource record asserts that the domain name in its RDATA forms part of the administrative boundary of the owner name. A OADMINB resource record with the single label "_" (called the "underscore target") is a positive assertion that no other domain name falls inside the administrative boundary of the owner name. This mechanism is equivalent to an empty answer section at a zone apex. The problem with that is its cache properties. For many domains, that's not a problem, but TLDs will want to make this assertion over long periods of time, and the underscore target allows you to make this statement with a long TTL. Is it worth having two ways to say the same thing?

The OADMINB resource record has two modes of use. In the first mode, called the "consumer mode", a OADMINB record expresses from what names the owner name is willing to accept content such as cookies and cross-document information sharing. Suppose that a client has a cookie that was obtained from www.example.net, and that is marked as being intended for use (among other sites) with www2.example.com. The client checks the OADMINB record at www2.example.com. If there is an answer with www.example.net (or *.example.net) in the RDATA, then www2.example.com is asserting that it will consume content from www.example.net. This clearly needs to be dressed up in the appropriate cookie terminology, but I wanted to try it out informally first to see whether it works. There is no need to check for a OADMINB record covering www2.example.com at www.example.net, because of the assertion on the part of www2.example.com that it is willing to accept the data. The second mode is called "asserter mode". The OADMINB record asserts that the name in the RDATA of the record is inside the administrative boundary of the owner name of the record. This assertion must be checked by asking the name in the RDATA of the OADMINB record whether it is a consumer of that data. Note that this means that the OADMINB relationship is symmetric: every consumer-mode record is also, in effect, an asserter-mode record. However, in the absence of a corresponding record at the other owner name, the asserter-mode record is not effective.

One of the uses of the list published at publicsuffix.org is for formatting names for display to users. A name that publishes a underscore target OADMINB record, or that does not publish a OADMINB record at all, is refusing to assert that there are other names in its administrative boundary. Therefore, that it is a point in the DNS tree below which administrative delegation may happen. Starting from the top of the tree, an agent may request the OADMINB record label by label. The parent label of the first label to provide an answer containing a OADMINB record that does not contain an underscore target is the "public suffix". Once a domain has been determined to be a public suffix, that result may be cached for the TTL of the domain's OADMINB record or, in the case of an empty answer, for the negative TTL for the zone.

To be provided if we decide that the OADMINB RR is the right thing to do.

A zone publisher can cause all domains beneath it to be in the same administrative boundary by publishing a wildcard record. For example, the wildcard expansion of an OADMINB record at *.example.com with a target of *.example.com would mean that every name beneath example.com considers every other name beneath example.com to be within the administrative boundary.

The underscore target is an assertion that no other name is inside the administrative boundary of the owner name. There is nothing to prevent a zone operator from publishing both an underscore target and some other target at the same owner name. Such an RRSET fo OADMINB would be internally inconsistent. To resolve this, the underscore record is hereby defined to take precedence.

It is possible to put enough OADMINB records into a zone such that the resulting response will exceed DNS or UDP protocol limits. In such cases, a UDP DNS response will arrive with the TC (truncation) bit set. Am OADMINB 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 underscore target (see ).

There are three significant problems with this proposal, both 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. Finally, in many environments the system hosting the application has only proxied access to the Internet, and cannot query the DNS directly. It is not clear how such clients could ever possibly retrieve the OADMINB record for a name.

This mechanism enables publication of assertions about administrative relationships of different DNS-named systems on the Internet. If such assertions are accepted without checking that both sides agree to the assertion, it would be possible for one site to become an illegitimate source for data to be consumed in some other site. Undertaking any of the inferences suggested in this draft without the use of the DNS Security Extensions exposes the user to the possibility of forged DNS responses.

IANA will be requested to register the OADMINB RRTYPE if this proceeds.

The author thanks Dave Crocker, Jeff Hodges, Murray Kucherawy, Patrick McManus, Yngve Pettersen, and Peter St Andre for early discussion of this idea.