resolving differently depending on location?
Kevin Darcy
kcd at daimlerchrysler.com
Tue Oct 18 00:12:39 UTC 2005
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.
>>
>>
>>
>>
>>
>
>
>
More information about the bind-users
mailing list