News for hackers. Stuff that matters.
Re:DNS Is for People – Not for IT Infrastructure by Bratmon on Wednesday June 03, 2026 @10:41PM (#48393025)
> Instead of configuring domain names that may not resolve, we can just directly inject the appropriate IP address(ess) into configuration files

Because now you've replaced one single point of failure configuration system with caching and TTLs (DNS) with a higher maintenance and much less widely supported one.

Re:DNS Is for People – Not for IT Infrastructure by bot403 on Thursday June 04, 2026 @12:49AM (#48394008)
Not to mention losing load balancing and failover.
Re:DNS Is for People – Not for IT Infrastructure by dzr0001 on Thursday June 04, 2026 @01:04AM (#48394147)
And making TLS more difficult, especially for HA systems. Guess you would just need one cert for 127.0.0.1 for all local services.
Re:DNS Is for People – Not for IT Infrastructure by louwrentius on Thursday June 04, 2026 @01:28AM (#48394363)
Certs support ip addresses? However, /etc/hosts would solve the issue probably, unless I’m missing something
Re:DNS Is for People – Not for IT Infrastructure by flumpcakes on Thursday June 04, 2026 @02:12AM (#48394674)
What has /etc/hosts got to do with valid TLS certificates? I think that’s a non-sequitur.
Re:DNS Is for People – Not for IT Infrastructure by louwrentius on Thursday June 04, 2026 @02:17AM (#48394706)
You don't need to setup one cert for 127.0.0.1 as stated by the parent comment.
Re:DNS Is for People – Not for IT Infrastructure by throw0101a on Thursday June 04, 2026 @06:40AM (#48396713)
Failover can be done with something like keepalived. VRRP/CARP are a thing.

For LB you'll need something in front of your service to bounce connections around, which is replacing one point of failure (DNS) for another (HAproxy, IPVS). Though I guess you can run the LB stack on your app service servers.