Network Working Group J. Levine Internet-Draft Taughannock Networks Intended status: Informational June 09, 2013 Expires: December 11, 2013 Publishing organization boundaries in the DNS draft-levine-orgboundary-00 Abstract Often, the organization that manages a subtree in the DNS is 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 December 11, 2013. Copyright Notice Copyright (c) 2013 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. Levine Expires December 11, 2013 [Page 1] Internet-Draft Spamtrap taxonomy June 2013 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Design issues . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Lookup process . . . . . . . . . . . . . . . . . . . . . . . 3 4. DNS records . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Security considerations . . . . . . . . . . . . . . . . . . . 5 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Informative References . . . . . . . . . . . . . . . . . 6 6.2. Normative References . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction Often, the organization that manages a subtree in the DNS is 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. SSL certificate services use them to determine the responsible party for the domain in a signing request. Some mail security applications such as DMARC use them to locate an organization's policy records. The most widely used source of boundary data is the Public Suffix List, maintained by the Mozilla Foundation. It is distributed as a text file available at a well known URL, with some libraries to parse and search it. While it has worked adequately, it has a variety of issues. Downloading the file is relatively slow, and adequate performance requires that each application cache a copy of the file. The file is in a unique format that requires a specialized parser and lookup routines. The file is managed by a third party rather than directly by the domain owners, which may or may not be considered a problem. 2. Design issues This design can adapt to a variety of design points. Policies can be published by the domains themselves, or by a third party. In the former case, each domain asserts 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. Levine Expires December 11, 2013 [Page 2] Internet-Draft Spamtrap taxonomy June 2013 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 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 TXT records. While it wouldn't hurt anything to use a new RRTYPE, it wouldn't be useful. All of the DNS names used include a distinctive prefixed name component, so there shouldn't be any RRs at those names other than the TXT record for the boundary. To avoid confusion due to top-level wildcards that might inadvertently cover the subtree of boundary records, the TXT strings contain a prefix tag. 3. Lookup process Each collection of boundary data has a base name and a prefix tag. If domains publish their own information, the base name is the DNS root. Otherwise it is a domain belonging to the publishing entity. The tag starts with an underscore and is intended to be unique. All of the rules for a given application use the same tag. In the examples below, the tag is _sb for sample boundary. Every valid policy record starts with a fixed prefix "ob=1 " for organization boundary version 1. If a lookup returns no TXT records that start with the prefix, or more than one record that starts with the prefix, the lookup fails. The lookup process takes a domain name and returns the name of the node closest to the root that belongs to the same organization. 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.) For the first lookup, the client separates the top level component of the domain name from the subcomponents, if any, and inserts the prefix between the top level component and the subcomponents. For example, if the domain to be checked is example.com, the client looks up example._sb.com, if the domain is www.example.com, the client looks up www.example._sb.com, and if the domain is just example, the client looks up _sb.example. If the base name is not null, it is Levine Expires December 11, 2013 [Page 3] Internet-Draft Spamtrap taxonomy June 2013 appended to the name to be looked up, so if the name example.com were to be checked in a collection with the base cookies.example, the name looked up would be example._sb.com.cookies.example. If the lookup returns a valid policy record, the contents of the record disregarding the prefix is the domain name just above the policy boundary. For example, if there is a boundary between example.com and the com TLD, the record would contain "ob=1 com" when checking example.com or www.example.com. If there are no boundaries below the TLD, the policy record contains "." for the root. For example, if all subdomains of the "example" TLD are under the same management as the TLD itself, checks for example, foo.example, and www.foo.example would all return "ob=1 .". If the lookup process only allows a single level of delegation, the process stops after a single lookup. If it allows multiple levels of delegation, the client moves the tag just below the name below the boundary just found and repeats the lookup. For example, if a lookup of www.foo.example._sb.com returned "ob=1 com", the next lookup would be www.foo._sb.example.com. or if a lookup of www.example.on._sb.ca returned "ob=1 on.ca" the next lookup would be www._sb.example.on.ca. This process repeats until a DNS lookup returns NXDOMAIN or NODATA, at which point the result is the result of the last successful lookup. The total number of DNS lookups is the number of levels of delegation, which is unlikely to be more than 1 or 2 in realistic scenarios. 4. DNS records The publishing entity uses a combination of wildcard and non-wildcard names to cover the relevant name space. If there is a boundary below a given name, a wildcard covers the names below it. For example, if there is a boundary at or immediately below .TEST, a suitable record would be: *._sb.test txt "ob=1 test" If the boundary is at the .TEST domain, i.e., TEST. is under the same management as FOO.TEXT, an additional non-wildcard record covers the domain itself. _sb.test txt "ob=1 test" Levine Expires December 11, 2013 [Page 4] Internet-Draft Spamtrap taxonomy June 2013 If the TLD has no policy for itself, e.g., the TLD has no mail policy because there are no mail addresses in the TLD itself, it publishes no policy record for itself. In domains with irregular policy boundaries, multiple wildcards describe the delegation points. For example, in the .CA TLD, for national organizations there might be a boundary directly below the TLD, for provincial organizations a boundary below a provincial subdomain such as on.ca, and for local organizations, a boundary below a municipal subdomain such as toronto.on.ca. A suitable set of wildcards covers this structure. *._sb.ca txt "ob=1 ca" *.on._sb.ca txt "ob=1 on.ca" *.toronto.on._sb.ca txt "ob=1 toronto.on.ca" The closest encloser rule in RFC 4592 [RFC4592] makes the wildcards match the appropriate names. 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. 5. Security considerations The point of publishing organization boundaries is to provide advice to third parties that wish to know whether two names are managed by the same organization so the names can be treated "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 mess with child subdomains, e.g., ICANN contracted gTLDs and registered 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. Levine Expires December 11, 2013 [Page 5] Internet-Draft Spamtrap taxonomy June 2013 6. References 6.1. Informative 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. 6.2. Normative References [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name System", RFC 4592, July 2006. Author's Address John Levine Taughannock Networks PO Box 727 Trumansburg, NY 14886 Phone: +1 831 480 2300 Email: standards@taugh.com URI: http://jl.ly Levine Expires December 11, 2013 [Page 6]