Can bind be configured to not drop RR's from the cache when the upstream DNS server is unresponsive

Dave Warren davew at
Sat Mar 19 05:02:16 UTC 2016

On 2016-03-18 01:46, Ron wrote:
> On Fri, Mar 18, 2016 at 12:12 AM, G.W. Haywood 
> <bind at <mailto:bind at>> wrote:
>     Hi there,
>     On Thu, 17 Mar 2016, Ron wrote:
>         ... in this case it's a supplier who is unable to keeps his
>         DNS servers
>         working, and we just want to keep the connectivity.
>     I'd just put something in /etc/hosts and send myself an email every
>     month or so to remind me I'd done that.
> This is what we're currently using, but it has the downside of not 
> picking up ip address changes.

If you want to reinvent caching, why not go a step further, periodically 
query the records and build a local /etc/hosts

I've done this in a couple places where I need certain records to work 
even if DNS is broken. For example, it's just not worth having a NFS or 
Gluster filesystem mount fail because DNS happens to be down. If DNS is 
down, I'm probably already mid-panic, I don't need to worry about 
whether or remote file systems will come back up if I need to reboot a 

My current logic is that I do a SOA query and check the serial number, 
if it has changed, I query every needed hostname into a temp file, and 
if every single query was successful, check the SOA again, and if it 
still matches, update the /etc/hosts. If anything goes wrong (including 
a mismatch between the SOA), dump the temp file and try again.

Slaving the zones would be better, but some machines have a resolver 
already, sometimes with unique configuration that I couldn't bulldoze 
(and I'm too lazy to manually review the configuration of every machine) 
and sometimes the local resolver was Unbound, and also the master DNS 
server doesn't have a list of every machine that needs a NOTIFY, or a 
way to keep that list up to date. It was just faster to code up a sloppy 
/etc/hosts script to update a handful of critical records. Lame reasons, 
but it works well enough and hasn't blown up in my face yet.

Dave Warren

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the bind-users mailing list