- 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.
In network operations you always see that stuff that isn't really used
is a big mess, because nobody cares to set it up correctly in the first
place and/or maintain it after that. Since current peer to peer
applications (the applications that use referrals) don't bother with the
DNS and for non-servers its only other purpose is looking pretty, it's
no surprise that DNS info isn't very good.
Of course a big part of the reason that distributed apps (not just p2p
apps) don't consistently use DNS is that it doesn't work well. But it's
not quite a chicken and egg problem. DNS cannot really work well for
referrals. Core design assumptions in DNS no longer apply.
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.
If it's good enough for the web and email, why wouldn't it be good
enough for p2p? (Which in itself is often very unreliable.)
I'd argue that DNS is NOT good enough for the web, and maybe not good
enough for email. When you click on a link and it takes seconds before
the page even starts loading, that's probably DNS. Email is less delay
sensitive, but when you send mail and it bounces because the MX records
were out of sync with reality, DNS is implicated there also.
Some p2p apps are unreliable because they are trying to layer over a
network that imposes arbitrary restrictions on its use (unlike the IP
design that assumes best effort) and on top of hosts that appear and
disappear at a whim. Even then, they sometimes work better than
client-server apps that try to serve the same purpose.
- 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.
Because there is little reason for them to be.
But by expecting distributed apps to use DNS, you would be imposing the
operational constraint that all of those hosts be listed in DNS.
But even if that's something that continues to be so, it would still be better to use the
DNS when available and use the address otherwise, rather than ignore the
DNS completely.
adding complexity that makes your app less relable is usually not a good
way to go.
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.
With the difference that the DNS is the control plane where you have
time to think about stuff, while IP is the data plane where you need to
perform millions of lookups per second.
no. DNS is just an app that lets other apps find out certain kinds of
information about certain resources on the network. It's nowhere nearly
flexible enough to be a control plane.
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.
If we can agree which problem should be solved where, then consensus on
the details becomes a lot easier. What I'm saying is that the IP address
wont be an identifier stable enough to handle referrals in the future,
so any protocols that make this assumption won't work very well.
What I'm saying is that if IP addresses won't be stable enough for
referrals in distributed apps, they won't be stable enough for referrals
in DNS either.
Keith
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf