> > first we would need a naming system that is fast and reliable. > > and referrals of addresses trades off reliability for a little speed.
when you're trying to complete a phone call, or trying to coordiate between hundreds of processes in a distributed computation, a 10 second delay in your message being transmitted due to a DNS lookup is simply not acceptable. (heck, it's not even acceptable when browsing the web from over a cell phone...) > As > you note here, some DNS servers are two faced, so how does referring > addresses actually work in that case? The referring node would have to > know the entire topology including the DNS server boundaries to be able > to send the right addresses (if it could even get a complete list). It > would be much simpler for the app to send the name string and let the > receiver find the traget address list from its own topological > perspective. You're missing something important, which is that the DNS server doesn't have a much better idea of which addresses work for the app than the app itself does, especially given that the DNS query might have been routed through one or more intermediaries in different parts of the topology. Two-faced DNS works only in very limited cases; it's not a general solution. Regardless of whether the app gets its addresses from DNS or a referral from a peer, it still has to guess about which address is best. > > no they won't. clearly you live in a fantasy land where DNS > > always works > > perfectly and lookups take only microseconds. in the real world, DNS > > fails to provide the correct answer a significant part of the time and > > lookups often take 10 seconds or more. > > So apps should pass around a potnetially bogus list of addresses? so DNS should pass around a potentially bogus list of addresses while apps shouldn't? DNS is just another way of doing address referrals. It works well in some cases, less well in others. It never has been the only way to get addresses for a resource. > I am > all for multi-party apps, but fixing the real problem with DNS seems > like a better approach than a hack that will end up failing anyway. you can't fix some of those problems, they're fairly fundamental consequences of DNS's design. for instance, the wide variation in response times seems to be a direct result of having DNS widely federated and widely distributed and the resulting lack of any reliable RTT estimates in advance of many queries (so the party doing the querying doesn't know when to time out or fail over). a lot of the unreliability (at least, last time I looked) seemed to be due to lots of zone administrators not knowing how to configure slave servers or glue records properly or to update the sequence numbers. this is what happens when you let everybody run their own servers. not that it was a bad decision overall, but it does make the idea that DNS is the only way that a app should obtain addresses sort of dubious. > > > What about IPv6 changes that? > > > > nothing about IPv6 changes that, except that IPv6 has the built-in > > expectation that an app may have to deal wth multiple addresses and > > somehow choose one of those addresses without any knowledge as > > which ones are more likely to work than others. > > > > and you think *I'm* in a fantasy land. > > trying to build complex topological information directly into the app > will fail more often than not. Pass name strings and follow > draft-ietf-ipv6-default-addr-select-08.txt. It will not be as fast, but > it will be more reliable. some apps will be better off doing this, but this is not a tradeoff that you are qualified to make for all apps. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
