Validating a DNSSEC installation
Chris Buxton
cbuxton at menandmice.com
Wed Jun 17 06:05:59 UTC 2009
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
More information about the bind-users
mailing list