Live data from Hacker News

DNS is for people, not for IT infrastructure

louwrentius.com

81–90 of 102 posts

Re: DNS is for people, not for IT infrastructure

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

Re: DNS is for people, not for IT infrastructure

#82

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

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.

Re: DNS is for people, not for IT infrastructure

#83

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

One does not even need to squint. The first page of RFC 882 explains outright that the DNS came about in the first place because the mechanisms for updating a HOSTS.TXT file and publishing it to loads of places did not scale.

That's still just as true for the intranets of the 2020s with thousands of machines all downloading a HOSTS file several times a day (or even hour/minute) as it was for the Internet of July 1983 with around 500 hosts that was merely downloaded by everyone a couple of times per week. The fact that a file can be copied faster now is counterbalanced by the fact that tying this to real-time failover means that it needs to be updated and distributed several orders of magnitude more quickly than it was in 1983 too. And that's ignoring the linear nature of a HOSTS file lookup contrasted with even the stupidest DNS implementation.

Those who think that HOSTS is a fallback for any sort of dynamic operation (into and out of service) of even hundreds of machines have not learned the history of why the DNS even exists.

Re: DNS is for people, not for IT infrastructure

#84
post #6

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

"It is not really true that DNS is for people only" Yes, "Any problem in computer science can be solved with another level of indirection... except for the problem of too many layers".

DNS is one mechanism of adding a layer of abstraction.

Re: DNS is for people, not for IT infrastructure

#85
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).

Re: DNS is for people, not for IT infrastructure

#86
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

Re: DNS is for people, not for IT infrastructure

#87
post #83

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

One does not even need to squint. The first page of RFC 882 explains outright that the DNS came about in the first place because the mechanisms for updating a HOSTS.TXT file and publishing it to loads of places did not scale. That's still just as true for the intranets of the 2020s with thousands of machines all downloading a HOSTS file several times a day (or even hour/minute) as it was for the Internet of July 1983…

>The first page of RFC 882 explains outright that the DNS came about in the first place because the mechanisms for updating a HOSTS.TXT file and publishing it to loads of places did not scale.

Great piece of history. The RFC is a bit older than I am so I've never studied it. Looking at it that way, then OP has just re-invented DNS.

Re: DNS is for people, not for IT infrastructure

#88
post #6

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

"It is not really true that DNS is for people only" Yes, "Any problem in computer science can be solved with another level of indirection... except for the problem of too many layers". DNS is one mechanism of adding a layer of abstraction.

No disagreement there, but this layer of abstraction (mapping names to unique numeric machine identifiers) seems unavoidable for the most part: even the OP does not propose doing away with it, just replacing one tech with another (eg. DNS with /etc/hosts).

So let's not make a general argument when there are specifics to be discussed — do you have an argument for why mapping names to IDs is an abstraction too much here?

Re: DNS is for people, not for IT infrastructure

#90

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

> Ansible

Shell scripts wrapped in YAML

Post reply on HN