resolving differently depending on location?

[Kevin Darcy]

Sten Carlsen wrote:

>As I understood, it was only intranet servers?
>In that case views could be effective, because the views can be selected
>by IPs, which typically will be sorted geographically.
>
Yes, that would be the gold-plated approach. *Every* zone that the 
clients cared about would have to be present in every view, of course, 
with only the location-differentiated entries having disparate values 
between views. And if -- like us -- one has old legacy, non-dynamic 
clients that get moved from one location to another and thus end up 
pointing at the "wrong" (non-local) nameserver, then to be safe, every 
nameserver would have to serve every view. Now we're looking at 
combinatorial amounts of memory and long load times here...

Views might work in a small and/or tightly-controlled environment. The 
best we can manage for now is a sortlist approach.

Bear in mind that modern Wintel networking stacks by default 
*automatically* sort addresses on the same subnet as the client to the 
top of the list, no matter how they came from the nameserver (see 
knowledgebase article #182644). So, if you're small enough, or your 
network topology is simple enough, and well-funded enough that you can 
arrange to always have a target server on the same subnet as the clients 
it serves, and they're all Wintel clients beyond a certain vintage, then 
you can just define a round-robin for the servers and you're done.

Of course, hybrid approaches (Windows subnet-sorting and/or sortlist 
and/or views) are possible...

                                                                         
                                                - Kevin

>
>Barry Margolin wrote:
>
>  
>
>>In article <dj17cv$2hks$1 at sf1.isc.org>,
>>Kevin Darcy <kcd at daimlerchrysler.com> wrote:
>>
>> 
>>
>>    
>>
>>>BIND *does* however, have support for "sortlist". One can have the name 
>>>resolve to all of the location-specific IPs, and then sort them 
>>>according to the source IP of the DNS client. This only works 
>>>*reliably*, however, when the sortlist configuration of all resolvers is 
>>>tightly controlled.
>>>   
>>>
>>>      
>>>
>>Right, so it's useless for a public web site.
>>
>> 
>>
>>    
>>
>>>Note that the sortlist approach also assumes that the DNS client address 
>>>is also the same as, or close to, the client for whatever service one is 
>>>trying to provide (HTTP, SMTP, whatever). Due to proxying and numerous 
>>>other factors, this isn't always a good assumption. But Akamai and 
>>>others seem to do fairly well making exactly the same assumption, so YMMV...
>>>   
>>>
>>>      
>>>
>>If you're just trying to select a server on the same continent or ISP 
>>backbone as the client, the assumption will be pretty good.  Also, many 
>>ISPs make use of anycast for their resolvers, so the resolver will be 
>>relatively close to the client on the backbone; therefore, choosing a 
>>server close to the resolver should be OK.
>>
>>While there may be occasional cases where it doesn't choose the optimal 
>>server, on average it seems like it can be expected to be better than 
>>random choice.  But having the server do it at the application level 
>>should generally be even better.
>>
>> 
>>
>>    
>>
>
>  
>