Making changes to your DNS configurations can be a daunting task for some. Especially when you could potentially be making changes to a production zone that your business heavily relies on.
Once you decide to take the leap and make the changes, we want you to be equipped with the right tools to test that these changes are propagating as expected. Before we jump into the specific tools that we utilize here at Oracle Dyn, we want to explain the logic behind DNS changes and how they propagate.
As you know, each DNS record has a “TTL,” or “Time to Live,” that has been assigned to that record. Most TTL values are expressed in seconds, and they represent how long you will allow external nameservers (or resolvers) to cache the information within that DNS record.
Here is an example: You have an A record of 188.8.131.52 on your zone with a TTL of 4 hours. Your end user will query your website, and that A record of 184.108.40.206 will be returned to their resolver. This resolver will keep this answer cached for the following 4 hours, which prevents the resolver from needing to re-query the zone for that hostname again. In the event that your endpoint of 220.127.116.11 goes down, you may have users who will see the site as non-responsive, as they still have the ‘down’ endpoint cached. Once you notice that your endpoint is down, and update the record accordingly, any users who still have this previous answer cached will see that the site is down. In the same event, if a user had not queried your site recently, but did right after you made the DNS change, they would get the new answer, as their resolver had no values cached. This is why most customers prefer to keep their TTLs set to a lower value which forces them to expire quicker with resolvers.
One thing to keep in mind, though, is that the lower your TTL’s are, the more queries your zone will receive, as resolvers will be forced to query your zone more frequently. If you do decide to keep your TTL’s low, it will assist in cutting down propagation times for changes you make, but it will drive your query volume upwards.
Additionally, Dyn does offer an Active Failover service which would automatically detect your endpoint as “down” and fail it over to another specified endpoint. Once your original endpoint is marked back as “up” by our Health Monitoring probes, it will begin to be served again. This is all done automatically without you having to worry about monitoring your endpoints and making emergency changes in the event of an outage (if you wish to learn more about this service, please contact your Account Director or Dyn Sales).
Now that we have looked into how DNS changes propagate, let’s look at what we can use to test them. My method of choice is “domain information groper”, or “dig”. dig is a command line tool that you can utilize to query DNS Servers. By using dig, I am able to test directly against the nameserver where my domain is hosted. This will allow me to ensure that the change has actually taken place, without having to worry about the caching factor. An example of dig is below:
dig yourdomain.com @ns1.pXX.dynect.net
This will return the answer that the nameserver currently has for that specific domain. This command will not take into account any TTLs you have in place, as you are testing directly against the server. If you would like to see how the resolver you are utilizing is behaving, you can simply take out the last portion, and utilize the following:
*Please note that if you utilize this method and do not see your DNS change returned, it is very likely that you have a cached answer, and will need to wait until that cache is cleared or expired.
Another method that you can utilize is nslookup. nslookup is similar to dig as it is a command line tool used to query DNS or obtain IP Mapping. nslookup does have some restrictions though, and is known to return skewed results. This is due to the fact that while accessing nslookup within the program itself, it utilizes it’s own internal resolver. The internal resolver has its own cache that it utilizes, which can cause unexpected behavior.
Additionally, this internal resolver is hardcoded to use a source port of 53. For DNS Spoofing resilience, we forbid source port 53, and expect randomized source ports as outlined in RFC 5452. You can read the RFC, and more about the flaw in the following articles:
One way to work around the nslookup flaw would be to add in a ‘-debug’ command into your command line. This will force the internal resolver to re-query the internet rather than relying on its own internal cache. The command would look like the following:
nslookup -debug @ns1.pXX.dynect.net yourdomain.com
If you do not have either of these tools installed on your machine, have no fear! There are external tools that we can also utilize to emulate these same tests. Kloth.net is a great resource for users who wish to utilize tools such as dig, nslookup, and WHOIS, if they do not have them installed locally. Here are direct links to dig, nslookup, and WHOIS.
Another free service that I would recommend to ensure that your changes have propagated successfully around the world is TurboBytes. TurboBytes allows you to utilize their points of presence all over the world to test against your domain. This will show you that the change you made has been propagated successfully. Here is a direct link to the TurboBytes test.
Lastly, we also utilize Catchpoint here at Dyn. Catchpoint is a paid service, that allows you to choose from specific regions, and/or ISPs to test the speed and reliability of your DNS answers. This can also prove very helpful when testing the functionality of a geo-based traffic steering service. As Catchpoint allows you to pick a location from any part of the world, see which DNS answers, and how quickly it is returned to that region.
Hopefully these tools have better equipped you and your team to tackle any DNS changes that may need to be made. If any additional questions come up, please do not hesitate to reach out to our Technical Support Team.