

That enables an amplification attack.
Technically, you’re right.
An amplification attack is just telling the server to respond to a different/wrong ip with the response to a query than the actual asking request. This is solved generally with DNSSEC verifying the origin and requester ips match, if not, the request is dumped.
However, if your authoritative server doesn’t have records for the request, it will simply forward it (if configured to do so) to an upstream and probably hardened server, or drop the request. Either way, it becomes not your problem.
So unless the amplification attack is asking for records your server is actually hosting and for which your server is authoritative, this isn’t a huge concern.


APIs. Or the ends are achieved by sharing data between apps in common data storage. But I prefer to be a tourist in my infrastructure, I no longer hand-bomb changes to systems.
My design pattern is essentially to integrate more and more of the container creation into config. Right now I’m using ansible and it’s nice. More automation means troubleshooting has fewer variables.
I had issues yesterday with a package upgrade across several containers, and it ended up being two config changes. I cycle the apps and done. That’s it.