package/network/services/dnsmasq/patches/000-fix-servfail-handling.patch

   1 From 68f6312d4bae30b78daafcd6f51dc441b8685b1e Mon Sep 17 00:00:00 2001
   2 From: Baptiste Jonglez <git@bitsofnetworks.org>
   3 Date: Mon, 6 Feb 2017 21:09:11 +0000
   4 Subject: [PATCH] Stop treating SERVFAIL as a successful response from upstream
   5  servers.
   6
   7 This effectively reverts most of 51967f9807 ("SERVFAIL is an expected
   8 error return, don't try all servers.") and 4ace25c5d6 ("Treat REFUSED (not
   9 SERVFAIL) as an unsuccessful upstream response").
  10
  11 With the current behaviour, as soon as dnsmasq receives a SERVFAIL from an
  12 upstream server, it stops trying to resolve the query and simply returns
  13 SERVFAIL to the client.  With this commit, dnsmasq will instead try to
  14 query other upstream servers upon receiving a SERVFAIL response.
  15
  16 According to RFC 1034 and 1035, the semantic of SERVFAIL is that of a
  17 temporary error condition.  Recursive resolvers are expected to encounter
  18 network or resources issues from time to time, and will respond with
  19 SERVFAIL in this case.  Similarly, if a validating DNSSEC resolver [RFC
  20 4033] encounters issues when checking signatures (unknown signing
  21 algorithm, missing signatures, expired signatures because of a wrong
  22 system clock, etc), it will respond with SERVFAIL.
  23
  24 Note that all those behaviours are entirely different from a negative
  25 response, which would provide a definite indication that the requested
  26 name does not exist.  In our case, if an upstream server responds with
  27 SERVFAIL, another upstream server may well provide a positive answer for
  28 the same query.
  29
  30 Thus, this commit will increase robustness whenever some upstream servers
  31 encounter temporary issues or are misconfigured.
  32
  33 Quoting RFC 1034, Section 4.3.1. "Queries and responses":
  34
  35     If recursive service is requested and available, the recursive response
  36     to a query will be one of the following:
  37
  38        - The answer to the query, possibly preface by one or more CNAME
  39          RRs that specify aliases encountered on the way to an answer.
  40
  41        - A name error indicating that the name does not exist.  This
  42          may include CNAME RRs that indicate that the original query
  43           name was an alias for a name which does not exist.
  44
  45        - A temporary error indication.
  46
  47 Here is Section 5.2.3. of RFC 1034, "Temporary failures":
  48
  49     In a less than perfect world, all resolvers will occasionally be unable
  50     to resolve a particular request.  This condition can be caused by a
  51     resolver which becomes separated from the rest of the network due to a
  52     link failure or gateway problem, or less often by coincident failure or
  53     unavailability of all servers for a particular domain.
  54
  55 And finally, RFC 1035 specifies RRCODE 2 for this usage, which is now more
  56 widely known as SERVFAIL (RFC 1035, Section 4.1.1. "Header section format"):
  57
  58     RCODE           Response code - this 4 bit field is set as part of
  59                     responses.  The values have the following
  60                     interpretation:
  61                     (...)
  62
  63                     2               Server failure - The name server was
  64                                     unable to process this query due to a
  65                                     problem with the name server.
  66
  67 For the DNSSEC-related usage of SERVFAIL, here is RFC 4033
  68 Section 5. "Scope of the DNSSEC Document Set and Last Hop Issues":
  69
  70     A validating resolver can determine the following 4 states:
  71     (...)
  72
  73     Insecure: The validating resolver has a trust anchor, a chain of
  74        trust, and, at some delegation point, signed proof of the
  75        non-existence of a DS record.  This indicates that subsequent
  76        branches in the tree are provably insecure.  A validating resolver
  77        may have a local policy to mark parts of the domain space as
  78        insecure.
  79
  80     Bogus: The validating resolver has a trust anchor and a secure
  81        delegation indicating that subsidiary data is signed, but the
  82        response fails to validate for some reason: missing signatures,
  83        expired signatures, signatures with unsupported algorithms, data
  84        missing that the relevant NSEC RR says should be present, and so
  85        forth.
  86     (...)
  87
  88     This specification only defines how security-aware name servers can
  89     signal non-validating stub resolvers that data was found to be bogus
  90     (using RCODE=2, "Server Failure"; see [RFC4035]).
  91
  92 Notice the difference between a definite negative answer ("Insecure"
  93 state), and an indefinite error condition ("Bogus" state).  The second
  94 type of error may be specific to a recursive resolver, for instance
  95 because its system clock has been incorrectly set, or because it does not
  96 implement newer cryptographic primitives.  Another recursive resolver may
  97 succeed for the same query.
  98
  99 There are other similar situations in which the specified behaviour is
 100 similar to the one implemented by this commit.
 101
 102 For instance, RFC 2136 specifies the behaviour of a "requestor" that wants
 103 to update a zone using the DNS UPDATE mechanism.  The requestor tries to
 104 contact all authoritative name servers for the zone, with the following
 105 behaviour specified in RFC 2136, Section 4:
 106
 107     4.6. If a response is received whose RCODE is SERVFAIL or NOTIMP, or
 108     if no response is received within an implementation dependent timeout
 109     period, or if an ICMP error is received indicating that the server's
 110     port is unreachable, then the requestor will delete the unusable
 111     server from its internal name server list and try the next one,
 112     repeating until the name server list is empty.  If the requestor runs
 113     out of servers to try, an appropriate error will be returned to the
 114     requestor's caller.
 115 ---
 116  src/forward.c | 3 ++-
 117  1 file changed, 2 insertions(+), 1 deletion(-)
 118
 119 --- a/src/forward.c
 120 +++ b/src/forward.c
 121 @@ -853,7 +853,8 @@ void reply_query(int fd, int family, tim
 122       we get a good reply from another server. Kill it when we've
 123       had replies from all to avoid filling the forwarding table when
 124       everything is broken */
 125 -  if (forward->forwardall == 0 || --forward->forwardall == 1 || RCODE(header) != REFUSED)
 126 +  if (forward->forwardall == 0 || --forward->forwardall == 1 ||
 127 +      (RCODE(header) != REFUSED && RCODE(header) != SERVFAIL))
 128      {
 129        int check_rebind = 0, no_cache_dnssec = 0, cache_secure = 0, bogusanswer = 0;
 130