Quoting Rick Moen (rick@linuxmafia.com):
Trying to figure out something in logfiles. Filtering down this report just to sf-lug.com, balug.org, and savingthedolph.in DNS stuff, as "retry limit exceeded" seems to be a recurring theme and I'd like to figure out why (and fix).
It may be utterly coincidental that all of those are sockets to port 5353 (rather than 53) on 96.86.170.229 . Or not. I remember that said configuration on both of our ends was a workaround for the fsckery imposed on my uplink by Comcast Business, quite a while ago. Thoughts?
Lots of searching on "refresh: retry limit for master exceeded" suggest that error is often caused by firewalling that blocks UDP packets.
I _think_ the +notcp flag on dig forces UDP, albeit that would be the default for simple queries anyway.
$ dig @96.86.170.229 balug.org +notcp | wc -l 18 $ dig @96.86.170.229 balug.org | wc -l 18 $
But, oh hey, lookie here, when we query 5353:
$ dig -p 5353 @96.86.170.229 balug.org ;; connection timed out; no servers could be reached $
Yeah, that would be a problem.
Right, commenting out all these in /etc/bind/named.conf.local :
96.86.170.229 port 5353; // workaround
Checking my work.
$ grep 5353 /etc/bind/named.conf.local //96.86.170.229 port 5353; // workaround //96.86.170.229 port 5353; // workaround //96.86.170.229 port 5353; // workaround //96.86.170.229 port 5353; // workaround //96.86.170.229 port 5353; // workaround //96.86.170.229 port 5353; // workaround //96.86.170.229 port 5353; // workaround //96.86.170.229 port 5353; // workaround //96.86.170.229 port 5353; // workaround //96.86.170.229 port 5353; // workaround $
Implementing:
linuxmafia:/etc/bind# rndc reconfig linuxmafia:/etc/bind