On Sep 6, 2011, at 7:32 AM, Lyle Giese wrote:
> On 9/6/2011 9:13 AM, Tony Finch wrote:
>> Lyle Giese<l...@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
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to