Hacker News Reader

Comment by vinay_ys | Hacker News Reader

DNS is for friendly names; friendly to humans using web browsers. Using DNS for machine to machine communication is not essential complexity. Every chance I get I eliminate DNS from internal infrastructure and a whole lot of things get a lot better. If you naively keep forward/reverse DNS resolutions on in different parts of the stack, you end up with a shitstorm of DNS lookup requests at even a moderate scale infrastructure. Then bad things tend to happen.

View on HN

DNS is more than just pretty names, it allows for a hierarchy that holds meaning. It is way more than just friendly for humans. TBH I would posit that having everything as IP literals would cause more human errors than not. You need to keep a context of all subnetting in your mind, which is not feasible in many networks.

Yea, how exactly is things like TLS supposed to work without using DNS!

What are you using instead? Hard coded IPs? Or have you built your own lookup service?

If you have decent TTLs dns doesn’t result in a shitstorm of lookups, nor does it require anything more powerful than a raspberry pi to respond to them

Yes, it is much easier to build and scale a general config service that can serve keys (like names in dns) and associated config snippets with versioning and expiry/go-live timestamps etc. Such a service enables us to build on top of it things like service discovery, failover, draining, cutover, weighted load-balancing etc. It is much easier to also control/orchestrate/audit changes to key-configs in globally consistent transactional manner and guarantee these changes will be instantly visible to every client or will be deterministically spread-out/staggered etc. It is also much easier to do interpolation of config variables arranged in a hierarchical class namespace. All this makes it a lot more powerful building block for large scale infra services than dns ever could and it has none of the drawbacks of dns.

Now we just need a kubernetes cluster with coredns to deploy eureka!

    http://eureka-0.eureka.default.svc.cluster.local:eureka:8761/eureka
    http://eureka-1.eureka.default.svc.cluster.local:eureka:8761/eureka
    http://eureka-2.eureka.default.svc.cluster.local:eureka:8761/eureka

> If you have decent TTLs dns doesn’t result in a shitstorm of lookups, nor does it require anything more powerful than a raspberry pi to respond to them

This applies equally to any kind of lookup service you use. It's not a distinguishing feature of DNS.

The distinguishing features of DNS are that it's a global, highly regulated, key-value storage with only eventual consistency that may take days to reach. (It has probably never been consistent on practice.) None of those features are desirable for your internal servers configuration.

/etc/hosts ?

Opposite take: I consider IPs appearing anywhere except the dhcpd configuration and the DNS zone files (or their database equivalents) to be a bug.

IPs are opaque and meaningless. Maybe you can keep in your head that “.2 is the database, .3 is the web server, .4 is the redis, .5 is the other api, .6 is the other database”, but I can’t and wouldn’t even if I could.

DNS is rarely the problem.

It's not like appserver1234.internal is significantly less opaque and meaningless. Either way you probably want a control panel somewhere that can give you extra information about a node.

db-server-4x-16g.cluster1.fqdn

contains a lot of information outside of an external lookup.

this doesn't scale – what happens when you want to add another piece of information? how do you change the schema for all the names?

Cnames, reverse records, TXT records, the sky is the limit

No what happens when you want to add information to the name. Do you go through and update all your existing records? Having DNS names just be opaque ids that point to an entry in a db (which can be a TXT record) is usually a lot better.

It's the only thing you can guarantee will never change. The name points to exactly that server.

DNS offers TXT records...

What happens when “db-server-4x-16g.cluster1.fqdn” stops hosting a database?

I’m all for DNS instead of IP’s, but we need to stop encoding too much information into names…

Delete it.

This is funniest convo I heard about DNS for a long time.

Makes me wonder what GP does with the plate when he finishes his dinner.

Pets = ceramic plate

Cattle = paper plate

I'll let the reader make the connections

Not if your hostnames look like that. There is the potential in DNS for semantic hierarchy, though, if you choose to take advantage of it, that is not available in IP addressing.

heh. no, don't use IPs either. You use well-known service names and use a dedicated service discovery mechanism to reach your service nodes in a resilient and scalable manner.

Some kind of name service could return various values for you different domains. Sounds like a great idea.

You joke but Consul is usually better at being DNS than actual DNS for a lot of use-cases.

>IPs are opaque and meaningless.

Get a sheet of paper. Draw a line down the middle. Put the IP in one column. Put the thing on it on the other side. Tape to wall, or put in binder.

>...but I can’t and wouldn’t even if I could.

>DNS is rarely the problem.

People that can't even be arsed to remember where their bits are on the other hand...

DNS allows for graceful failover and balancing, using standard and platform-independent tools.

(You don't want L3 failover, trust me when I say it won't work as you expect.)

You’re thinking of FNS

Reply on news.ycombinator.com