At Tue, 25 Jul 2017 12:04:04 -0400, tjw ietf <tjw.i...@gmail.com> wrote:
> This starts a Call for Adoption for draft-wkumari-dnsop-extended-error > > The draft is available here: > https://tools.ietf.org/html/draft-wkumari-dnsop-extended-error-02 > > Please review this draft to see if you think it is suitable for adoption by > DNSOP, and comments to the list, clearly stating your view. I support the adoption of the draft, if only to provide a way of signalling more helpful DNSSEC-related errors than a plain SERVFAIL. I may or may not support the specific proposal for that goal in the end, though (I simply don't know at this moment). I've reviewed draft-wkumari-dnsop-extended-error-02 and am willing to review followup versions. My comments on 02: - I wonder what if a forwarding recursive server receives a response containing an extended error (especially from an upstream validating resolver sending an error regarding DNSSEC validation). Is it expected to forward it back to the downstream client? - Can more than one extended error code be included in a single message? - One possible idea of another extended error code: one that indicates a type-ANY query is responded with just one type of RRset when there can be more. Technically it may not be considered to be an "error", but at least it indicates some special condition, so I think it's worth discussing. (This may also be related to question 1 of Section 6). - Section 1 Editorial - Section 1 When a stub resolver queries a DNSSEC bogus name (using a validating resolver), the stub resolver receives only a SERVFAIL in response. [...] If this is a major motivation of this proposal, it may not be very effective depending on how modern the stub resolver is. I suspect many existing stub resolver implementations still don't even include EDNS(0) in their queries (at least by default). It doesn't necessarily mean this proposal is completely useless, but we may have to note it won't be as effective until and unless the majority of stub resolvers become more modern. - Section 2 o FLAGS, 2 octets. We might just define the R bit and keep the remaining 15 bits "reserved", unless we know we'll definitely use these as "flags". Editorial nits: - Section 1 - e.g the answer was marked REFUSED because of a lame delegation, or because there is a lame delegation or because the nameserver is still "or because there is a lame delegation" is redundant and should be removed? - Section 7 and do don't get any of the protections which DNSSEC should provide. s/do don't/don't/ -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
