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/