Before the DNS: how yours truly upstaged the NIC's official HOSTS.TXT (2004)

>I would then telnet or ftp to these nameless hosts and see what host name the operating system login prompt gave me or what host name the ftp server announced in its greeting. I would then plug this information into my systems host table.

So, you removed what little security there was at the time to make sure that the machine pointed to by a host name actually had some connection to what the hostname implied. This is just one step below making the HOST.TXT file world editable. The NIC had a good reason for not adopting your method.

Remember at the time this was a closed network of less than a thousand computers, and there was no secrecy about what was connected to the network. For example, knowledgable users were able to identify where a computer was from its name, because sites had distinctive naming schemes https://elists.isoc.org/pipermail/internet-history/2020-Febr...

There are, unfortunately, people who still think this way.

I worked for someone a few years ago who wanted me to build tooling manage the hosts file across several hundred devices.

When I said no that that's exactly what DNS servers are for, they got shitty and went on about how DNS was unreliable and the cause of so many outages.

I wish I had a term for this sort of confusion. On the one hand, yes, DNS is the cause of many outages, and yes, in particular uncommon circumstances ("small networks" and "having an unusually good system for syncing text files that you're already keeping at five nines", etc.), syncing a hosts file might be reasonable. But most DNS outages aren't about DNS itself as a protocol, and won't be addressed by syncing the hosts file - they're about stale information in DNS, or incorrect information being stored in DNS, or something else like that. Whatever system you build to replace DNS is going to be prone to the same problems.

I have seen the same line of thinking in many other contexts - "Why don't we just replace problematic component X with other component Y" where X is, genuinely, not great but Y would need to be shaped just like X and our problems with X are actually its shape, and if you were able to reshape Y, you might as well just reshape X and not bother deploying Y. But I'm not sure this fallacy has a name.

For federated names DNS has won. There’s no point arguing how good or bad DNS is because it’s a necessary evil at this point. I wouldn’t use it in a new protocol or on a fully internal network though and that’s because nearly everything is better than DNS.

For internal networks this is obvious. I had hundreds of machines syncd up on my hosts file in the 1990s so global DNS outages didn’t affect my internal connectivity. Win.

If you make a mistake in DNS you either wait for caches to discover your correction or you ring up a bunch of other sysadmins and get them to restart named. If you rsync hosts files you just run rsync again. Easy.

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 every listed nameserver and compare with going to the roots. What’s the point? This runbook is long while running rsync is easy!

New protocols want IP mobility and cloud discovery- what does DNS do here? Causes problems that’s what. What do you do if you want to address a service instead of a machine? Know any browsers using SRV records?

And what about the home user? My printer is dell12345.local but how does DNS know that? The dhcp server could’ve told it but what stops clients from lying? Who signs the SSL certificate for my printer? How does layering on one more piece of bullshit like DNS help anything?

So not only is DNS not an obvious choice for anything new now, it wasn’t an obvious choice for this new thing then (naming federation). Communication was slower then and tech/science has always been a certain amount of cargo cult/echo chamber. These guys don’t know what they’re doing but they’re exhausting and they’re going to do it anyway. So we end up with the worst thing that could possibly succeed: DNS.

So yeah. DNS problems are absolutely because of DNS and almost anything will work better for any specific use-case. That means part of the reason this “fallacy” doesn’t have a name is because it isn’t a fallacy. Some things just suck, and seeking out a workaround sometimes any workaround needs to be considered a cry for help instead of browbeating them with how great DNS is and hope they end up with Stockholm syndrome.