Discovering Common DNS Problems with Dig
Most CDN problems are caused by one of the following:
You can use the dig utility to query DNS servers and view useful information about your domain. Dig is standard on Mac and Unix-based operating systems. If you're using Windows, dig isn't available by default, but you can install it separately.
The following example shows the response from a dig command run on www.scaexample.com.
This response has been trimmed.
$ dig www.scaexample.com
;; ANSWER SECTION:
www.scaexample.com. 14398 IN CNAME www.scaexample.com.hosting.netsuite.com.
www.scaexample.com.hosting.netsuite.com. 298 IN CNAME website-cdn.na1.netsuite.com.
website-cdn.na1.netsuite.com. 59 IN CNAME website-cdn.na1.netsuite.com.mdc.edgesuite.net.
website-cdn.na1.netsuite.com.mdc.edgesuite.net. 317 IN CNAME a1280.b.akamai.net.
a1280.b.akamai.net. 8 IN A 67.132.183.51
a1280.b.akamai.net. 8 IN A 67.132.183.49
In this example, you can see both the CNAME being translated and the hits to Akamai, so we know the CNAME's set up correctly and the CDN's enabled.
CNAME Configured Correctly But CDN Not Enabled
;; ANSWER SECTION:
www.scaexample.com. 14099 IN CNAME www.scaexample.com.hosting.netsuite.com.
www.scaexample.com.hosting.netsuite.com. 299 IN CNAME shopping.na1.netsuite.com.
shopping.na1.netsuite.com. 2962 IN A 64.89.45.13
In this example, the CNAME is translating to the standard NetSuite shopping servers, not the Akamai ones. If this looks like the answer section from your dig command, you might not have checked the Use CDN Cache box. Follow Steps 6 through 8 in the procedure for updating CNAME records in Check Your CNAME Setup to make sure you've checked Use CDN Cache.
CNAME Configured Incorrectly
;; ANSWER SECTION:
www.scaexample.com. 2997 IN A 123.123.123.123
In this example, the CNAME settings haven't been set up with the DNS provider. See Check Your CNAME Setup for instructions on configuring your CNAME record.
DNS Propagation and Caching
If your CNAME record is configured correctly with your DNS provider and you've enabled CDN, but dig commands still aren't returning the expected results, the problem might be related to propagation or caching. Make sure you allow up to a day for propagation and for all servers to update.
You can use dig to get information about when you can expect the DNS cache to refresh. The following example is of a dig trace from a properly configured server:
;; ANSWER SECTION:
www.scaexample.com. 3389 IN CNAME www.scaexample.com.hosting.netsuite.com.
www.scaexample.com.hosting.netsuite.com. 298 IN CNAME website-cdn.na1.netsuite.com.
website-cdn.na1.netsuite.com. 44 IN CNAME website-cdn.na1.netsuite.com.mdc.edgesuite.net.
website-cdn.na1.netsuite.com.mdc.edgesuite.net. 21551 IN CNAME a1168.b.akamai.net.
a1168.b.akamai.net. 20 IN A 23.62.237.89
a1168.b.akamai.net. 20 IN A 23.62.237.97
In this example, there's a number next to each domain. That's the TTL (time to live), which is how long the lookup is considered valid and cacheable. The first CNAME answer is 3389 seconds, or about 56 minutes, so you'll need to wait 56 minutes before it's looked up again. If you look at the bottom two domains, the values for the Akamai servers are short-only 20 seconds. That's because Akamai uses DNS to dynamically route requests from users to edge nodes close to them. In practice, it's usually only the numbers for NetSuite servers that cause issues.
You can periodically run dig commands until those numbers reach zero, which means the cache is reset. After it has, check that your CDN is working.
Flushing your DNS cache can help. But if a DNS server on your network or ISP is holding a cached DNS answer, it's tough to work around. Waiting for cached records to expire might be your only option. In some cases, you can work around this with cache invalidation. See Common Causes of Site Performance Issues.