On 11 October the root of the DNS switches to a new signing key, called KSK-2024. It's only the second time this has happened. The first was in October 2018.
In plain words: DNSSEC lets a resolver check that a DNS answer is real. Every check starts from one key at the top, the root key. Resolvers keep a copy of it, called the trust anchor. If a validating resolver doesn't have the new key on 11 October, it won't fail on a few lookups. It will fail on all of them (SERVFAIL, for the technical readers).
Who has to act: anyone running their own validating resolver, like BIND, Unbound or PowerDNS Recursor.
Who can relax: anyone using their provider's resolver or a public one. That includes me. My servers use Google (8.8.8.8) and Cloudflare (1.1.1.1), and those operators take care of the new key. My own DNS servers run PowerDNS, but they are authoritative servers. They answer for my domains and don't validate anyone else's, so the root key doesn't touch them. In 2018 I also used public resolvers, and I didn't have to do anything then either.
If you do run your own resolver, check that the new key, key tag 38696, is in your trust anchor file. BIND keeps it in bind.keys, and rndc managed-keys status shows the live state. Unbound and PowerDNS Recursor keep it in root.key. If the key is missing, make sure automatic trust anchor updates are on and that the resolver can write to its storage directory, then follow your vendor's guidance. Don't assume the automatic update worked. Check it.
For a quick visual check, the DNS team at Cloudflare put up a test page at dnstest.dev/ksk-2024. And if every lookup starts failing with SERVFAIL after the 11th, the trust anchor is the first place to look.
For most people, 11 October will be an ordinary Sunday.