September 2024 - BALUG-Admin

DNSSEC - some key changes, e.g.: Re: sflug.org sig
by Michael Paoli 29 Sep '24

29 Sep '24

+BALUG-Admin Al, Thanks for noticing! Did some DNSSEC key rollovers, notably changing in bind 1:9.18.28-1~deb12u2 from: auto-dnssec maintain (auto-dnssec is deprecated/obsolete and will be going away in future) to: dnssec-policy and related changes. "Of course" starting with non-canonical less critical domains. Yeah, if one goofs with that transition, DNSSEC can get messed up and cause some failures (at least for a wee bit, notably depending upon caching and relevant TTLs). Was "only" mostly just rolling some ZSKs (and adding KSKs some), so even there damage rather limited in scope (notably also time). Still, there ought not be hiccups. switching from auto-dnssec maintain to dnssec-policy is a bit persnickety/hazardous (found that out many moons ago with my very first such transition), notably any existing keys not compatible with such policy when one switches from auto-dnssec maintain to dnssec-policy are summarily ejected ... and that can be a (quite) bad thing. So, pretty careful but still, not sure exactly why, but for some zones it instantly dropped the old ZSK, whereas for others it did the much more expected rollover - adding the new, doing the relevant additional signings, waiting the requisite TTL times, and only then dropping the then vestigial old. Not 100% sure what's made that difference between the domains. Some are exact same gTLD and key types and sizes, and dnssec-policy and procedures, etc. used, yet still seeing somewhat different results. E.g. on sflug.com. vs. sf-lug.com. See also: https://dnsviz.net/ Can also there view the older (where saved) DNSSEC data too. Domains that have thus far had such changes in the last day or two: Thus far mostly worked on: (non-canonicals and less critical): e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa sf-lug.com sflug.com savingthedolph.in sf-lug.net sflug.net digitalwitness.org sflug.org And will probably hold off on these 'till all such kinks are worked out: sf-lug.org berkeleylug.com balug.org Longer term bit 'o plan is to not only get all of the auto-dnssec maintain config bits updated to dnssec-policy, but also at least rotate the ZSKs if they've not been rotated in a while (ought get rotated about monthly - and they may or may not have been already doing that), and then work up to KSKs. KSKs probably ought get rotated about yearly or so, but looks like most all of 'em are 4+ years old. No extreme rush or anything, but they could use wee bit of attention ... and also not - at least thus far - critical. Also, if/where registrars have implemented RFC 7344 that should make things way easier to handle that part of it. Hmmm, and just a little while ago I blew away delegated subdomain that I'd much earlier used for some such testing ... maybe time for some more such testing to get to the bottom of the matter. And if one's curious, that version of bind's default provided configurations for that: $ named -C | sed -ne '/^dnssec-policy "default" {$/,/^};$/{/^$/d;p};/^dnssec-policy "insecure" {$/,/^};$/{p;/^};$/q}' | expand dnssec-policy "default" { keys { csk key-directory lifetime unlimited algorithm 13; }; dnskey-ttl 3600; publish-safety 3600; retire-safety 3600; purge-keys P90D; signatures-jitter PT12H; signatures-refresh P5D; signatures-validity P14D; signatures-validity-dnskey P14D; max-zone-ttl 86400; zone-propagation-delay 300; parent-ds-ttl 86400; parent-propagation-delay 3600; }; dnssec-policy "insecure" { max-zone-ttl 0; keys { }; }; Here's what I've presently got, and some related notes: // as of 2024-09-23: // TTL algorithm zsk bits ksk bits // default parent DS 86400 13 // 4.0.1.0.0.2.ip6.arpa DNSKEY 86400 8 2048 1024 // com parent DS 86400 13 // in parent DS 3600 8 2048 1024 // net parent DS 86400 13 // org parent DS 3600 8 2048 1024 dnssec-policy "my_8_2048_1024" { # legacy keys { ksk key-directory lifetime unlimited algorithm 8 2048; zsk key-directory lifetime 30d algorithm 8 1024; }; nsec3param; }; dnssec-policy "my_13_8_2048_1024" { # transition keys { ksk key-directory lifetime unlimited algorithm 13; zsk key-directory lifetime 30d algorithm 13; ksk key-directory lifetime unlimited algorithm 8 2048; zsk key-directory lifetime 30d algorithm 8 1024; }; nsec3param; }; dnssec-policy "my_8_2048_1024_ds_ttl_3600" { # in org keys { ksk key-directory lifetime unlimited algorithm 8 2048; zsk key-directory lifetime 30d algorithm 8 1024; }; parent-ds-ttl 3600; nsec3param; }; dnssec-policy "my_default" { keys { ksk key-directory lifetime unlimited algorithm 13; zsk key-directory lifetime 30d algorithm 13; }; nsec3param; }; And thus far, on that primary, these are the domains that have dnssec-policy and the policy they're set to: my_8_2048_1024 e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa my_13_8_2048_1024 sf-lug.com my_13_8_2048_1024 sflug.com my_8_2048_1024_ds_ttl_3600 savingthedolph.in my_13_8_2048_1024 sf-lug.net my_13_8_2048_1024 sflug.net my_8_2048_1024_ds_ttl_3600 digitalwitness.org my_8_2048_1024_ds_ttl_3600 sflug.org $ On Mon, Sep 23, 2024 at 10:53 PM Al <aw009(a)sunnyside.com> wrote: > > On the way to bed, and no time to really dig into this now. I'll have > to have a better look tomorrow. > Seems like something is amiss on my ns0 (aka nsx) but not on ns1 or ns2 > (aka nsy). (all .sunnyside.com) > > ns0/nsx sample logs: > root@post:/var/log/named# tail -f *.log | grep -i sflug > 23-Sep-2024 22:39:25.360 lame-servers: info: lame server resolving > 'sflug.org' (in 'sflug.org'?): 2603:3024:180d:f100:50:242:105:34#53 > 23-Sep-2024 22:39:25.368 lame-servers: info: insecurity proof failed > resolving 'sflug.org/NS/IN': 2001:470:1f04:51a::2#53 > 23-Sep-2024 22:39:25.392 lame-servers: info: lame server resolving > 'sflug.org' (in 'sflug.org'?): 2600:1f1c:528:c500:5e0b:8a37:6598:356c#53 > 23-Sep-2024 22:39:25.416 lame-servers: info: no valid RRSIG resolving > 'sflug.org/NS/IN': 2001:470:1f05:19e::3#53 > 23-Sep-2024 22:39:25.440 lame-servers: info: no valid RRSIG resolving > 'sflug.org/NS/IN': 96.95.217.99#53 > 23-Sep-2024 22:39:25.440 lame-servers: info: lame server resolving > 'sflug.org' (in 'sflug.org'?): 50.242.105.52#53 > 23-Sep-2024 22:39:25.456 lame-servers: info: no valid RRSIG resolving > 'sflug.org/NS/IN': 198.144.194.12#53 > 23-Sep-2024 22:39:25.476 lame-servers: info: lame server resolving > 'sflug.org' (in 'sflug.org'?): 50.18.139.240#53 > 23-Sep-2024 22:39:25.504 lame-servers: info: no valid RRSIG resolving > 'sflug.org/NS/IN': 96.86.170.229#53 > 23-Sep-2024 22:39:25.368 dnssec: info: view internal: validating > sflug.org/NS: no valid signature found > 23-Sep-2024 22:39:25.416 dnssec: info: view internal: validating > sflug.org/NS: no valid signature found > 23-Sep-2024 22:39:25.440 dnssec: info: view internal: validating > sflug.org/NS: no valid signature found > 23-Sep-2024 22:39:25.456 dnssec: info: view internal: validating > sflug.org/NS: no valid signature found > 23-Sep-2024 22:39:25.504 dnssec: info: view internal: validating > sflug.org/NS: no valid signature found > > All three machines show: > sf-lug.org. 3591 IN SOA ns0.sf-lug.org. > Michael\.Paoli.berkeley.edu. 1727012375 10800 3600 3600000 86400 > > so at least they should be in sync. > > I got this failure: > al@post:/z/dns$ dig ns sflug.org > > ; <<>> DiG 9.16.6 <<>> ns sflug.org > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 27626 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 1472 > ; COOKIE: 6b64e1cd9d59aeff0100000066f2508d5ba5e929bf62035f (good) > ;; QUESTION SECTION: > ;sflug.org. IN NS > > ;; Query time: 155 msec > ;; SERVER: 192.147.248.10#53(192.147.248.10) > ;; WHEN: Mon Sep 23 22:39:25 PDT 2024 > ;; MSG SIZE rcvd: 66 > > > But a few minutes later it was fine. So whatever it is, it's intermittent. > > More later... > Al

