Publishing Organization Boundaries in the DNS
draft-levine-orgboundary-03

Abstract

Often, the organization that manages a subtree in the DNS is different from the one that manages the tree above it. Rather than describing a particular design, we describe an architecture to publish in the DNS the boundaries between organizations that can be adapted to various policy models.

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 May 12, 2016.

Copyright Notice

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must 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. Introduction
• 2. Design Issues
• 3. RRTYPE format
• 4. Lookup Process
• 5. DNS Records
• 6. Application scenearios
• 6.1. Cookies
• 6.2. SSL Certificates
• 6.3. DMARC
• 7. Discussion
• 8. Security Considerations
• 9. Variations
• 10. IANA considerations
• 11. Normative References
• Appendix A. Change Log
• A.1. Changes from -02 to -03
• A.2. Changes from -01 to -02
• A.3. Changes from -00 to -01
• Author's Address

1. Introduction

Often, the organization that manages a subtree in the DNS is different from the one that manages the tree above it. Many applications use information about such boundaries to implement security policies. For example, web browsers use them to limit the names where web cookies can be set, and Secure Socket Layer (SSL) certificate services use them to determine the party responsible for the domain in a signing request. Some mail security applications such as Domain-based Messaging Authetnication, Reporting and Conformance (DMARC) use them to locate an organization's policy records in the DNS.

[[Plese direct discusson of this draft to the dbound working group at dbound@ietf.org.]]

2. Design Issues

Organization boundaries can be assigned on what one could call an opt-in or opt-out basis. "Opt-in" means that two names are only managed by the same organization if both actively assert that they are related. "Opt-out" means that if there is any boundary information at all for a DNS subtree, each name is assumed to be under the same management as its parent unless there is a boundary assertion to the contrary. This design describes an opt-out model.

Within the opt-out model, this design can adapt to a variety of scenarios:

• Policies can be published by the domains themselves, or by a third party. In the former case, each domain might assert its own boundary policies. In the latter case, the third party makes the assertions, which may or may not agree with what the domains themselves would want.
• Multiple levels of delegation may be implemented, which is different from irregular boundaries. For example, "ca", "on.ca", and "toronto.on.ca" are irregular boundaries, because they're all handled by the Canadian Internet Registration Authority (CIRA). CentralNIC's "uk.com" would be a second level of delegation below Verisign's com.
• Different sets of boundary rules can be published for different applications. For example, the boundaries for SSL certificates might be different from the boundaries for e-mail policies, or for web cookie setting policies.

In the lookup process below, the boundary point data is stored in the DNS tree in a new BOUND RRTYPE. Each domain publishes its own policies.

3. RRTYPE format

The BOUND record contains two 16-bit numeric values and an uncompressed domain name. In a master file, they are written as two decimal values and a domain name.

The first numeric value is a bit mask expressing policy options. The only bit currently assigned is 0x0001 (NOLOWER) which means that no lower level boundaries can exist below this one.

The second numeric value is a number identifying the application to which this boundary applies. The number zero is a default for any applications not otherwise specified.

4. Lookup Process

In general, the lookup process takes as input a domain name an application number. It returns the name of the boundary node in the DNS, the one above the closest node to the root that also belongs to the same organization as the input domain name. This may be the domain itself or a parent. If there is no policy for the domain the lookup fails; there are no defaults, and the DNS root is not within any organization boundary. (Applications may apply defaults of their own, but that is beyond the scope of this specification.)

Names of boundary information records use the tag "_bound" which is intended to be unique.

For the first lookup, the client extracts the top level component (i.e., the rightmost label, as "label" is defined in Section 3 of [RFC1034]) of the domain name from the subcomponents, if any, and inserts the prefix in front of that component, after other components if any. For example, if the domain to be checked is "example.com" or "www.example.com", the client issues a DNS query for "example._bound.com" or "www.example._bound.com". If the domain is a dotless one such as "example", the client looks up "_bound.example".

The client does a DNS lookup of BOUND records at that name, which will return zero or more BOUND records. A failure such as NXDOMAIN is considered to return zero records. A lookup can return multiple records if different applications have different boundaries or policy options.

If a relevant policy record is returned, the domain name in the record is the policy boundary. A policy record is relevant if it its application number is the application's number, or its application number is zero and there is no record with the application's number. For example, a check for a boundary above "example.com" would be issued at "example._bound.com", and the expected response could be "BOUND 0 0 com".

If there are no boundaries below the queried point, the policy record contains "BOUND 1 0 ." indicating the root. For example, if all subdomains of the "example" top-level domain (TLD) are under the same management as the TLD itself, checks for "_bound.example" or "www._bound.example" would return "BOUND 1 0 .".

If the relevant record has the NOLOWER bit set, the process stops. Otherwise, the client inserts the prefix tag into the name just below (i.e., to the left of) the name at the largest matching boundary indicated in the lookup result, and repeats the lookup. For example:

