21–30 of 41 posts
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.
…did we work at the same place?
Earlier quoted context omitted.
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…
"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.
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.
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…
When an IP address changes, no amount of rsync will fix it. The IP address is simply out of band.
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.
…did we work at the same place?
Right now, we don't run a DNS -- we go old-school with a master hosts file as was done before DNS existed on the internet. For our situation, it's the easiest solution and is entirely manageable, since there aren't a ton of domain names and the hosts file rarely needs updating.
But it's clear that eventually this will no longer be sustainable. Kudos and thanks to the author for blazing this trail for us. It will make the eventual shift to a private DNS much easier.
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…
https://en.m.wikipedia.org/wiki/XY_problem
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 most DNS outages aren't about DNS itself as a protocol, and won't be addressed by syncing the hosts file Correct. > I'm not sure this fallacy has a name. In this case it was a mistrust of any kind of automation. The line of thinking that if the automation can do all of this, what will they do? DHCP was removed from the network and over a thousand devices were set to use static IPs because someone had plugged in…
Failure to contact the name server should not cause a failure in name resolution. It should mean that the server isn't getting record changes.
Caches suck for this use-case. Great for the public internet but terrible for intranets. I want DNS clients to replicate all my internal zones from the masters and then serve their own queries. Records don't change that often so "bad things" would happen far less often if the failure mode was the client was behind on replication.
It's the same story with DHCP and AD. If DHCP worked so that leases were basically indefinite and servers would keep using the last address they were given we would end up with fewer total problems. All server addresses are reserved anyway and change on human time. Just propagate the changes when they happen instead of having the client ask every time.
This is what all the rsync people are ranting about. They want a DNS system where the server pushes record updates to the clients. We're over here building chat systems based on message brokering and WebSockets but doing it for name resolution is suddenly weird?
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…
Earlier quoted context omitted.
"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 b…
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.
>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…
What're you implying? That someone would change their hostname to take over someone else's site?