< draft-ietf-dnsind-clarify-05.txt   draft-ietf-dnsind-clarify-06.txt >
Network Working Group Robert Elz Network Working Group Robert Elz
Internet Draft University of Melbourne Internet Draft University of Melbourne
Expiration Date: August 1997 Expiration Date: September 1997
Randy Bush Randy Bush
RGnet, Inc. RGnet, Inc.
February 1997 March 1997
Clarifications to the DNS Specification Clarifications to the DNS Specification
draft-ietf-dnsind-clarify-05.txt draft-ietf-dnsind-clarify-06.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 2, line 6 skipping to change at page 2, line 6
+ correct handling of zone cuts, + correct handling of zone cuts,
+ two minor issues concerning SOA records and their use, + 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 four 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 adds a brief discussion on the placement of an SOA This version tightens the procedures to be followed when a server
record in the answer to an authoritative query, and the issue of TTLs receives an RRSet with varying TTLs on the RRs comprising the RRSet.
on SOA records. It also contains rather more discussion inspired by This is an attempt to limit the spread of bogus data. This paragraph
the oddities of some of the new DNSSEC record types. The ordered will be deleted from the final version of this document.
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 ................................................ 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 .................................................... 9 7 SOA RRs .................................................... 10
8 Naming issues .............................................. 10 8 Naming issues .............................................. 10
9 Name syntax ................................................ 12 9 Name syntax ................................................ 12
10 Security Considerations .................................... 13 10 Security Considerations .................................... 13
11 References ................................................. 13 11 References ................................................. 13
12 Acknowledgements ........................................... 13 12 Acknowledgements ........................................... 14
13 Authors' addresses ......................................... 14 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,
skipping to change at page 4, line 46 skipping to change at page 4, line 46
the RRs in an RRSet to have different TTLs. No uses for this have the RRs in an RRSet to have different TTLs. No uses for this have
been found that cannot be better accomplished in other ways. This been found that cannot be better accomplished in other ways. This
can, however, cause partial replies (not marked "truncated") from a can, however, cause partial replies (not marked "truncated") from a
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 the RRs for all purposes as if all differing TTLs, it should treat this as an error. If the RRSet
TTLs in the RRSet had been set to the value of the lowest TTL in the concerned is from a non-authoritative source for this data, the
RRSet. client should simply ignore the RRSet, and if the values were
required, seek to acquire them from an authoritative source. Should
an authoritative source send such a malformed RRSet, the 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.
5.3.1. SIG records and RRSets 5.3.1. SIG records and RRSets
A SIG records provides signature (validation) data for another RRSet A SIG record provides signature (validation) data for another RRSet
in the DNS. Where a zone has been signed, every RRSet in the zone 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 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 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 particular RRSet this SIG record is associated. Were the rules above
applied, whenever a SIG record was included with a response to applied, whenever a SIG record was included with a response to
validate that response, the SIG records for all other RRSets validate that response, the SIG records for all other RRSets
associated with the appropriate node would also need to be included. associated with the appropriate node would also need to be included.
In some cases, this could be a very large number of records, not In some cases, this could be a very large number of records, not
helped by their being rather large RRs. helped by their being rather large RRs.
Thus, it is specifically permitted for only those SIG RRs with the Thus, it is specifically permitted for the authority section to
"type covered" field equal to the type field of an answer being contain only those SIG RRs with the "type covered" field equal to the
returned need be included in the authority section as validation type field of an answer being returned. However, where SIG records
data. However, where SIG records are being returned in the answer are being returned in the answer section, in response to a query for
section, in response to a query for SIG records, or a query for all SIG records, or a query for all records associated with a name
records associated with a name (type=ANY) the entire SIG RRSet must (type=ANY) the entire SIG RRSet must be included, as for any other RR
be included, as for any other RR type. type.
Servers that receive responses containing SIG records in the Servers that receive responses containing SIG records in the
authority section, or (probably incorrectly) as additional data, must authority section, or (probably incorrectly) as additional data, must
understand that the entire RRSet has almost certainly not been understand that the entire RRSet has almost certainly not been
included. Thus, they must not cache that SIG record in a way that 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 would permit it to be returned should a query for SIG records be
received at that server. RFC2065 actually requires that SIG queries received at that server. RFC2065 actually requires that SIG queries
be directed only to authoritative servers to avoid the problems that be directed only to authoritative servers to avoid the problems that
could be caused here, and while servers exist that do not understand could be caused here, and while servers exist that do not understand
the special properties of SIG records, this will remain necessary. the special properties of SIG records, this will remain necessary.
skipping to change at page 13, line 49 skipping to change at page 14, line 14
12. 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, 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, and answers, and provided the references. Michael Patton, as usual, Mark
Alan Barrett provided much assistance with many details. Andrews, and Alan Barrett provided much assistance with many details.
13. 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
 End of changes. 10 change blocks. 
26 lines changed or deleted 27 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/