summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGeorge Joseph <gjoseph@digium.com>2016-09-07 13:48:48 -0600
committerGeorge Joseph <gjoseph@digium.com>2016-09-15 08:23:16 -0500
commit4d64b176ebbd6ee6c51f028068a0d0d6ddaa4ac7 (patch)
treee07f5b17c4b0339b2ea8feecb09c6039707bcdb6
parent11d05fc3699aa3547be722b83529bfecbe15ee4f (diff)
pjproject_bundled: Prevent SERVFAIL from marking name server bad
A name server that returns "Server Failure" is indicating only that the server couldn't process that particular request. We should NOT assume that the name server is incapable of serving other requests. Here's the scenario we've been encountering... * 2 local name servers configured in resolv.conf. * An OPTIONS request causes a request for A and AAAA records to go out to both nameservers. * The A responses both come back successfully resolved. * Because of an issue at some upstream nameserver, the AAAA responses for that particular query come back as "SERVFAIL" from both local name servers. * Both local servers are marked as bad and no further queries can be sent until the 60 second ttl expires. Only previously cached results can be used. * In this case, 60 seconds is just enough time for another OPTIONS request to go out to the same host so the cycle repeats. We could set the bad ttl really low but that also affects REFUSED and NOTAUTH which probably DO signal a real server issue. Besides, even a really low bad ttl would be an issue on a pbx. Although we use our own resolver in 14 and master and don't have this issue there, Teluu has merged this patch upstream so it's appropriate to cherry-pick to 14 and master to keep pjproject consistent. Change-Id: Ie03ba902288e274aff23f9b9bb2786e1e8be09e0
-rw-r--r--third-party/pjproject/patches/0004-resolver.c-Prevent-SERVFAIL-from-marking-name-server.patch48
1 files changed, 48 insertions, 0 deletions
diff --git a/third-party/pjproject/patches/0004-resolver.c-Prevent-SERVFAIL-from-marking-name-server.patch b/third-party/pjproject/patches/0004-resolver.c-Prevent-SERVFAIL-from-marking-name-server.patch
new file mode 100644
index 000000000..55f3d2d15
--- /dev/null
+++ b/third-party/pjproject/patches/0004-resolver.c-Prevent-SERVFAIL-from-marking-name-server.patch
@@ -0,0 +1,48 @@
+From a5efddbe9151e9ad99279e59566c86f8bc27d3a9 Mon Sep 17 00:00:00 2001
+From: George Joseph <gjoseph@digium.com>
+Date: Wed, 7 Sep 2016 13:10:57 -0600
+Subject: [PATCH] resolver.c: Prevent SERVFAIL from marking name server bad
+
+A name server that returns "Server Failure" is indicating only that
+the server couldn't process that particular request. We should NOT
+assume that the name server is incapable of serving other requests.
+
+Here's the scenario we've been encountering...
+
+* 2 local name servers configured in resolv.conf.
+* An OPTIONS request causes a request for A and AAAA records to go out
+ to both nameservers.
+* The A responses both come back successfully resolved.
+* Because of an issue at some upstream nameserver, the AAAA responses
+ for that particular query come back as "SERVFAIL" from both local
+ name servers.
+* Both local servers are marked as bad and no further queries can be
+ sent until the 60 second ttl expires. Only previously cached results
+ can be used.
+* In this case, 60 seconds is just enough time for another OPTIONS
+ request to go out to the same host so the cycle repeats.
+
+We could set the bad ttl really low but that also affects REFUSED and
+NOTAUTH which probably DO signal a real server issue. Besides, even
+a really low bad ttl would be an issue on a pbx.
+---
+ pjlib-util/src/pjlib-util/resolver.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/pjlib-util/src/pjlib-util/resolver.c b/pjlib-util/src/pjlib-util/resolver.c
+index d277e4f..540f88f 100644
+--- a/pjlib-util/src/pjlib-util/resolver.c
++++ b/pjlib-util/src/pjlib-util/resolver.c
+@@ -1384,8 +1384,7 @@ static void report_nameserver_status(pj_dns_resolver *resolver,
+ q_id = (pj_uint32_t)-1;
+ }
+
+- if (!pkt || rcode == PJ_DNS_RCODE_SERVFAIL ||
+- rcode == PJ_DNS_RCODE_REFUSED ||
++ if (!pkt || rcode == PJ_DNS_RCODE_REFUSED ||
+ rcode == PJ_DNS_RCODE_NOTAUTH)
+ {
+ is_good = PJ_FALSE;
+--
+2.7.4
+