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

[Matt Larson]

On Fri, 23 May 2008, Ed Lewis wrote:
> A SERVFAIL return from bad DNSSEC is the same to the browser as 
> SERVFAIL from a lame delegation, lack of authoritative servers,

And that's a crying shame: we should never have (further) overloaded
SERVFAIL to encompass DNSSEC validation failures.  With EDNS, we've
got lots of returned codes and we should use one to indicate
validation failure.  This would give application developers the option
of a DNSSEC-specific error message.  Yes, I'm aware that early DNSSEC
development preceded EDNS and therefore RCODEs were scare, so that
perhaps contributed to the current state of affairs, but they are
scare no more.  And I'm also aware that others have proposed extensive
signalling of validation status between validator and stub, but I
think that's overkill: if an application really needs to differentiate
among validation failure models (signature validity period
vs. unsupported algorithm vs. whatever), it should do its own
validation.  For the vast majority of applications, I'd venture that
one more bit of data--"Is the resolution failure because of a DNSSEC
validation failure?"--would suffice.

If I sound bitter, it's because I am: I tried to get this feature
added three years ago when we were six months away from deployment.

Matt