Name Research                                                 W. Manning
INTERNET-DRAFT                                               UA partners
Intended Status: Informational
Expires: April 5, 2017                                  October 5, 2016

                      What is the Internet Domain Name System
                          <draft-pfrc-what-dns-00.txt>

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions
of BCP 78 and BCP 79.

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.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other
groups may also distribute working documents as Internet-Drafts.

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html

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."

Copyright (c) 2016 IETF Trust and the persons identified as the
document authors.
All rights reserved.

This Internet-Draft will expire on April 5, 2017.

Abstract

The DNS work inside the IETF has suffered from mission-creep since a
clear scoping of what was DNS and what was not has not been easy to
find. This document attempts to clarify what is within scope of DNS
work and what is not.

. What is the Internet Domain Name System (DNS)?

The DNS was created to provide a scalable system for providing a
mapping between the name of an instance and the location or address
of that instance usually for other applications use [RFC830]. It has
three essential elements; an ephemeral namespace, servers which
instantiate the namespace; a suite of protocols that allow a client
or resolver to ask the servers questions about the namespace.

All three of these are required to say that the system is or is part
of DNS.  A fourth presumption is that there is always on, always
connected reachability across the DNS namespace.

The suite of protocols used between resolvers and servers, as well as
server and cache behaviour are within the purview of the IETF and its
working groups.

The Namespace is designed as an inverted tree, with a single root
context per protocol.  Although other protocols and domain name systems
were envisioned at the outset, today they are primarily vestigial, at
least as far as the IETF is concerned.  There is a single root, and one
namespace for the Internet DNS, as far as the IETF is concerned.

Traditionally, the IETF did not concern itself with the contents of the
namespace, leaving the management of the delegation points to the zone
maintainers, since this was always going to be a matter of local
preference.

These four constructs, in unison, have created the global Internet DNS,
as we know it.  However, the tools are so useful, others have borrowed
from them for other work. Recently other domain name systems have
emerged, as predicted 35 years ago, but they do not meet the critera
for the Internet DNS.

. What is NOT (strictly) the DNS.

It is possible, and has been implemented for decades, to change out
parts of the DNS namespace for ones own version. RFC 1035 2.2 clearly
suggests a goal is transport agility, but the use of a single, common,
namespace. [RFC1035] Split-DNS enables DNS-like services for private
spaces not connected to the Internet.  Often these private namespaces
augment the Internet namespace with other, non-Internet names.  As far
as the servers and resolvers are concerned, they still use the default
DNS protocols.  It is hard to tell if one is or is not using the DNS
or a facsimile just from the resolver side.

Others want to use the DNS namespace, but invent their own protocols
for server/resolver communication. These can be viewed as a domain
name system, but not an Internet DNS. Some want to change out the
concept of servers/resolvers, but use the namespace.

NONE of these hybrids is Internet DNS.  They are DNS-like, some are
parasitic some are symbiotic, but they are not Internet DNS.

It is a mistake for the IETF to treat these non-DNS issues as Internet
DNS related and it is a mistake for the IETF to get involved in
dictating to zone maintainers what labels they may or may not chose
to put into their delegations as long as the communications protocols
are ok with the labels the specific domain name system returns.

Those involved with the DNS should also avoid mission creep into
how other applications may or may not chose to utilize the names/labels
returned from a DNS query.  If the DNS working groups stay focused on
staying within their remit, other application developers will not have
to be so concerned with what the DNS does or does not, and if they
have to develop their own systems.

.  Security Considerations

   This document has no explicit security considerations.

.  IANA Considerations

   This document requires no IANA consideration.

.  References

5.1.  Normative References

[RFC830] Su, Z., "A Distributed System for Internet Name Service",
      RFC 830, October 1982, <http://www.rfc-editor.org/info/rfc830>.

[RFC1035] Mockapetris, P., "Domain names - implementation and
 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
   November 1987, <http://www.rfc-editor.org/info/rfc1035>.

Author

W. Manning
UA Partners
PO Box 1671
Medford, OR
USA 97501