Re: Why DNS sucks for referrals (was Re: Stupid NAT tricks and how to st

Are you saying that ENUM is a dead end?

F.

--
francois(_at_)menards(_dot_)ca
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(_at_)ietf(_dot_)org
> https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf