> On Aug 3, 2025, at 12:38, Michael StJohns <[email protected]> wrote: > > > Hi - apologies, I wasn't paying attention as I thought this would have been a > simple and clean document. > > Mukund's note made me take a quick look a this. I think the document is > incomplete or ambiguous. > > Please add a reference to RFC 4035.
That is a partial reference to DNSSEC. It should be RFC 9364 (or BCP 237) > > > Please add a sentence or two that says something like "Insecure, with respect > to DNSSEC, has the meaning given to it per [RFC4035], section 4.3." if > that's what you mean by "insecure". I'm not sure if you meant that or Bogus. Bogus is never the same as insecure. Bogus represses the Answer Section content, while insecure does not. > Should a SHA1 signature over a DS record be treated differently than a > signature over other records? E.g. Is a SHA1 signature in a signed zone over > a DS record bogus, or can it be treated as if it weren't present? If the > latter, is the subordinate zone securely insecure, or bogus? It should either be validated or treated as not existing (aka insecure). It MUST NOT cause bogus. >> The RSASHA1 [RFC4034] and RSASHA1-NSEC3-SHA1 [RFC5155] algorithms >> MUST NOT be used when creating DS records. \ > This is fine. But instead perhaps.: > > The RSASHA1, and RSASHA-NSEC3-SHA1 algorithms MUST NOT be used when creating > DS records; authoritative servers MUST NOT serve DS RRSets containing these > records; You don’t want to define a new code path where an auth server is going to filter out part of the zone file it is given. > Also records aren't secure or insecure, RRSets and validations results are > secure or insecure. A DS RRSet containing both SHA1 and non SHA1 delegations > signed by a non-SHA1 algorithm is secure (assuming a chain of trust) for > example. Yes, agreed. Paul
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
