> you could return garbage (127.0.0.1) with a 5 min ttl

I use 0.0.0.0, though I'm not sure if some layer in that mess would interpret it creatively. Has worked on my machine for years at least:

  $ ping facebook.com
  connect: Invalid argument

(If you do this, please set the TTL to at least a month, and preferably upwards of a decade.)

lots of ISPs straight up ignore ttl

No, the protocol didn't support that when it was first written, and that absence has continued through today. Internet protocols are typically written from the standpoint that the transport/protocol layer handles all this for them, so the real question is how DNS-over-HTTPS can help manage that, since there's no hope of altering classical DNS. Unfortunately, the MDN page for it seems incomplete, so I have no idea how browsers typically handle that header, much less how a DNS resolver's "DNS-over-HTTPS" shim library will. It might be possible to use the QoS functions of HTTP2 or HTTP3 to accept the connection with a receive maxlen of 0 and send the 503 Retry-After at that point. This also assumes a client coded to behave in a kind manner rather than in a greedy manner, which is generally not a safe bet when "time is money" is a factor.

> no hope of altering classical DNS

Does DNS support extensibility?

If so, an option could be responding with a fake answer like 0.0.0.0 + some TTL, plus an extension that tells modern clients "hey, this is actually a SERVFAIL but please cache it for the TTL".

DNS is distributed. thats the problem, you can return nonsense but it might be ignored by the legion of other DNS services that are caching your responses.

because of this there are lots of settings in most servers to ignore and sanitise shitty responses.

Clients should really be using something like exponential backoff ethernet-style.

Just imagine how annoying that would be. Your local resolver has a blip of connectivity and during the time it cannot contact an origin nameserver it burns all of the reasonable retry intervals. After a few seconds its link comes back up but the resolver is still waiting because of "backoff".

Exponential backoff is a really bad antipattern that harms users. There are other, better ways to shed load.

Also, there's no evidence that any DNS infrastructure was overloaded during this event, so what are we even discussing?

6 seconds of wait for a 3-second blip still sounds reasonable.

Not really; if I unplug a cable, connections break; but if I plug it back in they can and should resume much faster than 6 seconds.

And what about a five minute "blip"? Arguably it should resume proper operations as soon as the link goes back up, not some (unknown to user) time afterwards.

Yes but event driven is way different. That should be instant because the software can be told by the system that connectivity was restored and respond immediately since it’s aware of the hardware being plugged in.

What should people use instead of exponential backoff?

Capped Fibonacci backoff with random delay inserted at the cap?