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