--- 1/draft-andrews-dns-no-response-issue-15.txt 2015-11-26 16:15:08.207832336 -0800 +++ 2/draft-andrews-dns-no-response-issue-16.txt 2015-11-26 16:15:08.239833121 -0800 @@ -1,87 +1,90 @@ Network Working Group M. Andrews Internet-Draft ISC -Intended status: Best Current Practice November 11, 2015 -Expires: May 14, 2016 +Intended status: Best Current Practice November 26, 2015 +Expires: May 29, 2016 A Common Operational Problem in DNS Servers - Failure To Respond. - draft-andrews-dns-no-response-issue-15 + draft-andrews-dns-no-response-issue-16 Abstract The DNS is a query / response protocol. Failure to respond or to respond correctly to queries causes both immediate operational problems and long term problems with protocol development. - This document identifies a number of common classes of queries that - some servers fail to respond too or respond incorrectly to. This - document also suggests procedures for TLD and other similar zone - operators to apply to help reduce / eliminate the problem. + This document identifies a number of common classes of queries to + which some servers either fail to respond or else respond + incorrectly. This document also suggests procedures for TLD and + other similar zone operators to apply to help reduce / eliminate the + problem. The document does not look at the DNS data itself, just the structure of the responses. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on May 14, 2016. + This Internet-Draft will expire on May 29, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Common queries class that result in non responses. . . . . . 3 - 2.1. EDNS Queries - Version Independent . . . . . . . . . . . 3 + 2.1. EDNS Queries - Version Independent . . . . . . . . . . . 4 2.2. EDNS Queries - Version Specific . . . . . . . . . . . . . 4 2.3. EDNS Options . . . . . . . . . . . . . . . . . . . . . . 4 2.4. EDNS Flags . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.5. DNS Flags . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.5. DNS Flags . . . . . . . . . . . . . . . . . . . . . . . . 5 2.6. Unknown / Unsupported Type Queries . . . . . . . . . . . 5 2.7. Unknown DNS opcodes . . . . . . . . . . . . . . . . . . . 5 2.8. TCP Queries . . . . . . . . . . . . . . . . . . . . . . . 5 - 3. Remediating . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3. Remediating . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Firewalls and Load Balancers . . . . . . . . . . . . . . . . 7 5. Scrubbing Services . . . . . . . . . . . . . . . . . . . . . 8 - 6. Whole Answer Caches . . . . . . . . . . . . . . . . . . . . . 8 + 6. Whole Answer Caches . . . . . . . . . . . . . . . . . . . . . 9 7. Response Code Selection . . . . . . . . . . . . . . . . . . . 9 - 8. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 - 11. Normative References . . . . . . . . . . . . . . . . . . . . 14 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 + 8. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 8.1. Testing - Basic DNS . . . . . . . . . . . . . . . . . . . 10 + 8.2. Testing - Extended DNS . . . . . . . . . . . . . . . . . 12 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 + 11. Normative References . . . . . . . . . . . . . . . . . . . . 15 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction The DNS [RFC1034], [RFC1035] is a query / response protocol. Failure to respond to queries or to respond incorrectly causes both immediate operational problems and long term problems with protocol development. Failure to respond to a query is indistinguishable from a packet loss without doing a analysis of query response patterns and results in @@ -407,81 +410,119 @@ If you do not support EDNS at all, FORMERR and NOTIMP are the expected error codes. That said a minimal EDNS server implementation just requires parsing the OPT records and responding with an empty OPT record. There is no need to interpret any EDNS options present in the request as unsupported options are expected to be ignored [RFC6891]. 8. Testing + Testing is broken into two sections. Basic DNS which all servers + should meet and Extended DNS which should be met by all servers that + support EDNS. + + It is advisable to run all the below tests in parallel so as to + minimise the delays due to multiple timeouts when the servers do not + respond. + + The below tests use dig from BIND 9.11.0 which is still in + development. + +8.1. Testing - Basic DNS + 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: dig +noedns +noad +norec soa $zone @$server expect: status: NOERROR expect: SOA record expect: flag: aa to be present Check that TCP queries work: dig +noedns +noad +norec +tcp soa $zone @$server expect: status: NOERROR expect: SOA record expect: flag: aa to be present + The requirement that TCP be supported is defined in [RFC5966]. + Check that queries for an unknown type to work: dig +noedns +noad +norec type1000 $zone @$server expect: status: NOERROR expect: an empty answer section. expect: flag: aa to be present + 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 + 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 + questions for unknown types with NOERROR or NXDOMAIN as per + Section 4.3.2, [RFC1034]. [RFC5395] later reserved distinct ranges + for meta and data types which allows servers to be definitive about + whether a query should be answerable from zone content or not. + Check that queries with CD=1 work: dig +noedns +noad +norec +cd soa $zone @$server expect: status: NOERROR expect: SOA record to be present expect: flag: aa to be present + CD use in queries is defined in [RFC4035]. + Check that queries with AD=1 work: dig +noedns +norec +ad soa $zone @$server expect: status: NOERROR expect: SOA record to be present expect: flag: aa to be present - Check that queries with the last unassigned DNS header flag to work: + AD use in queries is defined in [RFC6840]. + + Check that queries with the last unassigned DNS header flag to work + and that the flag bit is not copied to the response: dig +noedns +noad +norec +zflag soa $zone @$server expect: status: NOERROR expect: SOA record to be present expect: MBZ to not be in the response expect: flag: aa to be present - MBZ (Must Be Zero) presence indicates the flag bit has been copied. + MBZ (Must Be Zero) presence indicates the flag bit has been + incorrectly copied. See Section 4.1.1, [RFC1035] "Z Reserved for + future use. Must be zero in all queries and responses." Check that new opcodes are handled: - dig +noedns +noad +opcode=15 +norec soa $zone @$server + dig +noedns +noad +opcode=15 +norec +header-only @$server expect: status: NOTIMP expect: SOA record to not be present expect: flag: aa to NOT be present + As unknown opcodes have no definition, including packet format other + than there must be a DNS header present, there is only one possible + rcode that make sense to return to a request with a unknown opcode + and that is NOTIMP. + +8.2. Testing - Extended DNS + 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: dig +nocookie +edns=0 +noad +norec soa $zone @$server @@ -497,63 +538,68 @@ Check that EDNS version 1 queries work (EDNS supported): dig +nocookie +edns=1 +noednsneg +noad +norec soa $zone @$server expect: status: BADVERS expect: SOA record to not be present expect: OPT record to be present expect: EDNS Version 0 in response expect: flag: aa to NOT be present - (Only EDNS Version 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 - defined.) + defined. BADVERS is the expected rcode if EDNS is supported as per + Section 6.1.3, [RFC6891]. Check that EDNS queries with an unknown option work (EDNS supported): dig +nocookie +edns=0 +noad +norec +ednsopt=100 soa $zone @$server expect: status: NOERROR expect: SOA record to be present expect: OPT record to be present expect: OPT=100 to not be present expect: EDNS Version 0 in response expect: flag: aa to be present + Unknown EDNS options are supposed to be ignored, Section 6.1.2, + [RFC6891]. + Check that EDNS queries with unknown flags work (EDNS supported): dig +nocookie +edns=0 +noad +norec +ednsflags=0x40 soa $zone @$server expect: status: NOERROR expect: SOA record to be present expect: OPT record to be present expect: MBZ not to be present expect: EDNS Version 0 in response expect: flag: aa to be present - MBZ (Must Be Zero) presence indicates the flag bit has been copied. + MBZ (Must Be Zero) presence indicates the flag bit has been + incorrectly copied as per Section 6.1.4, [RFC6891]. Check that EDNS version 1 queries with unknown flags work (EDNS supported): dig +nocookie +edns=1 +noednsneg +noad +norec +ednsflags=0x40 soa \ $zone @$server expect: status: BADVERS expect: SOA record to NOT be present expect: OPT record to be present expect: MBZ not to be present expect: EDNS Version 0 in response expect: flag: aa to NOT be present +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 incorrectly copied. Check that EDNS version 1 queries with unknown options work (EDNS supported): dig +nocookie +edns=1 +noednsneg +noad +norec +ednsopt=100 soa \ $zone @$server expect: status: BADVERS expect: SOA record to NOT be present expect: OPT record to be present @@ -601,27 +647,20 @@ expect: status: NOERROR expect: SOA record to be present expect: OPT record to be present expect: EDNS Version 0 in response expect: flag: aa to be present 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 error response or the OPT record may just be ignored. - 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 - respond. - - The above tests use dig from BIND 9.11.0 which is still in - development. - 9. Security Considerations Testing protocol compliance can potentially result in false reports of attempts to break services from Intrusion Detection Services and firewalls. None of the tests listed above should break nominally EDNS compliant servers. None of the tests above should break non EDNS servers. All the tests above are well formed, though not necessarily common, DNS queries. Relaxing firewall settings to ensure EDNS compliance could @@ -639,31 +678,45 @@ 11. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . - [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC - 3225, DOI 10.17487/RFC3225, December 2001, + [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", + RFC 3225, DOI 10.17487/RFC3225, December 2001, . + [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, + . + + [RFC5395] Eastlake 3rd, D., "Domain Name System (DNS) IANA + Considerations", RFC 5395, DOI 10.17487/RFC5395, November + 2008, . + [RFC5966] Bellis, R., "DNS Transport over TCP - Implementation Requirements", RFC 5966, DOI 10.17487/RFC5966, August 2010, . + [RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and + Implementation Notes for DNS Security (DNSSEC)", RFC 6840, + DOI 10.17487/RFC6840, February 2013, + . + [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms - for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/ - RFC6891, April 2013, + for DNS (EDNS(0))", STD 75, RFC 6891, + DOI 10.17487/RFC6891, April 2013, . Author's Address M. Andrews Internet Systems Consortium 950 Charter Street Redwood City, CA 94063 US