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.
Since when is that any kind of argument? The real questions are
whether it CAN work well for this and whether there's something else
that can do it better/easier.
- DNS is often out of sync with reality
Dynamic DNS updates are your friend.
From an app developer's point-of-view, DDNS is worthless. DDNS is far
from universally implemented, and when it is implemented, it's often
implemented badly. DDNS can actually makes DNS a less reliable source
of information about the host.
- DNS is slow and unreliable.
It doesn't have to be, running a decent DNS service isn't rocket
science.
Sometimes DNS is slow and unreliable because of poor server
administration; sometimes it's slow and unreliable for other reasons.
The very design of DNS is starting to look like an anachronism.
- many networks use other ways of doing name to address mapping for
local hosts.
Not sure what you mean here.
Let me put it another way - lots of hosts that need to participate in
distributed apps aren't listed in public DNS.
- there's no good way for hosts to know their own DNS names
Again, dynamic DNS updates.
Doesn't solve the problem, especially when DDNS is done by some DHCP
server rather than the host itself.
- more generally, there's no good way for a host or an app to know
what a DNS name means.
This one can be problematic but it's not a fundamental problem but
rather a local management problem: apps should be able to obtain the
local hostname that they can use for referral purposes.
There's no standard way to do this - and the right name can vary from
one app to another on the same host.
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.
I wouldn't have a problem with that except that people somehow think
that IP addresses DO fulfill all the requirements for being stable
references.
Using DNS names as identifiers for referrals has problems.
Using IP addresses as identifiers for referrals has a different set of
problems. But IP addresses are a lot closer than DNS names.
In traditional IPv4 they did to a large degree, but then NAT came
along. With IPv6 a single host routinely has multiple addresses (of
more than one scope), and with MIP and shim those addresses change
from time to time. IP addresses are what get the packets from point A
to point B. That's hard enough. Stable identity needs to happen at a
higher level, and rejecting DNS names for this because of a few
simple operational difficulties is a bad idea.
I wasn't talking about stable references - I was talking about
references that are valid, for a short time, from anywhere
in the network. Stable references are a different problem.
But even in that case, it's not clear how to fix DNS to be reliable.
Protocol quality issues aside, there's not anything like a consensus on
how DNS should be used.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf