> 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.
DNS is for people, not for IT infrastructure
71–80 of 102 posts
Re: DNS is for people, not for IT infrastructure
#72Use Ansible to update /etc/hosts on hundreds of thousands of hosts every time a host is added or removed? Thanks for the laugh...
Re: DNS is for people, not for IT infrastructure
#73Earlier 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.
Re: DNS is for people, not for IT infrastructure
#74> 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?
Re: DNS is for people, not for IT infrastructure
#75Use 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.
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
#76Re: DNS is for people, not for IT infrastructure
#77Earlier 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.
Re: DNS is for people, not for IT infrastructure
#78Use 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 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
#79Earlier 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…
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 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.