On Mar 4, 2013, at 10:43 AM, Verne Britton wrote:
>
> I have been testing and testing and either just don't see what I'm doing
> wrong, or have a learning block :-)
>
> current thinking is that a open recursion DNS server is bad, so we want to
> implement an allow-recursion clause; perhaps even make some views so our
> local users still recurse while the general public cannot ...
>
> but I am running into a roadblock with our Google Apps cname:
>
> gmail.wvstateu.edu is a cname to ghs.google.com
>
> and bind wants recursion turned on in order to translate it.
Your client machines need recursive service. So give them a recursive server
that can find both your internal data and Internet data. If you must do this on
the same machine as hosts your authoritative data, you have a couple of choices:
1. Don't use views:
options {
allow-recursion { your-nets-go-here; };
[...]
};
zone "your.zone" {
[...]
};
2. Or, use views:
options {
[...]
};
view "recursion" {
match-recursive-only yes;
allow-recursion { your-nets-go-here; };
[ ...other recursion settings... ]
};
view "authority" {
recursion no;
zone "your.zone" {
[...]
};
};
While it may seem more complex to use views, there are advantages in terms of
flexibility. However, ultimately either way will probably work, at least until
you start rolling out DNSSEC (at which point you will probably need to use
either views or separate servers).
Chris Buxton
BlueCat Networks
_______________________________________________
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
