draft-ietf-dnsop-no-response-issue-01.txt		draft-ietf-dnsop-no-response-issue-02.txt
	Network Working Group M. Andrews		Network Working Group M. Andrews
	Internet-Draft ISC		Internet-Draft ISC
	Intended status: Best Current Practice December 1, 2015		Intended status: Best Current Practice February 21, 2016
	Expires: June 3, 2016		Expires: August 24, 2016
	A Common Operational Problem in DNS Servers - Failure To Respond.		A Common Operational Problem in DNS Servers - Failure To Respond.
	draft-ietf-dnsop-no-response-issue-01		draft-ietf-dnsop-no-response-issue-02
	Abstract		Abstract
	The DNS is a query / response protocol. Failure to respond or to		The DNS is a query / response protocol. Failure to respond or to
	respond correctly to queries causes both immediate operational		respond correctly to queries causes both immediate operational
	problems and long term problems with protocol development.		problems and long term problems with protocol development.
	This document identifies a number of common classes of queries to		This document identifies a number of common kinds of queries to which
	which some servers either fail to respond or else respond		some servers either fail to respond or else respond incorrectly.
	incorrectly. This document also suggests procedures for TLD and		This document also suggests procedures for TLD and other similar zone
	other similar zone operators to apply to help reduce / eliminate the		operators to apply to help reduce / eliminate the problem.
	problem.
	The document does not look at the DNS data itself, just the structure		The document does not look at the DNS data itself, just the structure
	of the responses.		of the responses.
	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 June 3, 2016.		This Internet-Draft will expire on August 24, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2016 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
	2. Common queries class that result in non responses. . . . . . 3		2. Common queries kinds that result in non responses. . . . . . 3
	2.1. EDNS Queries - Version Independent . . . . . . . . . . . 4		2.1. EDNS Queries - Version Independent . . . . . . . . . . . 3
	2.2. EDNS Queries - Version Specific . . . . . . . . . . . . . 4		2.2. EDNS Queries - Version Specific . . . . . . . . . . . . . 4
	2.3. EDNS Options . . . . . . . . . . . . . . . . . . . . . . 4		2.3. EDNS Options . . . . . . . . . . . . . . . . . . . . . . 4
	2.4. EDNS Flags . . . . . . . . . . . . . . . . . . . . . . . 4		2.4. EDNS Flags . . . . . . . . . . . . . . . . . . . . . . . 4
	2.5. DNS Flags . . . . . . . . . . . . . . . . . . . . . . . . 5		2.5. DNS Flags . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.6. Unknown / Unsupported Type Queries . . . . . . . . . . . 5		2.6. Unknown / Unsupported Type Queries . . . . . . . . . . . 5
	2.7. Unknown DNS opcodes . . . . . . . . . . . . . . . . . . . 5		2.7. Unknown DNS opcodes . . . . . . . . . . . . . . . . . . . 5
	2.8. TCP Queries . . . . . . . . . . . . . . . . . . . . . . . 5		2.8. TCP Queries . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Remediating . . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Remediating . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Firewalls and Load Balancers . . . . . . . . . . . . . . . . 7		4. Firewalls and Load Balancers . . . . . . . . . . . . . . . . 7
	5. Scrubbing Services . . . . . . . . . . . . . . . . . . . . . 8		5. Scrubbing Services . . . . . . . . . . . . . . . . . . . . . 8
	6. Whole Answer Caches . . . . . . . . . . . . . . . . . . . . . 9		6. Whole Answer Caches . . . . . . . . . . . . . . . . . . . . . 9
	7. Response Code Selection . . . . . . . . . . . . . . . . . . . 9		7. Response Code Selection . . . . . . . . . . . . . . . . . . . 9
	8. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 10		8. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	8.1. Testing - Basic DNS . . . . . . . . . . . . . . . . . . . 10		8.1. Testing - Basic DNS . . . . . . . . . . . . . . . . . . . 10
	8.2. Testing - Extended DNS . . . . . . . . . . . . . . . . . 12		8.2. Testing - Extended DNS . . . . . . . . . . . . . . . . . 12
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 15		9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	11. Normative References . . . . . . . . . . . . . . . . . . . . 16		11. Normative References . . . . . . . . . . . . . . . . . . . . 16
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	The DNS [RFC1034], [RFC1035] is a query / response protocol. Failure		The DNS [RFC1034], [RFC1035] is a query / response protocol. Failure
	to respond to queries or to respond incorrectly causes both immediate		to respond to queries or to respond incorrectly causes both immediate
	operational problems and long term problems with protocol		operational problems and long term problems with protocol
	development.		development.
	Failure to respond to a query is indistinguishable from a packet loss		Failure to respond to a query is indistinguishable from a packet loss
	without doing a analysis of query response patterns and results in		without doing a analysis of query response patterns and results in
	skipping to change at page 3, line 42		skipping to change at page 3, line 40
	especially if EDNS is supported. Limiting the rate of responses is		especially if EDNS is supported. Limiting the rate of responses is
	reasonable when this is occurring and the client should retry. This		reasonable when this is occurring and the client should retry. This
	however only works if legitimate clients are not being forced to		however only works if legitimate clients are not being forced to
	guess whether EDNS queries are accept or not. While there is still a		guess whether EDNS queries are accept or not. While there is still a
	pool of servers that don't respond to EDNS requests, clients have no		pool of servers that don't respond to EDNS requests, clients have no
	way to know if the lack of response is due to packet loss, EDNS		way to know if the lack of response is due to packet loss, EDNS
	packets not being supported or rate limiting due to the server being		packets not being supported or rate limiting due to the server being
	under attack. Mis-classifications of server characteristics are		under attack. Mis-classifications of server characteristics are
	unavoidable when rate limiting is done.		unavoidable when rate limiting is done.
	2. Common queries class that result in non responses.		2. Common queries kinds that result in non responses.
	There are three common query classes that result in non responses		There are three common query kinds that result in non responses
	today. These are EDNS queries, queries for unknown (unallocated) or		today. These are EDNS queries, queries for unknown (unallocated) or
	unsupported types, and filtering of TCP queries.		unsupported types, and filtering of TCP queries.
	2.1. EDNS Queries - Version Independent		2.1. EDNS Queries - Version Independent
	Identifying servers that fail to respond to EDNS queries can be done		Identifying servers that fail to respond to EDNS queries can be done
	by first identifying that the server responds to regular DNS queries,		by first identifying that the server responds to regular DNS queries,
	followed by a series of otherwise identical responses using EDNS,		followed by a series of otherwise identical queries using EDNS, then
	then making the original query again. A series of EDNS queries is		making the original query again. A series of EDNS queries is needed
	needed as at least one DNS implementation responds to the first EDNS		as at least one DNS implementation responds to the first EDNS query
	query with FORMERR but fails to respond to subsequent queries from		with FORMERR but fails to respond to subsequent queries from the same
	the same address for a period until a regular DNS query is made. The		address for a period until a regular DNS query is made. The EDNS
	EDNS query should specify a UDP buffer size of 512 bytes to avoid		query should specify a UDP buffer size of 512 bytes to avoid false
	false classification of not supporting EDNS due to response packet		classification of not supporting EDNS due to response packet size.
	size.
	If the server responds to the first and last queries but fails to		If the server responds to the first and last queries but fails to
	respond to most or all of the EDNS queries, it is probably faulty.		respond to most or all of the EDNS queries, it is probably faulty.
	The test should be repeated a number of times to eliminate the		The test should be repeated a number of times to eliminate the
	likelihood of a false positive due to packet loss.		likelihood of a false positive due to packet loss.
	Firewalls may also block larger EDNS responses but there is no easy		Firewalls may also block larger EDNS responses but there is no easy
	way to check authoritative servers to see if the firewall is		way to check authoritative servers to see if the firewall is
	misconfigured.		misconfigured.
	skipping to change at page 4, line 47		skipping to change at page 4, line 38
	2.3. EDNS Options		2.3. EDNS Options
	Some servers fail to respond to EDNS queries with EDNS options set.		Some servers fail to respond to EDNS queries with EDNS options set.
	Unknown EDNS options are supposed to be ignored by the server		Unknown EDNS options are supposed to be ignored by the server
	[RFC6891].		[RFC6891].
	2.4. EDNS Flags		2.4. EDNS Flags
	Some servers fail to respond to EDNS queries with EDNS flags set.		Some servers fail to respond to EDNS queries with EDNS flags set.
	Server should ignore EDNS flags there do not understand and should		Server should ignore EDNS flags they do not understand and should not
	not add them to the response [RFC6891].		add them to the response [RFC6891].
	2.5. DNS Flags		2.5. DNS Flags
	Some servers fail to respond to DNS queries with various DNS flags		Some servers fail to respond to DNS queries with various DNS flags
	set, regardless of whether they are defined or still reserved. At		set, regardless of whether they are defined or still reserved. At
	the time of writing there are servers that fail to respond to queries		the time of writing there are servers that fail to respond to queries
	with the AD bit set to 1 and servers that fail to respond to queries		with the AD bit set to 1 and servers that fail to respond to queries
	with the last reserved flag bit set.		with the last reserved flag bit set.
	2.6. Unknown / Unsupported Type Queries		2.6. Unknown / Unsupported Type Queries
	skipping to change at page 6, line 20		skipping to change at page 6, line 10
	between the code being corrected and a nameserver being upgraded with		between the code being corrected and a nameserver being upgraded with
	corrected code. With that in mind it is requested that TLD, and		corrected code. With that in mind it is requested that TLD, and
	other similar zone operators, take steps to identify and inform their		other similar zone operators, take steps to identify and inform their
	customers, directly or indirectly through registrars, that they are		customers, directly or indirectly through registrars, that they are
	running such servers and that the customers need to correct the		running such servers and that the customers need to correct the
	problem.		problem.
	TLD operators are being asked to do this as they, due to the nature		TLD operators are being asked to do this as they, due to the nature
	of running a TLD and the hierarchical nature of the DNS, have access		of running a TLD and the hierarchical nature of the DNS, have access
	to a large numbers of nameserver names as well as contact details for		to a large numbers of nameserver names as well as contact details for
	the registrants of those nameservers. While it is possible construct		the registrants of those nameservers. While it is possible to
	lists of nameservers from other sources and that has been done to		construct lists of nameservers from other sources, and that has been
	survey the state of the Internet, that doesn't give the tester the		done to survey the state of the Internet, that doesn't give the
	contact details necessary to inform the operators. The SOA RNAME is		tester the contact details necessary to inform the operators. The
	often invalid and whois data is obscured and / or not available which		SOA RNAME is often invalid and whois data is obscured and / or not
	makes it infeasible for others to do this.		available which makes it infeasible for others to do this.
	While this section talks about TLD operators performing this work, it		While this section talks about TLD operators performing this work, it
	may be done by registrars on behalf of the TLD operator. The intent		may be done by registrars on behalf of the TLD operator. The intent
	is to ensure that the testing happens and that operators of		is to ensure that the testing happens and that operators of non-
	noncompliant nameservers be informed, rather than to prescribe who		compliant nameservers be informed, rather than to prescribe who does
	does the actual testing and communication. Note: having registrars		the actual testing and communication. Note: having registrars
	perform this testing and reporting is likely to result in duplicate		perform this testing and reporting is likely to result in duplicate
	reports for the same server being issued by multiple registrars.		reports for the same server being issued by multiple registrars.
	TLD operators should construct a list of servers child zones are		TLD operators should construct a list of servers child zones are
	delegated to along with a delegated zone name. This name shall be		delegated to along with a delegated zone name. This name shall be
	the query name used to test the server as it is supposed to exist.		the query name used to test the server as it is supposed to exist.
	For each server the TLD operator shall make an SOA query of the		For each server the TLD operator shall make an SOA query of the
	delegated zone name. This should result in the SOA record being		delegated zone name. This should result in the SOA record being
	returned in the answer section. If the SOA record is not returned		returned in the answer section. If the SOA record is not returned
	skipping to change at page 8, line 20		skipping to change at page 8, line 8
	should not be construed as an attack. Nameservers have always been		should not be construed as an attack. Nameservers have always been
	expected to be able to handle such queries.		expected to be able to handle such queries.
	Requests with unassigned flags set (DNS or EDNS) is expected client		Requests with unassigned flags set (DNS or EDNS) is expected client
	behaviour and should not be construed as an attack. The behaviour		behaviour and should not be construed as an attack. The behaviour
	for unassigned is to ignore them in the request and to not set them		for unassigned is to ignore them in the request and to not set them
	in the response. All dropping DNS / EDNS packets with unassigned		in the response. All dropping DNS / EDNS packets with unassigned
	flags does is make it harder to deploy extensions that make use of		flags does is make it harder to deploy extensions that make use of
	them due to the need to reconfigure / update firewalls.		them due to the need to reconfigure / update firewalls.
	Requests with unknown EDNS options is expected client behaviour		Requests with unknown EDNS options is expected client behaviour and
	should not be construed as an attack. The correct behaviour for		should not be construed as an attack. The correct behaviour for
	unknown EDNS options is to ignore there presence when constructing a		unknown EDNS options is to ignore there presence when constructing a
	reply.		reply.
	Requests with unknown EDNS versions is expected client behaviour		Requests with unknown EDNS versions is expected client behaviour and
	should not be trued as an attack The correct behaviour for unknown		should not be construed as an attack. The correct behaviour for
	EDNS versions is to return BADVERS along with the highest EDNS		unknown EDNS versions is to return BADVERS along with the highest
	version the server supports. All dropping EDNS packets does is break		EDNS version the server supports. All dropping EDNS packets does is
	EDNS version negotiation.		break EDNS version negotiation.
	Firewalls should not assume that there will only be a single response		Firewalls should not assume that there will only be a single response
	message to a requests. There have been proposals to use EDNS to		message to a requests. There have been proposals to use EDNS to
	signal that multiple DNS messages be returned rather than a single		signal that multiple DNS messages be returned rather than a single
	UDP message that is fragmented at the IP layer.		UDP message that is fragmented at the IP layer.
	5. Scrubbing Services		5. Scrubbing Services
	Scrubbing services, like firewalls, can affect the externally visible		Scrubbing services, like firewalls, can affect the externally visible
	behaviour of a nameserver. If a operator uses a scrubbing service,		behaviour of a nameserver. If a operator uses a scrubbing service,
	skipping to change at page 9, line 4		skipping to change at page 8, line 41
	response to denial of service attacks. One needs to take care when		response to denial of service attacks. One needs to take care when
	choosing a scrubbing service and ask questions like:		choosing a scrubbing service and ask questions like:
	Do they pass unknown DNS query types?		Do they pass unknown DNS query types?
	Do they pass unknown EDNS versions?		Do they pass unknown EDNS versions?
	Do they pass unknown EDNS options?		Do they pass unknown EDNS options?
	Do they pass unknown EDNS flags?		Do they pass unknown EDNS flags?
	Do they pass requests with unknown DNS opcodes?		Do they pass requests with unknown DNS opcodes?
	Do they pass requests with the remaining reserved DNS header flag		Do they pass requests with the remaining reserved DNS header flag
	bit set?		bit set?
	All of these are not attack vectors but some scrubbing services treat		None of these are attack vectors but some scrubbing services treat
	them as such.		them as such.
	6. Whole Answer Caches		6. Whole Answer Caches
	Whole answer caches take a previously constructed answer and return		Whole answer caches take a previously constructed answer and return
	it to a subsequent query for the same name, type and class, just		it to a subsequent query for the same qname, qtype and qclass, just
	updating the query id field and possibly the qname to match the		updating the query id field and possibly the qname to match the
	incoming query to avoid constructing each response individually.		incoming query to avoid constructing each response individually.
	Whole answer caches can return the wrong response to a query if they		Whole answer caches can return the wrong response to a query if they
	do not take all of the attributes of the query into account, rather		do not take all of the attributes of the query into account, rather
	than just some of them e.g. qname, qtype and qclass. This has		than just some of them e.g. qname, qtype and qclass. This has
	implications when testing and with overall protocol compliance.		implications when testing and with overall protocol compliance.
	e.g. There are whole answer caches that ignore the EDNS version		e.g. There are whole answer caches that ignore the EDNS version
	field which results in incorrect answers to non EDNS version 0		field which results in incorrect answers to non EDNS version 0
	skipping to change at page 15, line 18		skipping to change at page 15, line 20
	expect: status: BADVERS		expect: status: BADVERS
	expect: SOA record to not be present		expect: SOA record to not be present
	expect: OPT record to be present		expect: OPT record to be present
	expect: DO=1 to be present if the EDNS version 0 DNSSEC query test		expect: DO=1 to be present if the EDNS version 0 DNSSEC query test
	returned DO=1		returned DO=1
	expect: EDNS Version 0 in response		expect: EDNS Version 0 in response
	expect: flag: aa to NOT be present		expect: flag: aa to NOT be present
	+noednsneg disables EDNS version negotiation in DiG.		+noednsneg disables EDNS version negotiation in DiG.
	Check that EDNS queries with multiple defined EDNS options work.		Check that EDNS queries with multiple defined EDNS options work:
	dig +edns=0 +noad +norec +cookie +nsid +expire +subnet=0.0.0.0/0 \		dig +edns=0 +noad +norec +cookie +nsid +expire +subnet=0.0.0.0/0 \
	soa $zone @$server		soa $zone @$server
	expect: status: NOERROR		expect: status: NOERROR
	expect: SOA record to be present		expect: SOA record to be present
	expect: OPT record to be present		expect: OPT record to be present
	expect: EDNS Version 0 in response		expect: EDNS Version 0 in response
	expect: flag: aa to be present		expect: flag: aa to be present
	skipping to change at page 15, line 47		skipping to change at page 15, line 49
	firewalls. None of the tests listed above should break nominally		firewalls. None of the tests listed above should break nominally
	EDNS compliant servers. None of the tests above should break non		EDNS compliant servers. None of the tests above should break non
	EDNS servers. All the tests above are well formed, though not		EDNS servers. All the tests above are well formed, though not
	necessarily common, DNS queries.		necessarily common, DNS queries.
	Relaxing firewall settings to ensure EDNS compliance could		Relaxing firewall settings to ensure EDNS compliance could
	potentially expose a critical implementation flaw in the nameserver.		potentially expose a critical implementation flaw in the nameserver.
	Nameservers should be tested for conformance before relaxing firewall		Nameservers should be tested for conformance before relaxing firewall
	settings.		settings.
			When removing delegations for non-compliant servers there can be a
			knock on effect on other zones that require these zones to be
			operational for the nameservers addresses to be resolved.
	10. IANA Considerations		10. IANA Considerations
	IANA / ICANN needs to consider what tests, if any, from above that it		IANA / ICANN needs to consider what tests, if any, from above that it
	should add to the zone maintenance procedures for zones under its		should add to the zone maintenance procedures for zones under its
	control including pre-delegation checks. Otherwise this document has		control including pre-delegation checks. Otherwise this document has
	no actions for IANA.		no actions for IANA.
	11. Normative References		11. Normative References
	[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",		[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
End of changes. 23 change blocks.
	46 lines changed or deleted		49 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/