From denesh at dns-oarc.net Thu Apr 1 13:22:28 2021 From: denesh at dns-oarc.net (Denesh Bhabuta :: OARC) Date: Thu, 1 Apr 2021 14:22:28 +0100 Subject: [dns-operations] OARC 35 in Asia Pacific (May 6th & 7th, 2021) Message-ID: <7E4FFFA1-2120-4D3C-8185-11A1E9D5B964@dns-oarc.net> Dear colleagues OARC 35 is coming to the Asia Pacific region! Well, it will be an online only workshop, but it will take place in an Asia Pacific friendly timezone on May 6th and 7th - in 5 weeks time! The sessions on each day are scheduled to start at 01:00 UTC and end at 06:00 UTC Call for Presentations === While the CfP is currently closed, we are encouraging those from the Asia Pacific region to submit their proposals by emailing Registration == Attending DNS-OARC Workshops is open to all OARC members and other parties interested in DNS operations and research. Attending OARC 35 is on a paid registration basis. The non-member fee is US$150. The active points of contact in the OARC member organizations have already received the code for discounted registration. Registration fee waivers are available for the workshop to support those who are part of under-represented groups at DNS-OARC. See the registration page on the main OARC 35 website for details. OARC 35 Blog: OARC 35 website: Hope to see you there. Regards Denesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Thu Apr 1 13:40:31 2021 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Thu, 1 Apr 2021 09:40:31 -0400 Subject: [dns-operations] IMPORTANT: Please ensure your NSEC3 iteration count is sufficiently low In-Reply-To: <607F46B6-2B13-4B2E-9AB8-D637F95F173D@dukhovni.org> References: <3AC8C6BC-6B75-4CBB-8076-1711DDB4616F@sys4.de> <607F46B6-2B13-4B2E-9AB8-D637F95F173D@dukhovni.org> Message-ID: RFC 5155 defined NSEC3 iterations to scale up with the RSA/DSA key size up to perhaps as high as 2500 iterations for 4096-bit keys. In retrospect such a generous iteration cap is counter-productive. It is neither particularly effective at keeping your zone content "secret", nor sufficiently cheap to avoid negative impact on authoritative and iterative resolver performance. In that light, Wes Hardaker and I have authored an Internet-Draft that strongly recommends setting the NSEC3 additional iteration count to 0 (at least one initial SHA1 hash is always performed). https://tools.ietf.org/html/draft-hardaker-dnsop-nsec3-guidance-02 Today, the Knot resolver became the first one to cap NSEC3 iterations for now at 150, but this will likely be reduced further (perhaps ultimately as low as ~25): https://gitlab.nic.cz/knot/knot-resolver/-/tags/v5.3.1 and is expected to be done by more resolvers. Since iteration counts above the resolver cap make denial-of-existence for the entire zone insecure, it is important that all domains with a high NSEC3 iteration count proactively lower it ideally to 0, but otherwise ~10 or less. While DNSSEC still precludes forged positive answers, any signed NXDomain or NODATA NSEC3 response can be replayed for any query, regardless of the qname. This impacts any protocol in which negative responses have security consequences. Potential exposures include: - Forged absence of RFC7672 DANE SMTP TLSA records - Forged absence of CAA records - Forged absence of HTTPS records enabling various downgrades - ... A number of TLDs have already lowred their iteration counts, and it is expected that most of the rest will follow soon. TLD before after --- ------ ----- la 150 1 xn--q7ce6a 150 1 blue 100 10 green 100 10 lat 100 10 mx 100 10 pink 100 10 red 100 10 schaeffler 100 10 by 100 3 creditunion 100 3 ally 100 1 autos 100 1 boats 100 1 homes 100 1 motorcycles 100 1 yachts 100 1 If your DNS zone is configured to use NSEC3, please: - Reduce the iteration count to 10 or less. - Disable opt-out, you're very unlikely to need it. - Either rotate the salt each time you sign, or skip it entirely. But a short fixed salt is harmless if leaving it alone easier than changing it. Of course, if your zone is small enough (just the zone apex and a handful of already public or easy to guess names) or in any case has nothing to hide, even better is to use just plain NSEC. You get smaller negative replies (less exposure to DoS) and more effective negative caching at resolvers. So in many cases, it is even simpler to abandon NSEC3 entirely. Please also consider the pros/cons of that option. -- Viktor. From sethm at rollernet.us Thu Apr 8 17:07:32 2021 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 8 Apr 2021 10:07:32 -0700 Subject: [dns-operations] Charter/Spectrum resolver trouble Message-ID: Is there someone from Charter/Spectrum who is responsible for resolvers 71.10.216.1 and 71.10.216.2 on here? I have a customer that's getting SERVFAIL responses from those DNS servers for zones they host. All the usual public DNS and other provider's DNS servers are fine. Examples testing from a Charter residential (coax) connection: ; <<>> DiG 9.11.5-P4-5.1+deb10u3-Debian <<>> A sprux.com @71.10.216.2 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 45159 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 8192 ;; QUESTION SECTION: ;sprux.com. IN A ;; Query time: 2564 msec ;; SERVER: 71.10.216.2#53(71.10.216.2) ;; WHEN: Thu Apr 08 10:05:13 PDT 2021 ;; MSG SIZE rcvd: 38 ; <<>> DiG 9.11.5-P4-5.1+deb10u3-Debian <<>> A sprux.com @209.18.47.61 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14541 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 8192 ;; QUESTION SECTION: ;sprux.com. IN A ;; ANSWER SECTION: sprux.com. 1800 IN A 74.118.157.133 ;; Query time: 124 msec ;; SERVER: 209.18.47.61#53(209.18.47.61) ;; WHEN: Thu Apr 08 10:05:39 PDT 2021 ;; MSG SIZE rcvd: 54 ; <<>> DiG 9.11.5-P4-5.1+deb10u3-Debian <<>> A sprux.com @9.9.9.9 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34051 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;sprux.com. IN A ;; ANSWER SECTION: sprux.com. 1800 IN A 74.118.157.133 ;; Query time: 57 msec ;; SERVER: 9.9.9.9#53(9.9.9.9) ;; WHEN: Thu Apr 08 10:05:27 PDT 2021 ;; MSG SIZE rcvd: 54 From sethm at rollernet.us Fri Apr 9 03:48:50 2021 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 8 Apr 2021 20:48:50 -0700 Subject: [dns-operations] Charter/Spectrum resolver trouble In-Reply-To: References: Message-ID: <4471bfd8-5744-8661-e00b-a642dbd68e79@rollernet.us> On 4/8/21 10:07 AM, Seth Mattinen wrote: > Is there someone from Charter/Spectrum who is responsible for resolvers > 71.10.216.1 and 71.10.216.2 on here? I have a customer that's getting > SERVFAIL responses from those DNS servers for zones they host. All the > usual public DNS and other provider's DNS servers are fine. > Figured out the issue; there appears to be a routing loop in AS6939 to prefix 68.114.45.0/24. Sending traffic out over a different transit AS resolves it for now. From sethm at rollernet.us Fri Apr 9 16:39:54 2021 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 9 Apr 2021 09:39:54 -0700 Subject: [dns-operations] Charter/Spectrum resolver trouble In-Reply-To: <4471bfd8-5744-8661-e00b-a642dbd68e79@rollernet.us> References: <4471bfd8-5744-8661-e00b-a642dbd68e79@rollernet.us> Message-ID: <4ce94026-05c2-957b-b89d-11bff12624dd@rollernet.us> On 4/8/21 8:48 PM, Seth Mattinen wrote: > On 4/8/21 10:07 AM, Seth Mattinen wrote: >> Is there someone from Charter/Spectrum who is responsible for >> resolvers 71.10.216.1 and 71.10.216.2 on here? I have a customer >> that's getting SERVFAIL responses from those DNS servers for zones >> they host. All the usual public DNS and other provider's DNS servers >> are fine. >> > > Figured out the issue; there appears to be a routing loop in AS6939 to > prefix 68.114.45.0/24. Sending traffic out over a different transit AS > resolves it for now. One last clarification; after digging by HE the problem is/was Charter advertising 68.114.45.0/24 and then looping traffic back to HE for unknown reasons. HE worked around this by filtering the announcement for 68.114.45.0/24 at that point. From seth.arnold at canonical.com Mon Apr 12 22:17:05 2021 From: seth.arnold at canonical.com (Seth Arnold) Date: Mon, 12 Apr 2021 22:17:05 +0000 Subject: [dns-operations] nsec vs nsec3 use Message-ID: <20210412221705.GC2257521@millbarge> Hello, I'm curious about how many domains are using nsec and how many domains are using nsec3. (I realize there's lots of ways to measure "use", and I'm not particular about any specific meaning; this is an idle curiosity.) Are there resources that already track nsec vs nsec3 use in domains or requests? Thanks -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From ietf-dane at dukhovni.org Tue Apr 13 01:51:35 2021 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Mon, 12 Apr 2021 21:51:35 -0400 Subject: [dns-operations] nsec vs nsec3 use In-Reply-To: <20210412221705.GC2257521@millbarge> References: <20210412221705.GC2257521@millbarge> Message-ID: <63D2B367-442E-4745-BC20-DB437AD5BD3A@dukhovni.org> > On Apr 12, 2021, at 6:17 PM, Seth Arnold wrote: > > Hello, I'm curious about how many domains are using nsec and how many > domains are using nsec3. (I realize there's lots of ways to measure "use", > and I'm not particular about any specific meaning; this is an idle > curiosity.) > > Are there resources that already track nsec vs nsec3 use in domains or > requests? I don't monitor NSEC3 vs. NSEC on a regular basis, but a few weeks back I took a survey of at the time ~14.4 million DNSSEC signed domains, of which ~10.9 million used NSEC3. My dataset is fairly comprehensive, I'm missing no more than ~1 million domains (likely closer to 0.5 million), most of the missing ones are likely parked. But, that said, my advice is to use NSEC unless you have an absolutely compelling case to attempt to deter zone enumeration, or your zone is so large (e.g. 10 million or more domains) and so sparsely signed, that opt-out is particularly appealing. -- Viktor. From gtaylor at tnetconsulting.net Tue Apr 13 15:58:16 2021 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Tue, 13 Apr 2021 09:58:16 -0600 Subject: [dns-operations] nsec vs nsec3 use In-Reply-To: <63D2B367-442E-4745-BC20-DB437AD5BD3A@dukhovni.org> References: <20210412221705.GC2257521@millbarge> <63D2B367-442E-4745-BC20-DB437AD5BD3A@dukhovni.org> Message-ID: <22f18b6a-f71a-0ecf-8f71-d17ee1a392c1@spamtrap.tnetconsulting.net> Hi Viktor, On 4/12/21 7:51 PM, Viktor Dukhovni wrote: > my advice is to use NSEC unless you have an absolutely compelling > case to attempt to deter zone enumeration Would you please elaborate on why that is your opinion / advice? It seems contrary to the litmus test of which is more secure vs difficult to implement. I'm trying to understand your thought process and subsequently make a more informed decision myself. Thank you for your time. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4013 bytes Desc: S/MIME Cryptographic Signature URL: From ietf-dane at dukhovni.org Tue Apr 13 16:40:08 2021 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Tue, 13 Apr 2021 12:40:08 -0400 Subject: [dns-operations] nsec vs nsec3 use In-Reply-To: References: <20210412221705.GC2257521@millbarge> <63D2B367-442E-4745-BC20-DB437AD5BD3A@dukhovni.org> Message-ID: On Tue, Apr 13, 2021 at 09:58:16AM -0600, Grant Taylor via dns-operations wrote: > On 4/12/21 7:51 PM, Viktor Dukhovni wrote: > > > my advice is to use NSEC unless you have an absolutely compelling > > case to attempt to deter zone enumeration > > Would you please elaborate on why that is your opinion / advice? - Most zones have no secrets, often just the zone apex and a couple of common labels, "www", "smtp", "mx1", ... - Names from zone files leak into CT logs, mailing lists, ... If you actually want to keep a secret, don't publish it via DNS! - NSEC responses are more compact, typically needing at most two signed records in the response, as opposed to three NSEC3. - With NSEC you benefit from aggressive negative caching reducing query load on your authoritative server. - If, on the other hand, you *really* care about keeping part of the zone confidential, and dynamic signing is an option, then NSEC is great for that, with a single NODATA record created on the fly sufficient to deny the existence of the requested RRSet. This is used by Cloudflare: bogusname.cloudflare.com. IN A ? ; NoError AD=1 cloudflare.com. IN SOA ( ns3.cloudflare.com. dns at cloudflare.com. 2036904638 10000 2400 604800 300 ) cloudflare.com. IN RRSIG ( SOA 13 2 300 20210414173321 20210412153321 34505 cloudflare.com. AEFzUMJqAWtS/RbemGnDgLUDgWtpm6qoag/MwDCKCf84jBwVckgYfOhArSwisX2ewqRbQkFMFfmLnpnxGPB7dA== ) bogusname.cloudflare.com. IN NSEC \000.bogusname.cloudflare.com. RRSIG NSEC bogusname.cloudflare.com. IN RRSIG ( NSEC 13 3 300 20210414173321 20210412153321 34505 cloudflare.com. E5K51Q+/FJG60DhFCc084MglrBLeXiKYislJNxSbl85/yn2ICID8wvknbJ/irUYEggbd7EWCSOKZDOlboyC9IQ== ) > It seems contrary to the litmus test of which is more secure vs > difficult to implement. You're using the phrase "more secure" in a way I am not familiar with. I don't think of Either NSEC or NSEC3 as "more secure". NSEC3 was primarily designed for "opt-out", which actually deliberately reduces security in order to gain a more compact zone with fewer records to sign. If, as should be the case for most zones, you don't use opt-out, you mostly don't need NSEC3. While discouraging casual zone walking is also a feature of NSEC3, this is a secondary benefit, that is oversold. It is fine to choose NSEC3 (with a low iteration count, see below), but often not particularly beneficial. > I'm trying to understand your thought process and subsequently make a > more informed decision myself. See also: https://mail.sys4.de/pipermail/dane-users/2021-March/000594.html https://datatracker.ietf.org/doc/html/draft-hardaker-dnsop-nsec3-guidance-02 -- Viktor. From dot at dotat.at Tue Apr 13 17:02:08 2021 From: dot at dotat.at (Tony Finch) Date: Tue, 13 Apr 2021 18:02:08 +0100 Subject: [dns-operations] nsec vs nsec3 use In-Reply-To: References: <20210412221705.GC2257521@millbarge> <63D2B367-442E-4745-BC20-DB437AD5BD3A@dukhovni.org> Message-ID: Grant Taylor via dns-operations wrote: > On 4/12/21 7:51 PM, Viktor Dukhovni wrote: > > my advice is to use NSEC unless you have an absolutely compelling > > case to attempt to deter zone enumeration > > Would you please elaborate on why that is your opinion / advice? > > It seems contrary to the litmus test of which is more secure vs > difficult to implement. Well, NSEC3 is definitely complicated, difficult to understand and debug, and it has parameters that need some expertise to configure. At least Wes and Viktor have a draft in progress to provide advice to those who choose NSEC3. https://tools.ietf.org/html/draft-hardaker-dnsop-nsec3-guidance NSEC3 gives you two things that NSEC does not: 1. opt-out, useful for zones that have a very large number of unsigned delegations; 2. an obfuscated list of names in the zone. Static NSEC3 can't provide any serious protection against zone enumeration, because DNS names are friendly to people and therefore an ideal candidate for password crackers. (If anyone populates their zones with the output from `pwgen` I will be both very entertained and eager to speak to their users.) And NSEC3 can't use the kind of work-hardening that password hashes use to protect against cracking, because high iteration counts are absolute murder to both authoritative servers and validators. Hence Wes and Viktor's draft recommends an iteration count of 0 (i.e. hash once). Maybe use NSEC3 if you have a stunt DNS server like Cloudflare's that is able to generate narrow NSEC3 denials, or if you are a large TLD without DNSSEC incentives, but otherwise NSEC3 gives you a lot of pain for no real benefit. Tony. -- f.anthony.n.finch https://dotat.at/ North Bailey: Southwesterly 3 to 5. Moderate. Showers. Good. From vladimir.cunat+ietf at nic.cz Tue Apr 13 17:31:38 2021 From: vladimir.cunat+ietf at nic.cz (=?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?=) Date: Tue, 13 Apr 2021 19:31:38 +0200 Subject: [dns-operations] nsec vs nsec3 use In-Reply-To: References: <20210412221705.GC2257521@millbarge> <63D2B367-442E-4745-BC20-DB437AD5BD3A@dukhovni.org> Message-ID: <3de88115-2b81-6838-0406-ad5106bcb3aa@nic.cz> On 13. 04. 21 18:40, Viktor Dukhovni wrote: > - With NSEC you benefit from aggressive negative caching reducing > query load on your authoritative server. Tiny detail: NSEC3 without opt-out also allows aggressive caching with the same benefits but it's less common.? (so NSEC does give advantage there) > Tony> Maybe use NSEC3 if you have a stunt DNS server like Cloudflare's that is > able to generate narrow NSEC3 denials I think even for online minimal responses, NSEC will be a slightly better choice.? (Cloudflare are such an example) From gtaylor at tnetconsulting.net Tue Apr 13 22:50:10 2021 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Tue, 13 Apr 2021 16:50:10 -0600 Subject: [dns-operations] nsec vs nsec3 use In-Reply-To: References: <20210412221705.GC2257521@millbarge> <63D2B367-442E-4745-BC20-DB437AD5BD3A@dukhovni.org> Message-ID: <332525d1-0d8d-248b-f993-6157720aa7a3@spamtrap.tnetconsulting.net> On 4/13/21 10:40 AM, Viktor Dukhovni wrote: > It is fine to choose NSEC3 (with a low iteration count, see below), > but often not particularly beneficial. Thank you for the additional information Viktor, Tony, and Vladimir. I will take what you have shared, do some more reading, and hopefully come out wiser for it. :-) -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4013 bytes Desc: S/MIME Cryptographic Signature URL: From ajs at anvilwalrusden.com Tue Apr 13 23:33:53 2021 From: ajs at anvilwalrusden.com (Andrew Sullivan) Date: Tue, 13 Apr 2021 19:33:53 -0400 Subject: [dns-operations] Historical reminiscences (was Re: nsec vs nsec3 use) In-Reply-To: References: <20210412221705.GC2257521@millbarge> <63D2B367-442E-4745-BC20-DB437AD5BD3A@dukhovni.org> Message-ID: <20210413233353.m2juue7fbpt5636l@crankycanuck.ca> Hi, On Tue, Apr 13, 2021 at 12:40:08PM -0400, Viktor Dukhovni wrote: >NSEC3 was primarily designed for "opt-out", which actually >deliberately reduces security in order to gain a more compact zone >with fewer records to sign. [?] While discouraging casual zone >walking is also a feature of NSEC3, this is a secondary benefit, that >is oversold. This is not how I recall the history. What I recall was that there _was_ an opt-out (well, it was opt-in) proposed that was rejected mostly for political or maybe techno-political reasons. This actually made DNSSEC look really problematic to deploy in one hugely important TLD, which seemed like a pretty bad barrier. Then (a) certain large delegation-centric zone operator(s) from Europe (it's now kind of ironic which the leader was) got a legal opinion that the GDPR would raise problems for them due to zone walking[1], and so something else had to be created. The zone-walking-resistant NSEC3 was an opportunity to reintroduce opt-out, and since NSEC3 was so obviously useful only for TLDs the techno-political objections to opt-out were somehow dissolved. Maybe some others have a different memory of this, though? Best regards, A [1] As I heard it told, even the lawyers agreed it was stupid, but it was the consequence of some detail of the law. This hearsay is not admissible in any proceeding, I'm sure. -- Andrew Sullivan ajs at anvilwalrusden.com From paul at redbarn.org Wed Apr 14 00:30:56 2021 From: paul at redbarn.org (Paul Vixie) Date: Wed, 14 Apr 2021 00:30:56 +0000 Subject: [dns-operations] Historical reminiscences (was Re: nsec vs nsec3 use) In-Reply-To: <20210413233353.m2juue7fbpt5636l@crankycanuck.ca> References: <20210412221705.GC2257521@millbarge> <63D2B367-442E-4745-BC20-DB437AD5BD3A@dukhovni.org> <20210413233353.m2juue7fbpt5636l@crankycanuck.ca> Message-ID: <20210414003056.nf4kyemci5wmfbl6@family.redbarn.org> On Tue, Apr 13, 2021 at 07:33:53PM -0400, Andrew Sullivan wrote: > ... What I recall was that there > _was_ an opt-out (well, it was opt-in) proposed that was rejected > mostly for political or maybe techno-political reasons. This actually > made DNSSEC look really problematic to deploy in one hugely important > TLD, which seemed like a pretty bad barrier. Then (a) certain large > delegation-centric zone operator(s) from Europe (it's now kind of > ironic which the leader was) got a legal opinion that the GDPR would > raise problems for them due to zone walking[1], and so something else > had to be created. The zone-walking-resistant NSEC3 was an > opportunity to reintroduce opt-out, and since NSEC3 was so obviously > useful only for TLDs the techno-political objections to opt-out were > somehow dissolved. > > Maybe some others have a different memory of this, though? that matches my recollection. there are other story elements, such as the working group meeting that devolved to queues of people shouting at each other from various microphones. ultimately, dnssec was NOT going to be deployed, even a little, without opt-in/out. however, first we had to uglify, complexify, and add another three to four years of "ideology delay". -- Paul Vixie From jaap at NLnetLabs.nl Wed Apr 14 07:44:33 2021 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Wed, 14 Apr 2021 09:44:33 +0200 Subject: [dns-operations] Historical reminiscences (was Re: nsec vs nsec3 use) In-Reply-To: <20210413233353.m2juue7fbpt5636l@crankycanuck.ca> References: <20210412221705.GC2257521@millbarge> <63D2B367-442E-4745-BC20-DB437AD5BD3A@dukhovni.org> <20210413233353.m2juue7fbpt5636l@crankycanuck.ca> Message-ID: <202104140744.13E7iXT7058288@bela.nlnetlabs.nl> Andrew Sullivan writes: About this part: > <...> > raise problems for them due to zone walking[1], and so something else > had to be created. The zone-walking-resistant NSEC3 was an > opportunity to reintroduce opt-out, > > Maybe some others have a different memory of this, though? > > [1] As I heard it told, even the lawyers agreed it was stupid, but it > was the consequence of some detail of the law. This hearsay is not > admissible in any proceeding, I'm sure. I do remember there was some discussion in Europe. At SIDN we (Where I was at that time) commissioned some academic research (Tilburg University I think) to see whether NSEC was interfering with privacy concerns (including European regulations). The conclusion was it didn't and got ignored. So NSEC3 developing of NSEC3 started, The opt-out thing got sneaked in and yes, the big zone problem was the motive for that. jaap From bortzmeyer at nic.fr Wed Apr 14 08:51:14 2021 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 14 Apr 2021 10:51:14 +0200 Subject: [dns-operations] Name:Wreck vulnerability Message-ID: <20210414085114.GA11855@nic.fr> Time for a new vunerability-with-a-catchy-name. Name:Wreck is a bug in some implementations of DNS clients when dereferencing compression pointers, in some cases leading to remote code execution when parsing a malicious packet. https://www.forescout.com/company/resources/namewreck-breaking-and-fixing-dns-implementations From jim at rfc1035.com Wed Apr 14 08:55:47 2021 From: jim at rfc1035.com (Jim Reid) Date: Wed, 14 Apr 2021 09:55:47 +0100 Subject: [dns-operations] Historical reminiscences (was Re: nsec vs nsec3 use) In-Reply-To: <20210414003056.nf4kyemci5wmfbl6@family.redbarn.org> References: <20210412221705.GC2257521@millbarge> <63D2B367-442E-4745-BC20-DB437AD5BD3A@dukhovni.org> <20210413233353.m2juue7fbpt5636l@crankycanuck.ca> <20210414003056.nf4kyemci5wmfbl6@family.redbarn.org> Message-ID: > On 14 Apr 2021, at 01:30, Paul Vixie wrote: > > that matches my recollection. there are other story elements, such as > the working group meeting that devolved to queues of people shouting > at each other from various microphones. Paul, are you suggesting that?s only ever happened at *one* IETF WG meeting? :-) > ultimately, dnssec was NOT going to be deployed, even a little, without > opt-in/out. however, first we had to uglify, complexify, and add another > three to four years of "ideology delay". My memory of the details of those events is a bit different. A few big TLDs said they would not deploy DNSSEC-bis because it allowed zone enumeration and that?s what lead to the effort on DNSSEC-ter. IIRC opt-in/out wasn?t a factor in those TLDs rejecting DNSSEC-bis. [Though it might well have been an issue for Verisign who were facing the prospect of signing zillions of delegations in .com/.net when it was expected only a handful of these would be likely to be signed.] The dnsext WG had debated opt-in at length while DNSSEC-bis was being developed. There was much shouting at the mikes at meetings and on the mailing lists about this topic. A chain of opt-in NSEC records would just yield the names of the signed delegations. Eventually the WG decided opt-in was bad because it prevented proof of non-existence. So DNSSEC-bis didn?t get to offer opt-in. However when work on DNSSEC-ter started, the proponents of opt-in were able to get this added to the spec. By then the WG was too exhausted and burnt out to rehash the previous arguments for yet another couple of years. The general mood was get DNSSEC-ter quickly out the door and close the WG. I think the concept got renamed to opt-out in RFC5155 because opt-in had become a far too contentious term for the WG. From edward.lewis at icann.org Wed Apr 14 13:49:58 2021 From: edward.lewis at icann.org (Edward Lewis) Date: Wed, 14 Apr 2021 13:49:58 +0000 Subject: [dns-operations] [Ext] Historical reminiscences (was Re: nsec vs nsec3 use) In-Reply-To: <20210413233353.m2juue7fbpt5636l@crankycanuck.ca> References: <20210412221705.GC2257521@millbarge> <63D2B367-442E-4745-BC20-DB437AD5BD3A@dukhovni.org> <20210413233353.m2juue7fbpt5636l@crankycanuck.ca> Message-ID: <6DDAD39C-85B4-46B9-B20A-2AC814805F0D@icann.org> On 4/13/21, 7:38 PM, "dns-operations on behalf of Andrew Sullivan" wrote: >Maybe some others have a different memory of this, though? I agree with that re-telling. The idea of an opt-out/in existed prior to NSEC3, it was even implemented in experimental code but never released because the IETF didn't approve of it. (I wasn't involved in that, but I knew of it.) When I wrote the first signer (1997 or so), COM was too large to be done, much larger than any other zone even then, for the equipment available to me. I managed to sign it by doing it in pieces. While developing the protocol, we didn't want to treat any zone or even any kind of zone ("widely-delegated") as a special case. That probably (as I wasn't working on it myself) led to the opt-out later on. A while back I asked some involved in the NSEC3 development if they felt all the effort was worth it. The answer was yes, it got DNSSEC past the privacy concerns, rightly or wrongly (doesn't matter) and into operations. The context of my question were the growing revelations of code to reverse engineer the name chain. From weiler at watson.org Wed Apr 14 16:46:09 2021 From: weiler at watson.org (Samuel Weiler) Date: Wed, 14 Apr 2021 12:46:09 -0400 (EDT) Subject: [dns-operations] Historical reminiscences (was Re: nsec vs nsec3 use) In-Reply-To: <20210413233353.m2juue7fbpt5636l@crankycanuck.ca> References: <20210412221705.GC2257521@millbarge> <63D2B367-442E-4745-BC20-DB437AD5BD3A@dukhovni.org> <20210413233353.m2juue7fbpt5636l@crankycanuck.ca> Message-ID: On Tue, 13 Apr 2021, Andrew Sullivan wrote: > Hi, > > On Tue, Apr 13, 2021 at 12:40:08PM -0400, Viktor Dukhovni wrote: > >> NSEC3 was primarily designed for "opt-out", which actually >> deliberately reduces security in order to gain a more compact zone >> with fewer records to sign. [?] While discouraging casual zone >> walking is also a feature of NSEC3, this is a secondary benefit, that >> is oversold. > > This is not how I recall the history. What I recall was that there > _was_ an opt-out (well, it was opt-in) proposed that was rejected > mostly for political or maybe techno-political reasons. This retelling is pretty reasonable. I also think the DNSEXT chairs got the consensus call on opt-in wrong. There were at least two of us who opposed it yet were willing to stand aside and let it go through. And while I sometimes feel called out by the camel discussions, looking back at namedroppers reminds me that one of my objections was complexity (which, of course, NSEC3 doubled down on). I even floated a proposal for "opt-in planned obsolescence". ... > Maybe some others have a different memory of this, though? The opt-in mess was 18 years ago. I'm shocked that I still remember it in such detail. -- Sam From bwelling at akamai.com Wed Apr 14 17:17:07 2021 From: bwelling at akamai.com (Wellington, Brian) Date: Wed, 14 Apr 2021 17:17:07 +0000 Subject: [dns-operations] [Ext] Historical reminiscences (was Re: nsec vs nsec3 use) In-Reply-To: <6DDAD39C-85B4-46B9-B20A-2AC814805F0D@icann.org> References: <20210412221705.GC2257521@millbarge> <63D2B367-442E-4745-BC20-DB437AD5BD3A@dukhovni.org> <20210413233353.m2juue7fbpt5636l@crankycanuck.ca> <6DDAD39C-85B4-46B9-B20A-2AC814805F0D@icann.org> Message-ID: <825AD2E8-A7CB-437B-9185-80DB38ECF02B@akamai.com> That all sounds about right to me, too. I don?t remember ever yelling into a microphone at an IETF, but I do remember signing all of .com (without NSEC3) in the span of an hour-long dnsext meeting, to show that it was possible with affordable hardware in a reasonable amount of time. Brian > On Apr 14, 2021, at 6:49 AM, Edward Lewis wrote: > > On 4/13/21, 7:38 PM, "dns-operations on behalf of Andrew Sullivan" wrote: > > >> Maybe some others have a different memory of this, though? > > I agree with that re-telling. > > The idea of an opt-out/in existed prior to NSEC3, it was even implemented in experimental code but never released because the IETF didn't approve of it. (I wasn't involved in that, but I knew of it.) > > When I wrote the first signer (1997 or so), COM was too large to be done, much larger than any other zone even then, for the equipment available to me. I managed to sign it by doing it in pieces. While developing the protocol, we didn't want to treat any zone or even any kind of zone ("widely-delegated") as a special case. That probably (as I wasn't working on it myself) led to the opt-out later on. > > A while back I asked some involved in the NSEC3 development if they felt all the effort was worth it. The answer was yes, it got DNSSEC past the privacy concerns, rightly or wrongly (doesn't matter) and into operations. The context of my question were the growing revelations of code to reverse engineer the name chain. > > > _______________________________________________ > dns-operations mailing list > dns-operations at lists.dns-oarc.net > https://urldefense.com/v3/__https://lists.dns-oarc.net/mailman/listinfo/dns-operations__;!!GjvTz_vk!EOdxu3O6xs7wik_vtzYm1ltvdltPaRzp0TOlBpoCatw4njiX5zET1BPjAFpltfI$ From dns at jrcs.net Wed Apr 14 18:20:43 2021 From: dns at jrcs.net (James Stevens) Date: Wed, 14 Apr 2021 19:20:43 +0100 Subject: [dns-operations] nsec vs nsec3 use In-Reply-To: References: <20210412221705.GC2257521@millbarge> <63D2B367-442E-4745-BC20-DB437AD5BD3A@dukhovni.org>

