Azure Traffic Manager - DNS Anycast

Question

In my understanding, while using azure traffic manager latency will calculated based on LDNS source IP, in case that's true how proximity will be calculated in case LDNS is based on anycast which existed anywhere?
or it's going to use some sort of mechanism to detect client IP address ?

Answer 1

Hello @Ajay Chauhan ,

Welcome to Microsoft Q&A Platform. Thank you for reaching out & hope you are doing well.

I understand that you would like to know how the proximity will be calculated for Azure traffic manager requests in case you are using a LDNS based on Anycast.

Traffic Manager works at the Domain Name System (DNS) level. It sends DNS responses to direct clients to the appropriate service endpoint. Clients then connect to the service endpoint directly, not through Traffic Manager.

Traffic Manager looks at the source IP of the query (this most likely is a local DNS resolver doing the querying on behalf of the user) and uses an internal IP to region map to determine the location. This map is updated on an ongoing basis to account for changes in the internet.
Refer : https://learn.microsoft.com/en-us/azure/traffic-manager/traffic-manager-faqs#how-does-traffic-manager-determine-where-a-user-is-querying-from

Traffic Manager uses a global network of name servers, and uses anycast networking to ensure DNS queries are always routed to the closest available name server.
Refer : https://learn.microsoft.com/en-us/azure/traffic-manager/traffic-manager-faqs#what-is-the-performance-impact-of-using-traffic-manager

Also, Traffic Manager can’t guarantee that the geographic region we infer from the source IP address of a DNS query will always correspond to the user's location due to the reasons listed in the below doc:
Refer : https://learn.microsoft.com/en-us/azure/traffic-manager/traffic-manager-faqs#is-it-guaranteed-that-traffic-manager-can-correctly-determine-the-exact-geographic-location-of-the-user-in-every-case

Hence, when using an Anycast DNS service, you may see strange results when querying Azure Traffic Manager URLs.

In Anycast, a collection of servers share the same IP address and send data from a source computer to the server that is topographically the closest. This helps cut down on latency and bandwidth costs, improves load time for users, and improves availability. It is important to remember that topographically closer does not inherently mean geographically closer, though this is often the case. Anycast is linked with the BGP protocol which ensures that all of a router’s neighbors are aware of the networks that can be reached through that router and the topographical distance to those networks. The main principle of anycast is that an IP address range is advertised in the BGP messages of multiple routers. As this propagates across the Internet, routers become aware of which of their neighbors provides the shortest topographical path to the advertised IP address.

The important thing to note here for Traffic Manager, however, is that these Anycast DNS services aren't always 100% accurate - in some cases, it could be geographically close, but in others, you may see unexpected behavior, especially if the nearest Anycast DNS server is particularly far away for some reason.

Anycast DNS will generally put the user close enough to their true location, but customers need to be aware of the limitations involved when using Anycast DNS services.

We've also seen instances where Anycast DNS provides cross-region redundancy. For example, a user in West US might have an Anycast server in West US, and their backup Anycast server in Central US. Due to this, they may "flap" to a different state/region if they use their backup Anycast server.

At a high-level, Traffic Manager maps the Client's DNS IP or Client IP to our internal geo-mapping and performance-routing databases. It can do this either by using the LDNS IP (most DNS servers use this), or the ECS IP, which is a newer, less-used technology.
Refer : https://learn.microsoft.com/en-us/azure/traffic-manager/traffic-manager-faqs#how-does-traffic-manager-know-the-ip-address-of-the-end-user

Extended DNS Client Subnet (ECS) extends the DNS RFC with an important new feature. Recursive DNS services that support ECS can provide the client (end-user) subnet as part of the DNS query, allowing authoritative DNS providers to use this extra information to make more informed traffic routing decisions. However, the DNS server/provider has to support the latest ECS standard (or have that feature enabled) in order to carry that client subnet info to provide better resolution of where client IP is located instead of LDNS location.

If your LDNS is ECS-Supported, Traffic Manager would use the ECS-supported IP for routing. If not, then the Traffic Manager would use the LDNS source IP for routing.

Kindly let us know if the above helps or you need further assistance on this issue.

----------------------------------------------------------------------------------------------------------------

Please "Accept the answer" if the information helped you. This will help us and others in the community as well.