< draft-ietf-dnsext-dnsproxy-05.txt		draft-ietf-dnsext-dnsproxy-06.txt >
	DNSEXT R. Bellis		DNSEXT R. Bellis
	Internet-Draft Nominet UK		Internet-Draft Nominet UK
	Intended status: BCP April 23, 2009		Intended status: BCP July 1, 2009
	Expires: October 25, 2009		Expires: January 2, 2010
	DNS Proxy Implementation Guidelines		DNS Proxy Implementation Guidelines
	draft-ietf-dnsext-dnsproxy-05		draft-ietf-dnsext-dnsproxy-06
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 32 ¶		skipping to change at page 1, line 32 ¶
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on October 25, 2009.		This Internet-Draft will expire on January 2, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 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 in effect on the date of		Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).		publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 26 ¶		skipping to change at page 2, line 26 ¶
	4.3. Unknown Resource Record Types . . . . . . . . . . . . . . 5		4.3. Unknown Resource Record Types . . . . . . . . . . . . . . 5
	4.4. Packet Size Limits . . . . . . . . . . . . . . . . . . . . 5		4.4. Packet Size Limits . . . . . . . . . . . . . . . . . . . . 5
	4.4.1. TCP Transport . . . . . . . . . . . . . . . . . . . . 6		4.4.1. TCP Transport . . . . . . . . . . . . . . . . . . . . 6
	4.4.2. Extension Mechanisms for DNS (EDNS0) . . . . . . . . . 6		4.4.2. Extension Mechanisms for DNS (EDNS0) . . . . . . . . . 6
	4.4.3. IP Fragmentation . . . . . . . . . . . . . . . . . . . 6		4.4.3. IP Fragmentation . . . . . . . . . . . . . . . . . . . 6
	4.5. Secret Key Transaction Authentication for DNS (TSIG) . . . 7		4.5. Secret Key Transaction Authentication for DNS (TSIG) . . . 7
	5. DHCP's Interaction with DNS . . . . . . . . . . . . . . . . . 7		5. DHCP's Interaction with DNS . . . . . . . . . . . . . . . . . 7
	5.1. Domain Name Server (DHCP Option 6) . . . . . . . . . . . . 8		5.1. Domain Name Server (DHCP Option 6) . . . . . . . . . . . . 8
	5.2. Domain Name (DHCP Option 15) . . . . . . . . . . . . . . . 8		5.2. Domain Name (DHCP Option 15) . . . . . . . . . . . . . . . 8
	5.3. DHCP Leases . . . . . . . . . . . . . . . . . . . . . . . 8		5.3. DHCP Leases . . . . . . . . . . . . . . . . . . . . . . . 9
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 9		6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	6.1. Forgery Resilience . . . . . . . . . . . . . . . . . . . . 9		6.1. Forgery Resilience . . . . . . . . . . . . . . . . . . . . 9
	6.2. Interface Binding . . . . . . . . . . . . . . . . . . . . 10		6.2. Interface Binding . . . . . . . . . . . . . . . . . . . . 10
	6.3. Packet Filtering . . . . . . . . . . . . . . . . . . . . . 10		6.3. Packet Filtering . . . . . . . . . . . . . . . . . . . . . 10
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 11		8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	skipping to change at page 4, line 45 ¶		skipping to change at page 4, line 45 ¶
	For example, some proxies have been observed to drop any packet		For example, some proxies have been observed to drop any packet
	containing either the "Authentic Data" (AD) or "Checking Disabled"		containing either the "Authentic Data" (AD) or "Checking Disabled"
	(CD) bits from DNSSEC [RFC4035]. This may be because [RFC1035]		(CD) bits from DNSSEC [RFC4035]. This may be because [RFC1035]
	originally specified that these unused "Z" flag bits "MUST" be zero.		originally specified that these unused "Z" flag bits "MUST" be zero.
	However these flag bits were always intended to be reserved for		However these flag bits were always intended to be reserved for
	future use, so refusing to proxy any packet containing these flags		future use, so refusing to proxy any packet containing these flags
	(now that uses for those flags have indeed been defined) is not		(now that uses for those flags have indeed been defined) is not
	appropriate.		appropriate.
	Therefore it is RECOMMENDED that proxies SHOULD ignore any unknown		Therefore proxies MUST ignore any unknown DNS flags and proxy those
	DNS flags and proxy those packets as usual.		packets as usual.
	4.2. Label Compression		4.2. Label Compression
	Compression of labels as per Section 4.1.4 of [RFC1035] is optional.		Compression of labels as per Section 4.1.4 of [RFC1035] is optional.
	Proxies MUST forward packets regardless of the presence or absence of		Proxies MUST forward packets regardless of the presence or absence of
	compressed labels therein.		compressed labels therein.
	4.3. Unknown Resource Record Types		4.3. Unknown Resource Record Types
	skipping to change at page 6, line 11 ¶		skipping to change at page 6, line 11 ¶
	If a proxy must unilaterally truncate a response then the proxy MUST		If a proxy must unilaterally truncate a response then the proxy MUST
	set the TC bit. Similarly, proxies MUST NOT remove the TC bit from		set the TC bit. Similarly, proxies MUST NOT remove the TC bit from
	responses.		responses.
	4.4.1. TCP Transport		4.4.1. TCP Transport
	Should a UDP query fail because of truncation, the standard fail-over		Should a UDP query fail because of truncation, the standard fail-over
	mechanism is to retry the query using TCP, as described in section		mechanism is to retry the query using TCP, as described in section
	6.1.3.2 of [RFC1123].		6.1.3.2 of [RFC1123].
	DNS proxies SHOULD therefore be prepared to receive and forward		Whilst TCP transport is not strictly mandatory, it is supported by
	queries over TCP.		the vast majority of stub resolvers and recursive servers. Lack of
			support in the proxy prevents this fail-over mechanism from working.
			DNS proxies MUST therefore be prepared to receive and forward queries
			over TCP.
	Note that it is unlikely that a client would send a request over TCP		Note that it is unlikely that a client would send a request over TCP
	unless it had already received a truncated UDP response. Some		unless it had already received a truncated UDP response. Some
	"smart" proxies have been observed to first forward any request		"smart" proxies have been observed to first forward any request
	received over TCP to an upstream resolver over UDP, only for the		received over TCP to an upstream resolver over UDP, only for the
	response to be truncated, causing the proxy to retry over TCP. Such		response to be truncated, causing the proxy to retry over TCP. Such
	behaviour increases network traffic and causes delay in DNS		behaviour increases network traffic and causes delay in DNS
	resolution since the initial UDP request is doomed to fail.		resolution since the initial UDP request is doomed to fail.
	Therefore whenever a proxy receives a request over TCP, the proxy		Therefore whenever a proxy receives a request over TCP, the proxy
	skipping to change at page 6, line 40 ¶		skipping to change at page 6, line 44 ¶
	additional request and response flags.		additional request and response flags.
	A client may send an OPT Resource Record (OPT RR) in the Additional		A client may send an OPT Resource Record (OPT RR) in the Additional
	Section of a request to indicate that it supports a specific receive		Section of a request to indicate that it supports a specific receive
	buffer size. The OPT RR also includes the "DNSSEC OK" (DO) flag used		buffer size. The OPT RR also includes the "DNSSEC OK" (DO) flag used
	by DNSSEC to indicate that DNSSEC-related RRs should be returned to		by DNSSEC to indicate that DNSSEC-related RRs should be returned to
	the client.		the client.
	However some proxies have been observed to either reject (with a		However some proxies have been observed to either reject (with a
	FORMERR response code) or black-hole any packet containing an OPT RR.		FORMERR response code) or black-hole any packet containing an OPT RR.
	As per Section 4.1 proxies SHOULD NOT refuse to proxy such packets.		As per Section 4.1 proxies MUST NOT refuse to proxy such packets.
	4.4.3. IP Fragmentation		4.4.3. IP Fragmentation
	Support for UDP packet sizes exceeding the WAN MTU depends on the		Support for UDP packet sizes exceeding the WAN MTU depends on the
	gateway's algorithm for handling fragmented IP packets. Several		gateway's algorithm for handling fragmented IP packets. Several
	methods are possible:		methods are possible:
	1. fragments are dropped		1. fragments are dropped
	2. fragments are forwarded individually as they're received		2. fragments are forwarded individually as they're received
	3. complete packets are reassembled on the gateway, and then re-		3. complete packets are reassembled on the gateway, and then re-
	skipping to change at page 10, line 45 ¶		skipping to change at page 10, line 50 ¶
	data.		data.
	Examples of malformed packets which MAY be dropped include:		Examples of malformed packets which MAY be dropped include:
	o invalid compression pointers (i.e. those that point outside of the		o invalid compression pointers (i.e. those that point outside of the
	current packet, or which might cause a parsing loop).		current packet, or which might cause a parsing loop).
	o incorrect counts for the Question, Answer, Authority and		o incorrect counts for the Question, Answer, Authority and
	Additional Sections (although care should be taken where		Additional Sections (although care should be taken where
	truncation is a possibility).		truncation is a possibility).
	Since dropped packets will cause the client to repeatedly retransmit		Dropped packets will cause the client to repeatedly retransmit the
	the original request, it is RECOMMENDED that proxies SHOULD instead		original request, with the client only detecting the error after
	return a suitable DNS error response to the client (i.e. SERVFAIL)		several retransmit intervals.
	instead of dropping the packet completely.
			In these circumstances proxies SHOULD synthesise a suitable DNS error
			response to the client (i.e. SERVFAIL) instead of dropping the
			packet completely. This will allow the client to detect the error
			immediately.
	7. IANA Considerations		7. IANA Considerations
	This document requests no IANA actions.		This document requests no IANA actions.
	8. Change Log		8. Change Log
	NB: to be removed by the RFC Editor before publication.		NB: to be removed by the RFC Editor before publication.
			draft-ietf-dnsproxy-06pre (from IESG review)
			Section 4.1 - cleaned up tautological language and changed SHOULD
			to MUST (Adrian Farrel)
			Section 4.4.1 - made TCP support mandatory (from Lars Eggert)
			Section 4.4.2 - made EDNS0 pass-thru mandatory (from Jari Arkko)
			Section 6.3 - clarified rationale for handling errors (from Robert
			Sparks)
	draft-ietf-dnsproxy-05		draft-ietf-dnsproxy-05
	Removed specific reference to 28 byte IP headers (from Mark		Removed specific reference to 28 byte IP headers (from Mark
	Andrews)		Andrews)
	draft-ietf-dnsproxy-04 - post WGLC		draft-ietf-dnsproxy-04 - post WGLC
	Introduction expanded		Introduction expanded
	Section 5.2 - changed SHOULD to MUST		Section 5.2 - changed SHOULD to MUST
	Section 4.5 - changed SHOULD to MUST (Alex Bligh)		Section 4.5 - changed SHOULD to MUST (Alex Bligh)
	Editorial nits (from Andrew Sullivan, Alfred Hones)		Editorial nits (from Andrew Sullivan, Alfred Hones)
	Clarificaton on end-user vs device administrator (Alan Barrett,		Clarificaton on end-user vs device administrator (Alan Barrett,
End of changes. 9 change blocks.
	14 lines changed or deleted		30 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/