@vaurora I'll take a stab at it, for what it's worth :
Generally I've adopted the "Defense in Depth" approach.

1 – Block all but the expected inbound traffic as early as possible, in each component. By port, domain, source IP, even whitelist if necessary/possible.
Think “block inbound port 22 if you don’t use it”, in your router component, and kernel packet filter/firewall (BPF/iptables), and even at user-level.
1/x

@vaurora Just one entry for the list: If an OS runs CoAP as a default service (which makes sense for embedded devices), keep up with the update (RFC9175, which I coauthored) as RFC7252 did mandate amplification mitigation but had limited tools for it.
Generalizing, for everything that's on-by-default, check if any layer in that does amplification mitigation in its standards (or explains why it's not needed), and whether the implementation does do it. (DNS is one instance thereof, but not alone).

Clarification: this is for things that an operating system can be configured to do in the default installation, not what you can do with network architecture or intermediate routers - though I will happily listen to your thoughts there!

@vaurora iirc any UDP service can be a source of reflection attacks. It is worse when said service sends lots of data like DNS with DNSSEC. Just limiting recursion is not enough in this case, you need rate limiting for regular queries as well :/

@vaurora
For an end user your pipe is too small to ever withstand a ddos attack, you need an ISP prepared to put in blocks high enough upstream it can cope (good ones can help with this, your typical home ISP likely won't).

In practice for a lot of small businesses they couldn't handle it.

If you've got money you proxy through cloudflare or similar.

Note though it's a fairly unlikely thing to happen for most sites.. your typical widget seller just isn't that interesting to attackers.

@vaurora https://github.com/craig/ddos-book-materials (link in there to where you can buy the book) is an exelent resource