No authoritative and authoritative replies for the same zone.
kcd at daimlerchrysler.com
Mon Apr 24 23:20:48 UTC 2006
Olivier.Khazem at equant.com wrote:
>We use ISC Bind 9.2.3rc1 for Window NT/2000
>This is for use of a platform that have access to two type of networks:
> - Internet;
> - private world.
>We have a domain name example.com for which we want
>some hosts to be
>searched by ISC Bind as no authoritative replies
>some other hosts to be
>searched by ISC Bind as authoritative replies
>(in order to get the private network area)
>How to do that?
Well, you can't configure BIND to disclaim authority for
arbitrarily-defined records in an authoritative zone, and that would in
any case violate the spirit, if not the exact wording of the DNS RFCs.
I don't think *authoritativeness* _per_se_ is really what you care about
anyway. Very few things other than DNS servers/resolvers themselves care
about the setting of the AA flag.
What I think you really meant to ask was how to allow internal clients
to resolve names in a particular domain, where some of names in that
domain resolve to internal addresses and some of them resolve to
Internet-accessible addresses. The usual answer to that is to populate
the internal version of your zone with all of the entries from the
external version that would otherwise not be resolvable. The internal
and external versions of the zone would need to be maintained in
parallel. Of course, then that would not satisfy your _stated_
requirement that the "Internet replies" be given as non-authoritative,
since *all* of the names under example.com would then be given as
The only way to meet your requirements as stated seems offhand to me to
be to define all of the internal-only names beneath example.com as
separate zones in the internal DNS, e.g. host1.example.com could be
defined as a zone in named.conf, with only SOA/NS/A records at its apex.
That seems like an even bigger maintenance headache than maintaining the
external entries in parallel. example.com itself, if you're not already
forwarding to the Internet by default, would then need to be defined as
either "type forward" (pointing to recursors that can resolve names from
the external version of example.com by following the delegation chain
down from the root) or "type stub" (pointing directly to authoritative
nameservers for the external version of example.com).
More information about the bind-users