5 ms·

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

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.

otabdeveloper4 3y ago
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.)
dilyevsky 3y ago
You’re thinking of FNS
whalesalad 3y ago
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.
- pixl97 3y ago
  Yea, how exactly is things like TLS supposed to work without using DNS!
midasuni 3y ago
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
- jovial_cavalier 3y ago
  /etc/hosts ?
- vinay_ys 3y ago
  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.
  - moondev 3y ago
    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
- marcosdumay 3y ago
  > 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.
sneak 3y ago
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.
- charcircuit 3y ago
  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.
  - pixl97 3y ago
    db-server-4x-16g.cluster1.fqdn contains a lot of information outside of an external lookup.
    - vinay_ys 3y ago
      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?
      - aaronax 3y ago
        Cnames, reverse records, TXT records, the sky is the limit
        Spivak 3y ago
        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.
mondomondo 3y ago
[dead]

otabdeveloper4 3y ago

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

dilyevsky 3y ago

You’re thinking of FNS

whalesalad 3y ago

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.

pixl97 3y ago
Yea, how exactly is things like TLS supposed to work without using DNS!

midasuni 3y ago

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

jovial_cavalier 3y ago
/etc/hosts ?
vinay_ys 3y ago
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.
- moondev 3y ago
  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
marcosdumay 3y ago
> 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.

sneak 3y ago

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.

charcircuit 3y ago
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.
- pixl97 3y ago
  db-server-4x-16g.cluster1.fqdn contains a lot of information outside of an external lookup.
  - vinay_ys 3y ago
    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?
    - aaronax 3y ago
      Cnames, reverse records, TXT records, the sky is the limit
      - Spivak 3y ago
        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.

mondomondo 3y ago

[dead]