Message-ID: <94a5c828-a8d4-14b9-ffbc-47dd865e9708@jrcs.net> NSEC has a lighter load on NS servers as they doesn't have to do the NSEC3 hashing on the fly J From tale at dd.org Wed Apr 14 22:36:39 2021 From: tale at dd.org (Dave Lawrence) Date: Wed, 14 Apr 2021 18:36:39 -0400 Subject: [dns-operations] F-Root and DNS Cookies? Message-ID: <24695.28279.764216.848511@gro.dd.org> A few recent analyses I've done at DNSViz have had warnings like these: com/DS (alg 8, id 30909): The server appears to support DNS cookies but did not return a COOKIE option. (192.5.5.241, UDP_-_EDNS0_4096_D_KN) Now I realize that F-Root is a large, heterogeneous set. Any idea which software is causing that? From tale at dd.org Wed Apr 14 23:00:40 2021 From: tale at dd.org (Dave Lawrence) Date: Wed, 14 Apr 2021 19:00:40 -0400 Subject: [dns-operations] [Ext] Historical reminiscences (was Re: nsec vs nsec3 use) In-Reply-To: References: <20210412221705.GC2257521@millbarge> <63D2B367-442E-4745-BC20-DB437AD5BD3A@dukhovni.org> <20210413233353.m2juue7fbpt5636l@crankycanuck.ca> <6DDAD39C-85B4-46B9-B20A-2AC814805F0D@icann.org> Message-ID: <24695.29720.208500.988291@gro.dd.org> To me, Andrew's retelling of the facts but for the emphasis. There's stated reasons, then there's the motivating reasons. GDPR was useful in making the argument, but Verisign and the pain of .com were the real motivation. From paul at redbarn.org Wed Apr 14 23:41:23 2021 From: paul at redbarn.org (Paul Vixie) Date: Wed, 14 Apr 2021 23:41:23 +0000 Subject: [dns-operations] [Ext] Historical reminiscences (was Re: nsec vs nsec3 use) In-Reply-To: <24695.29720.208500.988291@gro.dd.org> References: <20210412221705.GC2257521@millbarge> <63D2B367-442E-4745-BC20-DB437AD5BD3A@dukhovni.org> <20210413233353.m2juue7fbpt5636l@crankycanuck.ca> <6DDAD39C-85B4-46B9-B20A-2AC814805F0D@icann.org> <24695.29720.208500.988291@gro.dd.org> Message-ID: <20210414234123.a4iwthc35tsxnqhf@family.redbarn.org> On Wed, Apr 14, 2021 at 07:00:40PM -0400, Dave Lawrence wrote: > To me, Andrew's retelling of the facts but for the emphasis. > > There's stated reasons, then there's the motivating reasons. GDPR was > useful in making the argument, but Verisign and the pain of .com were > the real motivation. verisign was prepared to do what it would take to live in an NSEC-only world, and they were no part of the pressure toward NSEC3. only after NSEC3 became a thing did a number of prior backers of optionality during the NSEC discussions, ask for optionality in the NSEC3 design. do you know for a fact that someone who argued the GDPR case was in fact carrying water for verisign? -- Paul Vixie From casey at deccio.net Thu Apr 15 03:30:13 2021 From: casey at deccio.net (Casey Deccio) Date: Wed, 14 Apr 2021 21:30:13 -0600 Subject: [dns-operations] nsec vs nsec3 use In-Reply-To: <63D2B367-442E-4745-BC20-DB437AD5BD3A@dukhovni.org> References: <20210412221705.GC2257521@millbarge> <63D2B367-442E-4745-BC20-DB437AD5BD3A@dukhovni.org> Message-ID: <3C7D151B-0940-461F-A561-5B179D511C79@deccio.net> > On Apr 12, 2021, at 7:51 PM, Viktor Dukhovni wrote: > > I don't monitor NSEC3 vs. NSEC on a regular basis, but a few weeks back > I took a survey of at the time ~14.4 million DNSSEC signed domains, of > which ~10.9 million used NSEC3. We did a study a few years ago, with a much smaller data set that Viktor's. But the numbers were very much in the same ballpark: NSEC3: 83% NSEC: 13% But more specifically: NSEC3 (traditional): 53% NSEC3 (white lies): 30% NSEC (traditional): 11% NSEC (black lies): 2% Note that the remaining 4% were unclassified because of inconsistent behavior. Also: > On Apr 13, 2021, at 10:40 AM, Viktor Dukhovni wrote: > > - Most zones have no secrets, often just the zone apex and a couple > of common labels, "www", "smtp", "mx1", ... Again, we have some empirical measurements to confirm this. Nearly 90% of zones signed with NSEC3 have fewer than 10 names. The full paper is here: https://casey.byu.edu/papers/2019_pam_dnssec_lies.pdf And an OARC presentation on the topic here: https://indico.dns-oarc.net/event/32/contributions/725/attachments/699/1151/2019-11-01-dnssec-lies-oarc.pdf Cheers, Casey From tale at dd.org Thu Apr 15 18:21:34 2021 From: tale at dd.org (Dave Lawrence) Date: Thu, 15 Apr 2021 14:21:34 -0400 Subject: [dns-operations] [Ext] Historical reminiscences (was Re: nsec vs nsec3 use) In-Reply-To: <20210414234123.a4iwthc35tsxnqhf@family.redbarn.org> References: <20210412221705.GC2257521@millbarge> <63D2B367-442E-4745-BC20-DB437AD5BD3A@dukhovni.org> <20210413233353.m2juue7fbpt5636l@crankycanuck.ca> <6DDAD39C-85B4-46B9-B20A-2AC814805F0D@icann.org> <24695.29720.208500.988291@gro.dd.org> <20210414234123.a4iwthc35tsxnqhf@family.redbarn.org> Message-ID: <24696.33838.640107.323965@gro.dd.org> Paul Vixie writes: > do you know for a fact that someone who argued the GDPR case was in > fact carrying water for verisign? No, I don't. To be clear that is not what I was asserting. "Carrying water" has a derogatory connotation that has never been in my mind about this whole thing, either then or now. I just saw it as a useful alliance, and that to my ear the GDPR reason played more of a supporting role. Perhaps I am wrong about that; I am only sharing my independent perception. From pk at DENIC.DE Thu Apr 15 19:12:09 2021 From: pk at DENIC.DE (Peter Koch) Date: Thu, 15 Apr 2021 21:12:09 +0200 Subject: [dns-operations] Historical reminiscences (was Re: nsec vs nsec3 use) In-Reply-To: <20210413233353.m2juue7fbpt5636l@crankycanuck.ca> References: <20210412221705.GC2257521@millbarge> <63D2B367-442E-4745-BC20-DB437AD5BD3A@dukhovni.org> <20210413233353.m2juue7fbpt5636l@crankycanuck.ca> Message-ID: <20210415191209.GO6379@denic.de> Hi, On Tue, Apr 13, 2021 at 07:33:53PM -0400, Andrew Sullivan wrote: > TLD, which seemed like a pretty bad barrier. Then (a) certain large > delegation-centric zone operator(s) from Europe (it's now kind of > ironic which the leader was) got a legal opinion that the GDPR would > raise problems for them due to zone walking[1], and so something else > had to be created. [...] it is interesting how deep GDPR is now in everbody's mind, but back then the EU had a Directive that was implemented by member states in subtly (or not so) different ways, so the opinions could, much more legitimately than today, well differ. NSEC3 was also inspired by the proposal of the "NO RR" that dates back to at least as early as the year 2000. -Peter From puneets at google.com Fri Apr 16 18:29:07 2021 From: puneets at google.com (Puneet Sood) Date: Fri, 16 Apr 2021 14:29:07 -0400 Subject: [dns-operations] IMPORTANT: Please ensure your NSEC3 iteration count is sufficiently low In-Reply-To: References: <3AC8C6BC-6B75-4CBB-8076-1711DDB4616F@sys4.de> <607F46B6-2B13-4B2E-9AB8-D637F95F173D@dukhovni.org> Message-ID: Hi Viktor, Thanks for bringing this issue to everyone's attention and your ongoing work on DNSSEC. Google Public DNS is also planning to cap NSEC3 iterations to a safe value. Do you have data you can share on the prevalence of high iteration count NSEC3 zones? -Puneet On Thu, Apr 1, 2021 at 9:42 AM Viktor Dukhovni wrote: > RFC 5155 defined NSEC3 iterations to scale up with the RSA/DSA key size > up to perhaps as high as 2500 iterations for 4096-bit keys. In > retrospect such a generous iteration cap is counter-productive. It is > neither particularly effective at keeping your zone content "secret", > nor sufficiently cheap to avoid negative impact on authoritative and > iterative resolver performance. > > In that light, Wes Hardaker and I have authored an Internet-Draft that > strongly recommends setting the NSEC3 additional iteration count to 0 > (at least one initial SHA1 hash is always performed). > > https://tools.ietf.org/html/draft-hardaker-dnsop-nsec3-guidance-02 > > Today, the Knot resolver became the first one to cap NSEC3 iterations > for now at 150, but this will likely be reduced further (perhaps > ultimately as low as ~25): > > https://gitlab.nic.cz/knot/knot-resolver/-/tags/v5.3.1 > > and is expected to be done by more resolvers. > > Since iteration counts above the resolver cap make denial-of-existence > for the entire zone insecure, it is important that all domains with a > high NSEC3 iteration count proactively lower it ideally to 0, but > otherwise ~10 or less. > > While DNSSEC still precludes forged positive answers, any signed > NXDomain or NODATA NSEC3 response can be replayed for any query, > regardless of the qname. > > This impacts any protocol in which negative responses have security > consequences. Potential exposures include: > > - Forged absence of RFC7672 DANE SMTP TLSA records > - Forged absence of CAA records > - Forged absence of HTTPS records enabling various downgrades > - ... > > A number of TLDs have already lowred their iteration counts, and it is > expected that most of the rest will follow soon. > > TLD before after > --- ------ ----- > la 150 1 > xn--q7ce6a 150 1 > blue 100 10 > green 100 10 > lat 100 10 > mx 100 10 > pink 100 10 > red 100 10 > schaeffler 100 10 > by 100 3 > creditunion 100 3 > ally 100 1 > autos 100 1 > boats 100 1 > homes 100 1 > motorcycles 100 1 > yachts 100 1 > > If your DNS zone is configured to use NSEC3, please: > > - Reduce the iteration count to 10 or less. > > - Disable opt-out, you're very unlikely to need it. > > - Either rotate the salt each time you sign, or skip > it entirely. But a short fixed salt is harmless if > leaving it alone easier than changing it. > > Of course, if your zone is small enough (just the zone apex and a > handful of already public or easy to guess names) or in any case has > nothing to hide, even better is to use just plain NSEC. You get smaller > negative replies (less exposure to DoS) and more effective negative > caching at resolvers. So in many cases, it is even simpler to abandon > NSEC3 entirely. Please also consider the pros/cons of that option. > > -- > Viktor. > _______________________________________________ > dns-operations mailing list > dns-operations at lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Fri Apr 16 18:56:50 2021 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Fri, 16 Apr 2021 14:56:50 -0400 Subject: [dns-operations] IMPORTANT: Please ensure your NSEC3 iteration count is sufficiently low In-Reply-To: References: <3AC8C6BC-6B75-4CBB-8076-1711DDB4616F@sys4.de> <607F46B6-2B13-4B2E-9AB8-D637F95F173D@dukhovni.org>

