< draft-lewis-domain-names-12.txt   draft-lewis-domain-names-13.txt >
Network Working Group E. Lewis Network Working Group E. Lewis
Internet-Draft ICANN Internet-Draft ICANN
Intended status: Informational July 22, 2019 Intended status: Informational August 6, 2019
Expires: January 23, 2020 Expires: February 7, 2020
RFC Origins of Domain Names RFC Origins of Domain Names
draft-lewis-domain-names-12 draft-lewis-domain-names-13
Abstract Abstract
Is the concept of Domain Names owned by the DNS protocol or does the Is the concept of Domain Names owned by the DNS protocol or does the
DNS protocol exist to support the concept of Domain Names? This DNS protocol exist to support the concept of Domain Names? This
question has become pertinent in light of proposals to use Domain question has become pertinent in light of proposals to use Domain
Names in protocols in ways incompatible with the DNS protocol and the Names in protocols in ways incompatible with the DNS protocol and the
operational environment built to run the protocol. To help answer operational environment built to run the protocol.
this question, a look into the recorded history of Requests for
Comments is presented. This document is intended to help answer this question by presenting
a look into the recorded history of relevant Requests for Comments.
This document comprises the research and views of the author and has
benefited from review and input from many IETF experts, but it does
not represent the consensus opinion of the IETF.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 January 23, 2020. This Internet-Draft will expire on February 7, 2020.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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
1.1. Goal . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Goal . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Early RFCs . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Early RFCs . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Emergence of Domain Names . . . . . . . . . . . . . . . . . . 6 3. Emergence of Domain Names . . . . . . . . . . . . . . . . . . 6
3.1. The Term "Domain Name" Itself . . . . . . . . . . . . . . 6 3.1. The Term "Domain Name" Itself . . . . . . . . . . . . . . 7
3.2. The Term "Resolve" . . . . . . . . . . . . . . . . . . . 8 3.2. The Term "Resolve" . . . . . . . . . . . . . . . . . . . 8
3.3. Where Does It Start? . . . . . . . . . . . . . . . . . . 9 3.3. Where Does It Start? . . . . . . . . . . . . . . . . . . 9
4. Dialects, So To Speak, of Domain Names . . . . . . . . . . . 10 4. Dialects, So To Speak, of Domain Names . . . . . . . . . . . 10
4.1. Domain Names in the DNS . . . . . . . . . . . . . . . . . 10 4.1. Domain Names in the DNS . . . . . . . . . . . . . . . . . 10
4.2. Host Names . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Host Names . . . . . . . . . . . . . . . . . . . . . . . 11
4.3. URI Authority and Domain Names . . . . . . . . . . . . . 12 4.3. URI Authority and Domain Names . . . . . . . . . . . . . 12
4.4. Internet Protocol Address Literals . . . . . . . . . . . 12 4.4. Internet Protocol Address Literals . . . . . . . . . . . 12
4.5. Internationalized Domain Names in Applications . . . . . 12 4.5. Internationalized Domain Names in Applications . . . . . 12
4.6. Restricted for DNS Registration . . . . . . . . . . . . . 13 4.6. Restricted for DNS Registration . . . . . . . . . . . . . 13
4.7. Tor Network Names . . . . . . . . . . . . . . . . . . . . 13 4.7. Tor Network Names . . . . . . . . . . . . . . . . . . . . 13
4.8. X.509 . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.8. X.509 . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.9. Multicast DNS . . . . . . . . . . . . . . . . . . . . . . 13 4.9. Multicast DNS . . . . . . . . . . . . . . . . . . . . . . 14
4.10. /etc/hosts . . . . . . . . . . . . . . . . . . . . . . . 14 4.10. /etc/hosts . . . . . . . . . . . . . . . . . . . . . . . 14
4.11. Other Protocols . . . . . . . . . . . . . . . . . . . . . 14 4.11. Other Protocols . . . . . . . . . . . . . . . . . . . . . 14
4.12. Other Others . . . . . . . . . . . . . . . . . . . . . . 15 4.12. Other Others . . . . . . . . . . . . . . . . . . . . . . 15
5. Interoperability Considerations . . . . . . . . . . . . . . . 15 5. Interoperability Considerations . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
9. Informational References . . . . . . . . . . . . . . . . . . 16 9. Informational References . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Which came first, the concept of Domain Names or the DNS? This Which came first, the concept of Domain Names or the DNS? This
question is at the heart of whether or how Domain Names are put to question is at the heart of whether or how Domain Names are put to
use in ways avoiding the DNS protocol. use in ways avoiding the DNS protocol.
The discussion leading to "The '.onion' Special-Use Domain Name" The discussion leading to "The '.onion' Special-Use Domain Name"
[RFC7686], a document designating "onion" as a top-level domain in [RFC7686], a document designating "onion" as a top-level domain in
the Special Use Domain Names registry (see "Special Use Domain Names" the Special Use Domain Names registry (see "Special Use Domain Names"
[RFC6761]), opened the question of how to treat Domain Names that [RFC6761]), opened the question of how to treat Domain Names that
were designed to be used external to the DNS. The history of Domain were designed to be used external to the DNS. The history of Domain
Names and the DNS had become intertwined to the point over time to Names and the DNS had become intertwined over time to the point that
the point that what is essentially a case of permission-less what is essentially a case of permission-less innovation led to
innovation led to a contentious discussion on the IETF's DNS contentious discussions on the IETF's DNS Operations (DNSOP) working
Operations working group mail list. group mail list and an interim meeting of the DNSOP working
group[DNSOP].
A portion of the discussion centered around a seeming conflict among A portion of the discussion centered around a seeming conflict among
processes to register Domain Names, such as the process launched from processes to register Domain Names, such as the process launched from
"Memorandum of Understanding Concerning the Technical Work of the "Memorandum of Understanding Concerning the Technical Work of the
Internet Assigned Numbers Authority" [RFC2860], for registering a Internet Assigned Numbers Authority" [RFC2860], for registering a
name in the global, public DNS and the process for registering a name name in the global, public DNS and the process for registering a name
in the Special Use Domain Names registry. in the Special Use Domain Names registry. The latter process is
documented in "Special Use Domain Names" cited in the previous
paragraph.
To help establish a way forward, a look backward is thought to be a To help establish a way forward, a look backward is thought to be a
good start. A document search, sticking to RFC documents, reveals good start. A document search, sticking to RFC documents, reveals
evidence of discussions on Domain Names prior to the DNS, with the evidence of discussions on Domain Names prior to the DNS, with the
DNS protocol's base documents indicating that the DNS is based on DNS protocol's base documents indicating that the DNS is based on
some simplifying assumptions, implying there is a larger concept in some simplifying assumptions, implying there is a larger concept in
play. play.
To help bolster the idea that Domain Names came first, a look at how To help bolster the idea that Domain Names came first, a look at how
other protocols have treated identifying names, how Domain Names are other protocols have treated identifying names, how Domain Names are
put to use, how what a name is further restricted for the protocol's put to use, how what a name is further restricted for the protocol's
needs. From this it has become apparent that the concept of Domain needs. From this it has become apparent that the concept of Domain
Names has drifted over time, which leads to some uncertainty when it Names has drifted over time, which leads to some uncertainty when it
comes to looking forward. comes to looking forward.
During reviews of this document, documented studies of other During reviews of this document, documented studies of other
difficulties resulting form the uncertainty have surfaced. "IAB difficulties resulting from the uncertainty have surfaced. "IAB
Thoughts on Encodings for Internationalized Domain Names" [RFC6055] Thoughts on Encodings for Internationalized Domain Names" [RFC6055]
documents issues related to converting human-readable forms of Domain documents issues related to converting human-readable forms of Domain
Names in forms useful to automated applications when there is no Names in forms useful to automated applications when there is no
clear architecture or precise definition of how to handle Domain clear architecture or precise definition of how to handle Domain
Names. "Issues in Identifier Comparison for Security Purposes" Names. "Issues in Identifier Comparison for Security Purposes"
[RFC6943] documents issues related to the same conversion as related [RFC6943] documents issues related to the same conversion as related
to evaluating security policies. The presence of these studies to evaluating security policies. The presence of these studies
suggests a need to examine the architecture of naming and suggests a need to examine the architecture of naming and
identifiers. identifiers.
The most glaring omission in the document survey is a definitive The most glaring omission discovered by the document survey is a
foundation for Domain Names. There are abstract descriptions of the definitive foundation for Domain Names. There are abstract
concept that come close to qualifying as a definition. The descriptions of the concept that come close to qualifying as a
descriptions though are too loose to be something that can be tested definition. The descriptions though are too loose to be something
objectively, frustrating discussions when it comes to innovations in that can be tested objectively, frustrating discussions when it comes
the use of Domain Names. to innovations in the use of Domain Names.
In reviews of this document, an important thought has been expressed. In reviews of this document, an important thought has been expressed.
During the era when the early RFC documents were prepared, many During the era when the early RFC documents were prepared, many
considerations now deemed important were not considered, discussed, considerations now deemed important were not considered, discussed,
examined. This lack of attention should be taken simply as the the examined. This lack of attention should be taken simply as the the
limits of the problem space perceived at the time and not as an limits of the problem space perceived at the time and not as an
intentional non-statement about questions now under consideration. intentional non-statement about questions now under consideration.
The fact that the history is presented here does not imply that The fact that the history is presented here does not imply that
history will contain the answers and guide the way forward, the history will contain the answers and guide the way forward, the
history as presented is only a starting point. history as presented is only a starting point.
This document is a literature search covering the RFC series and This document is a literature search covering the RFC series and
comes to making a case for clarifications to be made. There are makes a case for clarifications to be made. There are obvious
obvious continuations to this work, such as the earlier Internet continuations to this work, such as the earlier Internet Engineering
Engineering Notes series (IEN), other published works, and interviews Notes series (IEN), other published works, and interviews with
with participants in the early days. participants from the early days. This document is intended to help
answer this question of whether the concept of Domain Names is owned
by the DNS protocol or does the DNS protocol exist to support the
concept of Domain Names. It does this by presenting a look into the
recorded history of relevant Requests for Comments. This document
comprises the research and views of the author and has benefited from
review and input from many IETF experts, but it does not represent
the consensus opinion of the IETF.
1.1. Goal 1.1. Goal
To establish a solid foundation accommodating an installed based and To establish a solid foundation accommodating an installed base and
permission-less innovation, having a clear definition of Domain Names permission-less innovation, having a clear definition of Domain Names
would be great. This document, however, does not attempt to achieve would be great. This document, however, does not attempt to achieve
a definition. This document's goal has settled into compiling a a definition. This document's goal has settled into compiling a
narrative on the history, within perhaps artificial bounds (the RFC narrative on the history, within perhaps artificial bounds (the RFC
series), and declaring that there is a need to clarify Domain Names. series), and declaring that there is a need to clarify Domain Names.
In this document are criteria for performing a clarification, In this document are criteria for performing a clarification,
recognizing from experience in preparing "The Role of Wildcards in recognizing from experience in preparing "The Role of Wildcards in
the Domain Name System" [RFC4592] and "DNS Zone Transfer Protocol the Domain Name System" [RFC4592] and "DNS Zone Transfer Protocol
(AXFR)" [RFC5936] that clarifications may have adverse impacts on (AXFR)" [RFC5936] that clarifications may have adverse impacts on
skipping to change at page 17, line 5 skipping to change at page 17, line 13
Dave Crocker, Ken Pogran, John Vittal, Lixia Zhang, Ralph Droms and a Dave Crocker, Ken Pogran, John Vittal, Lixia Zhang, Ralph Droms and a
growing list of others I am losing track of. Not to imply growing list of others I am losing track of. Not to imply
endorsement. endorsement.
9. Informational References 9. Informational References
[ANSIX34] American National Standards Institute (formerly United [ANSIX34] American National Standards Institute (formerly United
States of America Standards Institute), "USA Code for States of America Standards Institute), "USA Code for
Information Interchange, ANSI X3.4-1968", 1968. Information Interchange, ANSI X3.4-1968", 1968.
[DNSOP] Woolf, S., "Interim DNSOP WG meeting on Special Use Names:
some reading material", 2015,
<https://mailarchive.ietf.org/arch/msg/dnsop/
VnSjuXYiwd89K_mt05-CJLa0lbs>.
[IABSTMT] Board, I. A., "IAB Statement: Dotless Domains Considered [IABSTMT] Board, I. A., "IAB Statement: Dotless Domains Considered
Harmful", 2013, <https://www.iab.org/documents/ Harmful", 2013, <https://www.iab.org/documents/
correspondence-reports-documents/2013-2/ correspondence-reports-documents/2013-2/
iab-statement-dotless-domains-considered-harmful/>. iab-statement-dotless-domains-considered-harmful/>.
[IEEE1003] [IEEE1003]
Group, T. I. A. T. O., "The Open Group Base Specifications Group, T. I. A. T. O., "The Open Group Base Specifications
Issue 7, IEEE Std 1003.1, 2013 Edition, Copyright Issue 7, IEEE Std 1003.1, 2013 Edition, Copyright
2001-2013 The IEEE and The Open Group", 2013, 2001-2013 The IEEE and The Open Group", 2013,
<http://pubs.opengroup.org/onlinepubs/9699919799/ <http://pubs.opengroup.org/onlinepubs/9699919799/
 End of changes. 15 change blocks. 
28 lines changed or deleted 47 lines changed or added

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