Steve Bertrand wrote:
I believe that the problem is this: even if configured to be an authoritative server, BIND will respond to a query about zones outside what it has authoritative data for with data from its cache if that data is present. As there is only one cache per instance of BIND, enabling any sort of recursive capability on a server that is otherwise meant to be entirely authoritative can lead to data leaking between the authoritative and recursive parts. This opens up the possibility of tricking a server into caching false data and responding with it as if it was authoritative.
I cannot believe this, I want to research this myself (and the impact to my designs.
Maybe it is the time to give unbound a try: [EMAIL PROTECTED]:/usr/ports/dns/unbound] # cat pkg-descr Unbound is designed as a set of modular components, so that also DNSSEC (secure DNS) validation and stub-resolvers (that do not run as a server, but are linked into an application) are easily possible. Goals: * A validating recursive DNS resolver. * Code diversity in the DNS resolver monoculture. * Drop-in replacement for BIND apart from config. * DNSSEC support. * Fully RFC compliant. * High performance o even with validation. * Used as o stub resolver. o full caching name server. o resolver library. * Elegant design of validator, resolver, cache modules. o provide the ability to pick and choose modules. * Robust. * In C, open source: The BSD license. * Smallest as possible component that does the job. * Stub-zones can be configured (local data or AS112 zones). Non-goals: * An authoritative name server. * Too many Features. WWW: http://unbound.net _______________________________________________ email@example.com mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"