6 ms·

And in 1995, when the Defense Information Systems Agency was building the classified SIPRnet, the principal network manager wanted to use HOSTS.TXT tables inste

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 was able to convince them of the folly of their ways, and to use real DNS servers as registered from the NIC, and to use real network numbers as registered from the NIC. The kicker was that I knew they ultimately wanted to be able to connect the classified SIPRnet to the “unwashed masses”, through a mythical “multi level secure gateway” that the NSA was supposedly building which would theoretically keep the truly classified stuff from touching the unclassified stuff. But how would you route packets from one side to the other, if you had colliding network numbers because one side just pulled random numbers out of their ass? How would you connect through to the unclassified side, if you weren’t using the “real” DNS? Yes, this was 1995, and they still thought HOSTS.TXT files were a good idea. To those of you who have used SIPRnet, you’re welcome.

paranoidrobot 7y ago
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.
- 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.
sneak 7y ago
Well, if you’re going to plan do one impossible thing, you might as well plan to do n impossible things. :) (As it shook out, despite their classified networks having physically separated hardware, BULLRUN still has its own Wikipedia page. :D)

paranoidrobot 7y ago

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

sneak 7y ago

Well, if you’re going to plan do one impossible thing, you might as well plan to do n impossible things. :) (As it shook out, despite their classified networks having physically separated hardware, BULLRUN still has its own Wikipedia page. :D)