8 ms·

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 sev

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.

geofft 7y ago
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.
- paranoidrobot 7y ago
  > 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 a device with a DHCP server on it. It was DHCPs problem, not that the network switches were not configured to block DHCP Responses except from authorised hosts. Every machine had it's OS and software manually installed, because imaging 'never worked right'. Active Directory wasn't used, because AD was a 'single point of failure', and so local accounts on everything. Then when AD was eventually rolled out (and with it DNS/DHCP/etc)... Every machine had the printers manually configured, because group policies 'never work'.
  - Spivak 7y ago
    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 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?
    - paranoidrobot 7y ago
      > "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.
      - Spivak 7y ago
        > 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.
- geocar 7y ago
  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.
  - troquerre 7y ago
    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 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-dns-to-improve-the-security-of-the-internet https://www.namebase.io/blog/meet-handshake-decentralizing-d...
- erikmolin 7y ago
  >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.
  - geofft 7y ago
    Yeah, it's partially a grass-is-greener thing, but partially a fundamental failure to realize that you're allergic to grass, and even if the grass really is greener, that won't actually solve your problem.
- pixl97 7y ago
  https://en.m.wikipedia.org/wiki/XY_problem https://en.m.wikipedia.org/wiki/XY_problem
  - ramses0 7y ago
    JWZ Problem? (now you have two problems...) https://www.jwz.org/blog/2014/05/so-this-happened/ https://www.jwz.org/blog/2014/05/so-this-happened/
QuinnyPig 7y ago
…did we work at the same place?
- paranoidrobot 7y ago
  Unfortunately not, Corey.
- rconti 7y ago
  I worked at the same place too.

geofft 7y ago

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.

paranoidrobot 7y ago
> 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 a device with a DHCP server on it. It was DHCPs problem, not that the network switches were not configured to block DHCP Responses except from authorised hosts. Every machine had it's OS and software manually installed, because imaging 'never worked right'. Active Directory wasn't used, because AD was a 'single point of failure', and so local accounts on everything. Then when AD was eventually rolled out (and with it DNS/DHCP/etc)... Every machine had the printers manually configured, because group policies 'never work'.
- Spivak 7y ago
  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 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?
  - paranoidrobot 7y ago
    > "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.
    - Spivak 7y ago
      > 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.
geocar 7y ago
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.
- troquerre 7y ago
  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 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-dns-to-improve-the-security-of-the-internet https://www.namebase.io/blog/meet-handshake-decentralizing-d...
erikmolin 7y ago
>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.
- geofft 7y ago
  Yeah, it's partially a grass-is-greener thing, but partially a fundamental failure to realize that you're allergic to grass, and even if the grass really is greener, that won't actually solve your problem.
pixl97 7y ago
https://en.m.wikipedia.org/wiki/XY_problem https://en.m.wikipedia.org/wiki/XY_problem
- ramses0 7y ago
  JWZ Problem? (now you have two problems...) https://www.jwz.org/blog/2014/05/so-this-happened/ https://www.jwz.org/blog/2014/05/so-this-happened/

QuinnyPig 7y ago

…did we work at the same place?

paranoidrobot 7y ago
Unfortunately not, Corey.
rconti 7y ago
I worked at the same place too.