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
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to