[dns-operations] DNSSEC impact on applications was Re: security-aware stub resolver
Mark_Andrews at isc.org
Tue May 27 06:11:19 UTC 2008
> > What additional traffic? It's still a validating stub resolver.
> > It's still using the local caching nameserver. The only time it
> > would have to be a full iterative resolver is when the local caching
> > server doesn't know how to pass through the DNSSEC data.
> > Mark
> forgive my ignorance, if that's what it is, but a validating stub will never
> see the DS RRs for intermediate zone cuts between the RRset it's validating
> and the trust anchors it has, since it's not doing downward iteration and the
> DS RRs are normally learnt as side effects of downward delegation. how is a
> validating stub resolver going to know a chain of trust without querying for
> DS RRs, more or less like "the grandfather problem" except pretty much always
The same way a full iterative resolve does today. It queries
for DS records it doesn't have in its cache. As long as
the recursive server is DNSSEC aware it will find the DS
records or the appropriate NODATA responses.
DNSSEC was designed to work through intermediate servers
that are DNSSEC aware. Named does this today if you enable
both validation and forwarding.
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org
More information about the dns-operations