return address for failed DNSSEC validation

[Gilles Massen]

Alan,

Alan Clegg wrote:
> 
> The problem is that to correctly protect non-DNSSEC aware applications,
> a return code had to be chosen that even the lowliest of clients would
> understand as "STOP!  YOU MUST NOT USE THIS INFORMATION" to which
> SERVFAIL is the only correct response.

Any other return code would have been unknown - I don't object to
SERVFAIL (a tad late for that :) ). The shortcoming that the only
message it conveys is the "STOP!" part...

> I also would like to see a result that somehow says "Hey, DNSSEC broke
> this response, you need to figure out what happened".  However, this is
> not really possible considering the constraint of supporting resolvers
> that (as the humans in your example) don't have any idea what DNSSEC is,
> nor how to deal with anything beyond very simple responses.

Within the DNS protocol no. Wrong mailing list anyway... The proposal
was rather aiming at giving the ability to provide some information to
humans (specifically users of browsers), as an operator's choice. The
most tangible objection made was that the internet is not only http -
and that is an issue as it replaces a DNS error by a connection error.

If that inconvenience is worth the bad user experience I don't know. I
tend to say yes, but only temporarily - until validating moves to the
clients. Definetely not for ever.

Best,
Gilles

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