On 2/8/2013 10:44 AM, Matt wrote:
Also, is there a way to specify a backup parent NS
and ONLY use it if primary fails?
Do you mean "NS" here? Or "forwarder"? I know of no way to manually
"preference" the forwarders in a list, although you might find that the
forwarder that responds fastest -- and thus gets automatically selected for
the vast majority of the queries, according to its round-trip-time
statistics -- is the one you would want to manually preference anyway...
Looking at this further:
forward only;
forwarders { 192.168.10.10; };
If I do not set 'forward only', it will try the forwarder first and if
it fails it will do the lookup itself. If this is right it suits my
purpose perfectly. If the forwarder is down it will fall back and do
the lookup itself. Is that right?
The key difference to understand, though, is that "forward first" (the
default mode if "forward only" isn't set) will fail over from
*recursive* resolution to *non-recursive* (aka iterative) resolution.
Iterative resolution assumes a couple of things:
- a properly-primed root zone (meaning, your hints information must be
sufficiently up-to-date for the priming process to be successful)
- connectivity to all of the authoritative nameservers encountered
during the course of resolving the name (which might be several
delegation levels deep). NAT usually isn't a problem for DNS resolution,
but trying to resolve Internet names iteratively from behind heavy
firewall restrictions doesn't generally work.
If those things are in place already, I'm wondering why you're
forwarding in the first place (?) To achieve some sort of performance
enhancement? You might try ditching the forwarding, and see if your
performance is as good as (or possibly better than) your requirements.
How "forward first" helps you with your IPv4-versus-IPv6 challenge, I'm
not sure. I think Mark's suggestion to use the "dual-stack-servers"
feature (which quite frankly I didn't know existed until Mark's
suggestion) is probably your best bet.
- Kevin
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/bind-users
