On Sat, Jul 29, 2017 at 08:53:48AM -0400, Paul Wouters wrote:
> > This starts a Call for Adoption for draft-wkumari-dnsop-extended-error
>
> I have reviewed the draft, and while I think it could be useful, I'm
> seriously worried about sending unauthenticated errors back to the user,
> and fear that software will start using these without first validating
> the response using DNSSEC.
>
> I would like to see more discussion on this topic before adopting this
> document with a focus on how we could secure these error codes.
My DANE-related code always treats SERVFAIL as insecure, a more
detailed SERVFAIL would still be insecure. I don't see any new
exposure here. Providing additional diagnostic information can
help with deployment. Eliding useful information because some fool
might misuse it is IMHO the wrong trade-off.
Where necessary, the final document can emphasize that the information
provided, is typically useful, but is not trustworthy. The intended
purpose is presumably to facilitate problem resolution by enabling
clients to report more detailed diagnostics to the server operator.
Logging something more useful than SERVFAIL (e.g. signature
expiration, lame delegation, ...) would be quite useful.
Sometimes, by the time a problem is noticed in the logs it is no
longer observable in real-time. Having a better record of what
happened at the time of the problem is valuable.
--
Viktor.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