Message-ID: On Fri, Apr 16, 2021 at 02:29:07PM -0400, Puneet Sood via dns-operations wrote: > Google Public DNS is also planning to cap NSEC3 iterations to a safe value. > Do you have data you can share on the prevalence of high iteration count > NSEC3 zones? Sure, below are the absolute, percentile, and cumulative percentile frequencies by iteration count for ~10.9 million domains using NSEC3. The cumulative numbers are from 0 iterations up, but the table below is in reverse order, showing the high iterations first, I hope that's not too confusing. The suggested cutoff is presently at 150, with just 279 zones out of 10.9 million using more than 150 iterations. #iters #zones %zones cumulative% ------ ------ ------ ----------- 4096 1 0.0000 100.0000 2500 3 0.0000 100.0000 2000 1 0.0000 100.0000 1600 50 0.0005 100.0000 1337 2 0.0000 99.9995 1024 1 0.0000 99.9995 500 67 0.0006 99.9995 487 1 0.0000 99.9989 423 1 0.0000 99.9988 400 6 0.0001 99.9988 360 1 0.0000 99.9988 333 3 0.0000 99.9988 330 56 0.0005 99.9987 300 4 0.0000 99.9982 250 61 0.0006 99.9982 200 3 0.0000 99.9976 197 1 0.0000 99.9976 177 17 0.0002 99.9976 ----------- suggested cutoff ------------- 150 5070 0.0464 99.9974 149 21 0.0002 99.9510 128 6 0.0001 99.9508 127 2956 0.0271 99.9508 120 1 0.0000 99.9237 107 15 0.0001 99.9237 101 1 0.0000 99.9236 100 978251 8.9571 99.9236 99 5 0.0000 90.9665 96 1 0.0000 90.9664 90 20 0.0002 90.9664 85 26 0.0002 90.9662 81 8 0.0001 90.9660 80 1 0.0000 90.9659 75 33 0.0003 90.9659 69 1 0.0000 90.9656 64 16 0.0001 90.9656 55 1 0.0000 90.9654 54 1 0.0000 90.9654 53 1 0.0000 90.9654 52 18 0.0002 90.9654 51 1 0.0000 90.9652 50 11837 0.1084 90.9652 43 1 0.0000 90.8569 42 16 0.0001 90.8568 40 50605 0.4634 90.8567 35 12 0.0001 90.3933 34 1 0.0000 90.3932 33 697 0.0064 90.3932 32 74 0.0007 90.3868 31 4 0.0000 90.3862 30 12 0.0001 90.3861 25 27 0.0002 90.3860 24 66 0.0006 90.3858 23 20 0.0002 90.3852 22 4 0.0000 90.3850 21 5383 0.0493 90.3849 20 510107 4.6707 90.3357 19 5 0.0000 85.6650 18 8 0.0001 85.6649 17 13 0.0001 85.6649 16 14801 0.1355 85.6648 15 4113 0.0377 85.5292 14 19 0.0002 85.4916 13 88 0.0008 85.4914 12 302246 2.7674 85.4906 11 106 0.0010 82.7232 10 1204263 11.0265 82.7222 9 40 0.0004 71.6957 8 1168469 10.6988 71.6953 7 25308 0.2317 60.9965 6 55 0.0005 60.7648 5 1366608 12.5130 60.7643 4 40 0.0004 48.2513 3 28243 0.2586 48.2509 2 3816 0.0349 47.9923 1 5234737 47.9305 47.9574 0 2933 0.0269 0.0269 -- Viktor. From edward.lewis at icann.org Fri Apr 16 22:06:16 2021 From: edward.lewis at icann.org (Edward Lewis) Date: Fri, 16 Apr 2021 22:06:16 +0000 Subject: [dns-operations] Registration Operations Workshop #10 Message-ID: ROW#10: Register now & submit your proposal June 8th, 2021 | 13:00 - 16:00 UTC | Zoom Video Conference ROW#10 will be held via remote participation on June 8th, 2021, 13:00 - 16:00 UTC. Check additional time zones here. Registration is NOW available at: https://regiops.net/events/row10registration/ ROW's Program Committee has also opened the call for presentation and panel proposals and is interested in: 1. Topic related presentation proposals. 2. Topic suggestions for focused panel discussions. 3. Suggestions for additional topics. In the past, workshops have included discussions focused on Extensible Provisioning Protocol (EPP), WHOIS, Registry Lock, Registration Data Access Protocol (RDAP) and many more. Below is a non-exhaustive list of possible topics for this session. ? RDAP implementation experience ? DNS abuse ? DNS privacy and encryption ? Differentiated access ? Authentication and authorization ? Credential Security/Credential Management ? DNSSEC operationalization (CSYNC, managing transfers of secured domains) ? Registration support functions (data escrow/business continuity) ? Automation ? Other innovative uses for registration and resolution technologies Please email a short abstract describing your proposal to row at viagenie.ca We also encourage discussions/suggestions for additional topics on ROW?s mailing list regiops at googlegroups.com. Important dates: ? Deadline to submit proposals: May 14th, 2021 ? Program Committee to notify selected authors by May 21st, 2021 ? Speaker agreements and materials required from selected presenters by May 31st, 2021 We hope that you can join us and request that you disseminate this Call to other lists where it might be of interest. ROW Program Committee Stay tuned for further updates! Follow @ROW_by_Viagenie ROW website: http://regiops.net Contact us: row at viagenie.ca ROW mailing list: regiops at googlegroups.com ROW series: co-sponsored by Verisign & ICANN, organized by Viagenie (cross-posting to multiple lists - sorry for any duplicates) -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at kumari.net Sat Apr 17 14:43:27 2021 From: warren at kumari.net (Warren Kumari) Date: Sat, 17 Apr 2021 10:43:27 -0400 Subject: [dns-operations] IMPORTANT: Please ensure your NSEC3 iteration count is sufficiently low In-Reply-To: References: <3AC8C6BC-6B75-4CBB-8076-1711DDB4616F@sys4.de> <607F46B6-2B13-4B2E-9AB8-D637F95F173D@dukhovni.org>

