is it possible for a server to know which client(IP) did a DNS query for its domain name?

Solution 1:

What are you trying to accomplish? My guess is you're trying to do something and you think "monitoring DNS is the answer" when it won't work.

If you're looking to see a hit from a client IP on every DNS request, that will never happen. DNS is layered, and clients are configured to hit a local DNS server, which will then eventually hit your DNS server.

If you're looking to see a request (from someone) on every DNS request, you can try to tune your TTL to something small, like a second. You'd then see a hit from someone, somewhere. This may not be 100% - it depends on everyone respecting your TTL, which isn't a given.

UPDATE

If I read correctly, you're trying to associate a DNS request to a future HTTP request. This will fail for several reasons.

1. Caching. DNS - IP mappings are very cacheable, and therefore they are cached heavily. Even setting TTL won't help all that much, since some ISPs ignore TTL and cache for an hour/a day or so no matter the setting. Browsers also have their own DNS cache. There are too many levels for you to control all.

2. Multiple users - one IP address. Between NAT (and Carrier Grade NAT is on the horizon) and normal multiple users per machine, you can't map an IP to a browser anymore (not that you really ever could). Even multiple browsers per user or multiple tabs could throw this system off.

3. People may use DNS for other reasons. What if someone just does an nslookup on one domain, but then hits another (with the IP in cache). You'd forward the wrong site.

4. Multiple egress points. Though less common now, it used to be very common for ISPs to proxy requests out and at times a single subscriber might get rotated on egress points (what you'd see as their IP) in even a single session. AOL used to do this a lot, and as they've dropped in popularity, I've seen other tools (mobile Opera) use proxies as well.

5. DNS forwarding does not work this way. If someone tries to look up a hostname in your site, the vast majority of the time they'll wind up asking either google's 8.8.8.8 server or their ISP's recursive DNS server. In either case, the IP address that queries your DNS server for a hostname will not be the same as the source IP address of the web browser that comes looking a moment later.

In short, you can't get there from here. IP addresses are not (not they ever have been) unique 1-1 identifiers for a user. You'd break HTTP. You're stuck looking at the HTTP stream and parsing. Make sure your proxy supports Keep-Alive and you'd lessen the hit a bit.

Solution 2:

How would the browser/user know what http request to make in order to let your proxy to determine the actual requested server?

If you plan to have a portal from which the user would select the server he wants, you could generate random subdomains for your proxy depending on the user's choices/accessibility.

You can see a similar implementation on a rebind attack demonstration where the user would go to a server and since the server knows the user's ip, server creates a new random generated subdmain, assiging the desired server ip address on the DNS record and redirects the user to that subdomain.

You can't find the user's ip address on the DNS server.

As others wrote earlier, you shouldn't rely on TTL, since not all DNS resolvers respect it.