draft-ietf-dnsop-no-response-issue-20.txt   draft-ietf-dnsop-no-response-issue-21.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: October 9, 2020 April 7, 2020 Expires: October 15, 2020 April 13, 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-20 draft-ietf-dnsop-no-response-issue-21
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 October 9, 2020. This Internet-Draft will expire on October 15, 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 35 skipping to change at page 2, line 35
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. Packet 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 . . . . . . . . . . . . . . . . . . . 12
8.1.1. Is The Server Configured For The Zone? . . . . . . . 12 8.1.1. Is The Server Configured For The Zone? . . . . . . . 12
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
8.2.1. Testing Minimal EDNS . . . . . . . . . . . . . . . . 16 8.2.1. Testing Minimal EDNS . . . . . . . . . . . . . . . . 16
8.2.2. Testing EDNS Version Negotiation . . . . . . . . . . 17 8.2.2. Testing EDNS Version Negotiation . . . . . . . . . . 17
8.2.3. Testing Unknown EDNS Options . . . . . . . . . . . . 17 8.2.3. Testing Unknown EDNS Options . . . . . . . . . . . . 17
8.2.4. Testing Unknown EDNS Flags . . . . . . . . . . . . . 18 8.2.4. Testing Unknown EDNS Flags . . . . . . . . . . . . . 18
8.2.5. Testing EDNS Version Negotiation With Unknown EDNS 8.2.5. Testing EDNS Version Negotiation With Unknown EDNS
Flags . . . . . . . . . . . . . . . . . . . . . . . . 18 Flags . . . . . . . . . . . . . . . . . . . . . . . . 19
8.2.6. Testing EDNS Version Negotiation With Unknown EDNS 8.2.6. Testing EDNS Version Negotiation With Unknown EDNS
Options . . . . . . . . . . . . . . . . . . . . . . . 19 Options . . . . . . . . . . . . . . . . . . . . . . . 20
8.2.7. Testing Truncated Responses . . . . . . . . . . . . . 20 8.2.7. Testing Truncated Responses . . . . . . . . . . . . . 20
8.2.8. Testing DO=1 Handling . . . . . . . . . . . . . . . . 20 8.2.8. Testing DO=1 Handling . . . . . . . . . . . . . . . . 21
8.2.9. Testing EDNS Version Negotiation With DO=1 . . . . . 21 8.2.9. Testing EDNS Version Negotiation With DO=1 . . . . . 21
8.2.10. Testing With Multiple Defined EDNS Options . . . . . 22 8.2.10. Testing With Multiple Defined EDNS Options . . . . . 22
8.3. When EDNS Is Not Supported . . . . . . . . . . . . . . . 22 8.3. When EDNS Is Not Supported . . . . . . . . . . . . . . . 22
9. Remediation . . . . . . . . . . . . . . . . . . . . . . . . . 22 9. Remediation . . . . . . . . . . . . . . . . . . . . . . . . . 23
10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
13.1. Normative References . . . . . . . . . . . . . . . . . . 24 13.1. Normative References . . . . . . . . . . . . . . . . . . 24
13.2. Informative References . . . . . . . . . . . . . . . . . 25 13.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
skipping to change at page 3, line 29 skipping to change at page 3, line 29
to respond to queries, or responding incorrectly, causes both to respond to queries, or responding incorrectly, causes both
immediate operational problems and long term problems with protocol immediate operational problems and long term problems with protocol
development. development.
Failure to respond to a query is indistinguishable from packet loss Failure to respond to a query is indistinguishable from packet loss
without doing an analysis of query-response patterns. Additionally without doing an analysis of query-response patterns. Additionally
failure to respond results in unnecessary queries being made by DNS failure to respond results in unnecessary queries being made by DNS
clients, and introduces delays to the resolution process. clients, and introduces delays to the resolution process.
Due to the inability to distinguish between packet loss and Due to the inability to distinguish between packet loss and
nameservers dropping EDNS [RFC6891] queries, packet loss is sometimes nameservers or middle boxes dropping EDNS [RFC6891] queries, packet
misclassified as lack of EDNS support which can lead to DNSSEC loss is sometimes misclassified as lack of EDNS support which can
validation failures. lead to DNSSEC validation failures.
The existence of servers which fail to respond to queries results in The existence of servers which fail to respond to queries results in
developers being hesitant to deploy new standards. Such servers need developers being hesitant to deploy new standards. Such servers need
to be identified and remediated. to be identified and remediated.
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. There should be no need to drop queries because a query using them. There should be no need to drop queries because a
nameserver does not understand them. nameserver does not understand them.
Unless a nameserver is under attack, it should respond to all DNS Unless a nameserver is under attack, it should respond to all DNS
requests directed to it. When a nameserver is under attack it may requests directed to it. When a nameserver is under attack it may
wish to drop packets. A common attack is to use a nameserver as an wish to drop packets. A common attack is to use a nameserver as an
amplifier by sending spoofed packets. This is done because response amplifier by sending spoofed packets. This is done because response
packets are bigger than the queries and large amplification factors packets are bigger than the queries and large amplification factors
are available especially if EDNS is supported. Limiting the rate of are available especially if EDNS is supported. Limiting the rate of
responses is reasonable when this is occurring and the client should responses is reasonable when this is occurring and the client should
retry. This however only works if legitimate clients are not being retry. This however only works if legitimate clients are not being
forced to guess whether EDNS queries are accepted or not. While forced to guess whether EDNS queries are accepted or not. As long as
there is still a pool of servers that don't respond to EDNS requests, there are still a pool of servers that don't respond to EDNS
clients have no way to know if the lack of response is due to packet requests, clients have no way to know if the lack of response is due
loss, or EDNS packets not being supported, or rate limiting due to to packet loss, or EDNS packets not being supported, or rate limiting
the server being under attack. Misclassification of server behaviour due to the server being under attack. Misclassification of server
is unavoidable when rate limiting is used until the population of behaviour is unavoidable when rate limiting is used until the
servers which fail to respond to well-formed queries drops to near population of servers which fail to respond to well-formed queries
zero. drops to near zero.
Nameservers should respond to queries even if the queried name is not Nameservers should respond to queries even if the queried name is not
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], Section 4.4.2, Paragraph 3. Doing this they are not [RFC1034], Section 4.4.2, Paragraph 3. Doing this
regularly should reduce the instances of broken delegations. regularly should reduce the 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 an 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 by 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
specification [RFC6891], when implemented, need to be followed. specification [RFC6891], when implemented, need to be followed.
Some examples of known consequences include: Some examples of known consequences include:
o The AD flag bit in a response cannot be trusted to mean anything o The AD (Authenticated Data) bit in a response cannot be trusted to
as some servers incorrectly copy the flag bit from the request to mean anything as some servers incorrectly copy the flag bit from
the response [RFC1035], [RFC4035]. The use of the AD flag bit in the request to the response [RFC1035], [RFC4035]. The use of the
requests is defined in [RFC6840]. AD bit in requests is defined in [RFC6840].
o Widespread non-response to EDNS queries has lead to recursive o Widespread non-response to EDNS queries has led to recursive
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 specific EDNS option or the use of EDNS in general that is causing
limited amount of time required to resolve a query before the the non response. In the limited amount of time required to
client times out this is not possible. resolve a query before the client times out this is not possible.
o Incorrectly returning FORMERR to an 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
skipping to change at page 6, line 10 skipping to change at page 6, line 10
doesn't implement, it is expected to return the appropriate response doesn't implement, it is expected to return the appropriate response
as if it did recognise the type but does not have any data for that as if it did recognise the type but does not have any data for that
type: either NOERROR, or NXDOMAIN. The exception to this are queries type: either NOERROR, or NXDOMAIN. The exception to this are queries
for Meta-RR types which may return NOTIMP. for Meta-RR types which may return NOTIMP.
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 flag set to 1 and servers that fail to respond to queries
with the last reserved flag bit set. with the last reserved flag set.
Servers should respond to such queries. If the server does not know Servers should respond to such queries. If the server does not know
the meaning of a flag bit it must not copy it to the response the meaning of a flag it must not copy it to the response [RFC1035]
[RFC1035] Section 4.1.1. If the server does not understand the Section 4.1.1. If the server does not understand the meaning of a
meaning of a request it should reply with a FORMERR response with request it should reply with a FORMERR response with unknown flags
unknown flags set to zero. set to zero.
3.1.3.1. Recursive Queries 3.1.3.1. Recursive Queries
A non-recursive server is supposed to respond to recursive queries as A non-recursive server is supposed to respond to recursive queries as
if the RD bit is not set [RFC1034]. if the RD bit is not set [RFC1034].
3.1.4. Unknown DNS opcodes 3.1.4. Unknown DNS opcodes
The use of previously undefined opcodes is to be expected. Since the The use of previously undefined opcodes is to be expected. Since the
DNS was first defined two new opcodes have been added, UPDATE and DNS was first defined two new opcodes have been added, UPDATE and
skipping to change at page 11, line 36 skipping to change at page 11, line 36
These tests query for records at the apex of a zone that the server These tests query for records at the apex of a zone that the server
is nominally configured to serve. All tests should use the same is nominally configured to serve. All tests should use the same
zone. zone.
It is advisable to run all of the tests below 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. There are 16 queries directed to each nameserver (assuming respond. There are 16 queries directed to each nameserver (assuming
no packet loss) testing different aspects of Basic DNS and Extended no packet loss) testing different aspects of Basic DNS and Extended
DNS. DNS.
The tests below use dig from BIND 9.11.0. The tests below use dig from BIND 9.11.0 [ISC]. Replace $zone with
the name of the zone being used for testing. Replace $server with
the name or address of the server being tested.
When testing recursive servers set RD=1 and choose a zone name that When testing recursive servers set RD=1 and choose a zone name that
is know to exist and is not being served by the recursive server. is known to exist and is not being served by the recursive server.
The root zone (".") is often a good candidate as it is DNSSEC signed. The root zone (".") is often a good candidate as it is DNSSEC signed.
RD=1, rather than RD=0, should be present in the responses for all RD=1, rather than RD=0, should be present in the responses for all
test involving the opcode QUERY. Non-authoritative answers (AA=0) test involving the opcode QUERY. Non-authoritative answers (AA=0)
are expected when talking to a recursive server. AD=1 is only are expected when talking to a recursive server. AD=1 is only
expected if the server is validating responses and one or both AD=1 expected if the server is validating responses and one or both AD=1
or DO=1 is set in the request otherwise AD=0 is expected. or DO=1 is set in the request otherwise AD=0 is expected.
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
skipping to change at page 24, line 8 skipping to change at page 24, line 20
until the servers are fixed. This should only be done as a last until the servers are fixed. This should only be done as a last
resort and with due consideration, as removal of a delegation can resort and with due consideration, as removal of a delegation can
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 attack 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 of 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
skipping to change at page 25, line 26 skipping to change at page 25, line 39
Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895,
April 2013, <https://www.rfc-editor.org/info/rfc6895>. April 2013, <https://www.rfc-editor.org/info/rfc6895>.
[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
D. Wessels, "DNS Transport over TCP - Implementation D. Wessels, "DNS Transport over TCP - Implementation
Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
<https://www.rfc-editor.org/info/rfc7766>. <https://www.rfc-editor.org/info/rfc7766>.
13.2. Informative References 13.2. Informative References
[ISC] "Internet Systems Consortuim", <https://www.isc.org/>.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
RFC 2671, DOI 10.17487/RFC2671, August 1999, RFC 2671, DOI 10.17487/RFC2671, August 1999,
<https://www.rfc-editor.org/info/rfc2671>. <https://www.rfc-editor.org/info/rfc2671>.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, DOI 10.17487/RFC3597, September (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September
2003, <https://www.rfc-editor.org/info/rfc3597>. 2003, <https://www.rfc-editor.org/info/rfc3597>.
[RFC5001] Austein, R., "DNS Name Server Identifier (NSID) Option", [RFC5001] Austein, R., "DNS Name Server Identifier (NSID) Option",
RFC 5001, DOI 10.17487/RFC5001, August 2007, RFC 5001, DOI 10.17487/RFC5001, August 2007,
 End of changes. 20 change blocks. 
37 lines changed or deleted 41 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/