--- /dev/null
+From 68f6312d4bae30b78daafcd6f51dc441b8685b1e Mon Sep 17 00:00:00 2001
+From: Baptiste Jonglez <git@bitsofnetworks.org>
+Date: Mon, 6 Feb 2017 21:09:11 +0000
+Subject: [PATCH] Stop treating SERVFAIL as a successful response from upstream
+ servers.
+
+This effectively reverts most of 51967f9807 ("SERVFAIL is an expected
+error return, don't try all servers.") and 4ace25c5d6 ("Treat REFUSED (not
+SERVFAIL) as an unsuccessful upstream response").
+
+With the current behaviour, as soon as dnsmasq receives a SERVFAIL from an
+upstream server, it stops trying to resolve the query and simply returns
+SERVFAIL to the client. With this commit, dnsmasq will instead try to
+query other upstream servers upon receiving a SERVFAIL response.
+
+According to RFC 1034 and 1035, the semantic of SERVFAIL is that of a
+temporary error condition. Recursive resolvers are expected to encounter
+network or resources issues from time to time, and will respond with
+SERVFAIL in this case. Similarly, if a validating DNSSEC resolver [RFC
+4033] encounters issues when checking signatures (unknown signing
+algorithm, missing signatures, expired signatures because of a wrong
+system clock, etc), it will respond with SERVFAIL.
+
+Note that all those behaviours are entirely different from a negative
+response, which would provide a definite indication that the requested
+name does not exist. In our case, if an upstream server responds with
+SERVFAIL, another upstream server may well provide a positive answer for
+the same query.
+
+Thus, this commit will increase robustness whenever some upstream servers
+encounter temporary issues or are misconfigured.
+
+Quoting RFC 1034, Section 4.3.1. "Queries and responses":
+
+ If recursive service is requested and available, the recursive response
+ to a query will be one of the following:
+
+ - The answer to the query, possibly preface by one or more CNAME
+ RRs that specify aliases encountered on the way to an answer.
+
+ - A name error indicating that the name does not exist. This
+ may include CNAME RRs that indicate that the original query
+ name was an alias for a name which does not exist.
+
+ - A temporary error indication.
+
+Here is Section 5.2.3. of RFC 1034, "Temporary failures":
+
+ In a less than perfect world, all resolvers will occasionally be unable
+ to resolve a particular request. This condition can be caused by a
+ resolver which becomes separated from the rest of the network due to a
+ link failure or gateway problem, or less often by coincident failure or
+ unavailability of all servers for a particular domain.
+
+And finally, RFC 1035 specifies RRCODE 2 for this usage, which is now more
+widely known as SERVFAIL (RFC 1035, Section 4.1.1. "Header section format"):
+
+ RCODE Response code - this 4 bit field is set as part of
+ responses. The values have the following
+ interpretation:
+ (...)
+
+ 2 Server failure - The name server was
+ unable to process this query due to a
+ problem with the name server.
+
+For the DNSSEC-related usage of SERVFAIL, here is RFC 4033
+Section 5. "Scope of the DNSSEC Document Set and Last Hop Issues":
+
+ A validating resolver can determine the following 4 states:
+ (...)
+
+ Insecure: The validating resolver has a trust anchor, a chain of
+ trust, and, at some delegation point, signed proof of the
+ non-existence of a DS record. This indicates that subsequent
+ branches in the tree are provably insecure. A validating resolver
+ may have a local policy to mark parts of the domain space as
+ insecure.
+
+ Bogus: The validating resolver has a trust anchor and a secure
+ delegation indicating that subsidiary data is signed, but the
+ response fails to validate for some reason: missing signatures,
+ expired signatures, signatures with unsupported algorithms, data
+ missing that the relevant NSEC RR says should be present, and so
+ forth.
+ (...)
+
+ This specification only defines how security-aware name servers can
+ signal non-validating stub resolvers that data was found to be bogus
+ (using RCODE=2, "Server Failure"; see [RFC4035]).
+
+Notice the difference between a definite negative answer ("Insecure"
+state), and an indefinite error condition ("Bogus" state). The second
+type of error may be specific to a recursive resolver, for instance
+because its system clock has been incorrectly set, or because it does not
+implement newer cryptographic primitives. Another recursive resolver may
+succeed for the same query.
+
+There are other similar situations in which the specified behaviour is
+similar to the one implemented by this commit.
+
+For instance, RFC 2136 specifies the behaviour of a "requestor" that wants
+to update a zone using the DNS UPDATE mechanism. The requestor tries to
+contact all authoritative name servers for the zone, with the following
+behaviour specified in RFC 2136, Section 4:
+
+ 4.6. If a response is received whose RCODE is SERVFAIL or NOTIMP, or
+ if no response is received within an implementation dependent timeout
+ period, or if an ICMP error is received indicating that the server's
+ port is unreachable, then the requestor will delete the unusable
+ server from its internal name server list and try the next one,
+ repeating until the name server list is empty. If the requestor runs
+ out of servers to try, an appropriate error will be returned to the
+ requestor's caller.
+---
+ src/forward.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/src/forward.c
++++ b/src/forward.c
+@@ -853,7 +853,8 @@ void reply_query(int fd, int family, tim
+ we get a good reply from another server. Kill it when we've
+ had replies from all to avoid filling the forwarding table when
+ everything is broken */
+- if (forward->forwardall == 0 || --forward->forwardall == 1 || RCODE(header) != REFUSED)
++ if (forward->forwardall == 0 || --forward->forwardall == 1 ||
++ (RCODE(header) != REFUSED && RCODE(header) != SERVFAIL))
+ {
+ int check_rebind = 0, no_cache_dnssec = 0, cache_secure = 0, bogusanswer = 0;
+
projects / openwrt / openwrt.git / commitdiff