Hacker News new | ask | show | jobs
by gfody 12 days ago
> we'll just use /etc/hosts no DNS required!

this is classic "easy vs. simple" folly, witness how someone too lazy to [learn how to] setup proper DNS for their infrastructure will do 10x the work hacking something "easy"

2 comments

Serious response: how is templating out /etc/hosts with Ansible not 10x simpler than setting up an additional service that only introduces additional risk?
You lose the concept of DNS forwarding. Usually, if your company has example.com, your DNS server is authoritative for example.com, which means it will actually contain (fqdn,ip) entries belonging to example.com, and it will forward requests for other domains to other DNS servers, possibly one DNS server per domain.

If you remove DNS servers from the equation, you need to write down records for other domains, too. This means you have to chase every domain for changes in CDN configuration, hosting provider or ISP migrations, IPv4 to v6 migrations and so on.

You don't have PTR records, which means you can't find out a name from its IP address.

You also miss other features of DNS, like SRV, MX and so on.

More subtly, you lose the ability to control DNS resolution over systems you can't control. If a DNS server says host.example.com is 192.168.0.4, a Windows desktop, a Linux server and your toaster will agree on that (especially if no local cache is enabled, but even then TTLs apply). If for some reason you cannot control a particular machine, you will never get it to consider that new DNS record. This can happen for a lot of reasons.

It's interesting as I really address all these things in the article. Not explicitly PTR and SRV, MX records, but these aren't essential within your internal infrastructure. No need to look at MX records if I can just straight up point at the SMTP server(s).

And I explicitly argue within the section about egress filtering that allowing systems access to public DNS is a security risk.

Because managing one database using mature tooling that is purpose-built is easier than managing 10,000+ databases using a homegrown solution with exponentially more complicated software that wasn't built for that purpose.
If you're worried about bad DNS changes causing problems, then you should be terrified about bad Ansible changes.
Serious answer: I run [and must maintain] 100x fewer resolvers than hosts. If an endpoint changes or a host leaves/returns, I'm much better served (heh) by pointing templates at resolvers instead of the horde.
What happens when the person who is your Ansible expert gets sick and is out for a week?

What happens if you need to scale up (either a lot or a little) and you need to hire new people?

People are often the most vulnerable chain in your infrastructure.

Changes from a single point of failure to a thousand points of failure. What if a host if offline when the Ansible update runs? What if someone wants to run a service that ignores /etc/hosts, like a Docker container?
As an /etc/hosts enjoyer, I wouldn't want Ansible overwriting my customized hosts file.
You'd presumely managed that customization with Ansible...
Set up. You set up your setup.