< draft-levine-dbound-dns-02.txt   draft-levine-dbound-dns-03.txt >
Network Working Group J. Levine Network Working Group J. Levine
Internet-Draft Taughannock Networks Internet-Draft Taughannock Networks
Intended status: Informational April 6, 2019 Intended status: Informational April 27, 2019
Expires: October 8, 2019 Expires: October 29, 2019
Publishing Organization Boundaries in the DNS Publishing Organization Boundaries in the DNS
draft-levine-dbound-dns-02 draft-levine-dbound-dns-03
Abstract Abstract
The organization that manages a subtree in the DNS is often different The organization that manages a subtree in the DNS is often different
from the one that manages the tree above it. We describe an from the one that manages the tree above it. We describe an
architecture to publish in the DNS the boundaries between architecture to publish in the DNS the boundaries between
organizations that can be adapted to various policy models and can be organizations that can be adapted to various policy models and can be
queried with a small number of DNS lookups. queried with a small number of DNS lookups.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 October 8, 2019. This Internet-Draft will expire on October 29, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
skipping to change at page 2, line 12 skipping to change at page 2, line 12
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Design Issues . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Design Issues . . . . . . . . . . . . . . . . . . . . . . . . 2
3. TXT record format . . . . . . . . . . . . . . . . . . . . . . 3 3. TXT record format . . . . . . . . . . . . . . . . . . . . . . 3
4. Lookup Process . . . . . . . . . . . . . . . . . . . . . . . 4 4. Lookup Process . . . . . . . . . . . . . . . . . . . . . . . 4
5. DNS Records . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. DNS Records . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Application scenarios . . . . . . . . . . . . . . . . . . . . 6 6. Application scenarios . . . . . . . . . . . . . . . . . . . . 7
6.1. DMARC . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. DMARC . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.2. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.2. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.3. SSL Certificates . . . . . . . . . . . . . . . . . . . . 7 6.3. SSL Certificates . . . . . . . . . . . . . . . . . . . . 7
7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 7
8. ABNF syntax of bound records . . . . . . . . . . . . . . . . 7 8. ABNF syntax of bound records . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
10. Variations . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. Variations . . . . . . . . . . . . . . . . . . . . . . . . . 8
11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
12.1. Normative References . . . . . . . . . . . . . . . . . . 9 12.1. Normative References . . . . . . . . . . . . . . . . . . 10
12.2. Informative References . . . . . . . . . . . . . . . . . 10 12.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 10 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Often, the organization that manages a subtree in the DNS is Often, the organization that manages a subtree in the DNS is
different from the one that manages the tree above it. Many different from the one that manages the tree above it. Many
applications use information about such boundaries to implement applications use information about such boundaries to implement
security policies. For example, web browsers use them to limit the security policies. For example, web browsers use them to limit the
names where web cookies can be set, and Secure Socket Layer (SSL) names where web cookies can be set, and Secure Socket Layer (SSL)
certificate services use them to determine the party responsible for certificate services use them to determine the party responsible for
the domain in a signing request. Mail security applications such as the domain in a signing request. Mail security applications such as
skipping to change at page 4, line 13 skipping to change at page 4, line 13
NOLOWER which means that no lower level boundaries can exist below NOLOWER which means that no lower level boundaries can exist below
this one, and NOBOUND which means that this name is not a boundary this one, and NOBOUND which means that this name is not a boundary
for this application. for this application.
The second keyword string identifies the application(s) to which this The second keyword string identifies the application(s) to which this
boundary applies. The strings DMARC, COOKIE, and CERT mean that the boundary applies. The strings DMARC, COOKIE, and CERT mean that the
applications re DMARC, HTTP cookies, and SSL certificate signing applications re DMARC, HTTP cookies, and SSL certificate signing
respectively; a dot means it is a default for any applications not respectively; a dot means it is a default for any applications not
otherwise specified. otherwise specified.
The domain name is an absolute domain name, without the final dot.
The first label in the name may be "*" to indicate that the boundary
is at any name one label deeper than the rest of the name. That is,
the asterisk matches a single label, not the usual DNS sense of
matching any string of labels.
4. Lookup Process 4. Lookup Process
In general, the lookup process takes as input a domain name and In general, the lookup process takes as input a domain name and
application. It returns the name of the boundary node in the DNS. application. It returns the name of the boundary node in the DNS.
This may be the domain itself or a parent. If there is no policy for 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 the domain the lookup fails; there are no defaults, and the DNS root
is not within any organization boundary. (Applications may apply is not within any organization boundary. (Applications may apply
defaults of their own, but that is beyond the scope of this defaults of their own, but that is beyond the scope of this
specification.) specification.)
skipping to change at page 6, line 19 skipping to change at page 6, line 26
boundary below a provincial subdomain such as "on.ca"; and for local boundary below a provincial subdomain such as "on.ca"; and for local
(e.g., municipal) organizations, a boundary below a municipal (e.g., municipal) organizations, a boundary below a municipal
subdomain such as "toronto.on.ca" might exist. A suitable set of of subdomain such as "toronto.on.ca" might exist. A suitable set of of
records covers this structure. The closest encloser rule in RFC 4592 records covers this structure. The closest encloser rule in RFC 4592
[RFC4592] makes the wildcards match the appropriate names. [RFC4592] makes the wildcards match the appropriate names.
*._bound.ca IN TXT "bound=1 . . ca" *._bound.ca IN TXT "bound=1 . . ca"
*.on._bound.ca IN TXT "bound=1 . . on.ca" *.on._bound.ca IN TXT "bound=1 . . on.ca"
*.toronto.on._bound.ca IN TXT "bound=1 . . toronto.on.ca" *.toronto.on._bound.ca IN TXT "bound=1 . . toronto.on.ca"
In some cases, a domain may assert that every name below a given name
is a boundary, or that every name other than a specific set of
exceptions is a boundary. For example (adapted from the Mozilla PSL)
every name below kobe.jp is a boundary other than city.kobe.jp. This
could be expressed as:
*.kobe._bound.jp IN TXT "bound=1 . . *.kobe.jp"
city.kobe._bound.jp IN TXT "bound=1 NOBOUND . city.kobe.jp"
*.city.kobe._bound.jp IN TXT "bound=1 NOBOUND . city.kobe.jp"
For any set of policy boundaries in a tree of DNS names, a suitable 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 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 find the boundary for any name in the tree with a single policy
lookup per level of delegation. lookup per level of delegation.
Since the delegation structure is unlikely to change frequently, long Since the delegation structure is unlikely to change frequently, long
time-to-live (TTL) values in the TXT records are appropriate. time-to-live (TTL) values in the TXT records are appropriate.
If different applications have different boundaries or policy If different applications have different boundaries or policy
options, the policy records for each application are put at the options, the policy records for each application are put at the
skipping to change at page 10, line 18 skipping to change at page 10, line 40
12.2. Informative References 12.2. Informative References
[PSL] Mozilla Foundation, "Public Suffix List", Nov 2015. [PSL] Mozilla Foundation, "Public Suffix List", Nov 2015.
Appendix A. Change Log Appendix A. Change Log
*NOTE TO RFC EDITOR: This section may be removed upon publication of *NOTE TO RFC EDITOR: This section may be removed upon publication of
this document as an RFC.* this document as an RFC.*
02 to -03 Add wildcard labels like in the PSL.
01 to -02 Make TXT record the proposal, new RR as alternative. 01 to -02 Make TXT record the proposal, new RR as alternative.
-00 to -01 Editorial changes to limit standard use to DMARC. -00 to -01 Editorial changes to limit standard use to DMARC.
non-WG to -00 Add NOBOUND record to make wildcard matches do the non-WG to -00 Add NOBOUND record to make wildcard matches do the
right thing right thing
Rename to match WG name Rename to match WG name
Author's Address Author's Address
 End of changes. 10 change blocks. 
11 lines changed or deleted 29 lines changed or added

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