DNSSEC, views & trusted keys...
Chris Buxton
chris.p.buxton at gmail.com
Sun Sep 12 21:01:31 UTC 2010
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>
More information about the bind-users
mailing list