draft-andrews-dns-no-response-issue-13.txt   draft-andrews-dns-no-response-issue-14.txt 
Network Working Group M. Andrews Network Working Group M. Andrews
Internet-Draft ISC Internet-Draft ISC
Intended status: Informational November 2, 2015 Intended status: Informational November 10, 2015
Expires: May 5, 2016 Expires: May 13, 2016
A Common Operational Problem in DNS Servers - Failure To Respond. A Common Operational Problem in DNS Servers - Failure To Respond.
draft-andrews-dns-no-response-issue-13 draft-andrews-dns-no-response-issue-14
Abstract Abstract
The DNS is a query / response protocol. Failure to respond to The DNS is a query / response protocol. Failure to respond to
queries causes both immediate operational problems and long term queries causes both immediate operational problems and long term
problems with protocol development. problems with protocol development.
This document identifies a number of common classes of queries that This document identifies a number of common classes of queries that
some servers fail to respond too. This document also suggests some servers fail to respond too. This document also suggests
procedures for TLD and other similar zone operators to apply to help procedures for TLD and other similar zone operators to apply to help
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 5, 2016. This Internet-Draft will expire on May 13, 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 27 skipping to change at page 2, line 27
2.6. Unknown / Unsupported Type Queries . . . . . . . . . . . 4 2.6. Unknown / Unsupported Type Queries . . . . . . . . . . . 4
2.7. Unknown DNS opcodes . . . . . . . . . . . . . . . . . . . 5 2.7. Unknown DNS opcodes . . . . . . . . . . . . . . . . . . . 5
2.8. TCP Queries . . . . . . . . . . . . . . . . . . . . . . . 5 2.8. TCP Queries . . . . . . . . . . . . . . . . . . . . . . . 5
3. Remediating . . . . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . 8 6. Whole Answer Caches . . . . . . . . . . . . . . . . . . . . . 8
7. Response Code Selection . . . . . . . . . . . . . . . . . . . 8 7. Response Code Selection . . . . . . . . . . . . . . . . . . . 8
8. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
11. Normative References . . . . . . . . . . . . . . . . . . . . 13 11. Normative References . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
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 causes both immediate operational problems and to respond to queries causes both immediate operational problems and
long term problems with protocol development. long term problems with protocol 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 5, line 49 skipping to change at page 5, line 49
offending nameserver code corrected, there is a very long tail offending nameserver code corrected, there is a very long tail
problem with DNS servers in that it can often take over a decade problem with DNS servers in that it can often take over a decade
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 heirachical 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. One can construct lists of
nameservers from other sources and that has been done to survey the nameservers from other sources and that has been done to survey the
state of the Internet, but that doesn't give you the contact details state of the Internet, but that doesn't give you the contact details
necessary to inform the operators. The SOA RNAME is often invalid necessary to inform the operators. The SOA RNAME is often invalid
and whois data is obscured and / or not available which makes and whois data is obscured and / or not available which makes it
infeasible for others to do this. infeasible for others to do this.
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
skipping to change at page 8, line 35 skipping to change at page 8, line 35
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 can return the wrong reponse 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 query into account. This has implications
when testing and with overall protocol compliance. when testing and with overall protocol compliance.
e.g. There are whole answer caches that ingore 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 proceeded by a EDNS version 0
query for the same name and type. query for the same name and type.
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.
skipping to change at page 9, line 34 skipping to change at page 9, line 34
If you do not support EDNS at all, FORMERR and NOTIMP are the If you 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
This first set of tests cover basic DNS server behaviour and all
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
expect: status: NOERROR expect: status: NOERROR
expect: SOA record expect: SOA record
Check that TCP queries work: Check that TCP queries work:
dig +noedns +noad +norec +tcp soa $zone @$server dig +noedns +noad +norec +tcp soa $zone @$server
skipping to change at page 10, line 34 skipping to change at page 10, line 34
Check that queries with the last unassigned DNS header flag to work: Check that queries with the last unassigned DNS header flag to work:
dig +noedns +noad +norec +zflag soa $zone @$server dig +noedns +noad +norec +zflag soa $zone @$server
expect: status: NOERROR expect: status: NOERROR
expect: SOA record to be present expect: SOA record to be present
expect: MBZ to not be in the response expect: MBZ to not be in the response
MBZ (Must Be Zero) presence indicates the flag bit has been copied. MBZ (Must Be Zero) presence indicates the flag bit has been copied.
Check that new opcodes are handled:
dig +noedns +noad +opcode=15 +norec soa $zone @$server
expect: status: NOTIMP
expect: SOA record to not be present
The next set of test cover various aspects of EDNS behaviour. If any
of these tests succeed, then all of them should succeed. There are
servers that support EDNS but fail to handle plain EDNS queries
correctly so a plain EDNS query is not a good indicator of lack of
EDNS support.
Check that plain EDNS queries work: Check that plain EDNS queries work:
dig +edns=0 +noad +norec soa $zone @$server dig +nocookie +edns=0 +noad +norec 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
+nocookie disables sending a EDNS COOKIE option in which is on by
default.
Check that EDNS version 1 queries work (EDNS supported): Check that EDNS version 1 queries work (EDNS supported):
dig +edns=1 +noednsneg +noad +norec soa $zone @$server dig +nocookie +edns=1 +noednsneg +noad +norec soa $zone @$server
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: EDNS Version 0 in response expect: EDNS Version 0 in response
(Only EDNS Verion 0 is currently defined so the response should
(Only EDNS Version 0 is currently defined so the response should
always be a 0 version. This will change when EDNS version 1 is always be a 0 version. This will change when EDNS version 1 is
defined.) defined.)
Check that EDNS queries with an unknown option work (EDNS supported): Check that EDNS queries with an unknown option work (EDNS supported):
dig +edns=0 +noad +norec +ednsopt=100 soa $zone @$server dig +nocookie +edns=0 +noad +norec +ednsopt=100 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: OPT=100 to not be present expect: OPT=100 to not be present
expect: EDNS Version 0 in response expect: EDNS Version 0 in response
Check that EDNS queries with unknown flags work (EDNS supported): Check that EDNS queries with unknown flags work (EDNS supported):
dig +edns=0 +noad +norec +ednsflags=0x40 soa $zone @$server dig +nocookie +edns=0 +noad +norec +ednsflags=0x40 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: MBZ not to be present expect: MBZ not to be present
expect: EDNS Version 0 in response expect: EDNS Version 0 in response
MBZ (Must Be Zero) presence indicates the flag bit has been copied. MBZ (Must Be Zero) presence indicates the flag bit has been copied.
Check that EDNS version 1 queries with unknown flags work (EDNS Check that EDNS version 1 queries with unknown flags work (EDNS
supported): supported):
dig +edns=1 +noednsneg +noad +norec +ednsflags=0x40 soa \ dig +nocookie +edns=1 +noednsneg +noad +norec +ednsflags=0x40 soa \
$zone @$server $zone @$server
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: MBZ not to be present expect: MBZ not to be present
expect: EDNS Version 0 in response expect: EDNS Version 0 in response
+noednsneg disables EDNS version negotiation in DiG; MBZ (Must Be +noednsneg disables EDNS version negotiation in DiG; MBZ (Must Be
Zero) presence indicates the flag bit has been copied. Zero) presence indicates the flag bit has been copied.
Check that EDNS version 1 queries with unknown options work (EDNS Check that EDNS version 1 queries with unknown options work (EDNS
supported): supported):
dig +edns=1 +noednsneg +noad +norec +ednsopt=100 soa $zone @$server dig +nocookie +edns=1 +noednsneg +noad +norec +ednsopt=100 soa \
$zone @$server
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: OPT=100 to NOT be present expect: OPT=100 to NOT be present
expect: EDNS Version 0 in response expect: EDNS Version 0 in response
+noednsneg disables EDNS version negotiation in DiG. +noednsneg disables EDNS version negotiation in DiG.
Check that a DNSSEC queries work (EDNS supported): Check that a DNSSEC queries work (EDNS supported):
dig +edns=0 +noad +norec +dnssec soa $zone @$server dig +nocookie +edns=0 +noad +norec +dnssec soa $zone @$server
expect: status: NOERROR expect: status: NOERROR
expect: SOA record to be present expect: SOA record to be present
expect: OPT record to be present expect: OPT record to be present
expect: DO=1 to be present if a RRSIG is in the response expect: DO=1 to be present if a RRSIG is in the response
expect: EDNS Version 0 in response expect: EDNS Version 0 in response
DO=1 should be present if RRSIGs are returned as they indicate that DO=1 should be present if RRSIGs are returned as they indicate that
the server supports DNSSEC. Servers that support DNSSEC are supposed the server supports DNSSEC. Servers that support DNSSEC are supposed
to copy the DO bit from the request to the response as per [RFC3225]. to copy the DO bit from the request to the response as per [RFC3225].
Check that EDNS version 1 DNSSEC queries work (EDNS supported): Check that EDNS version 1 DNSSEC queries work (EDNS supported):
dig +edns=1 +noednsneg +noad +norec +dnssec soa \ dig +nocookie +edns=1 +noednsneg +noad +norec +dnssec soa \
$zone @$server $zone @$server
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
+noednsneg disables EDNS version negotiation in DiG. +noednsneg disables EDNS version negotiation in DiG.
Check that new opcodes are handled: Check that EDNS queries with multiple defined EDNS options work.
dig +noedns +noad +opcode=15 +norec soa $zone @$server dig +edns=0 +noad +norec +cookie +nsid +expire +subnet=0.0.0.0/0 \
soa $zone @$server
expect: status: NOTIMP expect: status: NOERROR
expect: SOA record to not be present expect: SOA record to be present
expect: OPT record to be present
expect: EDNS Version 0 in response
If EDNS is not supported by the nameserver, we expect a response to If EDNS is not supported by the nameserver, we expect a response to
all the above queries. That response may be a FORMERR or NOTIMP all the above queries. That response may be a FORMERR or NOTIMP
error response or the OPT record may just be ignored. error response or the OPT record may just be ignored.
It is advisable to run all the above tests in parallel so as to It is advisable to run all the above tests 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 above tests use dig from BIND 9.11.0 which is still in The above tests use dig from BIND 9.11.0 which is still in
 End of changes. 23 change blocks. 
23 lines changed or deleted 47 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/