Re: [DNSOP] [Ext] Working Group Last Call for aft-ietf-dnsop-dnssec-bcp
On 02. 08. 22 22:29, Edward Lewis wrote: On 8/2/22, 11:02 AM, "DNSOP on behalf of Paul Hoffman" wrote: I would rather mention NSEC/NSEC3 so the reader gets an idea for the mechanism in RFC 8198. I left off NSEC3 because I thought that basically all use of NSEC3 was with opt-out, but if I'm wrong, I could put it in the text. Just as a data point, there are two gTLDs over 1 million delegations that use NSEC3 / no-opt out. I have no data on ccTLDs, nor lower in the namespace. In ccTLD space e.g. CZ has 1.4 million delegations and uses NSEC3 without opt-out: https://stats.nic.cz/dashboard/en/DNSSEC.html -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Working Group Last Call for aft-ietf-dnsop-dnssec-bcp
Perfect, thanks Paul. On Wed, Aug 3, 2022, 07:50 Paul Hoffman wrote: > On Aug 3, 2022, at 6:48 AM, Gavin McCullagh wrote: > > > > > > > Nonetheless, the significant deployment of > > > DNSSEC within some top-level domains (TLDs), and the near-universal > > > deployment of DNSSEC in the TLDs, demonstrate that DNSSEC is suitable > > > for implementation by both ordinary and highly sophisticated domain > > > owners. > > > > Maybe it's my lack of dns inside baseball terminology > > Nope; it was just my unclear writing. > > > but I found the hard distinction between "within" and "in" a bit > confusing here and had to re-read to grok what was meant. It might be > clearer to contrast e.g. "at the TLDs" with "below/within some TLDs" to > bring out the distinction. > > Proposed fix: > > Nonetheless, the significant deployment of DNSSEC beneath some top-level > domains (TLDs), > and the near-universal deployment of DNSSEC for the TLDs in the DNS root > zone, > > > > > >* [RFC7344] describes using the CDS and CDNSKEY resource records to > > > help automate the creation of DS records in the parents of signed > > > zones. > > > > The term used in the RFC is "maintenance" as opposed to "creation" which > seems more precise, given that CDS does not directly address initial > creation of a DS. > > Good catch! Fixed. > > --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Working Group Last Call for aft-ietf-dnsop-dnssec-bcp
On Aug 3, 2022, at 6:48 AM, Gavin McCullagh wrote: > > > > Nonetheless, the significant deployment of > > DNSSEC within some top-level domains (TLDs), and the near-universal > > deployment of DNSSEC in the TLDs, demonstrate that DNSSEC is suitable > > for implementation by both ordinary and highly sophisticated domain > > owners. > > Maybe it's my lack of dns inside baseball terminology Nope; it was just my unclear writing. > but I found the hard distinction between "within" and "in" a bit confusing > here and had to re-read to grok what was meant. It might be clearer to > contrast e.g. "at the TLDs" with "below/within some TLDs" to bring out the > distinction. Proposed fix: Nonetheless, the significant deployment of DNSSEC beneath some top-level domains (TLDs), and the near-universal deployment of DNSSEC for the TLDs in the DNS root zone, > > >* [RFC7344] describes using the CDS and CDNSKEY resource records to > > help automate the creation of DS records in the parents of signed > > zones. > > The term used in the RFC is "maintenance" as opposed to "creation" which > seems more precise, given that CDS does not directly address initial creation > of a DS. Good catch! Fixed. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Working Group Last Call for aft-ietf-dnsop-dnssec-bcp
On Aug 2, 2022, at 1:29 PM, Edward Lewis wrote: > > On 8/2/22, 11:02 AM, "DNSOP on behalf of Paul Hoffman" > wrote: >> I would rather mention NSEC/NSEC3 so the reader gets an idea for the >> mechanism in RFC 8198. I left off NSEC3 because I thought that basically all >> use of NSEC3 was with opt-out, but if I'm wrong, I could put it in the text. > > Just as a data point, there are two gTLDs over 1 million delegations that use > NSEC3 / no-opt out. > > I have no data on ccTLDs, nor lower in the namespace. This is useful info; thanks! I'll update the draft to say NSEC and NSEC3. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Working Group Last Call for aft-ietf-dnsop-dnssec-bcp
On 8/2/22, 11:02 AM, "DNSOP on behalf of Paul Hoffman" wrote: >I would rather mention NSEC/NSEC3 so the reader gets an idea for the mechanism >in RFC 8198. I left off NSEC3 because I thought that basically all use of >NSEC3 was with opt-out, but if I'm wrong, I could put it in the text. Just as a data point, there are two gTLDs over 1 million delegations that use NSEC3 / no-opt out. I have no data on ccTLDs, nor lower in the namespace. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Working Group Last Call for aft-ietf-dnsop-dnssec-bcp
On Aug 2, 2022, at 7:57 AM, Vladimír Čunát wrote: > > Hello. > > This line is misleading, I believe: > > >> - RFC8198 describes how a validating resolver can emit fewer queries in >> signed zones that >> use NSEC for negative caching. > > That RFC describes aggressive caching also for NSEC3 and (positive) > wildcards. (Of course, opt-out NSEC3 records are basically useless, but many > zones are without opt-out.) > > For example, the formulation could be simply truncated as: > > RFC8198 describes how a validating resolver can emit fewer queries in > > signed zones. I would rather mention NSEC/NSEC3 so the reader gets an idea for the mechanism in RFC 8198. I left off NSEC3 because I thought that basically all use of NSEC3 was with opt-out, but if I'm wrong, I could put it in the text. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Working Group Last Call for aft-ietf-dnsop-dnssec-bcp
On Fri, 2022-07-29 at 13:50 +, Paul Hoffman wrote: > On Jul 29, 2022, at 8:58 AM, Peter van Dijk > wrote: > > The mention of 5011 talks about the root, but 5011 does not mention the > > root at all. 5011 is not limited to the root. > > It is limited to "trust anchors", and essentially all DNSSEC trust anchors > are for the DNS root. Still, the wording can be improved. On the Internet, this is true, and I think it would be unwise (and unnecessary) to use 5011 for anything. But I've been told 5011 sees non- root usage inside some private networks. > Current: > - [RFC5011] explains how recursive resolvers and the DNS root can work > together to automate > the rollover of the root's key signing key (KSK). > > Proposed: > - [RFC5011] describes a method to help resolvers update their DNSSEC trust > anchors in an > automated fashion. This method was used in 2018 to update the DNS root trust > anchor. Wonderful. > Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Working Group Last Call for aft-ietf-dnsop-dnssec-bcp
On Jul 29, 2022, at 8:58 AM, Peter van Dijk wrote: > The mention of 5011 talks about the root, but 5011 does not mention the > root at all. 5011 is not limited to the root. It is limited to "trust anchors", and essentially all DNSSEC trust anchors are for the DNS root. Still, the wording can be improved. Current: - [RFC5011] explains how recursive resolvers and the DNS root can work together to automate the rollover of the root's key signing key (KSK). Proposed: - [RFC5011] describes a method to help resolvers update their DNSSEC trust anchors in an automated fashion. This method was used in 2018 to update the DNS root trust anchor. > In the list of "Additional Documents of Interest", I think 7129 deserves > to be pointed out as an especially important document, as NSEC/NSEC3 are > almost impossible to understand without it. Done. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
