[dns-operations] DNSSEC impact on applications was Re: security-aware stub resolver

[Mark Andrews]

> > > 	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
> g
> > 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
> s
> > 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
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org