Clarifications to the DNS Specification
RFC 2181
|
| Document |
Type |
|
RFC - Proposed Standard
(July 1997; No errata)
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 2181 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group R. Elz
Request for Comments: 2181 University of Melbourne
Updates: 1034, 1035, 1123 R. Bush
Category: Standards Track RGnet, Inc.
July 1997
Clarifications to the DNS Specification
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
1. Abstract
This document considers some areas that have been identified as
problems with the specification of the Domain Name System, and
proposes remedies for the defects identified. Eight separate issues
are considered:
+ IP packet header address usage from multi-homed servers,
+ TTLs in sets of records with the same name, class, and type,
+ correct handling of zone cuts,
+ three minor issues concerning SOA records and their use,
+ the precise definition of the Time to Live (TTL)
+ Use of the TC (truncated) header bit
+ the issue of what is an authoritative, or canonical, name,
+ and the issue of what makes a valid DNS label.
The first six of these are areas where the correct behaviour has been
somewhat unclear, we seek to rectify that. The other two are already
adequately specified, however the specifications seem to be sometimes
ignored. We seek to reinforce the existing specifications.
Elz & Bush Standards Track [Page 1]
RFC 2181 Clarifications to the DNS Specification July 1997
Contents
1 Abstract ................................................... 1
2 Introduction ............................................... 2
3 Terminology ................................................ 3
4 Server Reply Source Address Selection ...................... 3
5 Resource Record Sets ....................................... 4
6 Zone Cuts .................................................. 8
7 SOA RRs .................................................... 10
8 Time to Live (TTL) ......................................... 10
9 The TC (truncated) header bit .............................. 11
10 Naming issues .............................................. 11
11 Name syntax ................................................ 13
12 Security Considerations .................................... 14
13 References ................................................. 14
14 Acknowledgements ........................................... 15
15 Authors' Addresses ......................................... 15
2. Introduction
Several problem areas in the Domain Name System specification
[RFC1034, RFC1035] have been noted through the years [RFC1123]. This
document addresses several additional problem areas. The issues here
are independent. Those issues are the question of which source
address a multi-homed DNS server should use when replying to a query,
the issue of differing TTLs for DNS records with the same label,
class and type, and the issue of canonical names, what they are, how
CNAME records relate, what names are legal in what parts of the DNS,
and what is the valid syntax of a DNS name.
Clarifications to the DNS specification to avoid these problems are
made in this memo. A minor ambiguity in RFC1034 concerned with SOA
records is also corrected, as is one in the definition of the TTL
(Time To Live) and some possible confusion in use of the TC bit.
Elz & Bush Standards Track [Page 2]
RFC 2181 Clarifications to the DNS Specification July 1997
3. Terminology
This memo does not use the oft used expressions MUST, SHOULD, MAY, or
their negative forms. In some sections it may seem that a
specification is worded mildly, and hence some may infer that the
specification is optional. That is not correct. Anywhere that this
memo suggests that some action should be carried out, or must be
carried out, or that some behaviour is acceptable, or not, that is to
be considered as a fundamental aspect of this specification,
regardless of the specific words used. If some behaviour or action
is truly optional, that will be clearly specified by the text.
4. Server Reply Source Address Selection
Show full document text