On 2/7/2013 1:42 PM, Matt wrote:
I am using Bind for caching only. Currently my VM only has IPv4
access. Is there a way to selectively forward any requests that only
have IPv6 nameservers to another DNS server that is dual stacked?
Hmmm... Is anyone actually publishing IPv6-accessible nameservers for
their zone *exclusively*? Really? On the Internet? Can you give an example?
If that's the case, there's nothing I can think of within BIND to
support IPv6-to-IPv4-forwarding-failover, as you describe.
Be aware that you can talk IPv6 even if you don't have IPv6 present on
your local LAN or any of your next-hop gateways. Set up an IPv6-in-IPv4
tunnel to a co-operating dual-stack node, and set your static route(s)
accordingly (or run a dynamic-routing-protocol daemon on the tunnel, if
you're really adventurous :-). Of course, this will affect *everything*
running on your VM, not just DNS.
If, after accomplishing that, you still want to preference (native) IPv4
access over (tunneled) IPv6 access, hopefully your underlying OS
respects RFC 6724 source/destination address selection -- in that case,
you should be able to tweak the "policy table" to accomplish the desired
preferencing. If it doesn't support RFC 6724, then that's a much more
difficult challenge...
If not is there a way to forward all requests that are not cached to a
parent nameserver?
Not sure what you're trying to accomplish with that. If you have
forwarding set up, and the answer to a query isn't cached, you're going
to forward. If it is cached, you'll answer from cache. So, how does what
you ask above differ from regular BIND forwarding?
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...
- Kevin
_______________________________________________
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
