Lookup answer depends on query source

[Kevin Darcy]

Mr. Chow Wing Siu wrote:
> Dear all,
>
> I wanna setup as follows:
>
> Use-case ONE)
> Query source for xxxx.com from:		Lookup IP answer:	
> *.hk					111.111.111.111
> *.cn					111.111.111.112
> *.uk					111.111.111.113
>   
Use-case one is going to be very difficult and unreliable, since not all 
client addresses have reverse-resolution, and, even if they do, it might 
map back to a gTLD (e.g. .com) rather than a ccTLD. What do you do if 
the query-source maps back to a .com name?

Also, BIND has no provision for basing view matches on the 
reverse-lookup of the client's address. This is a potentially dangerous 
thing to do, since if you let arbitrary clients trigger your nameserver 
to perform reverse lookups, you're creating the  possibility of DoS or 
DoS-amplification attacks. At the very least, you might be introducing 
an unacceptable amount of delay into the name-resolution process, since 
the reverse namespace is, notoriously, even less well-maintained than 
the regular "forward" (name-to-address) namespace, and often subject to 
long lookup delays due to broken/stale delegations, etc.
> Use-case TWO)
> Query source for xxxx.com from:		Lookup IP answer:	
> 222.111.111.111 (from country A)	111.111.111.111
> 226.111.111.111 (from country A)	111.111.111.111
> 228.123.111.111 (from country A)	111.111.111.111
> 222.111.222.111 (from country B)	111.111.111.112
> 226.111.222.111 (from country B)	111.111.111.112
> 228.125.111.111 (from country B)	111.111.111.112
>
> Using BIND view to setup seems to be not so good.  Isn't it?
> Then, do anyone knows how to setup as above?
>   
Use-case two is perfectly doable using "match-clients" views in BIND. 
You'd have to constantly maintain the match-clients clauses, however, 
which would more likely be address *ranges*, as opposed to specific 
addresses (as you show above).

Be aware that with any view-based approach you have *multiple* copies of 
each zone in memory at any given time. So this may be considered a 
non-scalable solution.

Note that, with either use-case, if your goal is to perform 
network-level optimization, be aware that the identity of a client's 
*resolver* may not reflect the actual location of the client *itself*. A 
web browser in India, for instance, may be using a DNS resolver, over a 
fast internal corporate link, in the United States, so do you really 
want to "optimize" that by giving out U.S. addresses to an Indian client?

Ultimately, it would be nice if someone could come up with an 
"on-behalf-of" DNS extension, which would carry information about the 
actual *client's* address (as opposed to whatever resolver happens to be 
processing the client's request) so that an optimizing nameserver would 
know exactly what it's trying to optimize for. But, even if someone were 
to come up with such a thing, it would take probably a decade or more 
before it was actually deployed everywhere...

In the meantime, we have the "nifty tricks" of companies like Akamai to 
give us something that more-or-less meets these requirements. For a price.

                                                                         
                           - Kevin