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 _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