Message-ID: On Fri, Apr 16, 2021 at 3:04 PM Viktor Dukhovni wrote: > On Fri, Apr 16, 2021 at 02:29:07PM -0400, Puneet Sood via dns-operations > wrote: > > > Google Public DNS is also planning to cap NSEC3 iterations to a safe > value. > > Do you have data you can share on the prevalence of high iteration count > > NSEC3 zones? > > Sure, below are the absolute, percentile, and cumulative percentile > frequencies by iteration count for ~10.9 million domains using NSEC3. > The cumulative numbers are from 0 iterations up, but the table below is > in reverse order, showing the high iterations first, I hope that's not > too confusing. > > The suggested cutoff is presently at 150, with just 279 zones out of > 10.9 million using more than 150 iterations. Thank you for doing this work - it?s helpful. Do you happen to have the list of the 279 anywhere? I realize that it *shouldn?t* matter, but if some of these are really ?popular? domains the calculation is different to them being domains which get almost no traffic. Also, perhaps we can do some outreach to the affected domains if easy? W > > #iters #zones %zones cumulative% > ------ ------ ------ ----------- > 4096 1 0.0000 100.0000 > 2500 3 0.0000 100.0000 > 2000 1 0.0000 100.0000 > 1600 50 0.0005 100.0000 > 1337 2 0.0000 99.9995 > 1024 1 0.0000 99.9995 > 500 67 0.0006 99.9995 > 487 1 0.0000 99.9989 > 423 1 0.0000 99.9988 > 400 6 0.0001 99.9988 > 360 1 0.0000 99.9988 > 333 3 0.0000 99.9988 > 330 56 0.0005 99.9987 > 300 4 0.0000 99.9982 > 250 61 0.0006 99.9982 > 200 3 0.0000 99.9976 > 197 1 0.0000 99.9976 > 177 17 0.0002 99.9976 > ----------- suggested cutoff ------------- > 150 5070 0.0464 99.9974 > 149 21 0.0002 99.9510 > 128 6 0.0001 99.9508 > 127 2956 0.0271 99.9508 > 120 1 0.0000 99.9237 > 107 15 0.0001 99.9237 > 101 1 0.0000 99.9236 > 100 978251 8.9571 99.9236 > 99 5 0.0000 90.9665 > 96 1 0.0000 90.9664 > 90 20 0.0002 90.9664 > 85 26 0.0002 90.9662 > 81 8 0.0001 90.9660 > 80 1 0.0000 90.9659 > 75 33 0.0003 90.9659 > 69 1 0.0000 90.9656 > 64 16 0.0001 90.9656 > 55 1 0.0000 90.9654 > 54 1 0.0000 90.9654 > 53 1 0.0000 90.9654 > 52 18 0.0002 90.9654 > 51 1 0.0000 90.9652 > 50 11837 0.1084 90.9652 > 43 1 0.0000 90.8569 > 42 16 0.0001 90.8568 > 40 50605 0.4634 90.8567 > 35 12 0.0001 90.3933 > 34 1 0.0000 90.3932 > 33 697 0.0064 90.3932 > 32 74 0.0007 90.3868 > 31 4 0.0000 90.3862 > 30 12 0.0001 90.3861 > 25 27 0.0002 90.3860 > 24 66 0.0006 90.3858 > 23 20 0.0002 90.3852 > 22 4 0.0000 90.3850 > 21 5383 0.0493 90.3849 > 20 510107 4.6707 90.3357 > 19 5 0.0000 85.6650 > 18 8 0.0001 85.6649 > 17 13 0.0001 85.6649 > 16 14801 0.1355 85.6648 > 15 4113 0.0377 85.5292 > 14 19 0.0002 85.4916 > 13 88 0.0008 85.4914 > 12 302246 2.7674 85.4906 > 11 106 0.0010 82.7232 > 10 1204263 11.0265 82.7222 > 9 40 0.0004 71.6957 > 8 1168469 10.6988 71.6953 > 7 25308 0.2317 60.9965 > 6 55 0.0005 60.7648 > 5 1366608 12.5130 60.7643 > 4 40 0.0004 48.2513 > 3 28243 0.2586 48.2509 > 2 3816 0.0349 47.9923 > 1 5234737 47.9305 47.9574 > 0 2933 0.0269 0.0269 > > -- > Viktor. > _______________________________________________ > dns-operations mailing list > dns-operations at lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > -- Perhaps they really do strive for incomprehensibility in their specs. After all, when the liturgy was in Latin, the laity knew their place. -- Michael Padlipsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Sat Apr 17 16:30:57 2021 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sat, 17 Apr 2021 12:30:57 -0400 Subject: [dns-operations] IMPORTANT: Please ensure your NSEC3 iteration count is sufficiently low In-Reply-To: References: <3AC8C6BC-6B75-4CBB-8076-1711DDB4616F@sys4.de> <607F46B6-2B13-4B2E-9AB8-D637F95F173D@dukhovni.org>

