return address for failed DNSSEC validation

[Gilles Massen]

Mark, Mat,

Mat wrote:
> End users will get confused by this, but then there are plenty of
> other possibilities with and without DNS they may get confused about.
> I think providing help to them should be dealt with by the OS instead
> of bloating DNS. Upon return of any error by DNS (or any other
> subsystem) it can show them a useful, platform-dependent message how
> to fix it.

Mark Andrews wrote:
> 	Additionally you can detect a DNSSEC failure by asking
> 	queries with and without the CD bit set.
> 
> 	Most DNSSEC failures can be diagnosed with dig, knowing the
> 	current time and date and access to named.conf for the trust
> 	anchors.  There are actually easier to diagnose than most
> 	other DNS failure issues.


I agree with both of you, but you are missing the point. The problem
space is users that don't know about DNS, and that don't have a local
validating resolver. So there is no point of even considering dig.

As soon as applications (or local stub resolvers) are validating, that
would be the place to generate a "user compatible" error. But in the
best case this will take years. In the mean term we are stuck with dummy
users, and ISPs that might want to enable validation, but might also be
kept off by the cost that unexplainable (or rather unexplained) failures
will produce (Helpdesk). Being able to return 'something' in case of
validation failures (and only them, not any SERVFAIL!) looks as it were
in the interest of the adoption of DNSSEC.

Obviously there are parallels to NXDOMAIN rewriting. However, the major
difference I see is that NXDOMAIN is a clear message, known by the OSs
and applications, that has basically one meaning. SERVFAIL is more like
'didn't work. go figure.' And the good thing is that 'validation error
rewriting' could be abandoned again if DNSSEC arrives at the
OS/applications.

Gilles