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/