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

[Mark Andrews]

> Mark,
> 
> On May 26, 2008, at 3:18 PM, Mark Andrews wrote:
> >> If you only get SERVFAIL on
> >> invalid answers, users will complain that they cannot reach a site,
> >> because they can't know better from the error message they get. So
> >> keeping DNSSEC off is the only option for an ISP today to reduce
> >> support calls. That should definitely be changed if you want a
> >> widespread use of DNSSEC.
> > 	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 caching server operators turning off DNSSEC.

	And if they stuff up their delegation you get the same thing.

	I get very few DNSSEC validation failures.  Most of the
	ones I've seen are delegation stuff ups (DSs not matching
	DNSKEYs). 

	BIND 9.6 and I'm sure other nameservers will be automating
	the re-signing of zones.  Once that is done the problem
	space essentially reduces to one of managing the delegation.

	I don't really see much difference between "they failed to
	update their NS RRset" to "they failed to update their DS
	RRset".  Both errors can be worked around in the caching
	nameservers if needed by configuration changes.

	The one thing that can't easily be worked around is editing
	the zone and not re-signing it.

	And yes I understand "but the other server works".  Named
	is a dual stack nameserver as as such is exposed to delegation
	errors that single stack nameservers never see.

> > 	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  
> hunks of code (with all that entails).

	Sure they are non-trivial pieces of code but they only need
	to be written once then linked in.  The work has basically
	already been done.

	Mark
 
> Regards,
> -drc
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org