it would be okay if the only apps you needed to run were two-party
apps. in other words, it's not just users and hosts that need
addresses to be the same from everywhere in the network - apps need
stable addressing so that a process on host A can say to a process on
host B, "contact this process on host C at address X and port Y"
Isn't this the kind of stuff the DNS was invented for?
not really. and even to the extent DNS was invented for this, it
doesn't work well in practice.
- DNS is often out of sync with reality
- DNS is slow and unreliable. DNS servers and the links to them do not
share fate with the hosts whose RRs they serve. DNS lookup delay is
often considerably longer than the RTT to the host.
- many networks use other ways of doing name to address mapping for
local hosts.
- there's no good way for hosts to know their own DNS names
- more generally, there's no good way for a host or an app to know what
a DNS name means. a DNS name is not irrevocably bound to a particular
host for all time, but rather, associates some role or service name with
a particular address. a single host may support more than one such role
or service at any particular time, but the set of roles or services
supported on a host will change over time.
- furthermore a single role or service with a single DNS name might be
supported on multiple hosts, and DNS be used to specify which hosts are
providing that particular service. this might be sufficient on an
initial connection when any one of those hosts will do; but this is not
sufficient when an app needs to know how to contact a process on a
particular one of those hosts.
IMHO, DNS is best used as a sort of bootstrapping mechanism - a way for
an app to get an initial contact point for some service. After that
initial contact is made, DNS is contraindicated.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf