This is a continuation of the series Why We Monitor. This time we are going to look at DNS, why we monitor it and what to monitor. The Domain Name System ( DNS ), among other things, is what allows us to have cute and memorable names for a web service instead of memorizing the ip of the local server that runs it. When it’s working, the DNS system gives all sorts of information about your domain. When it’s down it doesn’t matter how good your application is, no one will be able to find it. When it’s hijacked a person could send your users to another site or imitate your site and steal your user’s logins ( if your site uses clear text authentication forms ). I am going to run through some basic monitoring that can help you avoid issues.

     Every domain has a list of authorized name servers, SOA servers. Without going into a lot of detail about DNS architecture, these are the servers that are the final knowledge keepers for your domain. When other DNS servers don’t know about your domain they ask the SOA and remember the answer for a short while. For this reason you need to make sure that your SOA servers continue to stay in your control by regularly checking the SOA record of your domain in your monitoring. Be aware that if you do not run your own DNS servers these values may occasionally change, contact your provider to better understand their policy.

     Now that your sure your DNS records are still under your control it’s time to move on to the records themselves. The more records you have the more complicated it becomes to monitor all of them. I suggest to my clients that they evaluate all of the names that they are using and ask themselves, “Will this effect my end user if it’s gone?” If the answer is yes, monitor it. For checking entries I suggest checking the response on both your SOA servers and a public DNS server ( I frequently use one of 4.2.2.[1-6] ) to make sure the public sees what your seeing.

     My last suggestion is an extension of the previous one but is often over looked, MX records. MX records are how DNS servers tell mail servers where to send your domain’s email. If these were altered or removed a key piece of email could go missing or get sent to someone you would rather not read it. The solution for this is the same as the host records, check your servers and public servers for the correct response.

     This has been a very basic overview of what you should be thinking about when you are configuring your DNS monitoring. More complex setups that include geo-load-balancing as well as distributed and redundant services will require a more complex configuration but should still be monitored along these lines.

It is a question that seems to have an obvious answer but, in my opinion, does not get asked often enough. Why do we monitor? The reason I say that it does not get asked often enough is because if it did you would find that your monitoring isn’t getting the job done. So let’s get this out of the way.

Why do we monitor?

The simple answer is that we want to ensure that the vital service we provide is available to our clients. A developer approaches this from the application. A systems administrator approaches this from the server. A network administrator approaches this from the network. They are all correct but it only takes a failure to understand one of the components and you have a huge blind spot in what you think is a solid first line of defense. As I continue this blog I will explore various pieces of the monitoring puzzle and, hopefully, help you understand where your monitoring may be lacking.