Are you saying that ENUM is a dead end?
F.
--
[EMAIL PROTECTED]
819 692 1383
On Wed, 29 Mar 2006, Keith Moore wrote:
- 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 mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
