5 ms·

DNS is for people, not for IT infrastructure

63 points by louwrentius 5mo ago

linksnapzz 5mo ago
Counterpoint: DNS isn't used enough; consider replacing sssd/AD with Hesiod.
Bratmon 5mo ago
> Instead of configuring domain names that may not resolve, we can just directly inject the appropriate IP address(ess) into configuration files Because now you've replaced one single point of failure configuration system with caching and TTLs (DNS) with a higher maintenance and much less widely supported one.
- bot403 5mo ago
  Not to mention losing load balancing and failover.
  - dzr0001 5mo ago
    And making TLS more difficult, especially for HA systems. Guess you would just need one cert for 127.0.0.1 for all local services.
    - louwrentius 5mo ago
      Certs support ip addresses? However, /etc/hosts would solve the issue probably, unless I’m missing something
      - flumpcakes 5mo ago
        What has /etc/hosts got to do with valid TLS certificates? I think that’s a non-sequitur.
        louwrentius 5mo ago
        You don't need to setup one cert for 127.0.0.1 as stated by the parent comment.
  - throw0101a 4mo ago
    Failover can be done with something like keepalived. VRRP/CARP are a thing. For LB you'll need something in front of your service to bounce connections around, which is replacing one point of failure (DNS) for another (HAproxy, IPVS). Though I guess you can run the LB stack on your app service servers.
mixdup 5mo ago
"just use /etc/hosts" is wild. That is effectively just going from one DNS server servicing all of your machines to having bespoke DNS servers individually running on every host. madness
- louwrentius 5mo ago
  Why is that madness and not amazing? Isn’t the simplicity beautiful? Managing /etc/hosts with a tool like Ansible?
  - spragl 5mo ago
    /etc/hosts scales like a lead balloon. For small groups of servers, with limited egress communication, it might nevertheless make sense. And then go for it, by all means. As a general replacement for DNS, not likely. It is hard to see how Ansible should be simpler than DNS. Maybe if you have worked with Ansible and not DNS, you might think so.
    - trumpdong 4mo ago
      You're using Ansible anyway. I think the comparison is DNS+Ansible vs just Ansible.
  - mixdup 4mo ago
    Why not manage your one single DNS server with a tool like Ansible? Why fragment it and have to manage it on dozens/hundreds/thousands of endpoints instead?
  - bigstrat2003 4mo ago
    There is absolutely nothing simple about managing a hosts file across your fleet rather than DNS.
jaredhallen 5mo ago
Seems like a weird crusade. Pointing everything directly at the IP address might not seem so swell when it's time to upgrade the server or the address has to change for some reason. Sure would be nice to just update the DNS record to point to the new address.
- themafia 5mo ago
  > or the address has to change for some reason One annoying reason is you don't own it/have access through the owner anymore. > Sure would be nice to just update the DNS record to point to the new address. EC2. Elastic IPs are easy enough, but, precisely, I would just like to make a Route53 alias for an EC2 instance and not even have to care.
- louwrentius 5mo ago
  Proposed solution: update the inventory and run your Ansible playbook/role agains your infrastructure (or subset). I don’t see the issue, to be frank.
necovek 5mo ago
It is not really true that DNS is for people only: it is used as an aliasing system, for load balancing, and for caching (with no cache invalidation mechanism other than ahead-of-time TTL setting). It is used to make entire protocols work (MX records for email, but SRV records are used for much more). Now, if we do look at the most basic of basic DNS roles — mapping a human readable name to arbitrary set of numbers identifying a machine on the network — we should consider how do we avoid some of the issues while keeping all of the benefits of DNS. Eg. if we indeed "materialize" machine identifiers, we lose the ability to do virtual hosting (domains not passed in) or fix a problem with just a DNS update (eg. treating load-balancing machines like cattle). The author jumps immediately to, arguably, ill advised materialization techniques like /etc/hosts, without considering all that DNS does for a complex, real world system and what goes missing.
- louwrentius 5mo ago
  - note I was talking about internal infrastructure, not public services - DNS load balancing is not that important for internal services in most Cases? Would only use it if alternatives won’t work. - the virtual host issue is really adressed by /etc/hosts, I thought that was obvious, I now regret not explicitly adressing it.
  - necovek 5mo ago
    The examples you cite (eg. 2021 Facebook outage) have nothing to do with DNS being used for internal infrastructure. In the other example (Amazon DynamoDB issue), the problem is with dynamically choosing from a large dynamic pool of IP addresses for a service — DNS is but one mechanism to do it. If it wasn't DNS, it could have been something else that did that job that was broken. Even /etc/hosts if it was updated with an empty record. What I am saying is that your analysis is not defining the problem you want solved exactly, your examples are not backing up your proposal or analysis, and you are ignoring all the things DNS does both for public and private infrastructure. You seem to have some intuition about this adding complexity and thus being a risk (which is true), but you need to do a better job of connecting and analysing real risks and proposed solutions (and their comparative performance).
samrus 5mo ago
But whats the problem woth using DNS internally? Given the system is already present, and moving away fron it would be effort. Seems like a nitpick
themafia 5mo ago
> The case against DNS for internal IT infrastructure In SOHO settings I might actually agree, but, this is where I think site administered and distributed multicast DNS was a missed opportunity.
- throwway120385 4mo ago
  If your DHCP server + DNS Resolver support it you can set up a local TLD and register machines by hostname using DHCP and then have the DNS Resolver in your router resolve those hostnames as hostname.local-tld. You don't need any configuration other than at the router to make this work for most machines on the network.
gfody 5mo ago
> we'll just use /etc/hosts no DNS required! this is classic "easy vs. simple" folly, witness how someone too lazy to [learn how to] setup proper DNS for their infrastructure will do 10x the work hacking something "easy"
- louwrentius 5mo ago
  Serious response: how is templating out /etc/hosts with Ansible not 10x simpler than setting up an additional service that only introduces additional risk?
  - arter45 5mo ago
    You lose the concept of DNS forwarding. Usually, if your company has example.com, your DNS server is authoritative for example.com, which means it will actually contain (fqdn,ip) entries belonging to example.com, and it will forward requests for other domains to other DNS servers, possibly one DNS server per domain. If you remove DNS servers from the equation, you need to write down records for other domains, too. This means you have to chase every domain for changes in CDN configuration, hosting provider or ISP migrations, IPv4 to v6 migrations and so on. You don't have PTR records, which means you can't find out a name from its IP address. You also miss other features of DNS, like SRV, MX and so on. More subtly, you lose the ability to control DNS resolution over systems you can't control. If a DNS server says host.example.com is 192.168.0.4, a Windows desktop, a Linux server and your toaster will agree on that (especially if no local cache is enabled, but even then TTLs apply). If for some reason you cannot control a particular machine, you will never get it to consider that new DNS record. This can happen for a lot of reasons.
    - louwrentius 5mo ago
      It's interesting as I really address all these things in the article. Not explicitly PTR and SRV, MX records, but these aren't essential within your internal infrastructure. No need to look at MX records if I can just straight up point at the SMTP server(s). And I explicitly argue within the section about egress filtering that allowing systems access to public DNS is a security risk.
denkmoon 5mo ago
This is what happens when you take the "it was DNS" meme too seriously. DNS is brilliant. Learn it. If you're really that ideologically opposed to such brilliance, just use the addresses directly. The system described is insane.
jghefner 5mo ago
> It's easy to configure systems with tools like Ansible or pyinfra at scale. Tell me that you've never used Ansible at scale without telling me that you've never used Ansible at scale.
- louwrentius 5mo ago
  Tell me please what the problem is exactly
  - JackSlateur 5mo ago
    Please describe how you plan to use ansible to deploy config in ~200k containers, with hundreds of data updates per day
    - louwrentius 4mo ago
      I would not use containers in the first place as this adds added complexity and overhead in the first place.
      - JackSlateur 4mo ago
        Please share how to manage ~200k applications without containers
    - throwway120385 4mo ago
      The real "fish out of water" question is "tell me how to use Ansible to configure 200k embedded appliances where the end customer doesn't always allow firmware updates through their firewall?"
  - kassner 4mo ago
    Ansible will be terrible slow to update things if you're geographically far from the servers. Updating around 100 servers from another continent already takes longer than a 5 minute TTL. Parallel connections only work up to a point before a playbook run always have at least one failure and requires a re-run. Ansible also does not have locks or parallel users coordination, so you’ll need a single user/VM/GHA workflow running the playbook or at some point concurrent users will start overriding each other.
fulafel 5mo ago
History tip: Using /etc/hosts (or as it was called then, "the HOSTS.TXT file") ran into some problems.
- qmr 5mo ago
  Bah storage is cheap these days and we have git let's give it another go
irjustin 5mo ago
Hard disagree - only because if you didn't have DNS you would have something else in its place. But, we understand DNS _very_ well. People, services, machines, etc need to "dial" canonical-somewhere. Whatever does the canonical management is the piece that when it breaks everything breaks. Doesn't matter if it's DNS, EIP rotation, some HA proxy, whatever. It'll break. It's actually that DNS is so well understood that it doesn't fail more often. So no, DNS is for IT Infra.
- louwrentius 5mo ago
  > Whatever does the canonical management is the piece that when it breaks everything breaks. That is absolutely true. I believe that a solution where you provision a text file with an updated ip address or /etc/hosts file is inherently simpler, less risky and easier to recover from, although I admit I don't explicitly state this in the article.
  - protocolture 5mo ago
    >I believe that a solution where you provision a text file with an updated ip address or /etc/hosts file is inherently simpler, less risky and easier to recover from You are wrong. Its possible that your confidence in being wrong is due to your inexperience. But you are still wrong.
  - irjustin 5mo ago
    I'm surprised at this and some of your other responses. It makes me believe you've never managed anything at scale, but then why have such a strong opinion about DNS for infra? > I believe that a solution where you provision a text file with an updated ip address or /etc/hosts file is inherently simpler So simple that it doesn't scale beyond a few machines nor outside your org.
deleted 5mo ago
[deleted]
XYen0n 5mo ago
DNS is merely one implementation of service discovery; even without DNS, some other form of service discovery would still be needed.
- louwrentius 5mo ago
  Why would some form of service discovery be required? No need to discover things if you can push said information in configuration updates using tools like Ansible, pyinfra, and so on?
  - protocolture 5mo ago
    How does your convoluted Ansible system know which systems and services to maintain. If its a list of IP addresses, having a list of ip addresses is a crude service discovery protocol. Tasking developers (because lets be absolutely clear, the idea of removing DNS from production environments is something only a developer could come up with, no competent engineer would ever raise) with maintaining ordered lists of servers to keep updated is only going to overcomplicate things. And yes your hosts file is another example of a list.
    - trumpdong 4mo ago
      How does your DNS system know? There's always a list of all systems somewhere.
  - kube-system 4mo ago
    You probably don't need service discovery if your entire infrastructure is small enough that the whole thing is deployed with Ansible.
  - throwway120385 4mo ago
    What you're asking is akin to "why do people sometimes need a boat to get from point A to point B? All I've used are cars and I think that should be fine."
  - XYen0n 4mo ago
simonjgreen 5mo ago
This author has clearly never operated internal infrastructure at scale. The measures proposed in this are home lab grade at best, and require ludicrous levels of precision and overhead for something that changes thousands to tens of thousands of times per day. And for very specific nit picks, and I can’t believe I’m entertaining this idea enough to ask, but tell me how the new device on the network bootstraps without DNS? And the guest device. And the printer without Ansible support. And the NDI receiver that needs to resolve its host. And how do you resolve split brain resolution for roaming devices? Are you going to publicly address all internal resources now so my laptop keeps working outside the office? DNS was not created as a random solution looking for a problem…
- louwrentius 5mo ago
  I wasn't talking about an office environment. I'm talking server-to-server communication. Like all the internal infrastructure to support a web application. Maybe I should have been more explicit about that. How a new device bootstraps on the network without DNS? Depends, on the device, but a physical server doesn't need DNS, only PXE boot / TFTP / HTTP as usual and maybe a proxy to access an update server if you don't run one yourself.
  - JackSlateur 5mo ago
    "How a new device bootstraps on the network without DNS?" DHCP
- protocolture 5mo ago
  OP will just reinvent Netbios running over Ansible.
protocolture 5mo ago
>DNS Is for People DNS is for Infrastructure, people use infrastructure. >That got me thinking, why would we use DNS for infrastructure services? It isn't necessary for machine-to-machine communication. Instead of configuring domain names that may not resolve, we can just directly inject the appropriate IP address(ess) into configuration files. It's easy to configure systems with tools like Ansible or pyinfra at scale. No no no no god no. "What if we set up a convoluted higher level application solution" This is going to go wrong more frequently and contain more errors than DNS. >Fortunately, we still have /etc/hosts, which we can easily provision. Still no DNS service required! This way, we can configure domain names and pretend to use DNS. I also suspect that DNS queries against /etc/hosts are quite responsive. No thats a horrible idea. Userspace should never be updating your hosts file, users will fall behind on changes and be placed at extreme security risk. Fully half the benefit of UAC on windows is preventing persistence by preventing malicious entities from updating hosts. >As of today, most network traffic is encrypted by default, or tunneled through an encrypted channel. DNS is - by default - the exception. DNS is mostly secure now, to the point where its a problem. But thats a vendor issue not a you issue please dont attempt to solve it. If you go full encrypted DNS you generally also get dragged into HTTPS proxying and things of that nature. This does not get better by removing a dynamic protocol for querying names. >Due to this risk, there is a case to be made, to - at least - not allow systems to query public DNS records. As servers may need to interfact with services on the internet (update servers, APIs, and so on), such access can be facilitated by a proxy server using allow-listed domains. Attackers use DNS because its versatile and resistant to the very issues you keep confidently presenting. A protocol is not a risk just because hackers use it. Hackers also use HTTPS and other protocols but we arent burning them at the stake. >That said, I think it's reasonable to explore if DNS can be avoided altogether within the IT infrastructure to increase reliability and robustness. Its reasonable for people with much better understanding of the infrastructure and protocol to examine these things. This reads like an end user suggesting "what if we deliver websites by hand printed on paper".
cobbzilla 5mo ago
FTFY: DNS was for People Now it’s for machines
tikhonj 5mo ago
DNS is a database.
frollogaston 5mo ago
Why is DNS for people only? The article suggests rolling your own DNS with static config, which I could see myself doing in the right scenarios, but you can't always do that. Kinda reminds me of Kubernetes, though instead of /etc/hosts it runs an actual DNS server.
davkan 5mo ago
I’m not sure I’ve seen unanimous agreement in an HN comment section before so that’s nice I guess. But to address the article in a simple environment dns _just_works_. I’ve never once had an issue with bind. It’s incredibly simple and stable and easy to understand when working with within a small environment without much churn and enables other technologies to operate in an expected way because it’s the standard. ACME, kerberos, sshfp, many more are enabled by DNS. Sure maybe you can kludge some of that back together with hosts but I’d rather not just to replace one of the most stable services that exist. DNS does start to get more complicated in massive environments but that’s just a reflection of the environment. Using ansible to manage /etc/hosts across hundreds or thousands machines with churn will not be less complicated to manage than dns.
rho138 4mo ago
That’s not how DNSSEC works… it’s sole purpose is signing - not encryption. > https://www.rfc-editor.org/info/rfc9364/#name-dnssec-core-documents https://www.rfc-editor.org/info/rfc9364/#name-dnssec-core-do...
ritcgab 4mo ago
DNS is a federated, read-optimized, geo-replicated key-value store with eventual consistency.
ryanshrott 4mo ago
Everyone's dunking on /etc/hosts, but I've debugged enough production DNS loops to get the temptation. It's not the right answer, but the impulse isn't crazy either.
- throwway120385 4mo ago
  At the very least you can put it at the bottom of your /etc/resolv.conf prioritization and put some backup systems like an SSH bastion in /etc/hosts so that there's some system out there that you can reach with mutual-auth in the event that your DNS is REALLY messed up.
