Whether you’re new to Traffic Director, migrating from a different Advanced Service, or a Traffic Director connoisseur, here’s how to ensure you’re using this unique and powerful tool to its full potential. No matter if you’re managing just a few DNS records or you have a complex design, these three steps will help you optimize your configuration.
First, it’s important to understand how Traffic Director makes decisions before you can make intelligent choices about configurations. The two major components of Traffic Director are Response Pools and Rulesets. Response Pools are your DNS records. Rulesets define how you want your records served. You can define Rulesets by both geographic area and by which records are available to serve. Monitoring is utilized to determine record availability, but we will mostly focus on Response Pools and Rulesets for now. Essentially, Rulesets are defining the behavior of your Response Pools.
When a DNS query is received, the source IP is analyzed against our geolocation data. Next, the appropriate Ruleset is matched and the corresponding Response Pool is used to provide a DNS response. It is important to note that the source IP is not the end-users IP but the recursive DNS server (resolver). The resolver is often operated by the ISP of the end-user.
Why is this knowledge so important? Let’s say you have end-users accessing your site from Florida. Naturally, you would account for this by adding Florida to your Traffic Director geographic areas so they are served the closest DNS response. However, if the end-users actual location is in Florida, but their ISP’s resolver is in South Carolina, you will need to account for this by having a geographic DNS response for South Carolina configured in your Traffic Director. This can be impossible to determine in some cases, so this is where a Fallback Entry can really save you.
Tip # 1 – Configure a Fallback Entry
Why do you need a Fallback Entry? A Fallback Entry is important because if the requesting resolver is outside of a geographic region you have defined within any Ruleset, the end-user will receive no DNS answer! The query will fail.
To prevent this from happening:
- Set up a Response Pool in your Traffic Director that has a Record Serve Mode set to “Always Serve.”
- Make a corresponding Ruleset, but do not define a geographic area (this defaults to “all geographic areas”).
- Place this Response Pool as the final entry in your Rulesets. In the event that a request comes from a resolver that is not geographically defined, you will still be able to serve a DNS answer.
Tip # 2 – Use a single Response Pool when you want to weight your endpoints
In addition to being able to route traffic based off resolver location, you can also use Traffic Director to load balance. If you would like to define weight for traffic between endpoints (your records), you will want to confirm they are configured within a single Response Pool. First, create a Response Pool and then add all applicable records you will want to serve in that Response Pool. You can then configure the Weight field.
Note: The higher the weight, the more often that record is served over other records of the same type.
It is important to remember that weighting does not apply to records in separate Response Pools, however, you can use the same record in multiple Response Pools.
Tip # 3 – The order of your Rulesets matters
Remember, Response Pools are the records you want to serve and Rulesets are how you want to serve them. In each Ruleset, you define the geographic areas for the behavior you are about to configure. Then you define the Response Pool Failover chain. The first entry in your chain should be your primary Response Pool you want to answer for the geographic area(s). The next entry in the chain is the DNS answer you want to serve in the event your primary isn’t available. Same with the third and fourth entries, and so on.
It’s also important to note that the order of your Rulesets matter. How so? Let’s say you’ve defined the same geographic area in two different Rulesets. Which one would take precedence? This is where the order of your Rulesets matter. Rulesets are served top to bottom. This is another reason why it’s important to configure your Global Fallback Ruleset as the last in the chain. If you were to configure this first with no geographic area defined, all of your geographic areas would receive this response first! The Global Fallback Ruleset, if configured as the final Ruleset at the bottom, will only be served in the event that the other Rulesets have no answer (such as a query from an undefined geographic area or all pools in your Failover Chain are unavailable). You can move the order of your Rulesets easily by modifying the Ruleset Ordering.
These three tips are an excellent start to confirm you’re getting the most out of your Traffic Director. Now it’s time to turn these tips into a reality in your own instance of Traffic Director. The specific steps to implement these and other configurations can be found by reading help.dyn.com.