Internet DRAFT - draft-pfrc-2181--naming-issues
draft-pfrc-2181--naming-issues
INTERNET-DRAFT Declan Ma, Ed.
Intended Status: Proposed Standard zDNS Ltd.
Expires: 2015-10-15 2015-05-22
DNS Naming Issues
draft-pfrc-2181--naming-issues-00
Abstract
RFC 2181 collected eight independent considerations and created a single
docuement to address each of them in turn. Over the following two decades
it has become clear that each of these items should be considered and evovolve
in its own right, as suggested in RFC 2181. This document extracts the exact
text from RFC 2181 and places it into its own track.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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.
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."
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
Copyright and License Notice
Copyright (c) 2015 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
(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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Declan Ma, Ed. Expires 2015-10-15 [Page 1]
INTERNET DRAFT DNS Naming Issues 2015-05-22
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3 CNAME resource records . . . . . . . . . . . . . . . . . . . . 3
4 CNAME terminology . . . . . . . . . . . . . . . . . . . . . . . 3
5 PTR records . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6 MX and NS records . . . . . . . . . . . . . . . . . . . . . . . 4
7 Security Considerations . . . . . . . . . . . . . . . . . . . . 5
8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 5
Declan Ma, Ed. Expires 2015-10-15 [Page 2]
INTERNET DRAFT DNS Naming Issues 2015-05-22
1 Introduction
It has sometimes been inferred from some sections of the DNS
specification [RFC1034, RFC1035] that a host, or perhaps an interface
of a host, is permitted exactly one authoritative, or official, name,
called the canonical name. There is no such requirement in the DNS.
This document is intended to describe the issue of what is an
authoritative, or canonical, name.
2 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3 CNAME resource records
The DNS CNAME ("canonical name") record exists to provide the
canonical name associated with an alias name. There may be only one
such canonical name for any one alias. That name should generally be
a name that exists elsewhere in the DNS, though there are some rare
applications for aliases with the accompanying canonical name
undefined in the DNS. An alias name (label of a CNAME record) may,
if DNSSEC is in use, have SIG, NXT, and KEY RRs, but may have no
other data. That is, for any label in the DNS (any domain name)
exactly one of the following is true:
+ one CNAME record exists, optionally accompanied by SIG, NXT, and
KEY RRs,
+ one or more records exist, none being CNAME records,
+ the name exists, but has no associated RRs of any type,
+ the name does not exist at all.
4 CNAME terminology
It has been traditional to refer to the label of a CNAME record as "a
CNAME". This is unfortunate, as "CNAME" is an abbreviation of
"canonical name", and the label of a CNAME record is most certainly
not a canonical name. It is, however, an entrenched usage. Care
must therefore be taken to be very clear whether the label, or the
value (the canonical name) of a CNAME resource record is intended. In
this document, the label of a CNAME resource record will always be
referred to as an alias.
Declan Ma, Ed. Expires 2015-10-15 [Page 3]
INTERNET DRAFT DNS Naming Issues 2015-05-22
5 PTR records
Confusion about canonical names has lead to a belief that a PTR
record should have exactly one RR in its RRSet. This is incorrect,
the relevant section of RFC1034 (section 3.6.2) indicates that the
value of a PTR record should be a canonical name. That is, it should
not be an alias. There is no implication in that section that only
one PTR record is permitted for a name. No such restriction should
be inferred.
Note that while the value of a PTR record must not be an alias, there
is no requirement that the process of resolving a PTR record not
encounter any aliases. The label that is being looked up for a PTR
value might have a CNAME record. That is, it might be an alias. The
value of that CNAME RR, if not another alias, which it should not be,
will give the location where the PTR record is found. That record
gives the result of the PTR type lookup. This final result, the
value of the PTR RR, is the label which must not be an alias.
6 MX and NS records
The domain name used as the value of a NS resource record, or part of
the value of a MX resource record must not be an alias. Not only is
the specification clear on this point, but using an alias in either
of these positions neither works as well as might be hoped, nor well
fulfills the ambition that may have led to this approach. This
domain name must have as its value one or more address records.
Currently those will be A records, however in the future other record
types giving addressing information may be acceptable. It can also
have other RRs, but never a CNAME RR.
Searching for either NS or MX records causes "additional section
processing" in which address records associated with the value of the
record sought are appended to the answer. This helps avoid needless
extra queries that are easily anticipated when the first was made.
Additional section processing does not include CNAME records, let
alone the address records that may be associated with the canonical
name derived from the alias. Thus, if an alias is used as the value
of an NS or MX record, no address will be returned with the NS or MX
value. This can cause extra queries, and extra network burden, on
every query. It is trivial for the DNS administrator to avoid this
by resolving the alias and placing the canonical name directly in the
affected record just once when it is updated or installed. In some
particular hard cases the lack of the additional section address
records in the results of a NS lookup can cause the request to fail.
Declan Ma, Ed. Expires 2015-10-15 [Page 4]
INTERNET DRAFT DNS Naming Issues 2015-05-22
7 Security Considerations
It may be observed that in section 3.2.1 of RFC1035, which defines
the format of a Resource Record, that the definition of the TTL field
contains a throw away line which states that the TTL of an SOA record
should always be sent as zero to prevent caching. This is mentioned
nowhere else, and has not generally been implemented. Implementations
should not assume that SOA records will have a TTL of zero, nor are
they required to send SOA records with a TTL of zero.
8 References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2199] Ramos, A., "Request for Comments Summary RFC Numbers 2100-
2199", RFC 2199, January 1998.
9 Authors' Addresses
Declan Ma
ZDNS Ltd.
4, South 4th Street, Zhongguancun,
Haidian, Beijing 100190,
Declan Ma, Ed. Expires 2015-10-15 [Page 5]