jverce 4mo ago
How would Kubernetes work without DNS?
solatic 4mo ago
Use Ansible to update /etc/hosts on hundreds of thousands of hosts every time a host is added or removed? Thanks for the laugh...
- monkpit 4mo ago
  Isn’t this just DNS with extra steps, anyways? Now Ansible is the DNS server, basically.
  - solatic 4mo ago
    It replaces DNS's pull-based architecture (contact a DNS server to get the IP address) with a push-based one (push the IP addresses to each /etc/hosts file). Suggesting that a push-based, Ansible-based architecture will scale to hundreds of thousands of targets, with such pushes happening hundreds if not thousands of times a day, is a junior-level idea at best, dark comedy if I'm being charitable, and professional malpractice at worst.
    - colechristensen 4mo ago
      There are two kinds of junior engineers. Only hire one of them. (being very wrong is fine. Being CONFIDENTLY very wrong is not)
    - trumpdong 4mo ago
      This sounds a bit like saying: don't use MySQL, because it can't scale to one billion requests per second. How many applications are actually running at that scale?
      - solatic 4mo ago
        Did you read the original article? > The Facebook / Meta outage was so significant The author specifically called out the Meta outage, as if he was offering a prescription ("It's easy to configure systems with tools like Ansible or pyinfra at scale") that would have prevented Meta (at Meta's scale) from suffering an outage. The argument that Meta should not have used DNS except that Meta runs at a scale where DNS is necessary... who comes up with these arguments?
ranger207 4mo ago
Fundamentally the point of DNS versus Ansible updating /etc/hosts is the same: get a mapping from DNS named to IPs to the client. As such, Ansible will have all the same issues. Plus, it'll introduce its own issues, like the fact that /etc/hosts is effectively cached DNS with an infinite TTL
nemothekid 4mo ago
>Fortunately, we still have /etc/hosts, which we can easily provision This is the kind of thing you read in a post-mortem and wonder how they designed something so fiendishly wonderful. At 2:00am our MySQL master failed and failed over successfully to our secondary server. As part of post-failover ops, ansible playbook proceeded to login to 1000 instances to update the hosts file for the new master. This caused traffic amplication which caused our Etcd nodes to believe they were down. As the etcd nodes failed over, our ansible playbook proceeded to then login to 1000 instances to update the hosts file... Honestly, whatever system you built is justing do the same exact function as DNS just with extra steps. If you squint really hard /etc/hosts is your local dns cache and ansible is your resolver. I think this kind of "simplification fetishization" is dangerously attractive to people who have only managed relatively simply setups. I don't think anyone who has ever had to deal with high-availability failover would consider Ansible a good solution. The problem that so many people hit with DNS isn't specific to DNS the protocol - it's the problem of service discovery. This architecture doesn't eliminate service discovery, it just moves it to a far more brittle configuration.
- protocolture 4mo ago
  I had an ISP customer years ago that had an AAA system designed by people who didnt understand DNS, DHCP or RADIUS. They also had no idea about netflow or SNMP. The application would log into every router in the network and run a massive, on the fly script to manually create a bunch of PPPOE services, shaping targets for those connections, update firewall rules etc. It would also run manual mikrotik bandwidth tests across every logical link it was aware of. The application developers were adamant that this was the best way of doing things, and any disagreement would have them point at their dozen or so customers and boast that they surely wouldnt have been able to hoodwink that many people if they were doing it wrong. Anyway we took a packet capture of all the every 10 minute script updates and demonstrated those to the customer as a whole number % of their bandwidth to certain smaller sites, and also were able to show them how they stopped getting "My internet goes out every 10 minutes" complaints as we turned off the automatic mikrotik bandwidth tests running every 10 minutes. But to save their customer the application developers agreed to implement SNMP and RADIUS but they never did. IIRC their fee was a flat 15% of all profits generated by the customer, which was just staggering. And the fee could rise if they asked for support.
Twey 4mo ago
John Day talks about this a fair bit: what people want to do is naming of applications, in a way that makes it independent of addressing (i.e. where the application is running). DNS still names the machine — it's just a one-step abstracted machine addressing scheme, not an application naming scheme per se. Then we designed an ad-hoc protocol on top that associates applications with specific machine names (and port numbers): if you go to facebook.com:443 (a.k.a. https) you expect to find an instance of the Facebook application, not a webmail client or an SSH server. This isn't how any of this was really supposed to work. Back in the day the application identifier was the _port number_, according to a big list maintained by ICANN. The idea was that you could go to a machine (identified by IP or more conveniently by DNS) and see if it was running an instance of the ‘Facebook’ application, i.e. you'd find Facebook not at facebook.com:https but at meta.com:facebook. The end goal was to eliminate the need for the former part at some point, and come up with a better way of looking up applications than distributing a list by email. Instead the application ID is now used for transport and the host name instead encodes application ID, which it was never meant for, and that's why we can't have nice things (like device mobility).
gbraad 4mo ago
The title indicates a wrong assesment: as DNS provides indirection, a means to allow a system to group, balance, etc based on a record to an/a set of address(es). Not even considering to open the link as it sounds absurd. I take from some of the other comments he uses /etc/hosts on hosts with Ansible to provide resolving. Sounds convoluted as /etc/resolv.conf and libc resolvers works. Go for the lowest fallback and dump files with Ansible. Homelab with extra steps, as setting up a DNS server is easy, ... Consider coredns, dnsmasq, if bind is too much
vel0city 4mo ago
Why bother with all the issues and difficulties of hosting a web server when I can just SCP all the files to everyone's computers constantly?
sohex 4mo ago
This has a serious case of in-housing the edge cases that I don’t think many would want to pay the price for. The problem with DNS per the haiku isn’t that it’s difficult to understand, or even that running your own DNS server is particularly difficult. It’s that coordinating information and exchange at scale is a tricky problem with a lot of non-obvious edge cases and foot guns. So trying to reduce complexity by sidestepping DNS really doesn’t do that, it just leaves you holding the bag on all the problems that DNS was quietly solving for you in the background.

63 points by louwrentius 5mo ago

Counterpoint: DNS isn't used enough; consider replacing sssd/AD with Hesiod.

> Instead of configuring domain names that may not resolve, we can just directly inject the appropriate IP address(ess) into configuration files Because now you've replaced one single point of failure configuration system with caching and TTLs (DNS) with a higher maintenance and much less widely supported one.

bot403 5mo ago
Not to mention losing load balancing and failover.
- dzr0001 5mo ago
  And making TLS more difficult, especially for HA systems. Guess you would just need one cert for 127.0.0.1 for all local services.
  - louwrentius 5mo ago
    Certs support ip addresses? However, /etc/hosts would solve the issue probably, unless I’m missing something
    - flumpcakes 5mo ago
      What has /etc/hosts got to do with valid TLS certificates? I think that’s a non-sequitur.
      - louwrentius 5mo ago
        You don't need to setup one cert for 127.0.0.1 as stated by the parent comment.
- throw0101a 4mo ago
  Failover can be done with something like keepalived. VRRP/CARP are a thing. For LB you'll need something in front of your service to bounce connections around, which is replacing one point of failure (DNS) for another (HAproxy, IPVS). Though I guess you can run the LB stack on your app service servers.

mixdup 5mo ago

"just use /etc/hosts" is wild. That is effectively just going from one DNS server servicing all of your machines to having bespoke DNS servers individually running on every host. madness

louwrentius 5mo ago
Why is that madness and not amazing? Isn’t the simplicity beautiful? Managing /etc/hosts with a tool like Ansible?
- spragl 5mo ago
  /etc/hosts scales like a lead balloon. For small groups of servers, with limited egress communication, it might nevertheless make sense. And then go for it, by all means. As a general replacement for DNS, not likely. It is hard to see how Ansible should be simpler than DNS. Maybe if you have worked with Ansible and not DNS, you might think so.
  - trumpdong 4mo ago
    You're using Ansible anyway. I think the comparison is DNS+Ansible vs just Ansible.
- mixdup 4mo ago
  Why not manage your one single DNS server with a tool like Ansible? Why fragment it and have to manage it on dozens/hundreds/thousands of endpoints instead?
- bigstrat2003 4mo ago
  There is absolutely nothing simple about managing a hosts file across your fleet rather than DNS.

jaredhallen 5mo ago

Seems like a weird crusade. Pointing everything directly at the IP address might not seem so swell when it's time to upgrade the server or the address has to change for some reason. Sure would be nice to just update the DNS record to point to the new address.

themafia 5mo ago
> or the address has to change for some reason One annoying reason is you don't own it/have access through the owner anymore. > Sure would be nice to just update the DNS record to point to the new address. EC2. Elastic IPs are easy enough, but, precisely, I would just like to make a Route53 alias for an EC2 instance and not even have to care.
louwrentius 5mo ago
Proposed solution: update the inventory and run your Ansible playbook/role agains your infrastructure (or subset). I don’t see the issue, to be frank.

necovek 5mo ago

It is not really true that DNS is for people only: it is used as an aliasing system, for load balancing, and for caching (with no cache invalidation mechanism other than ahead-of-time TTL setting). It is used to make entire protocols work (MX records for email, but SRV records are used for much more). Now, if we do look at the most basic of basic DNS roles — mapping a human readable name to arbitrary set of numbers identifying a machine on the network — we should consider how do we avoid some of the issues while keeping all of the benefits of DNS. Eg. if we indeed "materialize" machine identifiers, we lose the ability to do virtual hosting (domains not passed in) or fix a problem with just a DNS update (eg. treating load-balancing machines like cattle). The author jumps immediately to, arguably, ill advised materialization techniques like /etc/hosts, without considering all that DNS does for a complex, real world system and what goes missing.

louwrentius 5mo ago
- note I was talking about internal infrastructure, not public services - DNS load balancing is not that important for internal services in most Cases? Would only use it if alternatives won’t work. - the virtual host issue is really adressed by /etc/hosts, I thought that was obvious, I now regret not explicitly adressing it.
- necovek 5mo ago
  The examples you cite (eg. 2021 Facebook outage) have nothing to do with DNS being used for internal infrastructure. In the other example (Amazon DynamoDB issue), the problem is with dynamically choosing from a large dynamic pool of IP addresses for a service — DNS is but one mechanism to do it. If it wasn't DNS, it could have been something else that did that job that was broken. Even /etc/hosts if it was updated with an empty record. What I am saying is that your analysis is not defining the problem you want solved exactly, your examples are not backing up your proposal or analysis, and you are ignoring all the things DNS does both for public and private infrastructure. You seem to have some intuition about this adding complexity and thus being a risk (which is true), but you need to do a better job of connecting and analysing real risks and proposed solutions (and their comparative performance).

samrus 5mo ago

But whats the problem woth using DNS internally? Given the system is already present, and moving away fron it would be effort. Seems like a nitpick

themafia 5mo ago

> The case against DNS for internal IT infrastructure In SOHO settings I might actually agree, but, this is where I think site administered and distributed multicast DNS was a missed opportunity.

throwway120385 4mo ago
If your DHCP server + DNS Resolver support it you can set up a local TLD and register machines by hostname using DHCP and then have the DNS Resolver in your router resolve those hostnames as hostname.local-tld. You don't need any configuration other than at the router to make this work for most machines on the network.

gfody 5mo ago

> we'll just use /etc/hosts no DNS required! this is classic "easy vs. simple" folly, witness how someone too lazy to [learn how to] setup proper DNS for their infrastructure will do 10x the work hacking something "easy"

louwrentius 5mo ago
Serious response: how is templating out /etc/hosts with Ansible not 10x simpler than setting up an additional service that only introduces additional risk?
- arter45 5mo ago
  You lose the concept of DNS forwarding. Usually, if your company has example.com, your DNS server is authoritative for example.com, which means it will actually contain (fqdn,ip) entries belonging to example.com, and it will forward requests for other domains to other DNS servers, possibly one DNS server per domain. If you remove DNS servers from the equation, you need to write down records for other domains, too. This means you have to chase every domain for changes in CDN configuration, hosting provider or ISP migrations, IPv4 to v6 migrations and so on. You don't have PTR records, which means you can't find out a name from its IP address. You also miss other features of DNS, like SRV, MX and so on. More subtly, you lose the ability to control DNS resolution over systems you can't control. If a DNS server says host.example.com is 192.168.0.4, a Windows desktop, a Linux server and your toaster will agree on that (especially if no local cache is enabled, but even then TTLs apply). If for some reason you cannot control a particular machine, you will never get it to consider that new DNS record. This can happen for a lot of reasons.
  - louwrentius 5mo ago
    It's interesting as I really address all these things in the article. Not explicitly PTR and SRV, MX records, but these aren't essential within your internal infrastructure. No need to look at MX records if I can just straight up point at the SMTP server(s). And I explicitly argue within the section about egress filtering that allowing systems access to public DNS is a security risk.

denkmoon 5mo ago

This is what happens when you take the "it was DNS" meme too seriously. DNS is brilliant. Learn it. If you're really that ideologically opposed to such brilliance, just use the addresses directly. The system described is insane.

jghefner 5mo ago

> It's easy to configure systems with tools like Ansible or pyinfra at scale. Tell me that you've never used Ansible at scale without telling me that you've never used Ansible at scale.

louwrentius 5mo ago
Tell me please what the problem is exactly
- JackSlateur 5mo ago
  Please describe how you plan to use ansible to deploy config in ~200k containers, with hundreds of data updates per day
  - louwrentius 4mo ago
    I would not use containers in the first place as this adds added complexity and overhead in the first place.
    - JackSlateur 4mo ago
      Please share how to manage ~200k applications without containers
  - throwway120385 4mo ago
    The real "fish out of water" question is "tell me how to use Ansible to configure 200k embedded appliances where the end customer doesn't always allow firmware updates through their firewall?"
- kassner 4mo ago
  Ansible will be terrible slow to update things if you're geographically far from the servers. Updating around 100 servers from another continent already takes longer than a 5 minute TTL. Parallel connections only work up to a point before a playbook run always have at least one failure and requires a re-run. Ansible also does not have locks or parallel users coordination, so you’ll need a single user/VM/GHA workflow running the playbook or at some point concurrent users will start overriding each other.

fulafel 5mo ago

History tip: Using /etc/hosts (or as it was called then, "the HOSTS.TXT file") ran into some problems.

qmr 5mo ago
Bah storage is cheap these days and we have git let's give it another go

irjustin 5mo ago

Hard disagree - only because if you didn't have DNS you would have something else in its place. But, we understand DNS _very_ well. People, services, machines, etc need to "dial" canonical-somewhere. Whatever does the canonical management is the piece that when it breaks everything breaks. Doesn't matter if it's DNS, EIP rotation, some HA proxy, whatever. It'll break. It's actually that DNS is so well understood that it doesn't fail more often. So no, DNS is for IT Infra.

louwrentius 5mo ago
> Whatever does the canonical management is the piece that when it breaks everything breaks. That is absolutely true. I believe that a solution where you provision a text file with an updated ip address or /etc/hosts file is inherently simpler, less risky and easier to recover from, although I admit I don't explicitly state this in the article.
- protocolture 5mo ago
  >I believe that a solution where you provision a text file with an updated ip address or /etc/hosts file is inherently simpler, less risky and easier to recover from You are wrong. Its possible that your confidence in being wrong is due to your inexperience. But you are still wrong.
- irjustin 5mo ago
  I'm surprised at this and some of your other responses. It makes me believe you've never managed anything at scale, but then why have such a strong opinion about DNS for infra? > I believe that a solution where you provision a text file with an updated ip address or /etc/hosts file is inherently simpler So simple that it doesn't scale beyond a few machines nor outside your org.

deleted 5mo ago

[deleted]

XYen0n 5mo ago

DNS is merely one implementation of service discovery; even without DNS, some other form of service discovery would still be needed.

louwrentius 5mo ago
Why would some form of service discovery be required? No need to discover things if you can push said information in configuration updates using tools like Ansible, pyinfra, and so on?
- protocolture 5mo ago
  How does your convoluted Ansible system know which systems and services to maintain. If its a list of IP addresses, having a list of ip addresses is a crude service discovery protocol. Tasking developers (because lets be absolutely clear, the idea of removing DNS from production environments is something only a developer could come up with, no competent engineer would ever raise) with maintaining ordered lists of servers to keep updated is only going to overcomplicate things. And yes your hosts file is another example of a list.
  - trumpdong 4mo ago
    How does your DNS system know? There's always a list of all systems somewhere.
- kube-system 4mo ago
  You probably don't need service discovery if your entire infrastructure is small enough that the whole thing is deployed with Ansible.
- throwway120385 4mo ago
  What you're asking is akin to "why do people sometimes need a boat to get from point A to point B? All I've used are cars and I think that should be fine."
- XYen0n 4mo ago

simonjgreen 5mo ago

This author has clearly never operated internal infrastructure at scale. The measures proposed in this are home lab grade at best, and require ludicrous levels of precision and overhead for something that changes thousands to tens of thousands of times per day. And for very specific nit picks, and I can’t believe I’m entertaining this idea enough to ask, but tell me how the new device on the network bootstraps without DNS? And the guest device. And the printer without Ansible support. And the NDI receiver that needs to resolve its host. And how do you resolve split brain resolution for roaming devices? Are you going to publicly address all internal resources now so my laptop keeps working outside the office? DNS was not created as a random solution looking for a problem…

louwrentius 5mo ago
I wasn't talking about an office environment. I'm talking server-to-server communication. Like all the internal infrastructure to support a web application. Maybe I should have been more explicit about that. How a new device bootstraps on the network without DNS? Depends, on the device, but a physical server doesn't need DNS, only PXE boot / TFTP / HTTP as usual and maybe a proxy to access an update server if you don't run one yourself.
- JackSlateur 5mo ago
  "How a new device bootstraps on the network without DNS?" DHCP
protocolture 5mo ago
OP will just reinvent Netbios running over Ansible.

protocolture 5mo ago

>DNS Is for People DNS is for Infrastructure, people use infrastructure. >That got me thinking, why would we use DNS for infrastructure services? It isn't necessary for machine-to-machine communication. Instead of configuring domain names that may not resolve, we can just directly inject the appropriate IP address(ess) into configuration files. It's easy to configure systems with tools like Ansible or pyinfra at scale. No no no no god no. "What if we set up a convoluted higher level application solution" This is going to go wrong more frequently and contain more errors than DNS. >Fortunately, we still have /etc/hosts, which we can easily provision. Still no DNS service required! This way, we can configure domain names and pretend to use DNS. I also suspect that DNS queries against /etc/hosts are quite responsive. No thats a horrible idea. Userspace should never be updating your hosts file, users will fall behind on changes and be placed at extreme security risk. Fully half the benefit of UAC on windows is preventing persistence by preventing malicious entities from updating hosts. >As of today, most network traffic is encrypted by default, or tunneled through an encrypted channel. DNS is - by default - the exception. DNS is mostly secure now, to the point where its a problem. But thats a vendor issue not a you issue please dont attempt to solve it. If you go full encrypted DNS you generally also get dragged into HTTPS proxying and things of that nature. This does not get better by removing a dynamic protocol for querying names. >Due to this risk, there is a case to be made, to - at least - not allow systems to query public DNS records. As servers may need to interfact with services on the internet (update servers, APIs, and so on), such access can be facilitated by a proxy server using allow-listed domains. Attackers use DNS because its versatile and resistant to the very issues you keep confidently presenting. A protocol is not a risk just because hackers use it. Hackers also use HTTPS and other protocols but we arent burning them at the stake. >That said, I think it's reasonable to explore if DNS can be avoided altogether within the IT infrastructure to increase reliability and robustness. Its reasonable for people with much better understanding of the infrastructure and protocol to examine these things. This reads like an end user suggesting "what if we deliver websites by hand printed on paper".

cobbzilla 5mo ago

FTFY: DNS was for People Now it’s for machines

tikhonj 5mo ago

DNS is a database.

frollogaston 5mo ago

Why is DNS for people only? The article suggests rolling your own DNS with static config, which I could see myself doing in the right scenarios, but you can't always do that. Kinda reminds me of Kubernetes, though instead of /etc/hosts it runs an actual DNS server.

davkan 5mo ago

I’m not sure I’ve seen unanimous agreement in an HN comment section before so that’s nice I guess. But to address the article in a simple environment dns _just_works_. I’ve never once had an issue with bind. It’s incredibly simple and stable and easy to understand when working with within a small environment without much churn and enables other technologies to operate in an expected way because it’s the standard. ACME, kerberos, sshfp, many more are enabled by DNS. Sure maybe you can kludge some of that back together with hosts but I’d rather not just to replace one of the most stable services that exist. DNS does start to get more complicated in massive environments but that’s just a reflection of the environment. Using ansible to manage /etc/hosts across hundreds or thousands machines with churn will not be less complicated to manage than dns.

rho138 4mo ago

That’s not how DNSSEC works… it’s sole purpose is signing - not encryption. > https://www.rfc-editor.org/info/rfc9364/#name-dnssec-core-documents https://www.rfc-editor.org/info/rfc9364/#name-dnssec-core-do...

ritcgab 4mo ago

DNS is a federated, read-optimized, geo-replicated key-value store with eventual consistency.

ryanshrott 4mo ago

Everyone's dunking on /etc/hosts, but I've debugged enough production DNS loops to get the temptation. It's not the right answer, but the impulse isn't crazy either.

throwway120385 4mo ago
At the very least you can put it at the bottom of your /etc/resolv.conf prioritization and put some backup systems like an SSH bastion in /etc/hosts so that there's some system out there that you can reach with mutual-auth in the event that your DNS is REALLY messed up.

jverce 4mo ago

How would Kubernetes work without DNS?

solatic 4mo ago

Use Ansible to update /etc/hosts on hundreds of thousands of hosts every time a host is added or removed? Thanks for the laugh...

monkpit 4mo ago
Isn’t this just DNS with extra steps, anyways? Now Ansible is the DNS server, basically.
- solatic 4mo ago
  It replaces DNS's pull-based architecture (contact a DNS server to get the IP address) with a push-based one (push the IP addresses to each /etc/hosts file). Suggesting that a push-based, Ansible-based architecture will scale to hundreds of thousands of targets, with such pushes happening hundreds if not thousands of times a day, is a junior-level idea at best, dark comedy if I'm being charitable, and professional malpractice at worst.
  - colechristensen 4mo ago
    There are two kinds of junior engineers. Only hire one of them. (being very wrong is fine. Being CONFIDENTLY very wrong is not)
  - trumpdong 4mo ago
    This sounds a bit like saying: don't use MySQL, because it can't scale to one billion requests per second. How many applications are actually running at that scale?
    - solatic 4mo ago
      Did you read the original article? > The Facebook / Meta outage was so significant The author specifically called out the Meta outage, as if he was offering a prescription ("It's easy to configure systems with tools like Ansible or pyinfra at scale") that would have prevented Meta (at Meta's scale) from suffering an outage. The argument that Meta should not have used DNS except that Meta runs at a scale where DNS is necessary... who comes up with these arguments?

ranger207 4mo ago

Fundamentally the point of DNS versus Ansible updating /etc/hosts is the same: get a mapping from DNS named to IPs to the client. As such, Ansible will have all the same issues. Plus, it'll introduce its own issues, like the fact that /etc/hosts is effectively cached DNS with an infinite TTL

nemothekid 4mo ago

>Fortunately, we still have /etc/hosts, which we can easily provision This is the kind of thing you read in a post-mortem and wonder how they designed something so fiendishly wonderful. At 2:00am our MySQL master failed and failed over successfully to our secondary server. As part of post-failover ops, ansible playbook proceeded to login to 1000 instances to update the hosts file for the new master. This caused traffic amplication which caused our Etcd nodes to believe they were down. As the etcd nodes failed over, our ansible playbook proceeded to then login to 1000 instances to update the hosts file... Honestly, whatever system you built is justing do the same exact function as DNS just with extra steps. If you squint really hard /etc/hosts is your local dns cache and ansible is your resolver. I think this kind of "simplification fetishization" is dangerously attractive to people who have only managed relatively simply setups. I don't think anyone who has ever had to deal with high-availability failover would consider Ansible a good solution. The problem that so many people hit with DNS isn't specific to DNS the protocol - it's the problem of service discovery. This architecture doesn't eliminate service discovery, it just moves it to a far more brittle configuration.

protocolture 4mo ago
I had an ISP customer years ago that had an AAA system designed by people who didnt understand DNS, DHCP or RADIUS. They also had no idea about netflow or SNMP. The application would log into every router in the network and run a massive, on the fly script to manually create a bunch of PPPOE services, shaping targets for those connections, update firewall rules etc. It would also run manual mikrotik bandwidth tests across every logical link it was aware of. The application developers were adamant that this was the best way of doing things, and any disagreement would have them point at their dozen or so customers and boast that they surely wouldnt have been able to hoodwink that many people if they were doing it wrong. Anyway we took a packet capture of all the every 10 minute script updates and demonstrated those to the customer as a whole number % of their bandwidth to certain smaller sites, and also were able to show them how they stopped getting "My internet goes out every 10 minutes" complaints as we turned off the automatic mikrotik bandwidth tests running every 10 minutes. But to save their customer the application developers agreed to implement SNMP and RADIUS but they never did. IIRC their fee was a flat 15% of all profits generated by the customer, which was just staggering. And the fee could rise if they asked for support.

Twey 4mo ago

John Day talks about this a fair bit: what people want to do is naming of applications, in a way that makes it independent of addressing (i.e. where the application is running). DNS still names the machine — it's just a one-step abstracted machine addressing scheme, not an application naming scheme per se. Then we designed an ad-hoc protocol on top that associates applications with specific machine names (and port numbers): if you go to facebook.com:443 (a.k.a. https) you expect to find an instance of the Facebook application, not a webmail client or an SSH server. This isn't how any of this was really supposed to work. Back in the day the application identifier was the _port number_, according to a big list maintained by ICANN. The idea was that you could go to a machine (identified by IP or more conveniently by DNS) and see if it was running an instance of the ‘Facebook’ application, i.e. you'd find Facebook not at facebook.com:https but at meta.com:facebook. The end goal was to eliminate the need for the former part at some point, and come up with a better way of looking up applications than distributing a list by email. Instead the application ID is now used for transport and the host name instead encodes application ID, which it was never meant for, and that's why we can't have nice things (like device mobility).

gbraad 4mo ago

The title indicates a wrong assesment: as DNS provides indirection, a means to allow a system to group, balance, etc based on a record to an/a set of address(es). Not even considering to open the link as it sounds absurd. I take from some of the other comments he uses /etc/hosts on hosts with Ansible to provide resolving. Sounds convoluted as /etc/resolv.conf and libc resolvers works. Go for the lowest fallback and dump files with Ansible. Homelab with extra steps, as setting up a DNS server is easy, ... Consider coredns, dnsmasq, if bind is too much

vel0city 4mo ago

Why bother with all the issues and difficulties of hosting a web server when I can just SCP all the files to everyone's computers constantly?

sohex 4mo ago

This has a serious case of in-housing the edge cases that I don’t think many would want to pay the price for. The problem with DNS per the haiku isn’t that it’s difficult to understand, or even that running your own DNS server is particularly difficult. It’s that coordinating information and exchange at scale is a tricky problem with a lot of non-obvious edge cases and foot guns. So trying to reduce complexity by sidestepping DNS really doesn’t do that, it just leaves you holding the bag on all the problems that DNS was quietly solving for you in the background.