DNS is for people, not for IT infrastructure

That framing did not land. The core reaction was that the post confuses “DNS caused the outage” with “a service discovery and dependency failure took down DNS too.” DNS was described as the mature, boring implementation of a problem you still have even if you ban the protocol. Once machines need stable names for moving targets, failover, load balancing, virtual hosting, certificates, mail routing, service records, or just consistent resolution across mixed clients, you are back to service discovery. Replacing pull-based lookups from a few resolvers with push-based updates to every host was seen as strictly worse for all but very small, slow-changing environments. Several people grounded this historically. DNS exists because distributing a shared hosts file stopped scaling in the early Internet, and the same failure mode comes back if you try to revive that model for modern fleets with faster change rates. Others pointed out that many headline incidents cited in the post were not failures of DNS as a protocol or resolver software. They were failures in the systems feeding DNS, or circular dependencies that made DNS part of a much larger blast radius. That shifts the practical lesson. The problem is not “machines should not use DNS.” It is “your control plane should not depend on itself in a way that makes recovery impossible.” The few sympathetic comments only went as far as saying the instinct is understandable if you have debugged nasty DNS loops, and that keeping a few emergency host entries or a bastion reachable without DNS can be smart. Nobody made a convincing case that fleet-wide /etc/hosts management is a better foundation than internal DNS for serious infrastructure.