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

Post by sneak » Fri, Feb 07, 2020, 7:12 AM UTC

bradknowles wrote: post #5

And in 1995, when the Defense Information Systems Agency was building the classified SIPRnet, the principal network manager wanted to use HOSTS.TXT tables instead of the DNS, because they thought it would be easier. They also wanted to use random network numbers pulled out of their ass, for the same reason. Fortunately, I got wind of this, and as the DISA.MIL Technical POC, I had a meeting with them. Ultimately, I wa…

Post by Ayesh » Fri, Feb 07, 2020, 7:50 AM UTC

gmiller123456 wrote: post #2

>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 i…

Post by troquerre » Fri, Feb 07, 2020, 9:39 AM UTC

geocar wrote: post #10

geofft wrote: post #8

Earlier quoted context omitted.

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 h…

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 connectivi…

Post by pixl97 » Fri, Feb 07, 2020, 11:32 AM UTC

geofft wrote: post #8

paranoidrobot wrote: post #6

Earlier quoted context omitted.

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 h…

Post by geofft » Fri, Feb 07, 2020, 1:31 PM UTC

erikmolin wrote: post #15

geofft wrote: post #8

Earlier quoted context omitted.

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 h…

>But I'm not sure this fallacy has a name. I've also noticed it, and I've attributed it to the fact that the devil is in the details - you see all the intricacies and problems in the details of the solution you know, but only the shiny facade of the other proposed solution. It's basically the same idea conveyed by "The grass is always greener on the other side of the fence" - that's not a very handy name though.