Re: [dns-operations] IMPORTANT: Please ensure your NSEC3 iteration count is sufficiently low
> 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 8300500 raytheon.com13880500 unitymedia.de 28724330 posteo.de 44277250 uneb.br 66247330 bbn.com 93451500 unity-mail.de 205975330 kabelbw.de 354397330 phst.at636940250 gender-summit.com 674579500 unity-mail.com 783623330 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. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] IMPORTANT: Please ensure your NSEC3 iteration count is sufficiently low
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% >-- -- -- --- > 40961 0. 100. > 25003 0. 100. > 20001 0. 100. > 1600 50 0.0005 100. > 13372 0. 99.9995 > 10241 0. 99.9995 > 500 67 0.0006 99.9995 > 4871 0. 99.9989 > 4231 0. 99.9988 > 4006 0.0001 99.9988 > 3601 0. 99.9988 > 3333 0. 99.9988 > 330 56 0.0005 99.9987 > 3004 0. 99.9982 > 250 61 0.0006 99.9982 > 2003 0. 99.9976 > 1971 0. 99.9976 > 177 17 0.0002 99.9976 > --- suggested cutoff - > 150 5070 0.0464 99.9974 > 149 21 0.0002 99.9510 > 1286 0.0001 99.9508 > 127 2956 0.0271 99.9508 > 1201 0. 99.9237 > 107 15 0.0001 99.9237 > 1011 0. 99.9236 > 100 978251 8.9571 99.9236 >995 0. 90.9665 >961 0. 90.9664 >90 20 0.0002 90.9664 >85 26 0.0002 90.9662 >818 0.0001 90.9660 >801 0. 90.9659 >75 33 0.0003 90.9659 >691 0. 90.9656 >64 16 0.0001 90.9656 >551 0. 90.9654 >541 0. 90.9654 >531 0. 90.9654 >52 18 0.0002 90.9654 >511 0. 90.9652 >5011837 0.1084 90.9652 >431 0. 90.8569 >42 16 0.0001 90.8568 >4050605 0.4634 90.8567 >35 12 0.0001 90.3933 >341 0. 90.3932 >33 697 0.0064 90.3932 >32 74 0.0007 90.3868 >314 0. 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 >224 0. 90.3850 >21 5383 0.0493 90.3849 >20 510107 4.6707 90.3357 >195 0. 85.6650 >188 0.0001 85.6649 >17 13 0.0001 85.6649 >1614801 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 > 725308 0.2317 60.9965 > 6 55 0.0005 60.7648 > 5 1366608 12.5130 60.7643 > 4 40 0.0004 48.2513 > 328243 0.2586 48.2509 > 2 3816
Re: [dns-operations] IMPORTANT: Please ensure your NSEC3 iteration count is sufficiently low
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% -- -- -- --- 40961 0. 100. 25003 0. 100. 20001 0. 100. 1600 50 0.0005 100. 13372 0. 99.9995 10241 0. 99.9995 500 67 0.0006 99.9995 4871 0. 99.9989 4231 0. 99.9988 4006 0.0001 99.9988 3601 0. 99.9988 3333 0. 99.9988 330 56 0.0005 99.9987 3004 0. 99.9982 250 61 0.0006 99.9982 2003 0. 99.9976 1971 0. 99.9976 177 17 0.0002 99.9976 --- suggested cutoff - 150 5070 0.0464 99.9974 149 21 0.0002 99.9510 1286 0.0001 99.9508 127 2956 0.0271 99.9508 1201 0. 99.9237 107 15 0.0001 99.9237 1011 0. 99.9236 100 978251 8.9571 99.9236 995 0. 90.9665 961 0. 90.9664 90 20 0.0002 90.9664 85 26 0.0002 90.9662 818 0.0001 90.9660 801 0. 90.9659 75 33 0.0003 90.9659 691 0. 90.9656 64 16 0.0001 90.9656 551 0. 90.9654 541 0. 90.9654 531 0. 90.9654 52 18 0.0002 90.9654 511 0. 90.9652 5011837 0.1084 90.9652 431 0. 90.8569 42 16 0.0001 90.8568 4050605 0.4634 90.8567 35 12 0.0001 90.3933 341 0. 90.3932 33 697 0.0064 90.3932 32 74 0.0007 90.3868 314 0. 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 224 0. 90.3850 21 5383 0.0493 90.3849 20 510107 4.6707 90.3357 195 0. 85.6650 188 0.0001 85.6649 17 13 0.0001 85.6649 1614801 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 725308 0.2317 60.9965 6 55 0.0005 60.7648 5 1366608 12.5130 60.7643 4 40 0.0004 48.2513 328243 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@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] IMPORTANT: Please ensure your NSEC3 iteration count is sufficiently low
--- Begin Message --- 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 > lat100 10 > mx 100 10 > pink 100 10 > red100 10 > schaeffler 100 10 > by 100 3 > creditunion100 3 > ally 100 1 > autos 100 1 > boats 100 1 > homes 100 1 > motorcycles100 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@lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] IMPORTANT: Please ensure your NSEC3 iteration count is sufficiently low
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 lat100 10 mx 100 10 pink 100 10 red100 10 schaeffler 100 10 by 100 3 creditunion100 3 ally 100 1 autos 100 1 boats 100 1 homes 100 1 motorcycles100 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@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
