[dns-operations] DNSSEC impact on applications was Re: security-aware stub resolver
Mark_Andrews at isc.org
Tue May 27 01:23:27 UTC 2008
> 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
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 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