The following comments are only loosely related to multiple threads here, so let me post them in a single bunch.
On 9/11/19 8:05 AM, Viktor Dukhovni wrote: > Section 3.2 (code 2), may warrant more guidance on when this is > appropriate. AFAIK, there is nothing wrong with all DNSKEY algorithms > being unsupported, provided the same holds for the DS RRset. So, > while I see a use-case for code 3 (all DS unsupported, perhaps to > signal why the AD bit is not set, despite the non-empty DS RRset), > I don't understand when one would use code 2. I do fail to understand the split codes 1 and 2 for all DS/DNSKEY algorithms being unsupported, and it actually makes me wonder how to exactly write the resolver code that would set this pair. For validation I need at least one usable DS RR, i.e. one where *both* the DS and DNSKEY algorithms are supported. I believe that's the exact condition to be able to extend the trust chain. (and that's how I implemented it for Knot Resolver) It may theoretically even happen that there is a supported DS algorithm and a supported DNSKEY algorithm but never paired together in the DS RRset - IIRC it's not perfectly correct to generate such an RRset but that's probably not something a validator should care for. On 9/11/19 8:05 AM, Viktor Dukhovni wrote: > Section 3.8 [...] > > So just *an* expired signature is not really a problem provided > another signature for the same RRset is not expired. So I think > the text could more clearly read "but *all* signatures for an > RRset in the validation chain expired", or some such. Nitpick: *if* we were diving into such details... each RRSIG might fail for a different reason, for example. That's the general problem with providing reasons for validation failures: validation is defined in the sense that you (may) succeed when at least one of various ways succeeds. A failure could typically be fixed by multiple different ways (EDE codes). Still, I'd hope that in most real-life cases the implementations can "correctly" guess what's wrong. On 9/13/19 10:01 PM, Tony Finch wrote: > 3.5. Extended DNS Error Code 4 - Forged Answer > 3.16. Extended DNS Error Code 15 - Blocked > 3.17. Extended DNS Error Code 16 - Censored > 3.19. Extended DNS Error Code 18 - Filtered > > I don't understand the shades of meaning that these are supposed to > distinguish. > > wrt "filtered", the description implies vaguely RPZ flavoured filtering, > but it mentions a REFUSED RCODE which isn't what a sensible implementation > would use for that purpose, so I am more confused. With the switch to codes not specific to RCODE, I think some more code-merging would be nice, in particular 3+19: stale (NXDOMAIN) answer. Perhaps also drop "4 forged" in favor of the other options? (blocked, censored, if I understand the definitions) Or is "forged" meant for cases like the special top-level invalid. zone? I think the current -09 "Security considerations" section is a bit misleading. It talks about the extended error being unauthenticated in case of validation failure, but the current SERVFAIL is the very same and that part is the more important bit (noticed by Paul Hoffman, too). With extended errors we only get more information of the same authenticity. In general, clients that don't want to validate themselves can also choose a middle ground where they trust the resolver and secure their link to it (typically by DoT or DoH). Also, *if* the EDE codes will only be used for [diagnostics], I don't really understand why have any "Security considerations" at all. Perhaps I'm just confused about the overall intention. [diagnostics] https://mailarchive.ietf.org/arch/msg/dnsop/rbkGvMH-vG-P5GHUx06-LRWYRgM --Vladimir _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
