Today we're releasing two closely related features - the DNS Check API, and the DNS Check Integrations Directory. These features enable DNS Check to better integrate with third party services.

DNS Check API

The DNS Check API is REST API which enables checking on the status of monitored DNS records, and record groups.

We're proud to announce that DNS Check has integrated with Flowdock to provide reliable DNS record and name server monitoring with real-time notifications. This integration combines the strengths of DNS Checks's DNS monitoring service with Flowdock's chat service. It also allows you to receive notifications from DNS Check, coworkers, and and other monitoring systems through a common Flowdock interface.

Flowdock is a team collaboration app for desktop, mobile & web. Flowdock enables you chat, notify and share files in real-time.

DNS Check enables you to easily monitor, share and troubleshoot DNS records. You can import DNS your zone file and have DNS Check monitor the records in it, or specify individual records that you would like monitored.

You can designate that a DNS record is "exclusive," meaning it should be the only DNS record of its name / record type combination. For example, the MX record for your company's domain name should be the only MX record for that domain.

You have the option of making each set of DNS records publicly visible, or private, which can save precious seconds if a DNS record or name server is broken, but the person who maintains it doesn't normally have access to your monitoring system. Here's an example set of public DNS record checks.

We've developed a REST API which enables checking on the status of DNS records, and record groups that are monitored through DNS Check.

An example use case of the API is to augment monitoring systems that have limited DNS record checking capabilities. For example, many services support checking A and AAAA records, but lack support for checking MX and SPF records.

We plan to make the DNS Check API available to both free and paid accounts.

We just added a new feature which allows you to enable or disable notifications on a per DNS record group basis:

Prior to this update, notifications were permanently enabled for all DNS record groups. Now they're enabled by default, with the option to turn them off.

MX, or Mail Exchange records are DNS records that specify which mail servers are responsible for receiving email for a domain. When someone sends you an email, their mail server looks up the MX records for your domain (the part of the email address after the @ sign), and attempts to deliver the message to a mail server that's specified by those MX records.

If MX records are improperly configured, then legitimate email may not get delivered to you, and spam may find a way to bypass your spam filter's checks.

This post provides some background on how MX records work, followed by suggestions on how to check them.

MX Record Structure

Each domain name can have one or more MX records, and each MX record has two fields - the "Preference" and "Exchange".

Preference

An MX record's "Preference" value is a number between 0 and 65,535 which indicates how preferable that record is relative to other MX records for the same domain. If a domain only has one MX record, then the Preference doesn't matter. When more than one MX record exists for a domain, the MX record with the lowest Preference is checked to decide which "Exchange", or mail server to attempt to deliver mail to first.

Having the lower Preference win can seem counter intuitive, so the Preference is also sometimes called the MX record's "distance".

If two or more MX records tie for lowest Preference value, then the sending mail server randomly picks one for the first delivery attempt.

If the first delivery attempt fails, then the sender attempts to deliver the message to the MX record with the next lowest Preference. This process repeats until the sender either succeeds in contacting a mail server, or runs out of MX records to check.

We're proud to announce that DNS Check has integrated with OpsGenie to provide fast, reliable DNS record and name server monitoring with notifications. This allows you to combine the strengths of DNS Checks's DNS monitoring service with OpsGenie's notification service. It also allows you to receive notifications from both DNS Check, and other monitoring systems through a common OpsGenie account.

OpsGenie enables you to transform alerts into notifications that are sent to users via iPhone, Android, Blackberry push notifications, email, SMS and phone calls.

DNS Check enables you to easily monitor, share and troubleshoot DNS records. You can import your DNS zone file and have DNS Check monitor the records in it, or specify individual records that you would like monitored.

You can designate that a DNS record is "exclusive," meaning it should be the only DNS record of its name / record type combination. For example, the MX record for your company's domain name should be the only MX record for that domain.

You have the option of making each set of DNS records publicly visible, or private, which can save precious seconds if a DNS record or name server is broken, but the person who maintains it doesn't normally have access to your monitoring system. Here's an example set of public DNS record checks.

Alerts are automatically created in OpsGenie when a DNS record check fails, and resolved when the DNS record check starts passing again.

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 as 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 zone 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:

1. All record types other than PTR (reverse DNS) records are exported to the "Forward DNS Records" zone file.
2. 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.