1 5

Comcast & the 5353 workaround --> 2025-06-05
by Michael Paoli 23 Sep '24

23 Sep '24

So, I'd much earlier noted on my calendar: 2024-09-24 >= 10:56AM US/Pacific PST8PDT -07:00, if Comcast Business hasn't screwed up DNS with linuxmafia.com for more than a year, probably time to remove the port 5353 work-arounds. But, I don't think (year earlier) was necessarily the last of those Comcast DNS issues. So, last I see that hints of that is chatter/discussions that tapered off around 2024-06-04 https://lists.balug.org/mailman3/hyperkitty/list/balug-admin@lists.balug.or… So, as earlier, since wasn't our first go-round, I'll push the end date of that work-around to >~=2025-06-05 and if it's by then had no more such glitches, will then drop that work-around. In the meantime, doesn't really hurt hardly anything, and easier to already have that workaround in place, should it be needed at all before then. So, calendar updated: 2025-06-25 if Comcast Business hasn't screwed up DNS with linuxmafia.com for more than a year, probably time to remove the port 5353 work-arounds.

1 0

mailman3 (re)start bug/issue #1174 https://gitlab.com/mailman/mailman/-/issues/1174
by Michael Paoli 19 Sep '24

19 Sep '24

After unclean shutdown of mailman3, even when (re)started with start --force mailman3 may fail to remove the lock files and thus fail to (re)start. Details on (I submitted as): https://gitlab.com/mailman/mailman/-/issues/1174 I'm definitely not the first person to have noticed this issue. Hopefully they'll get around to fixing it (it's been over 9 years ... but they may have lacked sufficient relevant detail in the earlier reports). Manual workaround: remove the lock files in /var/lib/mailman3/locks/ after checking to ensure that none of them reference and/or are used by any PID(s) still relevant to mailman3

