[dns-operations] DNSSEC impact on applications was Re: security-aware stub resolver
Mark_Andrews at isc.org
Tue May 27 05:43:24 UTC 2008
> > > You do not get answers that failed to validate.
> > This is, I believe, the problem. Instead of getting an indication that
> > validation failed, you get the same response you'd get if someone unplugged
> > your router. This will result in support calls which will result in cachin
> > server operators turning off DNSSEC.
> not that this is the right mailing list for this part of the discussion
> (see namedroppers at ops.ietf.org), but, i agree.
> > > If you want to process answers that failed to validate set CD=1 and
> > > DO=1 and provide the application with its own trust anchors. The
> > > application is then fully DNSSEC aware.
> > You forgot the part about the application having an actual validator
> > embedded in it. As you are no doubt aware, validators are non-trivial hunk
> > of code (with all that entails).
> i am especially concerned about the amount of duplicated backbone and
> authority server traffic if every app on every host has its own full
> resolver which is a building block of such a validator. right now we
> tend to cache at least at the host level and often at the LAN level.
> if we go to an "every app for itself" model, i fear the provisioning.
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 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