< draft-ietf-dnsind-clarify-04.txt   draft-ietf-dnsind-clarify-05.txt >
Network Working Group Robert Elz Network Working Group Robert Elz
Internet Draft University of Melbourne Internet Draft University of Melbourne
Expiration Date: July 1997 Expiration Date: August 1997
Randy Bush Randy Bush
RGnet, Inc. RGnet, Inc.
January 1997 February 1997
Clarifications to the DNS Specification Clarifications to the DNS Specification
draft-ietf-dnsind-clarify-04.txt draft-ietf-dnsind-clarify-05.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 37 skipping to change at page 1, line 37
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast). ftp.isi.edu (US West Coast).
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. Five separate issues are remedies for the defects identified. Six 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,
+ 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 three of these are areas where the correct behaviour has The first four of these are areas where the correct behaviour has
been somewhat unclear, we seek to rectify that. The other two are been somewhat unclear, we seek to rectify that. The other two are
already adequately specified, however the specifications seem to be already adequately specified, however the specifications seem to be
sometimes ignored. We seek to reinforce the existing specifications. sometimes ignored. We seek to reinforce the existing specifications.
This version contains corrections and clarifications as suggested on This version adds a brief discussion on the placement of an SOA
the mailing list. Most notable is a change to the order of record in the answer to an authoritative query, and the issue of TTLs
preference of similar information from multiple sources. on SOA records. It also contains rather more discussion inspired by
the oddities of some of the new DNSSEC record types. The ordered
list of trustworthiness of various data types was revised by grouping
the last three categories together, and adding a restriction on how
such data should be used. Many editorial changes were made. This
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 ................................................ 2 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 .................................................. 6 6 Zone Cuts .................................................. 8
7 Naming issues .............................................. 7 7 SOA RRs .................................................... 9
8 Name syntax ................................................ 9 8 Naming issues .............................................. 10
9 Security Considerations .................................... 10 9 Name syntax ................................................ 12
10 References ................................................. 10 10 Security Considerations .................................... 13
11 Acknowledgements ........................................... 10 11 References ................................................. 13
12 Authors' addresses ......................................... 11 12 Acknowledgements ........................................... 13
13 Authors' addresses ......................................... 14
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,
class and type, and the issue of canonical names, what they are, how 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, CNAME records relate, what names are legal in what parts of the DNS,
and what is the valid syntax of a DNS name. and what is the valid syntax of a DNS name.
Clarifications to the DNS specification to avoid these problems are Clarifications to the DNS specification to avoid these problems are
made in this memo. made in this memo. A minor ambiguity in RFC1034 concerned with SOA
records is also corrected.
3. Terminology 3. Terminology
This memo does not use the oft used expressions MUST, SHOULD, MAY, or This memo does not use the oft used expressions MUST, SHOULD, MAY, or
their negative forms. In some sections it may seem that a their negative forms. In some sections it may seem that a
specification is worded mildly, and hence some may infer that the specification is worded mildly, and hence some may infer that the
specification is optional. That is not correct. Anywhere that this specification is optional. That is not correct. Anywhere that this
memo suggests that some action should be carried out, or must be 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 carried out, or that some behaviour is acceptable, or not, that is to
be considered as a fundamental aspect of this specification, be considered as a fundamental aspect of this specification,
regardless of the specific words used. If some behaviour or action regardless of the specific words used. If some behaviour or action
is truly optional, that will be clearly specified by the text. is truly optional, that will be clearly specified by the text.
4. Server Reply Source Address Selection 4. Server Reply Source Address Selection
Most, if not all, DNS clients, whether servers acting as clients for Most, if not all, DNS clients, expect the address from which a reply
the purposes of recursive query resolution, or resolvers, expect the is received to be the same address as that to which the query
address from which a reply is received to be the same address as that eliciting the reply was sent. This is true for servers acting as
to which the query eliciting the reply was sent. This, along with clients for the purposes of recursive query resolution, as well as
the identifier (ID) in the reply is used for disambiguating replies, simple resolver clients. The address, along with the identifier (ID)
and filtering spurious responses. This may, or may not, have been in the reply is used for disambiguating replies, and filtering
intended when the DNS was designed, but is now a fact of life. spurious responses. This may, or may not, have been intended when
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 fail to expect this usage.
Consequently they send replies from the "wrong" source address, Consequently they send replies from a source address other than the
causing the reply to be discarded by the client. destination address from the original query. This causes the reply
to be discarded by the client.
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 11 skipping to change at page 4, line 22
the port to which they were directed. Except in extraordinary the port to which they were directed. Except in extraordinary
circumstances, this will be the well known port assigned for DNS circumstances, this will be the well known port assigned for DNS
queries [RFC1700]. queries [RFC1700].
5. Resource Record Sets 5. Resource Record Sets
Each DNS Resource Record (RR) has a label, class, type, and data. It Each DNS Resource Record (RR) has a label, class, type, and data. It
is meaningless for two records to ever have label, class, type and is meaningless for two records to ever have label, class, type and
data all equal - servers should suppress such duplicates if data all equal - servers should suppress such duplicates if
encountered. It is however possible for most record types to exist encountered. It is however possible for most record types to exist
with the same label class and type, but with different data. Such a with the same label, class and type, but with different data. Such a
group of records is hereby defined to be a Resource Record Set group of records is hereby defined to be a Resource Record Set
(RRSet). (RRSet).
5.1. Sending RRs from an RRSet 5.1. Sending RRs from an RRSet
A query for a specific (or non-specific) label, class, and type, will A query for a specific (or non-specific) label, class, and type, will
always return all records in the associated RRSet - whether that be always return all records in the associated RRSet - whether that be
one or more RRs. The response must be marked as "truncated" if the one or more RRs. The response must be marked as "truncated" if the
entire RRSet will not fit in the response. entire RRSet will not fit in the response.
skipping to change at page 4, line 39 skipping to change at page 5, line 5
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 the RRs for all purposes as if all differing TTLs, it 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 TTLs in the RRSet had been set to the value of the lowest TTL in the
RRSet. RRSet.
5.3. Receiving RRSets 5.3. DNSSEC Special Cases
Two of the record types added by DNS Security (DNSSEC) [RFC2065]
require special attention when considering the formation of Resource
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
experience with it. Readers should be prepared for the information
related to DNSSEC contained in this document to become outdated as
the DNS Security specification matures.
5.3.1. SIG records and RRSets
A SIG records provides signature (validation) data for another RRSet
in the DNS. Where a zone has been signed, every RRSet in the zone
will have had a SIG record associated with it. The data type of the
RRSet is included in the data of the SIG RR, to indicate with which
particular RRSet this SIG record is associated. Were the rules above
applied, whenever a SIG record was included with a response to
validate that response, the SIG records for all other RRSets
associated with the appropriate node would also need to be included.
In some cases, this could be a very large number of records, not
helped by their being rather large RRs.
Thus, it is specifically permitted for only those SIG RRs with the
"type covered" field equal to the type field of an answer being
returned need be included in the authority section as validation
data. However, where SIG records are being returned in the answer
section, in response to a query for SIG records, or a query for all
records associated with a name (type=ANY) the entire SIG RRSet must
be included, as for any other RR type.
Servers that receive responses containing SIG records in the
authority section, or (probably incorrectly) as additional data, must
understand that the entire RRSet has almost certainly not been
included. Thus, they must not cache that SIG record in a way that
would permit it to be returned should a query for SIG records be
received at that server. RFC2065 actually requires that SIG queries
be directed only to authoritative servers to avoid the problems that
could be caused here, and while servers exist that do not understand
the special properties of SIG records, this will remain necessary.
However, careful design of SIG record processing in new
implementations should permit this restriction to be relaxed in the
future, so resolvers do not need to treat SIG record queries
specially.
It has been occasionally stated that a received request for a SIG
record should be forwarded to an authoritative server, rather than
being answered from data in the cache. This is not necessary - a
server that has the knowledge of SIG as a special case for processing
this way would be better to correctly cache SIG records, taking into
account their characteristics. Then the server can determine when it
is safe to reply from the cache, and when the answer is not available
and the query must be forwarded.
5.3.2. NXT RRs
Next Resource Records (NXT) are even more peculiar. There will only
ever be one NXT record in a zone for a particular label, so
superficially, the RRSet problem is trivial. However, at a zone cut,
both the parent zone, and the child zone (superzone and subzone in
RFC2065 terminology) will have NXT records for the same name. Those
two NXT records do not form an RRSet, even where both zones are
housed at the same server. NXT RRSets always contain just a single
RR. Where both NXT records are visible, two RRSets exist. However,
servers are not required to treat this as a special case when
receiving NXT records in a response. They may elect to notice the
existence of two different NXT RRSets, and treat that as they would
two different RRSets of any other type. That is, cache one, and
ignore the other. Security aware servers will need to correctly
process the NXT record in the received response though.
5.4. Receiving RRSets
Servers must never merge RRs from a response with RRs in their cache Servers must never merge RRs from a response with RRs in their cache
to form an RRSet. If a response contains data that would form an to form an RRSet. If a response contains data that would form an
RRSet with data in a server's cache the server must either ignore the RRSet with data in a server's cache the server must either ignore the
RRs in the response, or discard the entire the existing RRSet in the RRs in the response, or discard the entire RRSet currently in the
cache, as appropriate. Consequently the issue of TTLs varying cache, as appropriate. Consequently the issue of TTLs varying
between the cache and a response does not cause concern, one will be between the cache and a response does not cause concern, one will be
ignored. That is, one of the data sets is always incorrect if the ignored. That is, one of the data sets is always incorrect if the
data from an answer differs from the data in the cache. The data from an answer differs from the data in the cache. The
challenge for the server is to determine which of the data sets is challenge for the server is to determine which of the data sets is
correct, if one is, and retain that, while ignoring the other. Note correct, if one is, and retain that, while ignoring the other. Note
that if a server receives an answer containing an RRSet that is that if a server receives an answer containing an RRSet that is
identical to that in its cache, with the possible exception of the identical to that in its cache, with the possible exception of the
TTL value, it may, optionally, update the TTL in its cache with the TTL value, it may, optionally, update the TTL in its cache with the
TTL of the received answer. It should do this if the received answer TTL of the received answer. It should do this if the received answer
would be considered more authoritative (as discussed in the next would be considered more authoritative (as discussed in the next
section) than the previously cached answer. section) than the previously cached answer.
5.3.1. Ranking data 5.4.1. Ranking data
When considering whether to accept an RRSet in a reply, or retain an When considering whether to accept an RRSet in a reply, or retain an
RRSet already in its cache instead, a server should consider the RRSet already in its cache instead, a server should consider the
relative likely trustworthiness of the various data. An relative likely trustworthiness of the various data. An
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,
+ That from the answer section of an authoritative reply, + Data from 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,
+ 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.
Unauthenticated RRs received and cached from the least trustworthy of
those groupings, that is data from the additional data section, and
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
answers to a received query. They may be returned as additional
information where appropriate. Ignoring this would allow the
trustworthiness of relatively untrustworthy data to be increased
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
been received and verified, the data thus authenticated shall be been received and verified, the data thus authenticated shall be
considered more trustworthy than unauthenticated data of the same considered more trustworthy than unauthenticated data of the same
type. Note that throughout this document, "authoritative" means a type. Note that throughout this document, "authoritative" means a
reply with the AA bit set. DNSSEC uses trusted chains of SIG and KEY reply with the AA bit set. DNSSEC uses trusted chains of SIG and KEY
records to determine the authenticity of data, the AA bit is almost records to determine the authenticity of data, the AA bit is almost
irrelevant. However DNSSEC aware servers must still correctly set irrelevant. However DNSSEC aware servers must still correctly set
the AA bit in responses to enable correct operation with servers that the AA bit in responses to enable correct operation with servers that
are not security aware (almost all currently). are not security aware (almost all currently).
Note that, glue excluded, it is impossible for data from two primary Note that, glue excluded, it is impossible for data from two
zone files, two secondary zones (data from zone transfers) or data correctly configured primary zone files, two correctly configured
from primary and secondary zones to ever conflict. Where glue for secondary zones (data from zone transfers) or data from correctly
the same name exists in multiple zones, and differs in value, the configured primary and secondary zones to ever conflict. Where glue
for the same name exists in multiple zones, and differs in value, the
nameserver should select data from a primary zone file in preference nameserver should select data from a primary zone file in preference
to secondary, but otherwise may choose any single set of such data. to secondary, but otherwise may choose any single set of such data.
Choosing that which appears to come from a source nearer the Choosing that which appears to come from a source nearer the
authoritative data source may make sense where that can be authoritative data source may make sense where that can be
determined. Choosing primary data over secondary allows the source determined. Choosing primary data over secondary allows the source
of incorrect glue data to be discovered more readily, when a problem of incorrect glue data to be discovered more readily, when a problem
with such data exists. with such data exists. Where a server can detect from two zone files
that one or more are incorrectly configured, so as to create
conflicts, it should refuse to load the zones determined to be
erroneous, and issue suitable diagnostics.
"Glue" above includes any record in a zone file that is not properly "Glue" above includes any record in a zone file that is not properly
part of that zone, including nameserver records of delegated sub- part of that zone, including nameserver records of delegated sub-
zones (NS records), address records that accompany those NS records zones (NS records), address records that accompany those NS records
(A, AAAA, etc), and any other stray data that might appear. (A, AAAA, etc), and any other stray data that might appear.
5.4. Sending RRSets (reprise) 5.5. Sending RRSets (reprise)
A Resource Record Set should only be included once in any DNS reply. A Resource Record Set should only be included once in any DNS reply.
It may occur in any of the Answer, Authority, or Additional It may occur in any of the Answer, Authority, or Additional
Information sections, as required, however should not be repeated in Information sections, as required. However it should not be repeated
the same, or any other, section, except where explicitly required by in the same, or any other, section, except where explicitly required
a specification. For example, an AXFR response requires the SOA by a specification. For example, an AXFR response requires the SOA
record (always an RRSet containing a single RR) be both the first and record (always an RRSet containing a single RR) be both the first and
last record of the reply. Where duplicates are required this way, last record of the reply. Where duplicates are required this way,
the TTL transmitted in each case must be the same. the TTL transmitted in each case must be the same.
6. Zone Cuts 6. Zone Cuts
A "Zone" is a set of one, or usually, more, domains collected and The DNS tree is divided into "zones", which are collections of
treated as a unit. A "Zone Cut" is the division between one zone and domains that are treated as a unit for certain management purposes.
another. A zone comprises some subset of the DNS tree, rooted at a Zones are delimited by "zone cuts". Each zone cut separates a
domain known as the "origin" of the zone. The origin domain itself, "child" zone (below the cut) from a "parent" zone (above the cut).
and some, or all, of its sub-domains, form the zone. The existence The domain name that appears at the top of a zone (just below the cut
of a zone cut is indicated by the presence, in the zone, of a that separates the zone from its parent) is called the zone's
NameServer (NS) record for any domain other than the origin of the "origin". The name of the zone is the same as the name of the domain
zone. at the zone's origin. Each zone comprises that subset of the DNS
tree that is at or below the zone's origin, and that is above the
cuts that separate the zone from its children (if any). The
existence of a zone cut is indicated in the parent zone by the
existence of NS records specifying the origin of the child zone. A
child zone does not contain any explicit reference to its parent.
6.1. Zone authority 6.1. Zone authority
The authoritative servers for a zone are enumerated in the NS records The authoritative servers for a zone are enumerated in the NS records
for the origin of the zone, which, along with a Start of Authority for the origin of the zone, which, along with a Start of Authority
(SOA) record are the mandatory records in every zone. Such a server (SOA) record are the mandatory records in every zone. Such a server
is authoritative for all resource records in a zone that are not in is authoritative for all resource records in a zone that are not in
another zone. The NS records that indicate a zone cut are the another zone. The NS records that indicate a zone cut are the
property of the child zone created, as are any other records for the property of the child zone created, as are any other records for the
origin of that child zone, or any sub-domains of it. A server for a origin of that child zone, or any sub-domains of it. A server for a
skipping to change at page 7, line 14 skipping to change at page 9, line 20
6.2. DNSSEC issues 6.2. DNSSEC issues
The DNS security mechanisms [RFC2065] complicate this somewhat, as The DNS security mechanisms [RFC2065] complicate this somewhat, as
some of the new resource record types added are very unusual when some of the new resource record types added are very unusual when
compared with other DNS RRs. In particular the NXT ("next") RR type compared with other DNS RRs. In particular the NXT ("next") RR type
contains information about which names exist in a zone, and hence contains information about which names exist in a zone, and hence
which do not, and thus must necessarily relate to the zone in which which do not, and thus must necessarily relate to the zone in which
it exists. The same domain name may have different NXT records in it exists. The same domain name may have different NXT records in
the parent zone and the child zone, and both are valid, and are not the parent zone and the child zone, and both are valid, and are not
an RRSet. an RRSet. See also section 5.3.2.
Since NXT records are intended to be automatically generated, rather Since NXT records are intended to be automatically generated, rather
than configured by DNS operators, servers may, but are not required than configured by DNS operators, servers may, but are not required
to, retain all differing NXT records they receive regardless of the to, retain all differing NXT records they receive regardless of the
rules in section 5.3. rules in section 5.4.
For a secure parent zone to securely indicate that a subzone is For a secure parent zone to securely indicate that a subzone is
insecure, DNSSEC requires that a KEY RR indicating that the subzone insecure, DNSSEC requires that a KEY RR indicating that the subzone
is insecure, and the parent zone's authenticating SIG RR(s) be is insecure, and the parent zone's authenticating SIG RR(s) be
present in the parent zone, as they by definition cannot be in the present in the parent zone, as they by definition cannot be in the
subzone. Where a subzone is secure, the KEY and SIG can be subzone. Where a subzone is secure, the KEY and SIG records will be
duplicated in both zone files, but should always be present in the present, and authoritative, in that zone, but should also always be
subzone. 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. Naming issues 7. SOA RRs
Two minor issues concerning the Start of Zone of Authority (SOA)
Resource Record need some clarification.
7.1. Placement of SOA RRs in authoritative answers
RFC1034, in section 3.7, indicates that the authority section of an
authoritative answer may contain the SOA record for the zone from
which the answer was obtained. When discussing negative caching,
RFC1034 section 4.3.4 refers to this technique but mentions the
additional section of the response. The former is correct, as is
implied by the example shown in section 6.2.5 of RFC1034. SOA
records, if added, are to be placed in the authority section.
7.2. TTLs on SOA RRs
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. 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.
7.1. CNAME records 8.1. CNAME 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 some applications for
aliases with no accompanying canonical name exist. An alias name aliases with no accompanying canonical name exist. An alias name
(label of a CNAME record) may, if DNSSEC is in use, have SIG, NXT, (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 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: 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 does not exist at all. + the name does not exist at all.
7.1.1. CNAME terminology 8.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
CNAME". This is unfortunate, as "CNAME" is an abbreviation of CNAME". This is unfortunate, as "CNAME" is an abbreviation of
"canonical name", and the label of a CNAME record is most certainly "canonical name", and the label of a CNAME record is most certainly
not a canonical name. It is, however, an entrenched usage. Care not a canonical name. It is, however, an entrenched usage. Care
must therefore be taken to be very clear whether the label, or the must therefore be taken to be very clear whether the label, or the
value (the canonical name) of a CNAME resource record is intended. value (the canonical name) of a CNAME resource record is intended.
In this document, the label of a CNAME resource record will always be In this document, the label of a CNAME resource record will always be
referred to as an alias. referred to as an alias.
7.2. PTR records 8.2. PTR records
Confusion about canonical names has lead to a belief that a PTR Confusion about canonical names has lead to a belief that a PTR
record should have exactly one RR in its RRSet. This is incorrect, record should have exactly one RR in its RRSet. This is incorrect,
the relevant section of RFC1034 (section 3.6.2) indicates that the 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 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 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 one PTR record is permitted for a name. No such restriction should
be inferred. be inferred.
Note that while the value of a PTR record must not be an alias, there 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 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 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 might have a CNAME record. That is, it might be an alias. The
value of that CNAME RR, if not another alias, will give the location value of that CNAME RR, if not another alias, which it should not be,
where the PTR record is found. That record gives the result of the will give the location where the PTR record is found. That record
PTR type lookup. This final result, the value of the PTR RR, is the gives the result of the PTR type lookup. This final result, the
label which must not be an alias. value of the PTR RR, is the label which must not be an alias.
7.3. MX and NS records 8.3. MX and NS records
The domain name used as the value of a NS resource record, or part of 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 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 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 of these positions neither works as well as might be hoped, nor well
fulfills the ambition that may have led to this approach. This fulfills the ambition that may have led to this approach. This
domain name must have as its value one or more address records. domain name must have as its value one or more address records.
Currently those will be A records, however in the future other record Currently those will be A records, however in the future other record
types giving addressing information may be acceptable. It can also types giving addressing information may be acceptable. It can also
have other RRs, but never a CNAME RR. have other RRs, but never a CNAME RR.
skipping to change at page 9, line 21 skipping to change at page 12, line 5
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 to avoid this by resolving the alias and
placing the canonical name directly in the affected record just once placing the canonical name directly in the affected record just once
when it is updated or installed. In some particular hard cases the 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 lack of the additional section address records in the results of a NS
lookup can cause the request to fail. lookup can cause the request to fail.
8. Name syntax 9. 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
that can be used to identify resource records. That one restriction that can be used to identify resource records. That one restriction
relates to the length of the label and the full name. The length of relates to the length of the label and the full name. The length of
skipping to change at page 10, line 6 skipping to change at page 12, line 39
load, a primary zone containing labels that might be considered load, a primary zone containing labels that might be considered
questionable, however this should not happen by default. questionable, however this should not happen by default.
Note however, that the various applications that make use of DNS data Note however, that the various applications that make use of DNS data
can have restrictions imposed on what particular values are can have restrictions imposed on what particular values are
acceptable in their environment. For example, that any binary label acceptable in their environment. For example, that any binary label
can have an MX record does not imply that any binary name can be used can have an MX record does not imply that any binary name can be used
as the host part of an e-mail address. Clients of the DNS can impose as the host part of an e-mail address. Clients of the DNS can impose
whatever restrictions are appropriate to their circumstances on the whatever restrictions are appropriate to their circumstances on the
values they use as keys for DNS lookup requests, and on the values values they use as keys for DNS lookup requests, and on the values
returned by the DNS. returned by the DNS. If the client has such restrictions, it is
solely responsible for validating the data from the DNS to ensure
that it conforms before it makes any use of that data.
See also [RFC1123] section 6.1.3.5. See also [RFC1123] section 6.1.3.5.
9. Security Considerations 10. Security Considerations
This document does not consider security. This document does not consider security.
In particular, nothing in section 4 is any way related to, or useful In particular, nothing in section 4 is any way related to, or useful
for, any security related purposes. for, any security related purposes.
Section 5.3.1 is also not related to security. Security of DNS data Section 5.4.1 is also not related to security. Security of DNS data
will be obtained by the Secure DNS [RFC2065], which is mostly will be obtained by the Secure DNS [RFC2065], which is mostly
orthogonal to this memo. orthogonal to this memo.
It is not believed that anything in this document adds to any It is not believed that anything in this document adds to any
security issues that may exist with the DNS, nor does it do anything security issues that may exist with the DNS, nor does it do anything
to lessen them. to that will necessarily lessen them. Correct implementation of the
clarifications in this document might play some small part in
limiting the spread of non-malicious bad data in the DNS, but only
DNSSEC can help with deliberate attempts to subvert DNS data.
10. References 11. References
[RFC1034] Domain Names - Concepts and Facilities, (STD 13) [RFC1034] Domain Names - Concepts and Facilities, (STD 13)
P. Mockapetris, ISI, November 1987. P. Mockapetris, ISI, November 1987.
[RFC1035] Domain Names - Implementation and Specification (STD 13) [RFC1035] Domain Names - Implementation and Specification (STD 13)
P. Mockapetris, ISI, November 1987. P. Mockapetris, ISI, November 1987.
[RFC1123] Requirements for Internet hosts - application and support, [RFC1123] Requirements for Internet hosts - application and support,
(STD 3) R. Braden, January 1989. (STD 3) R. Braden, January 1989.
[RFC1700] Assigned Numbers (STD 2) [RFC1700] Assigned Numbers (STD 2)
J. Reynolds, J. Postel, October 1994. J. Reynolds, J. Postel, October 1994.
[RFC2065] Domain Name System Security Extensions, [RFC2065] Domain Name System Security Extensions,
D. E. Eastlake, 3rd, C. W. Kaufman, January 1997. D. E. Eastlake, 3rd, C. W. Kaufman, January 1997.
11. Acknowledgements 12. 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, for help with the DNSSEC issues in this Donald E. Eastlake, 3rd, and Olafur Gudmundsson, for help with the
document, and to John Gilmore for pointing out where the DNSSEC issues in this document, and to John Gilmore for pointing out
clarifications were not necessarily clarifying. where the clarifications were not necessarily clarifying. Bob Halley
suggested clarifying the placement of SOA records in authoritative
answers, and provided the references. Michael Patton, as usual, and
Alan Barrett provided much assistance with many details.
12. Authors' addresses 13. 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
 End of changes. 42 change blocks. 
75 lines changed or deleted 208 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/