Forwarding is a different beast from "stub" (recursive rather than iterative resolution).
I'd look at "static-stub", if your NS list is overgrown with useless/unreachable stuff. It's configured basically the same way as forwarding, but without making the paradigm shift (and possible unforeseen consequences) from iterative to recursive resolution. http://jpmens.net/2011/01/25/binds-new-static-stub-zone-type/ https://lists.isc.org/pipermail/bind-users/2012-September/088719.html If you only have a *few*, relatively-static set of unreachables, you might consider listing just those ones as "bogus". - Kevin -----Original Message----- From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Ray Van Dolson Sent: Saturday, August 13, 2016 8:29 AM To: bind-users@lists.isc.org Subject: Stub Zone Behavior? Have a resolver at a branch office with a view containing a stub zone as follows: zone "domain.com." IN { type stub; masters { 10.216.11.6; 10.58.4.1; 10.50.4.32; }; file "stub/domain.com"; forwarders {}; }; Other notes: - "domain.com" is an Active Directory zone. - Running bind-9.8.2-0.47.rc1.el6.x86_64 (RHEL6) This setup seemed to work fine for many months, but within the last two or so has randomly started returning no answers for only certain queries (well the SOA stuff is returned) until I rndc flush on the system after which response returns to normal for a period of time. After trying a few things without success, I changed the zone type to forward instead of stub (with the servers used as masters in the stub config as the forwarders) and this has seemed to solved the problem. As I understand it, stub zones work by pulling down SOA, NS and "glue" for the NS from one of the masters into a local zone file and then queries to the domain are answered by querying one of the authoritative servers defined in the stub zone. My working theory is that BIND will randomly choose one of the NS servers to get an answer from, and since our NS list is very long with the servers scattered across the globe, perhaps BIND chooses one which doesn't respond quickly enough or at all (or maybe badly?) and then caches that negative or absent response. Probably in this case the forward type works just as well for our local clients at the office (I believe answers for "forward" zones can also be cached locally...), so am inclined to stand pat with this config but would still love to understand what might have caused the original stub setup to fail. Ray _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