2 1

list acceptance/moderation and balug-announc@lists.balug.org hold --> discard for most users
by Michael Paoli 07 Sep '24

07 Sep '24

One thing I do like about Mailman 3 is all the available message acceptance settings, both for list default, and per user. Those include: List default -- follow the list's default member action. Hold -- This holds the message for approval by the list moderators. Reject -- this automatically rejects the message by sending a bounce notice to the post's author. The text of the bounce notice can be configured by you. Discard -- this simply discards the message, with no notice sent to the post's author. Accept -- accepts any postings without any further checks. Default Processing -- run additional checks and accept the message. Most notably - Discard highly useful to set non-members to Discard. Likewise for moderated list(s) where few are allowed to post (e.g. balug-announce(a)lists.balug.org) Makes listadmin life fair bit easier, as most all such posting attempts, that would otherwise be held for moderation on Mailman 2, can be simply discarded, as almost all of them are junk/garbage/spam and the like - maybe only about once a year or so does a legitimate message come in that way. And Reject really isn't that useful, as that happens after the email has already been received, rather than at SMTP time, so there would be backscatter issues with that (the overwhelming number of such mail is spam, and those are typically rather to quite forged senders, victim compromised accounts, etc.). And ... not sure exactly how much I (dis)like it on Mailman 3, but Mailman 2 data was mostly in python 2 pickle (.pck) format files, with data/configuration bits also being in flat (and also html) files. Well, Mailman 3, while some configuration bits are stored in flat configuration files, for better and/or worse, most of the data is stored in an actual relatively proper database (e.g. sqlite). So, balug-announce(a)lists.balug.org e.g. imported from Mailman 2, most all users had the moderation set to hold (Mailman 2 didn't have a discard option). On Mailman 3 I set the list default to discard for that list. But almost all users were imported from Mailman 2 and that import preserved their hold setting. I wanted to change it for those users to the list default (discard). A bit to chase it down in the database, but once found and reasonably tested, one SQL statement to do the needed: UPDATE member SET moderation_action = NULL WHERE list_id = 'balug-announce.lists.balug.org' and moderation_action = 0; ... and with that done for 492 users. Yay!(?) Not super easy/pleasant but ... well, compared to Mailman 2, yeah I think it's at least fair bit better than Mailman 2, at least on that point/feature/capability.

1 0

balug.org domain renewed, now expires 2025-09-22T04:00:00Z
by Michael Paoli 02 Sep '24

02 Sep '24

balug.org domain renewed $ whois balug.org 2>&1 | fgrep -i expir Registry Expiry Date: 2025-09-22T04:00:00Z $

1 0

BALUG: Lists, stats, etc.
by Michael Paoli 01 Sep '24

01 Sep '24

dates, lists, number of members: YYYY-MM-DD announce talk admin 2024-08-01 497 232 32 2024-07-01 497 232 32 2024-06-01 498 231 33 2024-05-01 499 231 33 2024-04-01 500 230 33 2024-03-01 498 230 33 2024-02-01 499 229 33 2024-01-01 497 227 31 2023-12-01 497 227 32 2023-11-01 496 249 32 2023-10-01 496 248 32 2023-09-01 497 248 32 2023-08-01 498 248 32 2023-07-01 500 248 32 2023-06-01 501 249 32 2023-05-01 501 249 32 2023-04-01 501 249 32 2023-03-01 501 249 32 2023-02-01 501 249 32 2023-01-01 500 249 32 2022-12-01 520 249 32 2022-11-01 564 249 32 2022-10-01 589 249 32 2022-09-01 589 249 33 2022-08-01 616 249 33 2022-07-01 834 260 35 2022-06-01 832 259 35 2022-05-01 832 259 35 2022-04-01 832 259 35 2022-03-01 833 259 35 2022-02-01 833 259 35 2022-01-01 833 258 35 2021-12-01 832 257 35 2021-11-01 831 257 35 2021-10-01 832 257 35 2021-09-01 832 257 35 2021-08-01 832 257 35 2021-07-01 832 257 35 2021-06-01 832 256 35 2021-05-01 833 257 35 2021-04-01 832 259 35 2021-03-01 833 259 35 2021-02-01 833 259 35 2021-01-01 833 259 35 2020-12-01 832 259 35 2020-11-01 833 260 35 2020-10-01 834 260 35 2020-09-01 835 260 35 2020-08-01 834 259 34 2020-07-01 834 266 34 2020-06-01 838 266 34 2020-05-01 839 267 34 2020-04-01 840 270 34 2020-03-01 840 271 34 2020-02-01 841 271 34 2020-01-01 841 271 34 2019-12-01 841 271 34 2019-11-01 840 271 34 2019-10-01 842 271 34 2019-09-01 844 272 34 2019-08-01 847 272 34 2019-07-01 852 272 36 2019-06-01 854 273 37 2019-05-01 856 272 38 2019-04-01 853 273 38 2019-03-01 851 273 38 2019-02-01 853 273 38 2019-01-01 856 274 38 2018-12-01 858 274 38 2018-11-01 861 274 39 2018-10-02 862 274 39 2018-09-01 864 274 38 2018-07-28 866 278 38 2018-06-08 870 282 38 2018-04-28 875 282 38 2018-02-17 880 283 36 2017-11-04 883 284 36 2017-08-19 897 293 37 2017-07-01 897 297 38 2017-05-27 897 297 38 2017-05-16 897 296 38 2017-04-01 896 297 38 2017-03-30 885 297 38 2016-05-03 886 291 39 2016-04-03 887 290 39 2016-03-05 888 291 45 2016-01-05 887 295 45 2015-12-05 887 296 45 2015-11-07 887 301 45 2015-10-06 888 301 45 2015-09-05 887 301 45 2015-08-04 888 301 45 2015-07-03 888 300 45 2015-06-05 888 301 46 2015-05-02 885 298 45 2015-04-04 884 297 44 2015-03-07 886 298 44 2015-02-06 885 303 44 2015-01-07 885 304 45 2014-12-06 886 304 45 2014-11-01 884 302 45 2014-10-04 881 303 46 2014-09-06 878 309 44 2014-06-13 875 307 44 2014-05-02 874 306 44 2014-04-04 876 306 44 2014-03-01 876 306 43 2014-01-11 872 305 42 2013-10-05 854 293 40 2013-08-31 855 295 41 2013-07-20 852 297 40 2013-04-10 838 286 41 2013-03-03 841 289 41 2013-02-02 843 291 41 2012-12-15 845 310 41 2012-03-23 818 310 39 2012-02-01 813 307 40 2011-04-28 768 291 37 2011-02-27 762 288 36 2010-05-02 730 289 34 2010-04-01 727 291 33 2010-03-16 727 293 33 2009-12-16 716 290 33 2009-09-09 700 288 32 2009-03-27 677 287 29 2009-01-10 662 290 30 2008-08-17 635 290 29 2008-03-03 571 247 28 2008-01-02 337 260 28 2007-12-28 336 261 28 2007-09-03 264 258 27 2007-07-24 287 256 27 2007-06-17 280 249 27 references: http://www.balug.org/#Lists

1 0