Lookup answer depends on query source

[Jing Cao]

So if the client uses a DNS resolver, the DNS who is responsible for the
name translation will only "view" the DNS resolve's IP, not the client's IP?
If yes, then the view in the DNS doesn't mean anything for that client.
Will the DNS resolver tell the DNS who is in fact request the name
translation?


2008/10/14 Kevin Darcy <kcd at chrysler.com>

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