[dns-operations] Vista implements a bizarre DNS server selection algorithm from RFC3484?

[Joe Greco]

> > Given that IP(v4) space is delegated in a regional manner, it  
> > wouldn't be
> > completely insane to use that knowledge to try to optimize for a  
> > closer
> > server.  Coupled with the client's *actual* IP address, one could  
> > then use
> > it to pick the closer server.
> 
> Unfortunately, that doesn't always work.  Many multi-nationals use,  
> say, RIPE space in Asia, or APNIC space in the US.  This is common  
> enough to make using geography based on allocation wrong (sometimes  
> spectacularly wrong) enough of the time to probably wash out any gains.

Yes.  However, because this is a decision made by the client side site,
and we're talking client logic, that's something that you can configure 
around.

>From the server's side, it's spectacularly difficult to passively detect
this, but from the client's side, you can *know*.  I don't see this as
being even much of a speedbump.  You have to be able to have a way to
configure knowledge of IPv4 RIR assignments anyways.

There's also an argument to be made that there's no reason to expect that
a RIPE IP trying to reach another RIPE IP won't transit through the US on
its way, though I've heard it several times that this is becoming
increasingly uncommon.

> > Of course, a GSLB system at the other end may be trying to do the same
> > thing, based on the IP address of the recurser in use, which we all  
> > know
> > has some ins and outs.
> >
> > I guess the real question is why we have failed to design and  
> > implement
> > a standard to allow both clients and servers to specify, learn, and/or
> > infer some useful information about topology and performance that  
> > would
> > allow programs to automatically make intelligent decisions in an  
> > automated
> > manner that would also allow configuration by administrators.
> 
> Is that a good idea?

Yes, it is, without any doubt.  At least, it's a better idea than anything
done today on a wide scale.

> One of the issues with the idea of a client-side making a decision on  
> which end point to reach is the assumption the server-side is not  
> smart enough to figure out the best resource allocation of its own  
> resources.

By the time a client has connected to a server, Patrick, it's too late.
The decision has already been made.

Solutions such as DNS based GSLB's may attempt to "solve" this by making
guesses about where to punt a client, but they're using the recurser IP
address, not the client's.  This can trivially fail in many cases.  There
is no guarantee about the closeness of a recurser to the client.

> If you make that assumption, fine.  But even if you assume the server- 
> side has any intelligence at all, or even is just allocating things  
> randomly, then doing anything other than blindly accepting the  
> server's decision is counter-productive.
> 
> And since we have no way to signal "this server knows what it is  
> doing" vs. "this server is stupid", I think the safer assumption is  
> the server is doing something intelligent, or at least random.

But, Patrick, what did I just finish saying in my quoted message?
I would like to see a system where *both* sides could participate in the
process, because that's the only way to really cover all the cases.

If we allow a client to connect to an IP that it selects from a list
provided by the server's DNS system, the server lacks any means to
guarantee that this is most optimal, since it has no idea where the
client really is.  At that point, the remote server might be able to
VPN traffic to a closer cluster or something like that to improve the
efficiency somewhat, but you're still screwed out of a most-efficient
scenario.

Yet allowing the client to be "smart" all on its own is risky as well,
see what started this thread.

What I'm suggesting is that there ought to be some intermediary standard
that would allow clients and servers to "discuss" the issue of optimal
path.  For example, consider a strategy where the client contacts a
server, any server because we're talking a DNS-like one packet exchange, 
and basically says "I'm looking to connect to your service, provide me
with some guidance."  A simple response of "based on your location, we
suggest one of these IP addresses."  The client would then be free to
"ping" each server, maybe taking RTT and TTL into account, in the process
this could also verify availability and locally-generated preference
values (think: a server that's maybe too busy or at its bandwidth
capacity).  Client then makes a choice.  Or maybe the client is even
constrained to a single choice by what the server(s) replied.

There is a lot more real knowledge and potential for intelligence in this
system than there is in the currently deployed solutions.  It doesn't
prohibit the server from doing something smart, it merely adds the
ability for the client to also do something smart.

There's this big, gaping hole in the ability to get people connected
somewhere reasonable.  What I've described is just one trivial example
of things that could be done.  An official standard that would allow
smart clients and smart servers to discuss and discover optimal routing
would be a very interesting thing.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.