draft-ietf-dnsop-no-response-issue-00.txt		draft-ietf-dnsop-no-response-issue-01.txt
	Network Working Group M. Andrews		Network Working Group M. Andrews
	Internet-Draft ISC		Internet-Draft ISC
	Intended status: Best Current Practice November 28, 2015		Intended status: Best Current Practice December 1, 2015
	Expires: May 31, 2016		Expires: June 3, 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-00		draft-ietf-dnsop-no-response-issue-01
	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 classes of queries to
	which some servers either fail to respond or else respond		which some servers either fail to respond or else respond
	incorrectly. This document also suggests procedures for TLD and		incorrectly. This document also suggests procedures for TLD and
	skipping to change at page 1, line 41		skipping to change at page 1, line 41
	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 May 31, 2016.		This Internet-Draft will expire on June 3, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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
	skipping to change at page 2, line 34		skipping to change at page 2, line 34
	3. Remediating . . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Remediating . . . . . . . . . . . . . . . . . . . . . . . . . 6
	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 . . . . . . . . . . . . . . . . . . . . . 15
	11. Normative References . . . . . . . . . . . . . . . . . . . . 15		11. Normative References . . . . . . . . . . . . . . . . . . . . 16
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
	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
	skipping to change at page 3, line 21		skipping to change at page 3, line 21
	The DNS has response codes that cover almost any conceivable query		The DNS has response codes that cover almost any conceivable query
	response. A nameserver should be able to respond to any conceivable		response. A nameserver should be able to respond to any conceivable
	query using them.		query using them.
	Unless a nameserver is under attack, it should respond to all queries		Unless a nameserver is under attack, it should respond to all queries
	directed to it as a result of following delegations. Additionally		directed to it as a result of following delegations. Additionally
	code should not assume that there isn't a delegation to the server		code should not assume that there isn't a delegation to the server
	even if it is not configured to serve the zone. Broken delegations		even if it is not configured to serve the zone. Broken delegations
	are a common occurrence in the DNS and receiving queries for zones		are a common occurrence in the DNS and receiving queries for zones
	that you are not configured for is not a necessarily a indication		that the server is not configured for is not necessarily an
	that you are under attack. Parent zone operators are supposed to		indication that the server is under attack. Parent zone operators
	regularly check that the delegating NS records are consistent with		are supposed to regularly check that the delegating NS records are
	those of the delegated zone and to correct them when they are not		consistent with those of the delegated zone and to correct them when
	[RFC1034]. If this was being done regularly, the instances of broken		they are not [RFC1034]. If this was being done regularly, the
	delegations would be much lower.		instances of broken delegations would be much lower.
	When a nameserver is under attack it may wish to drop packets. A		When a nameserver is under attack it may wish to drop packets. A
	common attack is to use a nameserver as a amplifier by sending		common attack is to use a nameserver as a amplifier by sending
	spoofed packets. This is done because response packets are bigger		spoofed packets. This is done because response packets are bigger
	than the queries and big amplification factors are available		than the queries and big amplification factors are available
	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
	skipping to change at page 5, line 17		skipping to change at page 5, line 17
	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
	Identifying servers that fail to respond to unknown or unsupported		Identifying servers that fail to respond to unknown or unsupported
	types can be done by making an initial DNS query for an A record,		types can be done by making an initial DNS query for an A record,
	making a number of queries for an unallocated type, them making a		making a number of queries for an unallocated type, then making a
	query for an A record again. IANA maintains a registry of allocated		query for an A record again. IANA maintains a registry of allocated
	types.		types.
	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 the queries for the unallocated type, it is probably		respond to the queries for the unallocated type, it is probably
	faulty. The test should be repeated a number of times to eliminate		faulty. The test should be repeated a number of times to eliminate
	the likelihood of a false positive due to packet loss.		the likelihood of a false positive due to packet loss.
	2.7. Unknown DNS opcodes		2.7. Unknown DNS opcodes
	skipping to change at page 6, line 20		skipping to change at page 6, line 20
	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. One can construct lists of		the registrants of those nameservers. While it is possible construct
	nameservers from other sources and that has been done to survey the		lists of nameservers from other sources and that has been done to
	state of the Internet, but that doesn't give you the contact details		survey the state of the Internet, that doesn't give the tester the
	necessary to inform the operators. The SOA RNAME is often invalid		contact details necessary to inform the operators. The SOA RNAME is
	and whois data is obscured and / or not available which makes it		often invalid and whois data is obscured and / or not available which
	infeasible for others to do this.		makes it infeasible for others to do this.
			While this section talks about TLD operators performing this work, it
			may be done by registrars on behalf of the TLD operator. The intent
			is to ensure that the testing happens and that operators of
			noncompliant nameservers be informed, rather than to prescribe who
			does the actual testing and communication. Note: having registrars
			perform this testing and reporting is likely to result in duplicate
			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
	but some other response is returned, this is a indication of a bad		but some other response is returned, this is a indication of a bad
	delegation and the TLD operator should take whatever steps it		delegation and the TLD operator should take whatever steps it
	skipping to change at page 7, line 46		skipping to change at page 8, line 9
	4. Firewalls and Load Balancers		4. Firewalls and Load Balancers
	Firewalls and load balancers can affect the externally visible		Firewalls and load balancers can affect the externally visible
	behaviour of a nameserver. Tests for conformance need to be done		behaviour of a nameserver. Tests for conformance need to be done
	from outside of any firewall so that the system as a whole is tested.		from outside of any firewall so that the system as a whole is tested.
	Firewalls and load balancers should not drop DNS packets that they		Firewalls and load balancers should not drop DNS packets that they
	don't understand. They should either pass through the packets or		don't understand. They should either pass through the packets or
	generate an appropriate error response.		generate an appropriate error response.
	Requests for unknown query types are not attacks and should not be		Requests for unknown query types is normal client behaviour and
	treated as such.		should not be construed as an attack. Nameservers have always been
			expected to be able to handle such queries.
	Requests with unassigned flags set (DNS or EDNS) are not attacks and		Requests with unassigned flags set (DNS or EDNS) is expected client
	should not be treated as such. The behaviour for unassigned is to		behaviour and should not be construed as an attack. The behaviour
	ignore them in the request and to not set them in the response. All		for unassigned is to ignore them in the request and to not set them
	dropping DNS / EDNS packets with unassigned flags does is make it		in the response. All dropping DNS / EDNS packets with unassigned
	harder to deploy extensions that make use of them due to the need to		flags does is make it harder to deploy extensions that make use of
	reconfigure / update firewalls.		them due to the need to reconfigure / update firewalls.
	Requests with unknown EDNS options are not an attack and should not		Requests with unknown EDNS options is expected client behaviour
	be treated as such. The correct behaviour for unknown EDNS options		should not be construed as an attack. The correct behaviour for
	is to ignore them.		unknown EDNS options is to ignore there presence when constructing a
			reply.
	Requests with unknown EDNS versions are not a attack and should not		Requests with unknown EDNS versions is expected client behaviour
	be treated as such. The correct behaviour for unknown EDNS versions		should not be trued as an attack The correct behaviour for unknown
	is to return BADVERS along with the highest EDNS version the server		EDNS versions is to return BADVERS along with the highest EDNS
	supports. All dropping EDNS packets does is break EDNS version		version the server supports. All dropping EDNS packets does is break
	negotiation.		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 you use a scrubbing service, you		behaviour of a nameserver. If a operator uses a scrubbing service,
	should check that legitimate queries are not being blocked.		they should check that legitimate queries are not being blocked.
	Scrubbing services, unlike firewalls, are also turned on and off in		Scrubbing services, unlike firewalls, are also turned on and off in
	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?
	skipping to change at page 9, line 7		skipping to change at page 9, line 14
	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		All of these are not 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
			it to a subsequent query for the same name, type and class, just
			updating the query id field and possibly the qname to match the
			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 query into account. This has implications		do not take all of the attributes of the query into account, rather
	when testing and with overall protocol compliance.		than just some of them e.g. qname, qtype and qclass. This has
			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
	queries being returned if they were proceeded by a EDNS version 0		queries being returned if they were preceded by a EDNS version 0
	query for the same name and type.		query for the same name and type.
			e.g. There are caches that ignore the EDNS options in the query
			resulting in options only working some of the time and/or options
			being returned when not requested.
	7. Response Code Selection		7. Response Code Selection
	Choosing the correct response code when fixing a nameserver is		Choosing the correct response code when fixing a nameserver is
	important. Just because a type is not implemented does not mean that		important. Just because a type is not implemented does not mean that
	NOTIMP is the correct response code to return. Response codes need		NOTIMP is the correct response code to return. Response codes need
	to be chosen considering how clients will handle them.		to be chosen considering how clients will handle them.
	For unimplemented opcodes NOTIMP is the expected response code.		For unimplemented opcodes NOTIMP is the expected response code.
	Additionally a new opcode could change the message format by		Additionally a new opcode could change the message format by
	extending the header or changing the structure of the records etc.		extending the header or changing the structure of the records etc.
	skipping to change at page 9, line 40		skipping to change at page 10, line 10
	NOERROR (no data) are the expected response codes. A server is not		NOERROR (no data) are the expected response codes. A server is not
	supposed to serve a zone which contains unsupported types ([RFC1034])		supposed to serve a zone which contains unsupported types ([RFC1034])
	so the only thing left is return if the QNAME exists or not. NOTIMP		so the only thing left is return if the QNAME exists or not. NOTIMP
	and REFUSED are not useful responses as they force the clients to try		and REFUSED are not useful responses as they force the clients to try
	all the authoritative servers for a zone looking for a server which		all the authoritative servers for a zone looking for a server which
	will answer the query.		will answer the query.
	Meta queries type may be the exception but these need to be thought		Meta queries type may be the exception but these need to be thought
	about on a case by case basis.		about on a case by case basis.
	If you support EDNS and get a query with an unsupported EDNS version,		If the server supports EDNS and get a query with an unsupported EDNS
	the correct response is BADVERS [RFC6891].		version, the correct response is BADVERS [RFC6891].
	If you do not support EDNS at all, FORMERR and NOTIMP are the		If the server do not support EDNS at all, FORMERR and NOTIMP are the
	expected error codes. That said a minimal EDNS server implementation		expected error codes. That said a minimal EDNS server implementation
	just requires parsing the OPT records and responding with an empty		just requires parsing the OPT records and responding with an empty
	OPT record. There is no need to interpret any EDNS options present		OPT record. There is no need to interpret any EDNS options present
	in the request as unsupported options are expected to be ignored		in the request as unsupported options are expected to be ignored
	[RFC6891].		[RFC6891].
	8. Testing		8. Testing
	Testing is broken into two sections. Basic DNS which all servers		Testing is divided into two sections. Basic DNS which all servers
	should meet and Extended DNS which should be met by all servers that		should meet and Extended DNS which should be met by all servers that
	support EDNS.		support EDNS. If a server does not support EDNS it should still
			respond to all the tests.
	It is advisable to run all the below tests in parallel so as to		It is advisable to run all of the tests below in parallel so as to
	minimise the delays due to multiple timeouts when the servers do not		minimise the delays due to multiple timeouts when the servers do not
	respond.		respond.
	The below tests use dig from BIND 9.11.0 which is still in		The tests below use dig from BIND 9.11.0 which is still in
	development.		development.
	8.1. Testing - Basic DNS		8.1. Testing - Basic DNS
	This first set of tests cover basic DNS server behaviour and all		This first set of tests cover basic DNS server behaviour and all
	servers should pass these tests.		servers should pass these tests.
	Verify the server is configured for the zone:		Verify the server is configured for the zone:
	dig +noedns +noad +norec soa $zone @$server		dig +noedns +noad +norec soa $zone @$server
	skipping to change at page 11, line 5		skipping to change at page 11, line 26
	expect: status: NOERROR		expect: status: NOERROR
	expect: an empty answer section.		expect: an empty answer section.
	expect: flag: aa to be present		expect: flag: aa to be present
	That new types are to be expected is specified in Section 3.6,		That new types are to be expected is specified in Section 3.6,
	[RFC1035]. Servers that don't support a new type are expected to		[RFC1035]. Servers that don't support a new type are expected to
	reject a zone that contains a unsupported type as per Section 5.2,		reject a zone that contains a unsupported type as per Section 5.2,
	[RFC1035]. This means that a server that does load a zone can answer		[RFC1035]. This means that a server that does load a zone can answer
	questions for unknown types with NOERROR or NXDOMAIN as per		questions for unknown types with NOERROR or NXDOMAIN as per
	Section 4.3.2, [RFC1034]. [RFC6195] later reserved distinct ranges		Section 4.3.2, [RFC1034]. [RFC6895] later reserved distinct ranges
	for meta and data types which allows servers to be definitive about		for meta and data types which allows servers to be definitive about
	whether a query should be answerable from zone content or not.		whether a query should be answerable from zone content or not.
	Check that queries with CD=1 work:		Check that queries with CD=1 work:
	dig +noedns +noad +norec +cd soa $zone @$server		dig +noedns +noad +norec +cd soa $zone @$server
	expect: status: NOERROR		expect: status: NOERROR
	expect: SOA record to be present		expect: SOA record to be present
	expect: flag: aa to be present		expect: flag: aa to be present
	skipping to change at page 16, line 14		skipping to change at page 16, line 28
	[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "Protocol Modifications for the DNS Security		Rose, "Protocol Modifications for the DNS Security
	Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,		Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
	<http://www.rfc-editor.org/info/rfc4035>.		<http://www.rfc-editor.org/info/rfc4035>.
	[RFC5966] Bellis, R., "DNS Transport over TCP - Implementation		[RFC5966] Bellis, R., "DNS Transport over TCP - Implementation
	Requirements", RFC 5966, DOI 10.17487/RFC5966, August		Requirements", RFC 5966, DOI 10.17487/RFC5966, August
	2010, <http://www.rfc-editor.org/info/rfc5966>.		2010, <http://www.rfc-editor.org/info/rfc5966>.
	[RFC6195] Eastlake 3rd, D., "Domain Name System (DNS) IANA
	Considerations", RFC 6195, DOI 10.17487/RFC6195, March
	2011, <http://www.rfc-editor.org/info/rfc6195>.
	[RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and		[RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and
	Implementation Notes for DNS Security (DNSSEC)", RFC 6840,		Implementation Notes for DNS Security (DNSSEC)", RFC 6840,
	DOI 10.17487/RFC6840, February 2013,		DOI 10.17487/RFC6840, February 2013,
	<http://www.rfc-editor.org/info/rfc6840>.		<http://www.rfc-editor.org/info/rfc6840>.
	[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms		[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
	for DNS (EDNS(0))", STD 75, RFC 6891,		for DNS (EDNS(0))", STD 75, RFC 6891,
	DOI 10.17487/RFC6891, April 2013,		DOI 10.17487/RFC6891, April 2013,
	<http://www.rfc-editor.org/info/rfc6891>.		<http://www.rfc-editor.org/info/rfc6891>.
			[RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA
			Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895,
			April 2013, <http://www.rfc-editor.org/info/rfc6895>.
	Author's Address		Author's Address
	M. Andrews		M. Andrews
	Internet Systems Consortium		Internet Systems Consortium
	950 Charter Street		950 Charter Street
	Redwood City, CA 94063		Redwood City, CA 94063
	US		US
	Email: marka@isc.org		Email: marka@isc.org
End of changes. 25 change blocks.
	51 lines changed or deleted		72 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/