return address for failed DNSSEC validation

[Gilles Massen]

Kevin Darcy wrote:
> The fundamental requirement is that the requestor needs to know that
> their query FAILED. When you send back a "helpful", answerful response
> for a failure, either under NXDOMAIN redirection or your proposal, then
> you essentially deceive the client and confuse any troubleshooting efforts.

DNS messages should never be rewritten on transit.

The NXDOMAIN rewriting is evil: NXDOMAIN is an *answer* from the
authoritative zone about it's content (or lack thereof). Rewriting that
is altering the message - that's a lie.

The SERVFAIL as response to a validation error is *generated* on the
validator - who might also generate something else. The validator is the
only one having accurate information about the failure (and could even
have distinctive behaviour depending on the failure (like shortly
expired signatures vs wrong keys)). Sure, the behaviour would no longer
be RFC compliant - but as a help to clients who aren't yet either. With
the hope of hatching the the DNSSEC-egg quicker by easying the adoption
and as a result getting quicker rid of the workaround.

Troubleshooting would indeed suffer. You could help the manual
troubleshooter by throwing in a TXT record with information. Non browser
applications will expose unaccurate behaviour. But considering the
general user group it could still be worth it (ideally you would offer
opt-out, inform the non-dummy users, etc...but that's operational best
practices).

> SERVFAIL may not be as specific as we'd like for this particular failure
> mode, but it takes many years to define and get a new RCODE implemented,
> and DNSSEC can't wait for that.

Definetely. What I'm hoping for is a tool to smoothen the way until end
systems validate. No further. The DNS protocol should not be touched for
that.

Gilles

-- 
Fondation RESTENA - DNS-LU
6, rue Coudenhove-Kalergi
L-1359 Luxembourg
tel: (+352) 424409
fax: (+352) 422473