Internet DRAFT - draft-hardaker-dnsop-private-namespace-options
draft-hardaker-dnsop-private-namespace-options
Network Working Group W. Hardaker
Internet-Draft USC/ISI
Intended status: Standards Track November 02, 2020
Expires: May 6, 2021
DNS Private Namespace Options
draft-hardaker-dnsop-private-namespace-options-00
Abstract
This document discusses the trade-offs between various options about
creating a private namespace within top level domains within the root
zone.
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 https://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 6, 2021.
Copyright Notice
Copyright (c) 2020 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
(https://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.
Hardaker Expires May 6, 2021 [Page 1]
Internet-Draft DNS Private Namespace Options November 2020
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Document state . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements notation . . . . . . . . . . . . . . . . . . 3
2. Analysis of choices . . . . . . . . . . . . . . . . . . . . . 3
2.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. TLD choices . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.1. Working state aside . . . . . . . . . . . . . . . . . 4
2.2.2. Analysis of an unsigned TLD (eg .internal) . . . . . 5
2.2.3. Analysis of a special-use TLD (eg .zz) . . . . . . . 5
3. Other considerations . . . . . . . . . . . . . . . . . . . . 6
3.1. a unsigned delegated domain - .internal . . . . . . . . . 6
3.2. a special-use domain - .zz . . . . . . . . . . . . . . . 6
4. Deployment considerations . . . . . . . . . . . . . . . . . . 7
5. Recommendation . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Selecting good TLD names . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
HATS: The author is not wearing any hats while writing this document.
Deployed DNS clients within the Internet typically communicate with
upstream resolvers using their own in-application stub resolver.
These upstream resolvers may be run by ISPs, or may be a customer-
premises equipment (CPE) that may or may not forward requests to its
upstream ISP.
In an entirely singular Internet DNS there would be no name
collisions as all data is uniquely named. However, the prevalence of
local private name spaces within companies, organizations,
governments, home LANs, etc have shown that existence of a single,
unique naming system rarely exists. The deployment of Internet of
Things (IoT) devices is only accelerating this trend for private
namespaces by devices that bootstrap their names with the easy
solution of "just make one up until the customer provides us with a
better one", followed by the customer never providing one. This
document makes no judgment on whether this is right or wrong, and
takes this assumption as simply the state of the current world.
Hardaker Expires May 6, 2021 [Page 2]
Internet-Draft DNS Private Namespace Options November 2020
The for special use names is well spelled out in [RFC6761].
[RFC8244] provides additional insight into areas that are still under
discussion and where work is needed. Recently ICANN's SSAC has
issued [SAC113] entitled "SSAC Advisory on Private-Use TLDs", wherein
it suggests the creation of a private-use DNS TLD.
This document considers the aspects associated with DNSSEC and the
potential choices for a private-use TLD (also see [RFC8244] bullet
21). Specifically, we consider the case where somewhere in the
resolution path DNSSEC validation is in use, potentially at an end-
device (phone, laptop, etc), a CPE, or at an ISP's resolver.
1.1. Document state
This document is not a fully complete analysis, but rather a starting
point for discussion and continued analysis by both the author and
others that wish to contribute.
1.2. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Analysis of choices
Note that this analysis is not (yet) exhaustive. It does describe
some of the differences in the two approaches.
2.1. Assumptions
We make the following assumptions to begin:
1. A local environment needs to use both the Global Internet's DNS
(GID), as well as at least one private name space as well.
2. A end-device, a CPE and/or a resolver may choose to validate DNS
requests.
3. The validating resolver wishes to validate both responses from
the GID as well as local names using DNSSEC.
4. The validating resolver will, thus, need Trust Anchors (TAs) for
both the GID and all private namespaces, or will need a list of
names which are assumed insecure and exemptions to the GID.
Hardaker Expires May 6, 2021 [Page 3]
Internet-Draft DNS Private Namespace Options November 2020
5. The device may (unfortunately) move to another network where
private namespace resolution is not available, and thus queries
to it will leak to the GID. This is extremely common today.
6. We take as accepted consensus that anything protocol needing a
private name space that is not user visible can be properly
housed under .arpa. This document assumes a private-namespace
TLD is needed, as discussed in other documents ([SAC113, etc]) to
aid in user presentation and understanding. This document does
not make judgment on whether this or user-education may be the
right approach to this problem.
2.2. TLD choices
Given these assumptions, we consider the cases where a private
namespace TLD exists that is:
1. Is a special-use domain per [RFC6761], and does not (and will
never) exist in the GID. In this document, we refer to this as
".internal" for discussion purposes only following conventions in
[draft-wkumari-dnsop-internal].
2. Is an unsigned delegation within the (GID's) DNS root, with NS
records likely pointing eventually to something like 127.0.53.53.
In this document, we refer to this as ".zz" following convention
in [draft-ietf-dnsop-private-use-tld]. We note that [draft-ietf-
dnsop-alt-tld] also proposed a private namespace (".alt") that
also fits into this category.
This document recognizes that .zz itself is actually not necessarily
a normal special use domain, and [RFC6761] may not apply as its an
ISO reversed name. However, in other aspects it will behave like a
special-use registered domain and its under current consideration by
dnsop so we leave it in here as the example name.
In summary:
o .internal is an unsigned TLD
o .zz is a special-use-like TLD that MUST never be assigned
2.2.1. Working state aside
The next two sections mix together DNSSEC validation at end-devices
and resolvers; it would add significant more clarity to discuss them
individually, which will be done in a future version.
Hardaker Expires May 6, 2021 [Page 4]
Internet-Draft DNS Private Namespace Options November 2020
2.2.2. Analysis of an unsigned TLD (eg .internal)
An unsigned TLD such as .internal will:
o Exist within the DNS root
o have NS records pointing to something.arpa with on A/AAAA
resolution
2.2.2.1. non-validating end-devices querying within .internal will:
o inside the private network the client will:
* Believe the upstream resolver's responses
o outside the private network the client will:
* Believe the upstream resolver's NXDOMAIN responses for anything
deeper than .internal itself (IE, api.example.internal/A will
return NXDOMAIN)
2.2.2.2. validating end-devices querying within .internal will:
o inside the private network the client will:
* must be configured with a private TA to enable DNSSEC within
the private network (creating an island of trust)
* If unconfigured, it will believe the upstream resolver's
responses because its delegated insecure, and therefore has no
basis to distrust the answers
o outside the private network the client will:
* if not configured with a TA, all answers to .internal will
either be NXDOMAIN or spoofable
* if configured with a TA, all answers will be detected as BOGUS
2.2.3. Analysis of a special-use TLD (eg .zz)
A special-use TLD will:
o Not exist within the DNS root
o Proven by the root's NSEC chain
Hardaker Expires May 6, 2021 [Page 5]
Internet-Draft DNS Private Namespace Options November 2020
2.2.3.1. non-validating end-devices querying within .zz will:
o inside the private network the client will:
* Believe the upstream resolver's responses
o outside the private network the client will:
* Believe the upstream resolver's NXDOMAIN or spoofed answers for
all data within the .zz domain.
2.2.3.2. validating end-devices querying within .zz will:
o inside the private network the client will:
* with an upstream resolver
* self-resolving:
+ needs a configured TA or a configured negative trust anchor
+ possibly automatically obtained configuration with a
bootstrapping mechanism, or-preconfigured in a ROM image
o outside the private network the client will:
* if not configured with a TA, all answers to .internal will
either be NXDOMAIN or spoofable
* if configured with a TA, all answers will be detected as BOGUS
3. Other considerations
3.1. a unsigned delegated domain - .internal
o configuration of new TAs
o requires collaboration between the IETF and ICANN , since the TLD
will exist and falls outside the scope of [RFC6761]. This process
can be slow.
3.2. a special-use domain - .zz
o May require invoking [RFC6761] (depending on .zz or not .zz)
o may require more configuration per-device
Hardaker Expires May 6, 2021 [Page 6]
Internet-Draft DNS Private Namespace Options November 2020
4. Deployment considerations
During initial deployment of either of these, there is a fundamental
difference for validating resolvers.
Specifically, until all validating resolvers are updated with a new
TA for specific instances under a special-use TLD (e.g. .zz), the
resolvers will fail to validate any names underneath as .zz is
provable insecure. This could take a while to update all deployed
validating resolvers.
On the other hand, deploying a newly allocated, unsigned TLD will
take a long time in process both within the IETF and within ICANN.
And each may have impacts on what error processing results, based on
the differing resolution characteristics (Section 2.2.2,
Section 2.2.3).
5. Recommendation
This author recommends that the IETF take on both tracks
simultaneously, and:
1. starts the process of communicating with ICANN and ISO about the
use of .zz, or selects another name to use under [RFC6761] as a
special-use name.
2. Issues a request to the ICANN board via the IAB to follow the
guidance of [SAC113] and reserve a string or set of strings for
use as a private-namespace(s) as an unsigned TLD. The ICANN
board can not act on their own, based on ICANN bilaws, but can
take requests from the IETF via the IAB to act.
This leaves vendors the freedom to chose that path that best meets
their specific requirements. Recommendations about how to best
select one given their situation is hinted above, but should be more
formally written down in this document or others.
5.1. Selecting good TLD names
Unfortunately, here be dragons. Selecting a good name has been
discussed multiple times in the IETF, and has always resulted in a
lack of consensus. In part, this is because the IETF doesn't have
the skillsets needed to hold a discussion about what language
element(s) would be best for universal adoption and usage.
Instead, this author recommends that we direct ICANN to select the
names that should be used for both of these cases. ICANN has
Hardaker Expires May 6, 2021 [Page 7]
Internet-Draft DNS Private Namespace Options November 2020
significant more skill breadth in the area of selecting names best
suited to be understood by end-users. This discussion will not be
faster, however, within ICANN but this author believes a resolution
in that SDO will be more likely successful.
Thus, the IETF can make the technical recommendation and ICANN can
implement these two choices.
6. Security Considerations
TBD
(though much of this draft is a security considerations itself)
7. IANA Considerations
TBD
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
RFC 6761, DOI 10.17487/RFC6761, February 2013,
<https://www.rfc-editor.org/info/rfc6761>.
8.2. Informative References
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8244] Lemon, T., Droms, R., and W. Kumari, "Special-Use Domain
Names Problem Statement", RFC 8244, DOI 10.17487/RFC8244,
October 2017, <https://www.rfc-editor.org/info/rfc8244>.
Appendix A. Acknowledgments
Large portions of the technical analysis in this document derives
from a discussion with Roy Arends and Warren Kumari (back when we
could stand in front of a whiteboard together).
Hardaker Expires May 6, 2021 [Page 8]
Internet-Draft DNS Private Namespace Options November 2020
Author's Address
Wes Hardaker
USC/ISI
Email: ietf@hardakers.net
Hardaker Expires May 6, 2021 [Page 9]