< draft-wkumari-dnsop-multiple-responses-03.txt		draft-wkumari-dnsop-multiple-responses-04.txt >
	dnsop W. Kumari		dnsop W. Kumari
	Internet-Draft Google		Internet-Draft Google
	Intended status: Standards Track Z. Yan		Intended status: Standards Track Z. Yan
	Expires: December 28, 2016 CNNIC		Expires: January 4, 2018 CNNIC
	W. Hardaker		W. Hardaker
	Parsons, Inc.		USC/ISI
	June 26, 2016		July 3, 2017
	Returning extra answers in DNS responses.		Returning extra answers in DNS responses.
	draft-wkumari-dnsop-multiple-responses-03		draft-wkumari-dnsop-multiple-responses-04
	Abstract		Abstract
	This document (re)introduces the ability to provide multiple answers		This document (re)introduces the ability to provide multiple answers
	in a DNS response.		in a DNS response. This is especially useful as, in many cases, the
			entity making the request has no a prori knowledge of what other
			questions it will need to ask.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	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
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on December 28, 2016.		This Internet-Draft will expire on January 4, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2017 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3		1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
	2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Returning multiple answers . . . . . . . . . . . . . . . . . 4		4. Returning multiple answers . . . . . . . . . . . . . . . . . 4
	5. The EXTRA Resource Record . . . . . . . . . . . . . . . . . . 4		5. The EXTRA Resource Record . . . . . . . . . . . . . . . . . . 5
	5.1. File Format . . . . . . . . . . . . . . . . . . . . . . . 5		5.1. File Format . . . . . . . . . . . . . . . . . . . . . . . 5
	5.2. Wire Format . . . . . . . . . . . . . . . . . . . . . . . 5		5.2. Wire Format . . . . . . . . . . . . . . . . . . . . . . . 5
	6. Signaling support . . . . . . . . . . . . . . . . . . . . . . 6		6. Signaling support . . . . . . . . . . . . . . . . . . . . . . 6
	7. Stub-Resolver Considerations . . . . . . . . . . . . . . . . 6		7. Stub-Resolver Considerations . . . . . . . . . . . . . . . . 6
	8. Use of Additional information . . . . . . . . . . . . . . . . 6		8. Use of Additional information . . . . . . . . . . . . . . . . 6
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 6		10. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7		11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
	12. Normative References . . . . . . . . . . . . . . . . . . . . 7		12. Normative References . . . . . . . . . . . . . . . . . . . . 7
	Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 8		Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	In many cases a name being resolved in the DNS provides the reason		In many cases a name being resolved in the DNS provides the reason
	behind why the name is being resolved. This may allow the		behind why the name is being resolved. This may allow the
	authoritative nameserver to predict what other answers a recursive		authoritative nameserver to predict what other answers a recursive
	resolver will soon query for. By providing multiple answers in the		resolver will soon query for. By providing multiple answers in the
	response, the authoritative name server operator can assist a caching		response, the authoritative name server operator can assist a caching
	recursive resolver in pre-populating its cache before a stub resolver		recursive resolver in pre-populating its cache before a stub resolver
	or other client asks for the subsequent queries. Apart from		or other client asks for the subsequent queries. Apart from
	decreasing the latency for end users [RFC6555], this also decreases		decreasing the latency for end users [RFC6555], this also decreases
	the total number of queries that the recursive resolver needs to send		the total number of queries that the recursive resolver needs to send
	and the autorative server needs to answer.		and the authoritative server needs to answer.
	For example, the domain name administrator of Example Widgets, Inc		For example, the domain name administrator of Example Widgets, Inc
	(example.com) knows that the web page at www.example.com contains		(example.com) knows that the web page at www.example.com contains
	various other resources, including some images (served from		various other resources, including some images (served from
	images.example.com), some Cascading Style Sheets (served from		images.example.com), some Cascading Style Sheets (served from
	css.example.com) and some JavaScript (served from data.example.com).		css.example.com) and some JavaScript (served from data.example.com).
	An application attempting to resolve www.example.com is very likely		An application attempting to resolve www.example.com is very likely
	to be a web browser rendering the page and will likely also need to		to be a web browser rendering the page and will likely also need to
	resolve all of these additional names as well. Providing all of		resolve all of these additional names as well. Providing all of
	these answers in response to a query for www.example.com allows the		these answers in response to a query for www.example.com allows the
	recursive resolver to pre-populate its cache and have these answers		recursive resolver to pre-populate its cache and have these answers
	available immediately when a stub resolver or other DNS client asks		available immediately when a stub resolver or other DNS client asks
	for them.		for them. What is important to notice here is that the stub resolver
			does not know what other questions it will need to make until after
			it has already made the request for www.exmaple.com, received the
			reply, made the HTTP connection and parsed the HTML.
	Other examples where this technique may be useful include SMTP (by		Other examples where this technique may be useful include SMTP (by
	including mail server addresses, SPF and DKIM records when serving		including mail server addresses, SPF and DKIM records when serving
	the MX record), SRV (by providing the target information in addition		the MX record), SRV (by providing the target information in addition
	to the SRV response) and TLSA (by providing any TLSA records		to the SRV response) and TLSA (by providing any TLSA records
	associated with a name). This same technique can also be used to		associated with a name). This same technique can also be used to
	include both the IPv4 (A) and IPv6 (AAAA) addresses for any singular		include both the IPv4 (A) and IPv6 (AAAA) addresses for any singular
	address query.		address query.
	This technique, described in this document, is purely an optimization		This technique, described in this document, is purely an optimization
	skipping to change at page 3, line 48 ¶		skipping to change at page 4, line 10 ¶
	ubiquitous DNSSEC deployment [Ed note: By the time this document is		ubiquitous DNSSEC deployment [Ed note: By the time this document is
	published, there *will* be ubiquitous DNSSEC :-) ], a validating		published, there *will* be ubiquitous DNSSEC :-) ], a validating
	resolver can validate, authenticate and trust the records in the		resolver can validate, authenticate and trust the records in the
	additional information.		additional information.
	3. Terminology		3. Terminology
	Additional records Additional records are records that the		Additional records Additional records are records that the
	authoritative nameserver has included in the Additional section.		authoritative nameserver has included in the Additional section.
	EXTRTA Resource Record The EXTRA resource record (defined below)		EXTRA Resource Record The EXTRA resource record (defined below)
	carries a list fo additional records to send.		carries a list fo additional records to send.
	Primary query A Primary query (or primary question) is a QNAME that		Primary query A Primary query (or primary question) is a QNAME that
	the name server operator would like to return additional answers		the name server operator would like to return additional answers
	for.		for.
	Supporting DNSSEC information Supporting DNSSEC information is the		Supporting DNSSEC information Supporting DNSSEC information is the
	DNSSEC RRSIGs that prove the authenticity of the Additional		DNSSEC RRSIGs that prove the authenticity of the Additional
	records.		records.
	skipping to change at page 5, line 9 ¶		skipping to change at page 5, line 17 ¶
	To allow a zone content administrator to instruct the name server		To allow a zone content administrator to instruct the name server
	which additional records to serve when it receives a query to a		which additional records to serve when it receives a query to a
	label, we introduce the EXTRA Resource Record (RR). These additional		label, we introduce the EXTRA Resource Record (RR). These additional
	records are appended to the additional section (note that the EXTRA		records are appended to the additional section (note that the EXTRA
	RR itself is not appended). The EXTRA resource record MAY still be		RR itself is not appended). The EXTRA resource record MAY still be
	queried for directly (e.g for debugging), in which case the record		queried for directly (e.g for debugging), in which case the record
	itself is returned.		itself is returned.
	5.1. File Format		5.1. File Format
	The format of the Extra RR is:		The format of the EXTRA RR is:
	label EXTRA "label,type; label,type; label,type; ..."		label EXTRA "label,type; label,type; label,type; ..."
	For example, if the operator of example.com would like to also return		For example, if the operator of example.com would like to also return
	A record answers for images.example.com, css.html.example.com and		A record answers for images.example.com, css.html.example.com and
	both an A and AAAA for data.example.com when queried for		both an A and AAAA for data.example.com when queried for
	www.example.com, they would create the following record:		www.example.com, they would create the following record:
	www.example.com. EXTRA "images,A; css,A; data,A; data,AAA;"		www.example.com. EXTRA "images,A; css,A; data,A; data,AAAA;"
	The entries in the EXRTA list are ordered. An authoritative		The entries in the EXTRA list are ordered. An authoritative
	nameserver SHOULD insert the records in the order listed when filling		nameserver SHOULD insert the records in the order listed when filling
	the response packet. This is to allow the operator to express a		the response packet. This is to allow the operator to express a
	preference in case all the records will not fit in the response. The		preference in case all the records will not fit in the response. The
	TTL of the records added to the Additional section are MUST be the		TTL of the records added to the Additional section are MUST be the
	same as if queried directly.		same as if queried directly.
	In some cases a zone content administrator might not know what all		In some cases a zone content administrator might not know what all
	additional records clients need. For example, the owner of		additional records clients need. For example, the owner of
	www.example.com may have outsourced his DNS operations to a third		www.example.com may have outsourced his DNS operations to a third
	party. DNS administrators may be able to mine their query logs, and		party. DNS administrators may be able to mine their query logs, and
	skipping to change at page 5, line 49 ¶		skipping to change at page 6, line 11 ¶
	The wire format of the EXTRA RR is the same as the wire format for a		The wire format of the EXTRA RR is the same as the wire format for a
	TXT RR:		TXT RR:
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	/ TXT-DATA /		/ TXT-DATA /
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	Where TXT-DATA is one or more <character-string>s.		Where TXT-DATA is one or more <character-string>s.
	The Extra RR has RR type TBD [RFC Editor: insert the IANA assigned		The EXTRA RR has RR type TBD [RFC Editor: insert the IANA assigned
	value and delete this note]		value and delete this note]
	6. Signaling support		6. Signaling support
	Recursive Resolvers (or other DNS clients) that support EXTRA records		Recursive Resolvers (or other DNS clients) that support EXTRA records
	MAY signal this by setting the OPT record's EXTRA bit (bit NN [TBD:		MAY signal this by setting the OPT record's EXTRA bit (bit NN [TBD:
	assigned by IANA] in the EDNS0 extension header to 1.		assigned by IANA] in the EDNS0 extension header to 1.
	7. Stub-Resolver Considerations		7. Stub-Resolver Considerations
	skipping to change at page 6, line 28 ¶		skipping to change at page 6, line 37 ¶
	if it wants to pre-query for data that will likely be needed in the		if it wants to pre-query for data that will likely be needed in the
	process of supporting its application.		process of supporting its application.
	8. Use of Additional information		8. Use of Additional information
	When receiving additional records in the additional section, a		When receiving additional records in the additional section, a
	resolver follows certain rules:		resolver follows certain rules:
	1. Additional records MUST be validated before being used.		1. Additional records MUST be validated before being used.
	2. Additional records SHOULD be annotated in the cache as having		2. Additional records SHOULD have lower priority in the cache than
	been received as Additional records.
	3. Additional records SHOULD have lower priority in the cache than
	answers received because they were requested. This is to help		answers received because they were requested. This is to help
	evict Additional records from the cache first (to help prevent		evict Additional records from the cache first (to help prevent
	cache filling attacks).		cache filling attacks).
	4. Recursive resolvers MAY choose to ignore Additional records for		3. Recursive resolvers MAY choose to ignore Additional records for
	any reason, including CPU or cache space concerns, phase of the		any reason, including CPU or cache space concerns, phase of the
	moon, etc. It may choose to accept all, some or none of the		moon, etc. It may choose to accept all, some or none of the
	Additional records.		Additional records.
	9. IANA Considerations		9. IANA Considerations
	This document contains the following IANA assignment requirements:		This document contains the following IANA assignment requirements:
	1. The EXTRA bit discussed in Section 6 needs to be allocated.		1. The EXTRA bit discussed in Section 6 needs to be allocated.
	skipping to change at page 7, line 22 ¶		skipping to change at page 7, line 29 ¶
	recursive resolver to ignore Additional records whenever it considers		recursive resolver to ignore Additional records whenever it considers
	itself under attack or its CPU resources are otherwise over-		itself under attack or its CPU resources are otherwise over-
	committed.		committed.
	This specification requires that the all of the Additional records		This specification requires that the all of the Additional records
	are signed, and all necessary DNSSEC information for validation be		are signed, and all necessary DNSSEC information for validation be
	included to avoid cache poisoning attacks.		included to avoid cache poisoning attacks.
	11. Acknowledgements		11. Acknowledgements
	The authors wish to thank some folk.		The authors to thank Mark Andrews, John Dickinson, Kazunori Fujiwara,
			Bob Harold, John Heidemann, Tony Finch.
	12. Normative References		12. Normative References
	[Ref.Bellovin]		[Ref.Bellovin]
	Bellovin, S., "Using the Domain Name System for System		Bellovin, S., "Using the Domain Name System for System
	Break-Ins", 1995,		Break-Ins", 1995,
	<https://www.cs.columbia.edu/~smb/papers/dnshack.pdf>.		<https://www.cs.columbia.edu/~smb/papers/dnshack.pdf>.
	[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",		[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
	STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,		STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
	skipping to change at page 8, line 13 ¶		skipping to change at page 8, line 21 ¶
	2012, <http://www.rfc-editor.org/info/rfc6555>.		2012, <http://www.rfc-editor.org/info/rfc6555>.
	[RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)		[RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)
	Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,		Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,
	<http://www.rfc-editor.org/info/rfc7873>.		<http://www.rfc-editor.org/info/rfc7873>.
	Appendix A. Changes / Author Notes.		Appendix A. Changes / Author Notes.
	[RFC Editor: Please remove this section before publication ]		[RFC Editor: Please remove this section before publication ]
	From -00 to -01.		From -03 to -04:
	o Nothing changed in the template!		o Some additional text explaining how this differs from solutions
			which include muiltiple queries (you don't know what to ask until
			you have received some answers).
	From -02 to -3:		From -02 to -03:
	Sat down and rewrote and cleaned up large sections of text.		o Sat down and rewrote and cleaned up large sections of text.
	Changed name of RR from Additional to EXTRA (the term "Additional"		o Changed name of RR from Additional to EXTRA (the term "Additional"
	is overloaded in general)		is overloaded in general)
	Clarified that stub resolvers and other clients MAY use this		o Clarified that stub resolvers and other clients MAY use this
	specification.		specification.
	Attempted to clarify that the individual RRs are added to the		o Attempted to clarify that the individual RRs are added to the
	response, not the EXTRA record itself. The EXTRA RR can be		response, not the EXTRA record itself. The EXTRA RR can be
	queried directly.		queried directly.
	Authors' Addresses		From -00 to -01:
			o Nothing change in the template.
			Authors' Addresses
	Warren Kumari		Warren Kumari
	Google		Google
	1600 Amphitheatre Parkway		1600 Amphitheatre Parkway
	Mountain View, CA 94043		Mountain View, CA 94043
	US		US
	Email: warren@kumari.net		Email: warren@kumari.net
	Zhiwei Yan		Zhiwei Yan
	CNNIC		CNNIC
	skipping to change at page 9, line 4 ¶		skipping to change at page 9, line 19 ¶
	Email: warren@kumari.net		Email: warren@kumari.net
	Zhiwei Yan		Zhiwei Yan
	CNNIC		CNNIC
	No.4 South 4th Street, Zhongguancun		No.4 South 4th Street, Zhongguancun
	Beijing 100190		Beijing 100190
	P. R. China		P. R. China
	Email: yanzhiwei@cnnic.cn		Email: yanzhiwei@cnnic.cn
	Wes Hardaker		Wes Hardaker
	Parsons, Inc.		USC/ISI
	P.O. Box 382		P.O. Box 382
	Davis, CA 95617		Davis, CA 95617
	US		US
	Email: ietf@hardakers.net		Email: ietf@hardakers.net
End of changes. 30 change blocks.
	32 lines changed or deleted		41 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/