Validating a DNSSEC installation

[Chris Buxton]

On Jun 16, 2009, at 4:08 AM, Chris Thompson wrote:
> On Jun 15 2009, Chris Buxton wrote:
> On Jun 13, 2009, at 4:59 AM, Erik Lotspeich wrote:
>>> Is it normal that a validating resolver can't validate a domain it  
>>> is
>>> authoritative for?
>>
>> Absolutely. As Alan Clegg wrote not long ago on this list,
>
> You presumably refer to
>
> https://lists.isc.org/pipermail/bind-users/2009-January/074760.html
>
> which I *suppose* counts as "not long ago" ... :-)

That's not long ago to me... it was this year after all. :-)

>>                                                          this is  
>> why  a DNSSEC validating resolver should not be authoritative for  
>> any  signed zones.
>
> This seems too strong to me, There are lots of good reasons why one  
> may
> want a resolver to stealth slave local (possibly signed) zones, and  
> thus
> be "authoritative" for them. However, it is certainly the case that  
> because
> no other validation is performed on these zones, they should be  
> fetched
> by secure means, e.g. TSIG-signed transfers from trusted master  
> servers.

As a purist, I dislike stealth slaves. They're too error-prone. It's  
better to use a stub zone if necessary, in my opinion.

That said, if only DNSSEC-ignorant resolvers (including stub  
resolvers) are querying the server, then yes, there is a valid case to  
be made for a stealth slave. But even then, if the zone has any  
subzones, or might ever be given any subzones, then I believe there  
will be problems unless the resolving stealth slave is also given  
trust anchors for all such subzones. It's better and simpler, then, to  
use a single trust anchor and a stub zone (a resolver hint) for the  
domain apex rather than a slave zone.

Chris Buxton
Professional Services
Men & Mice