draft-ietf-dnsop-no-response-issue-18.txt		draft-ietf-dnsop-no-response-issue-19.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: September 23, 2020 March 22, 2020		Expires: October 7, 2020 April 5, 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-18		draft-ietf-dnsop-no-response-issue-19
	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 September 23, 2020.		This Internet-Draft will expire on October 7, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 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
	skipping to change at page 2, line 31 ¶		skipping to change at page 2, line 31 ¶
	3.1.5. TCP Queries . . . . . . . . . . . . . . . . . . . . . 6		3.1.5. TCP Queries . . . . . . . . . . . . . . . . . . . . . 6
	3.2. EDNS Queries . . . . . . . . . . . . . . . . . . . . . . 6		3.2. EDNS Queries . . . . . . . . . . . . . . . . . . . . . . 6
	3.2.1. EDNS Queries - Version Independent . . . . . . . . . 7		3.2.1. EDNS Queries - Version Independent . . . . . . . . . 7
	3.2.2. EDNS Queries - Version Specific . . . . . . . . . . . 7		3.2.2. EDNS Queries - Version Specific . . . . . . . . . . . 7
	3.2.3. EDNS Options . . . . . . . . . . . . . . . . . . . . 7		3.2.3. EDNS Options . . . . . . . . . . . . . . . . . . . . 7
	3.2.4. EDNS Flags . . . . . . . . . . . . . . . . . . . . . 7		3.2.4. EDNS Flags . . . . . . . . . . . . . . . . . . . . . 7
	3.2.5. Truncated EDNS Responses . . . . . . . . . . . . . . 8		3.2.5. Truncated EDNS Responses . . . . . . . . . . . . . . 8
	3.2.6. DO=1 Handling . . . . . . . . . . . . . . . . . . . . 8		3.2.6. DO=1 Handling . . . . . . . . . . . . . . . . . . . . 8
	3.2.7. EDNS over TCP . . . . . . . . . . . . . . . . . . . . 8		3.2.7. EDNS over TCP . . . . . . . . . . . . . . . . . . . . 8
	4. Firewalls and Load Balancers . . . . . . . . . . . . . . . . 8		4. Firewalls and Load Balancers . . . . . . . . . . . . . . . . 8
	5. Scrubbing Services . . . . . . . . . . . . . . . . . . . . . 9		5. Packet Scrubbing Services . . . . . . . . . . . . . . . . . . 9
	6. Whole Answer Caches . . . . . . . . . . . . . . . . . . . . . 10		6. Whole Answer Caches . . . . . . . . . . . . . . . . . . . . . 10
	7. Response Code Selection . . . . . . . . . . . . . . . . . . . 10		7. Response Code Selection . . . . . . . . . . . . . . . . . . . 10
	8. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 11		8. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	8.1. Testing - Basic DNS . . . . . . . . . . . . . . . . . . . 11		8.1. Testing - Basic DNS . . . . . . . . . . . . . . . . . . . 11
	8.1.1. Is The Server Configured For The Zone? . . . . . . . 11		8.1.1. Is The Server Configured For The Zone? . . . . . . . 11
	8.1.2. Testing Unknown Types . . . . . . . . . . . . . . . . 12		8.1.2. Testing Unknown Types . . . . . . . . . . . . . . . . 12
	8.1.3. Testing Header Bits . . . . . . . . . . . . . . . . . 13		8.1.3. Testing Header Bits . . . . . . . . . . . . . . . . . 13
	8.1.4. Testing Unknown Opcodes . . . . . . . . . . . . . . . 15		8.1.4. Testing Unknown Opcodes . . . . . . . . . . . . . . . 15
	8.1.5. Testing TCP . . . . . . . . . . . . . . . . . . . . . 15		8.1.5. Testing TCP . . . . . . . . . . . . . . . . . . . . . 15
	8.2. Testing - Extended DNS . . . . . . . . . . . . . . . . . 16		8.2. Testing - Extended DNS . . . . . . . . . . . . . . . . . 16
	skipping to change at page 7, line 35 ¶		skipping to change at page 7, line 35 ¶
	3.2.2. EDNS Queries - Version Specific		3.2.2. EDNS Queries - Version Specific
	Some servers respond correctly to EDNS version 0 queries but fail to		Some servers respond correctly to EDNS version 0 queries but fail to
	respond to EDNS queries with version numbers that are higher than		respond to EDNS queries with version numbers that are higher than
	zero. Servers should respond with BADVERS to EDNS queries with		zero. Servers should respond with BADVERS to EDNS queries with
	version numbers that they do not support.		version numbers that they do not support.
	Some servers respond correctly to EDNS version 0 queries but fail to		Some servers respond correctly to EDNS version 0 queries but fail to
	set QR=1 when responding to EDNS versions they do not support. Such		set QR=1 when responding to EDNS versions they do not support. Such
	answers responses may be discarded as invalid (as QR is not 1) or		responses may be discarded as invalid (as QR is not 1) or treated as
	treated as requests (when the source port of the original request was		requests (when the source port of the original request was port 53).
	port 53).
	3.2.3. EDNS Options		3.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.
	The original EDNS specification left this behaviour undefined		The original EDNS specification left this behaviour undefined
	[RFC2671], but the correct behaviour was clarified in [RFC6891].		[RFC2671], but the correct behaviour was clarified in [RFC6891].
	Unknown EDNS options are supposed to be ignored by the server.		Unknown EDNS options are supposed to be ignored by the server.
	3.2.4. EDNS Flags		3.2.4. EDNS Flags
	skipping to change at page 9, line 45 ¶		skipping to change at page 9, line 45 ¶
	design.		design.
	However, there may be times when a nameserver mishandles messages		However, there may be times when a nameserver mishandles messages
	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. Packet Scrubbing Services
	Scrubbing services can affect the externally visible behaviour of a		Packet scrubbing services are used to filter out undesired traffic,
	nameserver in a similar way to firewalls. If an operator uses a		including but not limited to, denial of service traffic. This is
	scrubbing service, they should check that legitimate queries are not		often done using heuristic analysis of the traffic.
	being blocked.
	Scrubbing services, unlike firewalls, are also turned on and off in		Packet scrubbing services can affect the externally visible behaviour
	response to denial of service attacks. One needs to take care when		of a nameserver in a similar way to firewalls. If an operator uses a
	choosing a scrubbing service.		packet scrubbing service, they should check that legitimate queries
			are not being blocked.
	Ideally, Operators should run these tests against a scrubbing service		Packet scrubbing services, unlike firewalls, are also turned on and
	to ensure that these tests are not seen as attack vectors.		off in response to denial of service attacks. One needs to take care
			when choosing a scrubbing service.
			Ideally, Operators should run these tests against a packet scrubbing
			service to ensure that these tests are not seen as attack vectors.
	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 question. However, they can		it to a subsequent query for the same question. However, they can
	return the wrong response if they do not take all of the relevant		return the wrong response if they do not take all of the relevant
	attributes of the query into account.		attributes of the query into account.
	In addition to the standard tuple of <qname,qtype,qclass> a non-		In addition to the standard tuple of <qname,qtype,qclass> a non-
	exhaustive set of attributes that must be considered include: RD, AD,		exhaustive set of attributes that must be considered include: RD, AD,
	skipping to change at page 24, line 10 ¶		skipping to change at page 24, line 10 ¶
	have unanticipated side effects. For example, other parts of the DNS		have unanticipated side effects. For example, other parts of the DNS
	tree may depend on names below the removed zone cut, and the parent		tree may depend on names below the removed zone cut, and the parent
	operator may find themselves responsible for causing new DNS failures		operator may find themselves responsible for causing new DNS failures
	to occur.		to occur.
	10. Security Considerations		10. Security Considerations
	Testing protocol compliance can potentially result in false reports		Testing protocol compliance can potentially result in false reports
	of attempts to break services from Intrusion Detection Services and		of attempts to break services from Intrusion Detection Services and
	firewalls. All of the tests are well-formed (though not necessarily		firewalls. All of the tests are well-formed (though not necessarily
	common) DNS queries. None the tests listed above should cause any		common) DNS queries. None of the tests listed above should cause any
	harm to a protocol-compliant server.		harm to a protocol-compliant server.
	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		When removing delegations for non-compliant servers there can be a
	knock on effect on other zones that require these zones to be		knock on effect on other zones that require these zones to be
	operational for the nameservers addresses to be resolved.		operational for the nameservers addresses to be resolved.
End of changes. 10 change blocks.
	18 lines changed or deleted		21 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/