Please find in attachment a new patch related to gihub issue #345.
Basically, when the resolution status was VALID, we ignored the "timeout
resolve", which goes against the documentation...
And as stated in the github issue, there was some impacts: an entire
backend could go down when the nameserver is not very reliable...

From d278cff87aa9037f1d05216ea14e2bc8bab5cd2a Mon Sep 17 00:00:00 2001
From: Baptiste Assmann <bed...@gmail.com>
Date: Thu, 7 Nov 2019 11:02:18 +0100
Subject: [PATCH] BUG: dns: timeout resolve not applied for valid resolutions

Documentation states that the interval between 2 DNS resolution is
driven by "timeout resolve <time>" directive.
From a code point of view, this was applied unless the latest status of
the resolution was VALID. In such case, "hold valid" was enforce.
This is a bug, because "hold" timers are not here to drive how often we
want to trigger a DNS resolution, but more how long we want to keep an
information if the status of the resolution itself as changed.
This avoid flapping and prevent shutting down an entire backend when a
DNS server is not answering.

This issue was reported by hamshiva in github issue #345.

Backport status: 1.8
 src/dns.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/src/dns.c b/src/dns.c
index 15d40a1..78349a2 100644
--- a/src/dns.c
+++ b/src/dns.c
@@ -150,10 +150,7 @@ static inline uint16_t dns_rnd16(void)
 static inline int dns_resolution_timeout(struct dns_resolution *res)
-	switch (res->status) {
-		case RSLV_STATUS_VALID: return res->resolvers->hold.valid;
-		default:                return res->resolvers->timeout.resolve;
-	}
+	return res->resolvers->timeout.resolve;
 /* Updates a resolvers' task timeout for next wake up and queue it */

Reply via email to