This seems to also fix #1941335

Yeah, it has a patch for that. I forgot to include it in notes though.

Here's dig @127.0.0.53 output for a name that doesn't work (www.google.com), then one that does (fedoraproject.org):

; <<>> DiG 9.11.28-RedHat-9.11.28-1.fc33 <<>> @127.0.0.53 www.google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32195
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.com.            IN  A

;; Query time: 2 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Tue Mar 23 22:20:19 EDT 2021
;; MSG SIZE  rcvd: 32


; <<>> DiG 9.11.28-RedHat-9.11.28-1.fc33 <<>> @127.0.0.53 fedoraproject.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9540
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;fedoraproject.org.     IN  A

;; ANSWER SECTION:
fedoraproject.org.  60  IN  A   10.3.163.76
fedoraproject.org.  60  IN  A   10.3.163.75
fedoraproject.org.  60  IN  A   10.3.163.74

;; Query time: 5 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Tue Mar 23 22:20:23 EDT 2021
;; MSG SIZE  rcvd: 83

Here's resolvectl query output for the same two:

?[0;1;31mwww.google.com: resolve call failed: 'www.google.com' does not have any RR of the requested type?[0m

fedoraproject.org: 10.3.163.74                              -- link: ens4
                   10.3.163.75                              -- link: ens4
                   10.3.163.76                              -- link: ens4

-- Information acquired via protocol DNS in 3.3ms.
-- Data is authenticated: no

Also, oddly, ping 1.1.1.1 works fine but dig @1.1.1.1 anyname fails with "connection timed out; no servers could be reached".

Apologies for the bad version. Please test again. The diff is the first five commits on https://github.com/systemd/systemd-stable/commits/v246-stable.

@zbyszek given the recent general experiences, wouldn't it be sensible to disable autopush for this and future systemd updates, or at least set the threshold higher than +3?

The bad version here was extremely close to going stable and breaking networking for most of our user base, which would've done huge damage to both Fedora's and systemd's reputations.

I've tested that the new build fixes BZ#1941335 and the base test cases pass, and I don't experience any networking issues with this one.

I can verify that this fixes BZ#1941335 in the Europe/Dublin time zone. I'm not leaving overall karma to keep this from getting autopushed.

I did notice that this also fixes the networking errors that I belatedly saw with the previous build.

Seems ok here. No odd networking issues seen.

given the recent general experiences, wouldn't it be sensible to disable autopush for this and future systemd updates, or at least set the threshold higher than +3?

Yes, that's reasonable. I disabled autokarma now.

Works.