On Thu, Feb 14, 2019 at 2:53 PM Stephane Bortzmeyer <[email protected]> wrote:
> On Mon, Jan 07, 2019 at 12:30:10PM -0800, > [email protected] <[email protected]> wrote > a message of 44 lines which said: > > > Title : Extended DNS Errors > > Authors : Warren Kumari > > Evan Hunt > > Roy Arends > > Wes Hardaker > > David C Lawrence > > Filename : draft-ietf-dnsop-extended-error-04.txt > > Some remarks but before, note I think that it is very important that > we have a way to report more detailed error causes. One of the biggest > problems of DNSSEC is that there is no easy way for the resolver to > report to the application about a DNSSEC problem. So, the work on this > draft is essential. > > Thank you, I / we certainly think so. > Now, the problems: > > It seems to me that this draft is mostly for resolvers, most planned > extended codes are useless for authoritative servers (except may be > REFUSED/Lame?). > > I suggest to make that clear in the introduction: > > These extended error codes are specially useful for resolvers, to > return to stub resolvers or to downstream resolvers. Authoritative > servers MAY use them but most error codes would make no sense for > them. > Yup, at the moment the majority of these are resolver errors - I don't think we necessarily expected / thought that through when starting this. I'm guessing that the majority of these will be resolver errors on the future as well, but how about: "The majority of these extended error codes are primarily useful for resolvers, to return to stub resolvers or to downstream resolvers. Authoritative servers may also use this technique to annotate errors (for example, REFUSED), but as of publication there are not as many of these defined" or something? > > > Unless a protective transport mechanism (like TSIG [RFC2845] or TLS > > [RFC8094]) > > Why 8094, which does not have even one implementation, instead of > 7858? > I believe that that was an oversight / error. > > > 4.2.3. SERVFAIL Extended DNS Error Code 3 - Signature Expired > > > > The resolver attempted to perform DNSSEC validation, but the > > signature was expired. > > I suggest to replace "the signature was expired" by "a signature in > the validation chain was expired". > > Rationale: which signature? What if a DS at the parent is sign with an > expired signature? > > LGTM. > > 4.2.5. SERVFAIL Extended DNS Error Code 5 - DNSKEY missing > > > > A DS record existed at a parent, but no DNSKEY record could be found > > for the child. > > I suggest to replace "no DNSKEY record could be found for the child" > by "no DNSKEY record for this specific key could be found for the > child". > > LGTM. > Rationale : the current text seems to imply this code is only when > there is no DNSKEY at all. > > > 4.4.1. NXDOMAIN Extended DNS Error Code 1 - Blocked > > > > The resolver attempted to perfom a DNS query but the domain is > > blacklisted due to a security policy. The R flag should not be set. > > The last sentence is touchy. If a stub is configured with two > resolvers, and one is fast but known for lying in some cases that you > disagree with, you may ask a cookie from the other parent (no, resolver). > Yup. The R flag is entirely, 100% simply a hint - you are perfectly allowed to ignore it, and in this case, you may want to (keep reading!) So, why bother having the flag at all? Primarily it exists so that, if an implementation gets an extended error code which it doesn't understand (e.g 42), it can choose to take the hint, or not. If an implementation *does* understand the code, it can decide it knows better. Now, in this particular case, I think you are right - unless anyone objects, I'm a gonna flip that to "the R flag should be set". > > > 4.4.1. NXDOMAIN Extended DNS Error Code 1 - Blocked > > > > The resolver attempted to perfom a DNS query but the domain is > > blacklisted due to a security policy. > > I tend to think it would be a good idea to separate the case where the > policy was decided by the resolver and the case where the policy came > from outside, typically from the local law (see RFC 7725 for a similar > case with HTTP). > > Rationale: in the first case (local policy of the resolver), the user > may be interested in talking with the resolver admin if he or she > disagrees with the blocking. In the second case, this would be useless. > > Otherwise, I suggest to add an error code: > > NOERROR Extended DNS Error Code 3 - Forged answer > > For policy reasons (legal obligation, or malware filtering, for > instance), an answer was forged. The R flag should not be set. > > Rationale: there is "NXDOMAIN Extended DNS Error Code 1 - Blocked" but > policy-aware resolvers (lying resolvers, in plain english) do not > always forge NXDOMAIN, they can also forge A or AAAA answers. > > See also the issue just before, about the need to differentiate > resolver policy from "upper" policy, law, for instance. > Errr... I like the idea / concept, but I'd really like to avoid the word "Forged" -- while you and I (and probably almost everyone else on the list) would agree that this is forged, I think that the pejorative nature of the word would make it that people are forced to forge answers might not be allowed to tag it as such. Can anying think of a better word? I was hoping to find something in the HTTP 451 Error Code page - https://en.wikipedia.org/wiki/HTTP_451, but no luck. Fictional answer? Alternative fact? Supposititious answer? Thank you for your comments and text, W > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
