idnits 2.17.1 draft-pfrc-what-dns-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 140 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 5, 2016) is 2732 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Name Research W. Manning 2 INTERNET-DRAFT UA partners 3 Intended Status: Informational 4 Expires: April 5, 2017 October 5, 2016 6 What is the Internet Domain Name System 7 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the provisions 12 of BCP 78 and BCP 79. 14 This document is subject to BCP 78 and the IETF Trust's Legal Provisions 15 Relating to IETF Documents (http://trustee.ietf.org/license-info) in 16 effect on the date of publication of this document. Please review these 17 documents carefully, as they describe your rights and restrictions with 18 respect to this document. 20 Internet-Drafts are working documents of the Internet Engineering Task 21 Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference material 33 or to cite them other than as "work in progress." 35 Copyright (c) 2016 IETF Trust and the persons identified as the 36 document authors. 37 All rights reserved. 39 This Internet-Draft will expire on April 5, 2017. 41 Abstract 43 The DNS work inside the IETF has suffered from mission-creep since a 44 clear scoping of what was DNS and what was not has not been easy to 45 find. This document attempts to clarify what is within scope of DNS 46 work and what is not. 48 1. What is the Internet Domain Name System (DNS)? 50 The DNS was created to provide a scalable system for providing a 51 mapping between the name of an instance and the location or address 52 of that instance usually for other applications use [RFC830]. It has 53 three essential elements; an ephemeral namespace, servers which 54 instantiate the namespace; a suite of protocols that allow a client 55 or resolver to ask the servers questions about the namespace. 57 All three of these are required to say that the system is or is part 58 of DNS. A fourth presumption is that there is always on, always 59 connected reachability across the DNS namespace. 61 The suite of protocols used between resolvers and servers, as well as 62 server and cache behaviour are within the purview of the IETF and its 63 working groups. 65 The Namespace is designed as an inverted tree, with a single root 66 context per protocol. Although other protocols and domain name systems 67 were envisioned at the outset, today they are primarily vestigial, at 68 least as far as the IETF is concerned. There is a single root, and one 69 namespace for the Internet DNS, as far as the IETF is concerned. 71 Traditionally, the IETF did not concern itself with the contents of the 72 namespace, leaving the management of the delegation points to the zone 73 maintainers, since this was always going to be a matter of local 74 preference. 76 These four constructs, in unison, have created the global Internet DNS, 77 as we know it. However, the tools are so useful, others have borrowed 78 from them for other work. Recently other domain name systems have 79 emerged, as predicted 35 years ago, but they do not meet the critera 80 for the Internet DNS. 82 2. What is NOT (strictly) the DNS. 84 It is possible, and has been implemented for decades, to change out 85 parts of the DNS namespace for ones own version. RFC 1035 2.2 clearly 86 suggests a goal is transport agility, but the use of a single, common, 87 namespace. [RFC1035] Split-DNS enables DNS-like services for private 88 spaces not connected to the Internet. Often these private namespaces 89 augment the Internet namespace with other, non-Internet names. As far 90 as the servers and resolvers are concerned, they still use the default 91 DNS protocols. It is hard to tell if one is or is not using the DNS 92 or a facsimile just from the resolver side. 94 Others want to use the DNS namespace, but invent their own protocols 95 for server/resolver communication. These can be viewed as a domain 96 name system, but not an Internet DNS. Some want to change out the 97 concept of servers/resolvers, but use the namespace. 99 NONE of these hybrids is Internet DNS. They are DNS-like, some are 100 parasitic some are symbiotic, but they are not Internet DNS. 102 It is a mistake for the IETF to treat these non-DNS issues as Internet 103 DNS related and it is a mistake for the IETF to get involved in 104 dictating to zone maintainers what labels they may or may not chose 105 to put into their delegations as long as the communications protocols 106 are ok with the labels the specific domain name system returns. 108 Those involved with the DNS should also avoid mission creep into 109 how other applications may or may not chose to utilize the names/labels 110 returned from a DNS query. If the DNS working groups stay focused on 111 staying within their remit, other application developers will not have 112 to be so concerned with what the DNS does or does not, and if they 113 have to develop their own systems. 115 3. Security Considerations 117 This document has no explicit security considerations. 119 4. IANA Considerations 121 This document requires no IANA consideration. 123 5. References 125 5.1. Normative References 127 [RFC830] Su, Z., "A Distributed System for Internet Name Service", 128 RFC 830, October 1982, . 130 [RFC1035] Mockapetris, P., "Domain names - implementation and 131 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 132 November 1987, . 134 Author 136 W. Manning 137 UA Partners 138 PO Box 1671 139 Medford, OR 140 USA 97501