Live data from Hacker News

DNS is for people, not for IT infrastructure

louwrentius.com

71–80 of 102 posts

Re: DNS is for people, not for IT infrastructure

#71
post #9

> The case against DNS for internal IT infrastructure In SOHO settings I might actually agree, but, this is where I think site administered and distributed multicast DNS was a missed opportunity.

If your DHCP server + DNS Resolver support it you can set up a local TLD and register machines by hostname using DHCP and then have the DNS Resolver in your router resolve those hostnames as hostname.local-tld. You don't need any configuration other than at the router to make this work for most machines on the network.

Re: DNS is for people, not for IT infrastructure

#73
post #64

Earlier quoted context omitted.

Serious response: how is templating out /etc/hosts with Ansible not 10x simpler than setting up an additional service that only introduces additional risk?

As an /etc/hosts enjoyer, I wouldn't want Ansible overwriting my customized hosts file.

You'd presumely managed that customization with Ansible...

Re: DNS is for people, not for IT infrastructure

#74
post #10

> 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"

Serious response: how is templating out /etc/hosts with Ansible not 10x simpler than setting up an additional service that only introduces additional risk?

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?

Re: DNS is for people, not for IT infrastructure

#75
post #72
post #62

Use Ansible to update /etc/hosts on hundreds of thousands of hosts every time a host is added or removed? Thanks for the laugh...

Isn’t this just DNS with extra steps, anyways? Now Ansible is the DNS server, basically.

It replaces DNS's pull-based architecture (contact a DNS server to get the IP address) with a push-based one (push the IP addresses to each /etc/hosts file).

Suggesting that a push-based, Ansible-based architecture will scale to hundreds of thousands of targets, with such pushes happening hundreds if not thousands of times a day, is a junior-level idea at best, dark comedy if I'm being charitable, and professional malpractice at worst.

Re: DNS is for people, not for IT infrastructure

#76
Fundamentally the point of DNS versus Ansible updating /etc/hosts is the same: get a mapping from DNS named to IPs to the client. As such, Ansible will have all the same issues. Plus, it'll introduce its own issues, like the fact that /etc/hosts is effectively cached DNS with an infinite TTL

Re: DNS is for people, not for IT infrastructure

#77

Earlier quoted context omitted.

Serious response: how is templating out /etc/hosts with Ansible not 10x simpler than setting up an additional service that only introduces additional risk?

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.

[deleted]

Re: DNS is for people, not for IT infrastructure

#78
post #72
post #62

Use Ansible to update /etc/hosts on hundreds of thousands of hosts every time a host is added or removed? Thanks for the laugh...

Isn’t this just DNS with extra steps, anyways? Now Ansible is the DNS server, basically.

The whole thing is nonsense. DNS is terrifically reliable, complex schemes to update it are often fragile. Replacing DNS with /etc/hosts and... a complex scheme to update it with ansible isn't exactly a fix. The author even admits the high profile DNS incidents weren't actually DNS servers failing.

It is pretty insane to switch from DNS servers to pushing domain config to every single client every single update.

From TFA

>There are multiple(1) high-profile(2) incidents where DNS was involved. In these linked cases, the root-cause of the incident isn't the DNS system itself. Yet, because the root-cause affects the DNS service - which is in the critical path for virtually all services - the incident has such a huge impact.

From AWS incident report linked in TFA

>The root cause of this issue was a latent race condition in the DynamoDB DNS management system that resulted in an incorrect empty DNS record for the service’s regional endpoint

Re: DNS is for people, not for IT infrastructure

#79
post #75
post #72

Earlier quoted context omitted.

Isn’t this just DNS with extra steps, anyways? Now Ansible is the DNS server, basically.

It replaces DNS's pull-based architecture (contact a DNS server to get the IP address) with a push-based one (push the IP addresses to each /etc/hosts file). Suggesting that a push-based, Ansible-based architecture will scale to hundreds of thousands of targets, with such pushes happening hundreds if not thousands of times a day, is a junior-level idea at best, dark comedy if I'm being charitable, and professional ma…

There are two kinds of junior engineers. Only hire one of them. (being very wrong is fine. Being CONFIDENTLY very wrong is not)

Re: DNS is for people, not for IT infrastructure

#80

> It's easy to configure systems with tools like Ansible or pyinfra at scale. Tell me that you've never used Ansible at scale without telling me that you've never used Ansible at scale.

Tell me please what the problem is exactly

Ansible will be terrible slow to update things if you're geographically far from the servers. Updating around 100 servers from another continent already takes longer than a 5 minute TTL. Parallel connections only work up to a point before a playbook run always have at least one failure and requires a re-run.

Ansible also does not have locks or parallel users coordination, so you’ll need a single user/VM/GHA workflow running the playbook or at some point concurrent users will start overriding each other.

Post reply on HN