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

[Patrick W. Gilmore]

On Mar 6, 2009, at 11:20 AM, Joe Greco wrote:

>>> 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.

The client can only know geography / latency, and latency can only be  
known with work done at the time of connection.  Geography can be  
known pre-connection - if you get lucky.

The server, OTOH, can pre-calculate a lot of stuff.  (I guess  
theoretically the client can too, but I don't think that's  
reasonable.)  The server also knows about its own resources, which the  
client does not and cannot know.  If a server hands out two IP  
addresses, you have every reason to believe the server expects them to  
be loaded evenly.  Geography / latency is not a good way to guarantee  
even loading.  Why would you intentionally work against the intentions  
of the owner of the resource?


>>> 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.

We disagree.


>> 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.

Wow, I didn't think you were that confused.

Look at Google's GGC for just one pretty minor example of how wrong  
your statement is.


> 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.

Of course not.  Fortunately objective reality shows that it works high  
90s percent of the time.  And most of the time it is wrong, the  
"wrongness" is still not horrifically wrong (e.g. nameserver in SJC,  
host in IAD).

I do not have numbers, but I would bet that this matching is much  
higher than the RIR/geography matching.  (Sorry, we don't use RIR  
geography to map things.)

I do have hard numbers that the idea of doing a redirect or latency  
test _at the time of connection_ is on average slower than this tiny  
percentage of disoptimization for all but the largest files (e.g. 100s  
of MBs or GBs), and even then only for the worst of misdirected clients.

Of course if you are in South Africa, South America, some South East  
Asian countries, etc. (hrmm, I see a pattern forming here :), then  
things change.  But the entire traffic to Africa is smaller than some  
cities in the EU or North America.  Doing more work in the vast  
majority of cases to optimize the corner cases is silly.  And even in  
those corner cases, the server _can_ optimize without harming the rest  
of the clients.  Look at most CDNs or Google's GGC for just two  
examples.

IOW: Let the server do it.  The server has more information and can  
make better decisions.  The client does not, and therefore cannot.


>> 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?

Yeah, Joe, I'm the one not listening to you.


> 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.

[snip]

I think you'll find that unless you are downloading DVDs from across a  
continent or ocean (and sometimes not even then), the extra work done  
to optimize things actually makes the whole experience worse than just  
doing it the way we do it today.  You know, because no one has  
actually thought of this before or tested it or anything.  But I'm  
happy to be wrong.  Anything that improves user experience is a Good  
Thing, IMHO.

Good luck.  Let us know what you find.

-- 
TTFN,
patrick