We just added SOA record monitoring to DNS Check.
SOA, or Start of Authority resource records are DNS records that define a number of global parameters for a DNS zone, or domain.
An SOA record’s Serial Number normally gets updated each time the zone file is updated. This makes monitoring the SOA record an idea that’s worth considering for infrequently modified zone files, since monitoring a single record normally has the effect of monitoring all records in the zone file for changes. We still recommend monitoring the remaining DNS records, since it’s not guaranteed that the Serial Number will be updated. Think of SOA record monitoring of one layer of a multi-layered DNS record monitoring system.
If a zone file is updated frequently, then you may decide to exclude its SOA record from monitoring. To do this, just delete the SOA record from the DNS Check DNS record group after importing the zone file.
Each zone file should contain a single SOA record.
DNS is the Achilles heel of many monitoring systems. They often allow you to monitor A and AAAA records, which resolve domain names to IP addresses, but lack support for other DNS record types. They also often lack support for detecting incorrectly duplicated DNS records.
If this Achilles heel is present in your monitoring system, it could cause a failure to detect downtime in your production systems.
For example, if a conflicting MX record is created, will you get notified by your DNS monitoring system immediately, or by your users later when they notice that they’re no longer receiving emails?
Security is another concern. If NS records get hijacked for a phishing attack, will you get notified by your DNS monitoring system immediately, or will it go unnoticed?
We noticed an interesting thing when analyzing the DNS errors that DNS Check has logged. 57% of the errors are of the “ServFail” variety, and of those, the vast majority are resolved 5 minutes later, when the record is next checked.
A ServFail error occurs when there’s an error communicating with the DNS server. This could occur for a number of reasons, including an error on the DNS server itself, or a temporary networking issue.
Fortunately, most domains use multiple authoritative DNS servers, so if there is a short lived ServFail issue on one name server which doesn’t impact the others, DNS lookups should still work. That said, if a name server has chronic ServFail issues, we recommend investigating why. ServFail errors happen, but should be rare.
Some of our customers are using DNS Check to page them when there’s a DNS lookup failure. Of those, some do want to be notified if there’s a short lived error that leads to a ServFail error, but others would rather not be paged, unless the error occurs more than once in a row.
Because of this, we’ve added a new option named “Suppress first ServFail notification” to the Notification Options page to suppress isolated ServFail errors:
We just added a feature that allows you to export DNS records to zone files.
To generate zones files, visit a DNS record group, like this example, then click the “Export zone file” button.
Any DNS record groups that are made public will also have the “Export zone file” button publicly visible. This was done to make it easier to post requested DNS record updates.
There are two zone files that DNS records can be exported to:
- All record types other than PTR (reverse DNS) records are exported to the “Forward DNS Records” zone file.
- PTR (reverse DNS) records are exported to a “Reverse DNS Records” zone file.
This division is in place because reverse DNS records are often managed by a different provider than other records.
We’re currently working on integrating our DNS monitoring services with PagerDuty’s incident management system.
This will allow you to use DNS Check to monitor your DNS records, and if something goes wrong, get notified via PagerDuty. This will augment the existing email notification option.
We plan to make PagerDuty integration available to both free and paid DNS Check accounts.
The estimated release date is September 1st. Please contact us if you’re interested in being a beta tester before the official release.
We just added DNS zone file syntax highlighting to our site. Heres’ an example:
$ORIGIN example.com @ IN SOA ns1.example.com. root.example.com. ( 2015071101 14400 3600 1209600 86400 ) @ NS ns1.isp.com. @ NS ns2.isp.com. @ A 192.168.0.2 mail A 192.168.0.3 @ MX 10 mail.example.com.
The syntax highlighting is being done using highlight.js.
If you’re interested in trying out highlight.js, you can download it, or use one of the CDNs listed on their download pages.
The CDNs listed on their download page provide support for the 22 most commonly highlighted languages. Unfortunately, DNS zone files didn’t make the cut, so we’ve posted a copy to CloudFlare’s CDN that you’re welcome to use. This copy includes support for the 22 most commonly highlighted languages, plus DNS zone files.
We just added a new feature which allows you to view the past 30 days of state changes for any DNS record. A state change occurs any time a DNS record’s status changes from passing to failing, or vice versa.
Viewing a DNS record’s state change history can be useful for identifying and resolving DNS record flapping issues. It can also be useful for identifying what happened if a problem appears to fix itself before you investigate it.
You can see a live example of this by going to the Example DNS Check, then clicking on the (View History) button next to any DNS record:
Subscribe via RSS