DNSSEC, views & trusted keys...

[Chris Buxton]

On Sep 12, 2010, at 10:45 AM, Tony Finch wrote:

> I could not get private stub nor forward zones to work if their public parent is signed and does not have a delegation to the private zone.

Does it work if the parent does have a DS record for the child covered by the stub zone? I would expect it would not do so, since with a stub zone, the resolver ought to start resolution right there, thus never seeing the parent's DS record.

Instead, add a trusted key for the stub zone.

Conceptually, a stub zone is like a root hints zone. You need a trusted key for the root in order to trust its DNSKEY. The same should be true of stub zones.

Disclaimer: I have not actually tested this. It's never come up as a problem I've had to solve; stub zones have typically been for internal DNS environments, where DNSSEC rollout has not been a priority.

Chris Buxton
BlueCat Networks

> On 12 Sep 2010, at 03:41, Chris Buxton <chris.p.buxton at gmail.com> wrote:
> 
>> 
>> On Sep 11, 2010, at 2:34 AM, Phil Mayers wrote:
>>> 
>>> You'll need a:
>>> 
>>> zone "name" {
>>> type forward;
>>> forward only;
>>> forwarders {
>>>   ips;
>>> };
>>> };
>>> 
>>> It won't automatically detect that another view contains the zone and redirect it; you have to tell it.
>> 
>> Use a stub zone instead of a forward zone, so that the query will actually reach the authoritative view. With a forward zone, the query is recursive, so will be picked up by the recursive view - the view will query itself and not receive an answer.
>> 
>> zone "zone.name" {
>>    type stub;
>>    file "/path/to/recursive-view-data/zone.name";
>>    masters { 127.0.0.1; }; // or whatever the correct IP is to reach the internal view
>> };

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20100912/633b0c64/attachment.html>