Well, from what I read (I can't remember where), if I use views to do
this with only a single instance running, the problem arises that even
though the 'external' (requests for authoritative answers) clients can
and will get responses from the caching side of the server if the result
they are after is already cached.
I didn't quite parse this, could you please elaborate?
I want the two services to be completely disparate, and more precise,
I'd like to have the recursive instance to have to query the
authoritative instance for a result from the same box.
The same result can be achieved by using the same master zone file in
your caching and authoritative views. Not quite what you wanted, but the
end result should be the same.
I'm beginning to feel that I'm on a different page here.
I understand 'views' as far as BIND is concerned as thus (I may be
misguided):
Internet
|
external clients looking for resolution
|
|
|
external view
(accept from acl x.x.x.x)
|
BIND DNS Server
|
internal view
(accept from acl x.x.x.x)
|
|
|
internal clients looking for resolution
|
A private LAN perhaps
My authoritative name server (service, eventually cluster) will
eventually house about 500 domains, which I want only recursive DNS
servers that come from the root .tld down to see (no caching).
The caching name server (service, and eventually cluster) will see tens
of thousands of our clients requests (we are an ISP) to use as their DNS
lookup, which will perform recursive lookups that we are not
authoritative for.
I'm sorry, I don't know how to put it into other words, other than I
want complete separation from dns authoritative and dns caching services
to be disparate.
The same thing I get when I run tinydns and dnscache on two separate
IP's via ucspi. Again, example configs are welcome.
Steve
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