• When evaluating "www.foo.example.com", the first query would be to "www.foo.example._bound.com". If the reply to this is "BOUND 0 0 com", then the second query would go to "www.foo._bound.example.com".
• When evaluating "www.example.on.ca", the first query would be to "www.example.on._bound.ca". If the reply to this is "BOUND 0 0 on.ca", the next lookup would be to "www._bound.example.on.ca".

This process repeats until a DNS lookup returns a relevant record with the NOLOWER bit set, or a lookup returns no relevant records, at which point the boundary is the domain name in the last retrieved relevant record.

The total number of DNS lookups is the number of levels of boundary delegation, which is unlikely to be more than 1 or 2 in realistic scenarios.

5. DNS Records

The publishing entity uses wildcards and prefixed names that parallel the regular names under a TLD to cover the domain's name space.

  *._bound.test IN BOUND 0 0 test"

If there is a boundary at a given name, an entry in the TLD record covers the names below it. For example, if there is a boundary at ".TEST", a suitable record would be:

If the boundary is above the TEST domain, i.e., TEST is under the same management as FOO.TEST, the record would indicate no boundaries, and an additional non-wildcard record is needed to cover TEST itself:

  *._bound.test IN BOUND 0 0 .
  _bound.test   IN BOUND 0 0 .

In domains with irregular policy boundaries, multiple records in the record describe the boundary points. For example, in the CA (Canada) TLD, for national organizations there might be a boundary directly below the national TLD; for provincial organizations there might be a boundary below a provincial subdomain such as "on.ca"; and for local (e.g., municipal) organizations, a boundary below a municipal subdomain such as "toronto.on.ca" might exist. A suitable set of of records covers this structure. The closest encloser rule in RFC 4592 [RFC4592] makes the wildcards match the appropriate names.

*._bound.ca            IN BOUND 0 0 ca
*.on._bound.ca         IN BOUND 0 0 on.ca
*.toronto.on._bound.ca IN BOUND 0 0 toronto.on.ca"

For any set of policy boundaries in a tree of DNS names, a suitable set of policy records can describe the boundaries, so a client can find the boundary for any name in the tree with a single policy lookup per level of delegation.

Since the delegation structure is unlikely to change frequently, long time-to-live (TTL) values in the DBOUND records are appropriate.

If different applications have different boundaries or policy options, the policy records for each application are put at the appropriate names for the boundaries.

6. Application scenearios

Here are some ways that applications might use BOUND data.

6.1. Cookies

If an http request attempts to set a cookie for a domain other than the request's own domain, the client would do boundary check for the "cookie" application for both the request's domain and the cookie domain. If they have the same boundary, the request is allowed.

6.2. SSL Certificates

The client would do a boundary check for the domain name in an normal certificate, or the name after the "*." in a wildcard certificate for the "cert" application. f the boundary is above the name, the name is allowed.

6.3. DMARC

If a DMARC lookup for the domain in a message's From: header fails, the client would do a boundary check for the domain name using the "dmarc" application. The organizational domain is the immediate subdomain of the boundary domain. (Note that the boundary will always be the one looked up or an ancestor.)

7. Discussion

Some domains have very irregular boundaries. This may require a large number of records to describe all the boundaries, perhaps several hundred, but it doesn't seem like a number that would challenge modern DNS servers.

The wildcard lookup means that each time an application looks up the boundaries for a hostname, the lookup results use DNS cache entries that will not be reused other than for subsequent lookups for the identical hostname. This might cause cache churn, but it seems at worst no more than we already tolerate from DNSBL lookups.

8. Security Considerations

The purpose of publishing organization boundaries is to provide advice to third parties that wish to know whether two names are managed by the same organization, allowing those names to be treated "as the same" in some sense. Clients that rely on published boundaries are outsourcing some part of their own security policy to the publisher, so their own security depends on the publisher's boundaries being accurate.

Although in some sense domains are always in control of their subdomains, there are many situations in which parent domains are not expected to influence subdomains. For example, the Internet Corporation for Assigned Names and Numers (ICANN) contracted global TLDs (gTLDs) and registers second level domains. Since there is no technical bar to a parent publishing records that shadow part or all of the boundary record namespace for delegated subdomains, correct operation depends on the parent and subdomains agreeing about who publishes what.

The DNS is subject to a variety of attacks. DBOUND records are subject to the same ones as any other bit of the DNS, and the same responses, such as using DNSSEC, apply.

9. Variations

Since nothing but BOUND records should be published at names with _bound components, one could get the same effect with TXT records, e.g.:

  *.toronto.on._ob.ca IN TXT "bound=1 0 0 toronto.on.ca"

If third parties wanted to publish boundary information, they could do it in their own subtree of the DNS. For example, if polgroup.example were publishing boundary information about boundaries, the records for the test domain described above would be:

  *._bound.test.polgroup.exaple IN BOUND 0 0 .
  _bound.test.polgroup.exampl   IN BOUND 0 0 .

10. IANA considerations

This document defines a new DBOUND RRTYPE. IANA has assigned value TBD.

This document requests that IANA create a registry of BOUND Flag Bits. Its registration policy is IETF Review. Its initial contents are as follows. [[NOTE: new flags are likely to change the lookup algorithm]]