Message-ID: > On Apr 17, 2021, at 10:43 AM, Warren Kumari wrote: > > Do you happen to have the list of the 279 anywhere? Yes. I sent the full dossier off-list to Puneet. I'll resend you a copy. Few are broadly popular, but not all are complete unknowns. The only ones with an "Alexa rank" (recentish snapshot of the Tranco list) are: Zone Tranco# Iters ---- ------- ----- photon.com 8300 500 raytheon.com 13880 500 unitymedia.de 28724 330 posteo.de 44277 250 uneb.br 66247 330 bbn.com 93451 500 unity-mail.de 205975 330 kabelbw.de 354397 330 phst.at 636940 250 gender-summit.com 674579 500 unity-mail.com 783623 330 Of the above: - posteo.de is a small to midsize email provider in Germany. An early DANE adopter. The are multiple posteo.* domains with other TLD suffixes, but these don't show up on Tranco. - kabelbw.de, unity-mail.com, unitymedia.de is a cable broadband+email provider in Germany, also an early DANE adopter. - uneb.br is a university in Brazil - phst.at is a teacher training school in Austria. I've already reached out to posteo.de and unitymedia.de via my contacts at sys4.de, I hope they'll take appropriate action soon, but feel free to ping them separately, they may expedite remediation. Grouped by SOA mname, the top 10 zone counts (224 total) are: 51 ns01.posteo-dns.de # posteo.de ... 48 ns01.3s-dns.de # 3sdns.de, 3shosting.de, 3smail.de ... 45 dfw-infma1.ext.ray.com # photon.com, raytheon.com, bbn.com ... 36 ns1.upc.biz # unitymedia.de ... 15 jupiter.cloud1500.com # caffari.net ... 7 ns5.dnsmadeeasy.com # webactive.ch ... 6 dns01.consistec.de # consistec.de ... 6 devnull.itsynergy.net.uk # gender-summit.com, itsynergy.net.uk ... 5 ns1.vnode.net # vnode.net ... 5 ns1.phst.at # phst.at ... The below are somewhat more exposed to forgery via negative responses, because they also have a zone apex wildcard record, so any name can be denied and the wildcard substituted (which may not be a problem if the data's the same). *.itsspasadena.com. IN A 199.46.197.68 *.rispasadena.com. IN A 199.46.197.68 *.ybti.net. IN CNAME ybti.net. ybti.net. IN A 212.12.48.75 *.unitymediabusiness.de. IN A 68.183.242.60 *.posteo.de. IN A 89.146.220.134 *.initramfs.io. IN CNAME initramfs.io. initramfs.io. IN A 36.227.174.26 *.dwreports.com. IN A 208.81.182.169 -- Viktor. From paul.hoffman at icann.org Sat Apr 17 16:53:40 2021 From: paul.hoffman at icann.org (Paul Hoffman) Date: Sat, 17 Apr 2021 16:53:40 +0000 Subject: [dns-operations] [Ext] IMPORTANT: Please ensure your NSEC3 iteration count is sufficiently low In-Reply-To: References: <3AC8C6BC-6B75-4CBB-8076-1711DDB4616F@sys4.de> <607F46B6-2B13-4B2E-9AB8-D637F95F173D@dukhovni.org>

