< draft-ietf-dnsind-clarify-07.txt   draft-ietf-dnsind-clarify-08.txt >
Network Working Group Robert Elz Network Working Group Robert Elz
Internet Draft University of Melbourne Internet Draft University of Melbourne
Expiration Date: September 1997 Expiration Date: November 1997
Randy Bush Randy Bush
RGnet, Inc. RGnet, Inc.
March 1997 May 1997
Clarifications to the DNS Specification Clarifications to the DNS Specification
draft-ietf-dnsind-clarify-07.txt draft-ietf-dnsind-clarify-08.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
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
skipping to change at page 1, line 43 skipping to change at page 1, line 43
1. Abstract 1. Abstract
This draft considers some areas that have been identified as problems This draft considers some areas that have been identified as problems
with the specification of the Domain Name System, and proposes with the specification of the Domain Name System, and proposes
remedies for the defects identified. Eight separate issues are remedies for the defects identified. Eight separate issues are
considered: considered:
+ IP packet header address usage from multi-homed servers, + IP packet header address usage from multi-homed servers,
+ TTLs in sets of records with the same name, class, and type, + TTLs in sets of records with the same name, class, and type,
+ correct handling of zone cuts, + correct handling of zone cuts,
+ two minor issues concerning SOA records and their use, + three minor issues concerning SOA records and their use,
+ the precise definition of the Time to Live (TTL) + the precise definition of the Time to Live (TTL)
+ Use of the TC (truncated) header bit + Use of the TC (truncated) header bit
+ the issue of what is an authoritative, or canonical, name, + the issue of what is an authoritative, or canonical, name,
+ and the issue of what makes a valid DNS label. + and the issue of what makes a valid DNS label.
The first six of these are areas where the correct behaviour has been 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 somewhat unclear, we seek to rectify that. The other two are already
adequately specified, however the specifications seem to be sometimes adequately specified, however the specifications seem to be sometimes
ignored. We seek to reinforce the existing specifications. ignored. We seek to reinforce the existing specifications.
This versions ads two new minor clarifications, to the definition of This versions adds one new minor clarification, to the definition and
a TTL, and to use of the TC bit. This paragraph will be deleted from use of the SOA.mname field, and some editorial cleanups. This
the final version of this document. paragraph will be deleted from the final version of this document.
Contents Contents
1 Abstract ................................................... 1 1 Abstract ................................................... 1
2 Introduction ............................................... 2 2 Introduction ............................................... 2
3 Terminology ................................................ 3 3 Terminology ................................................ 3
4 Server Reply Source Address Selection ...................... 3 4 Server Reply Source Address Selection ...................... 3
5 Resource Record Sets ....................................... 4 5 Resource Record Sets ....................................... 4
6 Zone Cuts .................................................. 8 6 Zone Cuts .................................................. 8
7 SOA RRs .................................................... 10 7 SOA RRs .................................................... 10
8 Time to Live (TTL) ......................................... 10 8 Time to Live (TTL) ......................................... 10
9 The TC (truncated) header bit .............................. 11 9 The TC (truncated) header bit .............................. 11
10 Naming issues .............................................. 11 10 Naming issues .............................................. 11
11 Name syntax ................................................ 13 11 Name syntax ................................................ 13
12 Security Considerations .................................... 14 12 Security Considerations .................................... 14
13 References ................................................. 14 13 References ................................................. 14
14 Acknowledgements ........................................... 14 14 Acknowledgements ........................................... 15
15 Authors' addresses ......................................... 15 15 Authors' addresses ......................................... 15
2. Introduction 2. Introduction
Several problem areas in the Domain Name System specification Several problem areas in the Domain Name System specification
[RFC1034, RFC1035] have been noted through the years [RFC1123]. This [RFC1034, RFC1035] have been noted through the years [RFC1123]. This
draft addresses several additional problem areas. The issues here draft addresses several additional problem areas. The issues here
are independent. Those issues are the question of which source are independent. Those issues are the question of which source
address a multi-homed DNS server should use when replying to a query, 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, the issue of differing TTLs for DNS records with the same label,
skipping to change at page 3, line 28 skipping to change at page 3, line 28
Most, if not all, DNS clients, expect the address from which a reply Most, if not all, DNS clients, expect the address from which a reply
is received to be the same address as that to which the query is received to be the same address as that to which the query
eliciting the reply was sent. This is true for servers acting as eliciting the reply was sent. This is true for servers acting as
clients for the purposes of recursive query resolution, as well as clients for the purposes of recursive query resolution, as well as
simple resolver clients. The address, along with the identifier (ID) simple resolver clients. The address, along with the identifier (ID)
in the reply is used for disambiguating replies, and filtering in the reply is used for disambiguating replies, and filtering
spurious responses. This may, or may not, have been intended when spurious responses. This may, or may not, have been intended when
the DNS was designed, but is now a fact of life. the DNS was designed, but is now a fact of life.
Some multi-homed hosts running DNS servers fail to expect this usage. Some multi-homed hosts running DNS servers generate a reply using a
Consequently they send replies from a source address other than the source address that is not the same as the destination address from
destination address from the original query. This causes the reply the client's request packet. Such replies will be discarded by the
to be discarded by the client. client because the source address of the reply does not match that of
a host to which the client sent the original request. That is, it
appears to be an unsolicited response.
4.1. UDP Source Address Selection 4.1. UDP Source Address Selection
To avoid these problems, servers when responding to queries using UDP To avoid these problems, servers when responding to queries using UDP
must cause the reply to be sent with the source address field in the must cause the reply to be sent with the source address field in the
IP header set to the address that was in the destination address IP header set to the address that was in the destination address
field of the IP header of the packet containing the query causing the field of the IP header of the packet containing the query causing the
response. If this would cause the response to be sent from an IP response. If this would cause the response to be sent from an IP
address that is not permitted for this purpose, then the response may address that is not permitted for this purpose, then the response may
be sent from any legal IP address allocated to the server. That be sent from any legal IP address allocated to the server. That
skipping to change at page 4, line 49 skipping to change at page 4, line 49
caching server, where the TTLs for some but not all the RRs in the caching server, where the TTLs for some but not all the RRs in the
RRSet have expired. RRSet have expired.
Consequently the use of differing TTLs in an RRSet is hereby Consequently the use of differing TTLs in an RRSet is hereby
deprecated, the TTLs of all RRs in an RRSet must be the same. deprecated, the TTLs of all RRs in an RRSet must be the same.
Should a client receive a response containing RRs from an RRSet with Should a client receive a response containing RRs from an RRSet with
differing TTLs, it should treat this as an error. If the RRSet differing TTLs, it should treat this as an error. If the RRSet
concerned is from a non-authoritative source for this data, the concerned is from a non-authoritative source for this data, the
client should simply ignore the RRSet, and if the values were client should simply ignore the RRSet, and if the values were
required, seek to acquire them from an authoritative source. Should required, seek to acquire them from an authoritative source. Clients
an authoritative source send such a malformed RRSet, the client that are configured to send all queries to one, or more, particular
should treat the RRs for all purposes as if all TTLs in the RRSet had servers should treat those servers as authoritative for this purpose.
been set to the value of the lowest TTL in the RRSet. In no case may Should an authoritative source send such a malformed RRSet, the
a server send an RRSet with TTLs not all equal. client should treat the RRs for all purposes as if all TTLs in the
RRSet had been set to the value of the lowest TTL in the RRSet. In
no case may a server send an RRSet with TTLs not all equal.
5.3. DNSSEC Special Cases 5.3. DNSSEC Special Cases
Two of the record types added by DNS Security (DNSSEC) [RFC2065] Two of the record types added by DNS Security (DNSSEC) [RFC2065]
require special attention when considering the formation of Resource require special attention when considering the formation of Resource
Record Sets. Those are the SIG and NXT records. It should be noted Record Sets. Those are the SIG and NXT records. It should be noted
that DNS Security is still very new, and there is, as yet, little that DNS Security is still very new, and there is, as yet, little
experience with it. Readers should be prepared for the information experience with it. Readers should be prepared for the information
related to DNSSEC contained in this document to become outdated as related to DNSSEC contained in this document to become outdated as
the DNS Security specification matures. the DNS Security specification matures.
skipping to change at page 7, line 20 skipping to change at page 7, line 20
authoritative answer from a reply should replace cached data that had authoritative answer from a reply should replace cached data that had
been obtained from additional information in an earlier reply. been obtained from additional information in an earlier reply.
However additional information from a reply will be ignored if the However additional information from a reply will be ignored if the
cache contains data from an authoritative answer or a zone file. cache contains data from an authoritative answer or a zone file.
The accuracy of data available is assumed from its source. The accuracy of data available is assumed from its source.
Trustworthiness shall be, in order from most to least: Trustworthiness shall be, in order from most to least:
+ Data from a primary zone file, other than glue data, + Data from a primary zone file, other than glue data,
+ Data from a zone transfer, other than glue, + Data from a zone transfer, other than glue,
+ Data from the answer section of an authoritative reply, + The authoritative data included in the answer section of an
authoritative reply.
+ Data from the authority section of an authoritative answer, + Data from the authority section of an authoritative answer,
+ Glue from a primary zone, or glue from a zone transfer, + Glue from a primary zone, or glue from a zone transfer,
+ Data from the answer section of a non-authoritative answer, + Data from the answer section of a non-authoritative answer, and
non-authoritative data from the answer section of authoritative
answers,
+ Additional information from an authoritative answer, + Additional information from an authoritative answer,
Data from the authority section of a non-authoritative answer, Data from the authority section of a non-authoritative answer,
Additional information from non-authoritative answers. Additional information from non-authoritative answers.
Note that the answer section of an authoritative answer normally
contains only authoritative data. However when the name sought is an
alias (see section 10.1.1) only the record describing that alias is
necessarily authoritative. Clients should assume that other records
may have come from the server's cache. Where authoritative answers
are required, the client should query again, using the canonical name
associated with the alias.
Unauthenticated RRs received and cached from the least trustworthy of Unauthenticated RRs received and cached from the least trustworthy of
those groupings, that is data from the additional data section, and those groupings, that is data from the additional data section, and
data from the authority section of a non-authoritative answer, should data from the authority section of a non-authoritative answer, should
not be cached in such a way that they would ever be returned as not be cached in such a way that they would ever be returned as
answers to a received query. They may be returned as additional answers to a received query. They may be returned as additional
information where appropriate. Ignoring this would allow the information where appropriate. Ignoring this would allow the
trustworthiness of relatively untrustworthy data to be increased trustworthiness of relatively untrustworthy data to be increased
without cause or excuse. without cause or excuse.
When DNS security [RFC2065] is in use, and an authenticated reply has When DNS security [RFC2065] is in use, and an authenticated reply has
skipping to change at page 10, line 7 skipping to change at page 10, line 11
subzone. Where a subzone is secure, the KEY and SIG records will be subzone. Where a subzone is secure, the KEY and SIG records will be
present, and authoritative, in that zone, but should also always be present, and authoritative, in that zone, but should also always be
present in the parent zone (if secure). present in the parent zone (if secure).
Note that in none of these cases should a server for the parent zone, Note that in none of these cases should a server for the parent zone,
not also being a server for the subzone, set the AA bit in any not also being a server for the subzone, set the AA bit in any
response for a label at a zone cut. response for a label at a zone cut.
7. SOA RRs 7. SOA RRs
Two minor issues concerning the Start of Zone of Authority (SOA) Three minor issues concerning the Start of Zone of Authority (SOA)
Resource Record need some clarification. Resource Record need some clarification.
7.1. Placement of SOA RRs in authoritative answers 7.1. Placement of SOA RRs in authoritative answers
RFC1034, in section 3.7, indicates that the authority section of an RFC1034, in section 3.7, indicates that the authority section of an
authoritative answer may contain the SOA record for the zone from authoritative answer may contain the SOA record for the zone from
which the answer was obtained. When discussing negative caching, which the answer was obtained. When discussing negative caching,
RFC1034 section 4.3.4 refers to this technique but mentions the RFC1034 section 4.3.4 refers to this technique but mentions the
additional section of the response. The former is correct, as is additional section of the response. The former is correct, as is
implied by the example shown in section 6.2.5 of RFC1034. SOA implied by the example shown in section 6.2.5 of RFC1034. SOA
skipping to change at page 10, line 30 skipping to change at page 10, line 34
7.2. TTLs on SOA RRs 7.2. TTLs on SOA RRs
It may be observed that in section 3.2.1 of RFC1035, which defines 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 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 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 should always be sent as zero to prevent caching. This is mentioned
nowhere else, and has not generally been implemented. nowhere else, and has not generally been implemented.
Implementations should not assume that SOA records will have a TTL of 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. zero, nor are they required to send SOA records with a TTL of zero.
7.3. The SOA.MNAME field
It is quite clear in the specifications, yet seems to have been
widely ignored, that the MNAME field of the SOA record should contain
the name of the primary (master) server for the zone identified by
the SOA. It should not contain the name of the zone itself. That
information would be useless, as to discover it, one needs to start
with the domain name of the SOA record - that is the name of the
zone.
8. Time to Live (TTL) 8. Time to Live (TTL)
The definition of values appropriate to the TTL field in STD 13 is The definition of values appropriate to the TTL field in STD 13 is
not as clear as it could be, with respect to how many significant not as clear as it could be, with respect to how many significant
bits exist, and whether the value is signed or unsigned. It is bits exist, and whether the value is signed or unsigned. It is
hereby specified that a TTL value is an unsigned number, with a hereby specified that a TTL value is an unsigned number, with a
minimum value of 0, and a maximum value of 2147483647. That is, a minimum value of 0, and a maximum value of 2147483647. That is, a
maximum of 2^31 - 1. When transmitted, this value shall be encoded maximum of 2^31 - 1. When transmitted, this value shall be encoded
in the less significant 31 bits of the 32 bit TTL field, with the in the less significant 31 bits of the 32 bit TTL field, with the
most significant, or sign, bit set to zero. most significant, or sign, bit set to zero.
skipping to change at page 11, line 29 skipping to change at page 11, line 38
set, it should ignore that response, and query again, using a set, it should ignore that response, and query again, using a
mechanism, such as a TCP connection, that will permit larger replies. mechanism, such as a TCP connection, that will permit larger replies.
10. Naming issues 10. Naming issues
It has sometimes been inferred from some sections of the DNS It has sometimes been inferred from some sections of the DNS
specification [RFC1034, RFC1035] that a host, or perhaps an interface specification [RFC1034, RFC1035] that a host, or perhaps an interface
of a host, is permitted exactly one authoritative, or official, name, of a host, is permitted exactly one authoritative, or official, name,
called the canonical name. There is no such requirement in the DNS. called the canonical name. There is no such requirement in the DNS.
10.1. CNAME records 10.1. CNAME resource records
The DNS CNAME ("canonical name") record exists to provide the The DNS CNAME ("canonical name") record exists to provide the
canonical name associated with an alias name. There may be only one canonical name associated with an alias name. There may be only one
such canonical name for any one alias. That name should generally be such canonical name for any one alias. That name should generally be
a name that exists elsewhere in the DNS, though some applications for a name that exists elsewhere in the DNS, though there are some rare
aliases with no accompanying canonical name exist. An alias name applications for aliases with the accompanying canonical name
(label of a CNAME record) may, if DNSSEC is in use, have SIG, NXT, undefined in the DNS. An alias name (label of a CNAME record) may,
and KEY RRs, but may have no other data. That is, for any label in if DNSSEC is in use, have SIG, NXT, and KEY RRs, but may have no
the DNS (any domain name) exactly one of the following is true: 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 + one CNAME record exists, optionally accompanied by SIG, NXT, and
KEY RRs, KEY RRs,
+ one or more records exist, none being CNAME records, + one or more records exist, none being CNAME records,
+ the name exists, but has no associated RRs of any type, + the name exists, but has no associated RRs of any type,
+ the name does not exist at all. + the name does not exist at all.
10.1.1. CNAME terminology 10.1.1. CNAME terminology
It has been traditional to refer to the label of a CNAME record as "a It has been traditional to refer to the label of a CNAME record as "a
skipping to change at page 12, line 49 skipping to change at page 13, line 15
Searching for either NS or MX records causes "additional section Searching for either NS or MX records causes "additional section
processing" in which address records associated with the value of the processing" in which address records associated with the value of the
record sought are appended to the answer. This helps avoid needless record sought are appended to the answer. This helps avoid needless
extra queries that are easily anticipated when the first was made. extra queries that are easily anticipated when the first was made.
Additional section processing does not include CNAME records, let Additional section processing does not include CNAME records, let
alone the address records that may be associated with the canonical 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 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 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 value. This can cause extra queries, and extra network burden, on
every query. It is trivial to avoid this by resolving the alias and every query. It is trivial for the DNS administrator to avoid this
placing the canonical name directly in the affected record just once by resolving the alias and placing the canonical name directly in the
when it is updated or installed. In some particular hard cases the affected record just once when it is updated or installed. In some
lack of the additional section address records in the results of a NS particular hard cases the lack of the additional section address
lookup can cause the request to fail. records in the results of a NS lookup can cause the request to fail.
11. Name syntax 11. Name syntax
Occasionally it is assumed that the Domain Name System serves only Occasionally it is assumed that the Domain Name System serves only
the purpose of mapping Internet host names to data, and mapping the purpose of mapping Internet host names to data, and mapping
Internet addresses to host names. This is not correct, the DNS is a Internet addresses to host names. This is not correct, the DNS is a
general (if somewhat limited) hierarchical database, and can store general (if somewhat limited) hierarchical database, and can store
almost any kind of data, for almost any purpose. almost any kind of data, for almost any purpose.
The DNS itself places only one restriction on the particular labels The DNS itself places only one restriction on the particular labels
skipping to change at page 14, line 49 skipping to change at page 15, line 14
14. Acknowledgements 14. Acknowledgements
This memo arose from discussions in the DNSIND working group of the This memo arose from discussions in the DNSIND working group of the
IETF in 1995 and 1996, the members of that working group are largely IETF in 1995 and 1996, the members of that working group are largely
responsible for the ideas captured herein. Particular thanks to responsible for the ideas captured herein. Particular thanks to
Donald E. Eastlake, 3rd, and Olafur Gudmundsson, for help with the Donald E. Eastlake, 3rd, and Olafur Gudmundsson, for help with the
DNSSEC issues in this document, and to John Gilmore for pointing out DNSSEC issues in this document, and to John Gilmore for pointing out
where the clarifications were not necessarily clarifying. Bob Halley where the clarifications were not necessarily clarifying. Bob Halley
suggested clarifying the placement of SOA records in authoritative suggested clarifying the placement of SOA records in authoritative
answers, and provided the references. Michael Patton, as usual, Mark answers, and provided the references. Michael Patton, as usual, and
Andrews, and Alan Barrett provided much assistance with many details. Mark Andrews, Alan Barrett and Stan Barber provided much assistance
with many details. Josh Littlefield helped make sure that the
clarifications didn't cause problems in some irritating corner cases.
15. Authors' addresses 15. Authors' addresses
Robert Elz Robert Elz
Computer Science Computer Science
University of Melbourne University of Melbourne
Parkville, Victoria, 3052 Parkville, Victoria, 3052
Australia. Australia.
EMail: kre@munnari.OZ.AU EMail: kre@munnari.OZ.AU
Randy Bush Randy Bush
RGnet, Inc. RGnet, Inc.
10361 NE Sasquatch Lane 5147 Crystal Springs Drive NE
Bainbridge Island, Washington, 98110 Bainbridge Island, Washington, 98110
United States. United States.
EMail: randy@psg.com EMail: randy@psg.com
 End of changes. 18 change blocks. 
34 lines changed or deleted 62 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/