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.bux...@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
>> };
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