Message-ID: OK, I know this is trivial, but: > bbn.com 93451 500 Stephen Kent. Just sayin'.... --Paul Hoffman -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2584 bytes Desc: not available URL: From jtk at dataplane.org Mon Apr 19 02:50:10 2021 From: jtk at dataplane.org (John Kristoff) Date: Sun, 18 Apr 2021 21:50:10 -0500 Subject: [dns-operations] DNS over TCP - operational requirements draft Message-ID: <20210418215010.36de58f0@p50.localdomain> Friends, In case you're not on the IETF dnsop list, this draft needs to either move forward or be abandoned. If you feel free strongly about it one way or the other, now would be a good time to state your position to the dnsop WG. John From davidb at verisign.com Mon Apr 19 13:26:20 2021 From: davidb at verisign.com (Blacka, David) Date: Mon, 19 Apr 2021 13:26:20 +0000 Subject: [dns-operations] [Ext] Historical reminiscences (was Re: nsec vs nsec3 use) In-Reply-To: <24695.29720.208500.988291@gro.dd.org> References: <20210412221705.GC2257521@millbarge> <63D2B367-442E-4745-BC20-DB437AD5BD3A@dukhovni.org> <20210413233353.m2juue7fbpt5636l@crankycanuck.ca> <6DDAD39C-85B4-46B9-B20A-2AC814805F0D@icann.org> <24695.29720.208500.988291@gro.dd.org> Message-ID: As someone who was closely involved at the time, and as one of the editors of RFC5155, I can assure you that Verisign's decision to use NSEC3 was not in any way related to GDPR, privacy, or zone-walking. Optionality was (and remains) a requirement for signing the .COM zone due to its size. We could've signed with NSEC if the "opt-in" feature had become a part of the standard. But NSEC opt-in was rejected and so we embraced NSEC3 with opt-out. -- David Blacka Verisign Fellow Product Engineering ?On 4/14/21, 7:10 PM, "dns-operations on behalf of Dave Lawrence" wrote: Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. To me, Andrew's retelling of the facts but for the emphasis. There's stated reasons, then there's the motivating reasons. GDPR was useful in making the argument, but Verisign and the pain of .com were the real motivation. _______________________________________________ dns-operations mailing list dns-operations at lists.dns-oarc.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4817 bytes Desc: not available URL: From denesh at dns-oarc.net Wed Apr 21 12:29:54 2021 From: denesh at dns-oarc.net (Denesh Bhabuta :: DNS-OARC) Date: Wed, 21 Apr 2021 13:29:54 +0100 Subject: [dns-operations] OARC 35 Agenda published Message-ID: Dear colleagues The agenda for the OARC 35 (taking place in an Asia Pacific friendly timezone) is now published! OARC 32 is now only 2 weeks away. It will take place on May 6th & 7th and will start at 01:00 UTC each day and end around 06:00 UTC on both days. The Agenda / Schedule along with the summary of each talk is published on the meeting website at: Registration == Attending DNS-OARC Workshops is open to all OARC members and other parties interested in DNS operations and research. Attending OARC 35 is on a paid registration basis. The non-member fee is US$150. The active points of contact in the OARC member organizations have already received the code for discounted registration. Registration fee waivers are available for the workshop to support those who are part of under-represented groups at DNS-OARC. See the registration page on the main OARC 35 website for details. OARC 35 Blog: OARC 35 website: Hope to see you there! Regards Denesh