"If you are trying to diagnose a name problem, you check the hosts file. If you use DNS even for your internal name discovery you have to check every resolv.conf"

If you are using a distributed hosts file you have to check every hosts file on every host and that it's in sync.

Nonsense. You already have something that copies the hosts file to every host. It does that check as a product of copying the hosts file. rsync is old, and even before that we had rcp!

What you don't have, and have never had, is the ability to check all of your recursive resolvers from every machine and easily compare the results. rsh might've failed for other reasons that you have to check first. Nameservers might be ok, but ethernet hub might be broken. Might be temporary. Might be an active cache poisoning attack. Might be out of ports. You just don't know. DNS is always a moving target. A huge amount of energy is put into building monitoring and recording the results of monitoring and looking back on previous observations, and it's still not perfect: nagios can say everything is okay, and still service was down. Sometimes you never find out why.

A better way to think about it is: push don't poll. You know when the master hosts file changes and you know how long it takes to push it to all the machines. Polling the DNS servers just in case it changes is silly.

The entire Internet uses DNS for billions of hosts. To say it won't work for a tiny internal network seems a bit strange.

Also, if you can push files with rsync, you can write a script to SSH to every host and check its DNS settings. Pretty simple stuff.

DNS isn't "new" at this point. I remember configuring old SunOS boxes in the 90's, switching them from NIS to DNS. Exciting times.

> The entire Internet uses DNS for billions of hosts. To say it won't work for a tiny internal network seems a bit strange.

Ok. Then look at it this way. A DNS server effectively has to look at its own hosts file and publish the results in response to online queries.

Assuming the failure rate of getting answers from a hosts file is constant, why exactly do you think those online requests have a negative failure rate? That’s what would be required for DNS to beat hosts files!

If we’re talking about different networks then the hosts files do not have the same failure rate, and that’s the first time DNS (or something like it) could be better.

> DNS isn't "new" at this point. I remember configuring old SunOS boxes in the 90's, switching them from NIS to DNS. Exciting times.

Confessions from the cargo cult. Oh well. Hopefully the above makes it clear why this was a mistake.

If not, I’m not sure what else to say. In 1996 I was converting sunos boxes at that time back to hosts files and yp because the failure rate of DNS was higher and the previous guy left. What else could I do? If I’d told my boss we needed to keep using DNS because “it works for the Internet” I would’ve gotten laughed at. We had real work to do!

Your time would've been better spent fixing your DNS servers, adding a second one for redundancy. If you told me you couldn't make DNS work in 1996, I would've laughed, figured you were just inexperienced. If you told me you couldn't make it work today, I'd ask HR to get the paperwork ready.

Wow.

You would choose a failure rate of nonzero over a failure rate of zero and threaten a coworker with an HR trip for disagreeing with you?

I'm so glad I don't work with you.

Ok. Let's go back to 1985 and use host files. Who wants to join me?

Agree DNS has won today but I don’t think the current infrastructure will be what the world is using 10 years from now. ie We're trying to improve the security of the Internet by replacing Certificate Authorities with a distributed root of trust. DNS is currently centralized and controlled by a few organizations at the top of the hierarchy (namely ICANN) and easily censored by governments. Trust in HTTPS is delegated by CAs, but security follows a one of many model, where only one CA out of thousands needs to be compromised in order for your traffic to be compromised. We're building on top of a new protocol (https://handshake.org, just launched 4 days ago!!) to create an alternate root zone that's distributed. Developers can register their own TLDs and truly own them by controlling their private keys. In addition, they can pin TLSA certs to their TLD so that CAs aren't needed anymore. I wrote a more in-depth blog post here: https://www.namebase.io/blog/meet-handshake-decentralizing-d...

For internal networks, you set up a couple of local DNS servers. These servers are set up as slaves for all your local zones. DHCP provides those servers to the clients. Done. This is very simple and has worked for decades.

These are Internet hosts.

You don’t run dhcp and update your dns from a client supplied unauthenticated field unless you’ve got no idea what you’re doing.

That's good. DNS works with the Internet. ;)

I'm talking about providing a the DNS server list to update the client's resolv.conf, not updating the DNS server's host entries dynamically from the clients.

> I'm talking about providing a the DNS server list to update the client's resolv.conf, not updating the DNS server's host entries dynamically from the clients.

Why?

This isn't what anyone else is talking about.

Rsync doesn't replace DNS. It is a file copying mechanism, not an addressing system.

When an IP address changes, no amount of rsync will fix it. The IP address is simply out of band.

If someone can change your IP addresses on you, I have news for you: you’re not on the Internet but on someone else’s network who is on the Internet. I got my addresses from ARIN so my host numbers only ever changed when I thought it was convenient.

But whatever. You’re still wrong: Rsync is instant. DNS requires waiting for caches or an admin task to bounce the nameservers.