draft-ietf-dnsop-no-response-issue-14.txt		draft-ietf-dnsop-no-response-issue-15.txt
	Network Working Group M. Andrews		Network Working Group M. Andrews
	Internet-Draft R. Bellis		Internet-Draft R. Bellis
	Intended status: Best Current Practice ISC		Intended status: Best Current Practice ISC
	Expires: May 7, 2020 November 4, 2019		Expires: September 9, 2020 March 8, 2020
	A Common Operational Problem in DNS Servers - Failure To Communicate.		A Common Operational Problem in DNS Servers - Failure To Communicate.
	draft-ietf-dnsop-no-response-issue-14		draft-ietf-dnsop-no-response-issue-15
	Abstract		Abstract
	The DNS is a query / response protocol. Failing to respond to		The DNS is a query / response protocol. Failing to respond to
	queries, or responding incorrectly, causes both immediate operational		queries, or responding incorrectly, 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 kinds of queries to which		This document identifies a number of common kinds of queries to which
	some servers either fail to respond or else respond incorrectly.		some servers either fail to respond or else respond incorrectly.
	This document also suggests procedures for zone operators to apply to		This document also suggests procedures for zone operators to apply to
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 7, 2020.		This Internet-Draft will expire on September 9, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2020 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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
	skipping to change at page 4, line 21 ¶		skipping to change at page 4, line 21 ¶
	for any name the server is configured to answer for. Misconfigured		for any name the server is configured to answer for. Misconfigured
	nameservers are a common occurrence in the DNS and receiving queries		nameservers are a common occurrence in the DNS and receiving queries
	for zones that the server is not configured for is not necessarily an		for zones that the server is not configured for is not necessarily an
	indication that the server is under attack. Parent zone operators		indication that the server is under attack. Parent zone operators
	are advised to regularly check that the delegating NS records are		are advised to regularly check that the delegating NS records are
	consistent with those of the delegated zone and to correct them when		consistent with those of the delegated zone and to correct them when
	they are not [RFC1034]. Doing this regularly should reduce the		they are not [RFC1034]. Doing this regularly should reduce the
	instances of broken delegations.		instances of broken delegations.
	This document does not try to identify all possible errors nor does		This document does not try to identify all possible errors nor does
	it supply a exhaustive list of tests.		it supply an exhaustive list of tests.
	2. Consequences		2. Consequences
	Failure to follow the relevant DNS RFCs has multiple adverse		Failure to follow the relevant DNS RFCs has multiple adverse
	consequences. Some are caused directly from the non-compliant		consequences. Some are caused directly from the non-compliant
	behaviour and others as a result of work-arounds forced on recursive		behaviour and others as a result of work-arounds forced on recursive
	servers. Addressing known issues now will reduce future		servers. Addressing known issues now will reduce future
	interoperability issues as the DNS protocol continues to evolve and		interoperability issues as the DNS protocol continues to evolve and
	clients make use of newly-introduced DNS features. In particular the		clients make use of newly-introduced DNS features. In particular the
	base DNS specification [RFC1034], [RFC1035] and the EDNS		base DNS specification [RFC1034], [RFC1035] and the EDNS
	skipping to change at page 5, line 5 ¶		skipping to change at page 5, line 5 ¶
	servers having to assume that EDNS is not supported and that		servers having to assume that EDNS is not supported and that
	fallback to plain DNS is required, potentially causing DNSSEC		fallback to plain DNS is required, potentially causing DNSSEC
	validation failures.		validation failures.
	o Widespread non-response to EDNS options, requires recursive		o Widespread non-response to EDNS options, requires recursive
	servers to have to decide whether to probe to see if it is the		servers to have to decide whether to probe to see if it is the
	EDNS option or just EDNS that is causing the non response. In the		EDNS option or just EDNS that is causing the non response. In the
	limited amount of time required to resolve a query before the		limited amount of time required to resolve a query before the
	client times out this is not possible.		client times out this is not possible.
	o Incorrectly returning FORMERR to a EDNS option being present,		o Incorrectly returning FORMERR to an EDNS option being present,
	leads to the recursive server not being able to determine if the		leads to the recursive server not being able to determine if the
	server is just broken in the handling of the EDNS option or		server is just broken in the handling of the EDNS option or
	doesn't support EDNS at all.		doesn't support EDNS at all.
	o Mishandling of unknown query types has contributed to the		o Mishandling of unknown query types has contributed to the
	abandonment of the transition of the SPF type.		abandonment of the transition of the SPF type.
	o Mishandling of unknown query types has slowed up the development		o Mishandling of unknown query types has slowed up the development
	of DANE and resulted in additional rules being specified to reduce		of DANE and resulted in additional rules being specified to reduce
	the probability of interacting with a broken server when making		the probability of interacting with a broken server when making
	skipping to change at page 5, line 38 ¶		skipping to change at page 5, line 38 ¶
	3. Common kinds of queries that result in no or bad responses.		3. Common kinds of queries that result in no or bad responses.
	This section is broken down into Basic DNS requests and EDNS		This section is broken down into Basic DNS requests and EDNS
	requests.		requests.
	3.1. Basic DNS Queries		3.1. Basic DNS Queries
	3.1.1. Zone Existence		3.1.1. Zone Existence
	Initially, to test existence of the zone, an SOA query should be		If a zone is delegated to a server, that server should respond to an
	made. If the SOA record is not returned but some other response is		SOA query for that zone with an SOA record. Failing to respond at
	returned, this is an indication of a bad delegation.		all is always incorrect, regardless of the configuration of the
			server. Responding with anything other than an SOA record in the
			Answer section indicates a bad delegation.
	3.1.2. Unknown / Unsupported Type Queries		3.1.2. Unknown / Unsupported Type Queries
	Identifying servers that fail to respond to unknown or unsupported		Some servers fail to respond to unknown or unsupported types. If a
	types can be done by making an initial DNS query for an A record,		server receives a query for a type that it doesn't recognize, or
	making a number of queries for an unallocated type, then making a		doesn't implement, it is expected to return the appropriate response
	query for an A record again. IANA maintains a registry of allocated		as if it did recognize the type but does not have any data for that
	types.		type: either NOERROR, or NXDOMAIN. The exception to this are queries
			for Meta-RR types which may return NOTIMP.
	If the server responds to the first and last queries but fails to
	respond to the queries for the unallocated type, it is probably
	faulty. The test should be repeated a number of times to eliminate
	the likelihood of a false positive due to packet loss.
	3.1.3. DNS Flags		3.1.3. 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.
	3.1.3.1. Recursive Queries		3.1.3.1. Recursive Queries
	skipping to change at page 9, line 39 ¶		skipping to change at page 9, line 39 ¶
	with a particular flag, EDNS option, EDNS version field, opcode, type		with a particular flag, EDNS option, EDNS version field, opcode, type
	or class field or combination thereof to the point where the		or class field or combination thereof to the point where the
	integrity of the nameserver is compromised. Firewalls should offer		integrity of the nameserver is compromised. Firewalls should offer
	the ability to selectively reject messages using an appropriately		the ability to selectively reject messages using an appropriately
	constructed response based on all these fields while awaiting a fix		constructed response based on all these fields while awaiting a fix
	from the nameserver vendor.		from the nameserver vendor.
	5. Scrubbing Services		5. Scrubbing Services
	Scrubbing services can affect the externally visible behaviour of a		Scrubbing services can affect the externally visible behaviour of a
	nameserver in a similar way to firewalls. If a operator uses a		nameserver in a similar way to firewalls. If an operator uses a
	scrubbing service, they should check that legitimate queries are not		scrubbing service, they should check that legitimate queries are not
	being blocked.		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.		choosing a scrubbing service.
	Ideally, Operators should run these tests against a scrubbing service		Ideally, Operators should run these tests against a scrubbing service
	to ensure that these tests are not seen as attack vectors.		to ensure that these tests are not seen as attack vectors.
	skipping to change at page 12, line 7 ¶		skipping to change at page 12, line 7 ¶
	expect: status: NOERROR		expect: status: NOERROR
	expect: the SOA record to be present in the answer section		expect: the SOA record to be present in the answer section
	expect: flag: aa to be present		expect: flag: aa to be present
	expect: flag: rd to NOT be present		expect: flag: rd to NOT be present
	expect: flag: ad to NOT be present		expect: flag: ad to NOT be present
	expect: the OPT record to NOT be present		expect: the OPT record to NOT be present
	8.1.2. Testing Unknown Types		8.1.2. Testing Unknown Types
			Identifying servers that fail to respond to unknown or unsupported
			types can be done by making an initial DNS query for an A record,
			making a number of queries for an unallocated type, then making a
			query for an A record again. IANA maintains a registry of allocated
			types.
			If the server responds to the first and last queries but fails to
			respond to the queries for the unallocated type, it is probably
			faulty. The test should be repeated a number of times to eliminate
			the likelihood of a false positive due to packet loss.
	Ask for the TYPE1000 RRset at the configured zone's name. This query		Ask for the TYPE1000 RRset at the configured zone's name. This query
	is made with no DNS flag bits set and without EDNS. TYPE1000 has		is made with no DNS flag bits set and without EDNS. TYPE1000 has
	been chosen for this purpose as IANA is unlikely to allocate this		been chosen for this purpose as IANA is unlikely to allocate this
	type in the near future and it is not in a range reserved for private		type in the near future and it is not in a range reserved for private
	use [RFC6895]. Any unallocated type code could be chosen for this		use [RFC6895]. Any unallocated type code could be chosen for this
	test.		test.
	We expect no records to be returned in the answer section with the		We expect no records to be returned in the answer section with the
	rcode set to NOERROR and the AA and QR bits to be set in the		rcode set to NOERROR and the AA and QR bits to be set in the
	response; RA may also be set [RFC1034]. We do not expect an OPT		response; RA may also be set [RFC1034]. We do not expect an OPT
	skipping to change at page 17, line 26 ¶		skipping to change at page 17, line 26 ¶
	+noednsneg has been set as dig supports EDNS version negotiation and		+noednsneg has been set as dig supports EDNS version negotiation and
	we want to see only the response to the initial EDNS version 1 query.		we want to see only the response to the initial EDNS version 1 query.
	8.2.3. Testing Unknown EDNS Options		8.2.3. Testing Unknown EDNS Options
	Ask for the SOA record of the configured zone. This query is made		Ask for the SOA record of the configured zone. This query is made
	with no DNS flag bits set. EDNS version 0 is used without any EDNS		with no DNS flag bits set. EDNS version 0 is used without any EDNS
	flags. An EDNS option is present with a value that has not yet been		flags. An EDNS option is present with a value that has not yet been
	assigned by IANA. We have picked an unassigned code of 100 for the		assigned by IANA. We have picked an unassigned code of 100 for the
	example below. Any unassigned EDNS option code could have been		example below. Any unassigned EDNS option code could have been
	choose for this test.		choosen for this test.
	We expect the SOA record for the zone to be returned in the answer		We expect the SOA record for the zone to be returned in the answer
	section with the rcode set to NOERROR and the AA and QR bits to be		section with the rcode set to NOERROR and the AA and QR bits to be
	set in the response; RA may also be set [RFC1034]. We expect an OPT		set in the response; RA may also be set [RFC1034]. We expect an OPT
	record to be returned. There should be no EDNS flags present in the		record to be returned. There should be no EDNS flags present in the
	response. The EDNS version field should be 0 as EDNS versions other		response. The EDNS version field should be 0 as EDNS versions other
	than 0 are yet to be specified and there should be no EDNS options		than 0 are yet to be specified and there should be no EDNS options
	present as unknown EDNS options are supposed to be ignored by the		present as unknown EDNS options are supposed to be ignored by the
	server [RFC6891] Section 6.1.2.		server [RFC6891] Section 6.1.2.
	skipping to change at page 21, line 12 ¶		skipping to change at page 21, line 12 ¶
	present if the server supports DNSSEC. The EDNS version field should		present if the server supports DNSSEC. The EDNS version field should
	be 0 and there should be no EDNS options present [RFC6891].		be 0 and there should be no EDNS options present [RFC6891].
	Check that DO=1 queries work (EDNS supported):		Check that DO=1 queries work (EDNS supported):
	dig +nocookie +edns=0 +noad +norec +dnssec soa $zone @$server		dig +nocookie +edns=0 +noad +norec +dnssec soa $zone @$server
	expect: status: NOERROR		expect: status: NOERROR
	expect: the SOA record to be present in the answer section		expect: the SOA record to be present in the answer section
	expect: an OPT record to be present in the additional section		expect: an OPT record to be present in the additional section
	expect: DO=1 to be present if a RRSIG is in the response		expect: DO=1 to be present if an RRSIG is in the response
	expect: EDNS Version 0 in response		expect: EDNS Version 0 in response
	expect: flag: aa to be present		expect: flag: aa to be present
	8.2.9. Testing EDNS Version Negotiation With DO=1		8.2.9. Testing EDNS Version Negotiation With DO=1
	Ask for the SOA record of the configured zone, which does not need to		Ask for the SOA record of the configured zone, which does not need to
	be DNSSEC signed. This query is made with no DNS flag bits set.		be DNSSEC signed. This query is made with no DNS flag bits set.
	EDNS version 1 is used without any EDNS options. The only EDNS flag		EDNS version 1 is used without any EDNS options. The only EDNS flag
	set is DO.		set is DO.
End of changes. 12 change blocks.
	22 lines changed or deleted		31 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/