Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

iconia.com

Post reply on HN
Print view View original

31–40 of 41 posts

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

#31

Post by geocar »

icedchai wrote: post #29
geocar wrote: post #22

Earlier quoted context omitted.

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…

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!

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

#32

Post by geocar »

icedchai wrote: post #28
geocar wrote: post #10

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…

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.

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

#33

Post by geocar »

creeble wrote: post #23
geocar wrote: post #10

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…

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.

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

#34

Post by paranoidrobot »

Spivak wrote: post #27
paranoidrobot wrote: post #9

Earlier quoted context omitted.

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

But we're sitting here misunderstanding what the hosts people actually want from DNS and why they're frustrated with the current state of it. 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 interna…

> "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."

That's... an entirely environment specific situation whether that's true or not.

If you're doing modern CI/CD practices with k8s, etc - those records might be valid for minutes at a time.

In many situations it's better to specifically get a DNS Resolution failure than to get out of date records.

That at least should be noticeable and obvious to the application and anything/anyone monitoring/using it.

> They want a DNS system where the server pushes record updates to the clients.

This is what Zone transfers between DNS servers are.

Running a DNS Server on each client in your network seems like an overly complicated situation but hey, if you want to do that - you can. I suspect it'll cause more problems than it solves by just having a set of well monitored/configured DNS servers.

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

#35

Post by Spivak »

paranoidrobot wrote: post #34
Spivak wrote: post #27

Earlier quoted context omitted.

But we're sitting here misunderstanding what the hosts people actually want from DNS and why they're frustrated with the current state of it. 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 interna…

> "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." That's... an entirely environment specific situation whether that's true or not. If you're doing modern CI/CD practices with k8s, etc - those records might be valid for minutes at a time. In many situations it's better to specifically get a DNS Resolution failure than to get ou…

> Better to get resolution failure.

But this is just as env specific! The point is that the “copy hosts” people are basically saying in their env that serving potentially stale records is the preferred failure mode.

> Zone xfer!

Yes! I just with the software support was better/more mature for “caching servers” (i.e clients) to act as slaves for zones rather than catching requests in-flight.

> Running a DNS server on each client...

This is what Ubuntu has done for ages with dnsmasq and now systemd-resolved. Every Linux server these days is running a DNS server.

This isn’t a “solving problems“ thing. This is a “what sounds happen in the event of a failure of those well configured and monitored DNS servers.” You can’t just be like “just never fail” as a solution.

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

#36

Post by icedchai »

geocar wrote: post #31
icedchai wrote: post #29

Earlier quoted context omitted.

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

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.

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

#37

Post by icedchai »

geocar wrote: post #32
icedchai wrote: post #28

Earlier quoted context omitted.

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.

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

#38

Post by DonHopkins »

>This was easy because in those early days the Network Control Program known as NCP (this was before TCP/IP) would broadcast messages called RSTs to every possible host address on the network when they booted.

Note that NCP used 8 bit host addresses, so it wasn't as if you couldn't write a program to connect to all 256 possible addresses and see if a computer answered. But that would be rude.

https://en.wikipedia.org/wiki/Network_Control_Program

The author's top level web page says:

https://iconia.com/

>from the keyboard of geoff goodfellow

I'm glad to learn that Geoffrey has finally upgraded his tty to a real keyboard! He used to always use this From address:

https://iconia.com/TELECOMDigestV2.33.txt

From: the tty of Geoffrey S. Goodfellow

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

#39

Post by geocar »

icedchai wrote: post #36
geocar wrote: post #31

Earlier quoted context omitted.

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

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.

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

#40

Post by geocar »

icedchai wrote: post #37
geocar wrote: post #32

Earlier quoted context omitted.

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.

Post reply on HN