< draft-ietf-dnsind-clarify-06.txt		draft-ietf-dnsind-clarify-07.txt >
	skipping to change at page 1, line 13 ¶		skipping to change at page 1, line 13 ¶
	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: September 1997
	Randy Bush		Randy Bush
	RGnet, Inc.		RGnet, Inc.
	March 1997		March 1997
	Clarifications to the DNS Specification		Clarifications to the DNS Specification
	draft-ietf-dnsind-clarify-06.txt		draft-ietf-dnsind-clarify-07.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. Six 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,		+ two 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,		+ 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 six of these are areas where the correct behaviour has been
	been somewhat unclear, we seek to rectify that. The other two are		somewhat unclear, we seek to rectify that. The other two are already
	already adequately specified, however the specifications seem to be		adequately specified, however the specifications seem to be sometimes
	sometimes ignored. We seek to reinforce the existing specifications.		ignored. We seek to reinforce the existing specifications.
	This version tightens the procedures to be followed when a server		This versions ads two new minor clarifications, to the definition of
	receives an RRSet with varying TTLs on the RRs comprising the RRSet.		a TTL, and to use of the TC bit. This paragraph will be deleted from
	This is an attempt to limit the spread of bogus data. This paragraph		the final version of this document.
	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 Naming issues .............................................. 10		8 Time to Live (TTL) ......................................... 10
	9 Name syntax ................................................ 12		9 The TC (truncated) header bit .............................. 11
	10 Security Considerations .................................... 13		10 Naming issues .............................................. 11
	11 References ................................................. 13		11 Name syntax ................................................ 13
	12 Acknowledgements ........................................... 14		12 Security Considerations .................................... 14
	13 Authors' addresses ......................................... 14		13 References ................................................. 14
			14 Acknowledgements ........................................... 14
			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,
	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. A minor ambiguity in RFC1034 concerned with SOA		made in this memo. A minor ambiguity in RFC1034 concerned with SOA
	records is also corrected.		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.
	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,
	skipping to change at page 10, line 30 ¶		skipping to change at page 10, line 30 ¶
	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.
	8. Naming issues		8. Time to Live (TTL)
			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
			bits exist, and whether the value is signed or unsigned. It is
			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
			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
			most significant, or sign, bit set to zero.
			Implementations should treat TTL values received with the most
			significant bit set as if the entire value received was zero.
			Implementations are always free to place an upper bound on any TTL
			received, and treat any larger values as if they were that upper
			bound. The TTL specifies a maximum time to live, not a mandatory
			time to live.
			9. The TC (truncated) header bit
			The TC bit should be set in responses only when an RRSet is required
			as a part of the response, but could not be included in its entirety.
			The TC bit should not be set merely because some extra information
			could have been included, but there was insufficient room. This
			includes the results of additional section processing. In such cases
			the entire RRSet that will not fit in the response should be omitted,
			and the reply sent as is, with the TC bit clear. If the recipient of
			the reply needs the omitted data, it can construct a query for that
			data and send that separately.
			Where TC is set, the partial RRSet that would not completely fit may
			be left in the response. When a DNS client receives a reply with TC
			set, it should ignore that response, and query again, using a
			mechanism, such as a TCP connection, that will permit larger replies.
			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.
	8.1. CNAME records		10.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:
	skipping to change at page 11, line 4 ¶		skipping to change at page 11, line 42 ¶
	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 exists, but has no associated RRs of any type,
	+ the name does not exist at all.		+ the name does not exist at all.
	8.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
	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.
	8.2. PTR records		10.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, which it should not be,		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		will give the location where the PTR record is found. That record
	gives the result of the PTR type lookup. This final result, the		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.		value of the PTR RR, is the label which must not be an alias.
	8.3. MX and NS records		10.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 12, line 18 ¶		skipping to change at page 13, line 7 ¶
	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.
	9. 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
	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 13, line 10 ¶		skipping to change at page 14, line 5 ¶
	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. If the client has such restrictions, it is		returned by the DNS. If the client has such restrictions, it is
	solely responsible for validating the data from the DNS to ensure		solely responsible for validating the data from the DNS to ensure
	that it conforms before it makes any use of that data.		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.
	10. Security Considerations		12. 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.4.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 that will necessarily lessen them. Correct implementation of the		to that will necessarily lessen them. Correct implementation of the
	clarifications in this document might play some small part in		clarifications in this document might play some small part in
	limiting the spread of non-malicious bad data in the DNS, but only		limiting the spread of non-malicious bad data in the DNS, but only
	DNSSEC can help with deliberate attempts to subvert DNS data.		DNSSEC can help with deliberate attempts to subvert DNS data.
	11. References		13. 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.
	12. 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, Mark
	Andrews, and Alan Barrett provided much assistance with many details.		Andrews, and Alan Barrett provided much assistance with many details.
	13. 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
End of changes. 19 change blocks.
	28 lines changed or deleted		68 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/