Bug in Bind 9.8 or am I doing something wrong?

[Chris Buxton]

On Sep 6, 2011, at 7:32 AM, Lyle Giese wrote:
> On 9/6/2011 9:13 AM, Tony Finch wrote:
>> Lyle Giese<lyle at lcrcomputer.net>  wrote:
>> 
>>> zone "chaseprod.local"{
>>> 	type forward;
>>> 	forwarders {10.0.100.205;};};
>>> 
>>> This seemed to work until I added some stuff for DNSSEC to my named.conf.
>> 
>> In order to forward a zone in the presence of DNSSEC validation, the zone
>> has to have a valid delegation in the public DNS. You can't use forwarding
>> to splice some private namespace onto the public DNS.
>> 
>> There is a new "static-stub" zone type which should avoid this problem,
>> though it has a number of other differences from a forwarding
>> configuration.
>> 
>> Tony.
> 
> Changing zone to:
> 
> zone "chaseprod.local"{
> 	type static-stub;
> 	server-addresses {10.0.100.205;};};
> 
> And adding back in the DNSSEC stuff, it's still broke, but the output from dig changes.
> 
> 
> ; <<>> DiG 9.8.0-P4 <<>> @127.0.0.1 chasew8s1.corp.chaseprod.local
> ; (1 server found)
> ;; global options: +cmd
> ;; connection timed out; no servers could be reached
> 
> 
> Very informative.  But if I disable DNSSEC, resolution using a static-stub zone does work.

If named is logging, is there anything interesting in the log from this test?

A response from ISC would be useful here. It's pretty normal to mix DNSSEC validation for public namespace with add-on private namespace. Is it true that enterprise networks using BIND 9.8 need to have a two-step resolution process, as shown below? When did this start? (I haven't tested because nearly every customer already uses this kind of strategy.)

client -> internal resolver -> internal auth (unsigned)
                            -> forwarders in the DMZ with DNSSEC validation enabled

Is the situation different when the resolving/caching/validating name server is also authoritative for (some of) the internal namespace?

Regards,
Chris Buxton
BlueCat Networks