I had this idea and had began to code it but never finished as the need evaporated first.
The DNS server has the host names and MAC addresses of all the machines on its LAN and a way to reach them. When it receives a request for a machine it knows, it sends a reverse ARP for the IP address given the MAC address and uses the response to construct the DNS answer.
This is nothing to do with what you are trying to do, but it illustrates the point. A DNS server can in theory be coded to carry out whatever novel scheme you want to resolve names to IP addresses.
The actual question appears to be how to get the customer's IP address to decide where to send them. This is a small bit of an XY problem. What you really want is the customer's ISP to geolocate on, and you can get that by doing it directly off the IP address making the request, assuming it isn't 8.8.4.4 or some other DNS redirecting service. To my mind, the best solution to the DNS redirectors is to ignore the problem and do a self-relative geolocation (that is, from the DNS server try to locate the calling IP address) and redirect appropriately. See here for how to geolocate: https://stackoverflow.com/questions/2574542/location-detecting-techniques-for-ip-addresses
You really really don't want anycast here but something more sane. Anycast has the annoying property is it can reroute packets in the middle of your TCP stream causing mass confusion.
Ron Maupin claims that anycast is route-reliable for TCP. Here is the traceroute showing otherwise:
3 cr1-rhe-a-be153.bb.as11404.net (174.127.183.14) 20.657 ms 20.763 ms 19.660 ms
4 cr1-che-b-be-2.as11404.net (192.175.29.161) 22.550 ms 23.562 ms 23.538 ms
5 * cr1-9greatoaks-hu-0-6-0-20-0.bb.as11404.net (192.175.28.108) 24.409 ms 38.083 ms
6 72.14.222.146 (72.14.222.146) 40.038 ms 39.106 ms 39.125 ms
7 108.170.242.225 (108.170.242.225) 37.930 ms 108.170.243.1 (108.170.243.1) 35.434 ms 108.170.242.225 (108.170.242.225) 33.694 ms
8 209.85.240.249 (209.85.240.249) 33.476 ms 108.170.232.65 (108.170.232.65) 31.683 ms 108.170.234.155 (108.170.234.155) 30.754 ms
9 google-public-dns-b.google.com (8.8.4.4) 30.491 ms 28.644 ms 25.718 ms
If you try to geolocate the upstream IP addresses the obvious way you get they're both in Wichita. This is not correct by which a simple demonstration of physics will suffice.
The range to 8.8.4.4 is measured at 30ms of which the first 18ms is the local penalty (hop 3 is my ISP's local router). My distance to Wichita is 1297 miles. The minimum round trip time is therefore (1297 * 2 miles / 225,000 kilometers per second (speed of light in glass)) which is 18.55ms. Therefore I should get no response back faster than 28ms but I got one back in 25ms.
The packets are arriving at Google by two different BGP routes. BGP did not pick the closest.