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