Gilles Massen wrote: > 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.
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. 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. AlanC
signature.asc
Description: OpenPGP digital signature
_______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
