We just finished refactoring the code that we use for integrating DNS Check with services like Slack and PagerDuty. It felt good to take some of the bespoke code that had accumulated over the past couple years as integrations got added in and generalize it.

These updates will allow us to more easily add and update integrations in the future.

You shouldn't notice any difference in how existing DNS Check integrations work.

We're going to migrate DNS Check's website to new hardware on Thursday, October 13th starting at 12:00 am UTC. We anticipate that this migration will cause 5-10 minutes of downtime for our website.

If you're using our API for DNS record monitoring, then we recommend scheduling a maintenance window within your monitoring system which covers this window.

Wildcard DNS records are used to serve requests for otherwise non-existent domain names.

For example, the following DNS zone file excerpt contains two non-wildcard A records along with a wildcard record:

; Name            Record Type     IP Address
example.com.      A               1.2.3.4
www.example.com.  A               1.2.3.4
*.example.com.    A               5.6.7.8

If you look up the www.example.com A record in the above recordset, you'll receive a response of 1.2.3.4, since explicit records take precedence over wildcard records. If you look up the foo.example.com DNS record, you'll receive a response of 5.6.7.8, since there is only a wildcard record for foo.example.com.

Wildcard DNS records are handy, but how do you monitor them? Two options come to mind:

We're excited to announce that we've integrated DNS Check with Basecamp 3. This integration enables you to receive notifications in the Basecamp Campfire chat of your choice each time a DNS record transitions between passing and failing:

Integrating your DNS Check account with Basecamp 3 is simple, and only takes about a minute. See the DNS Check / Basecamp 3 integration Guide to get started.

We've added CNAME DNS load balancer monitoring to DNS Check.

DNS load balancers distribute load for performance and/or redundancy purposes.

You can also use DNS Check to monitor A record and AAAA record based load balancers:

We've added SPF resource record monitoring to DNS Check.

SPF records are used to control which IP addresses and services are authorized to send email for a domain name.

SPF records are unusual in that they can actually be published using either of the following resource record types:

We've added support for monitoring Internationalized Domain Names (IDNs) using DNS Check.

The DNS protocol uses ASCII characters to represent domain names. That works fine for domains which only contain English alphabet characters, but leaves many other languages short-changed.

Internationalized Domain Names (IDN) address this shortcoming by encoding non-ASCII characters. Punycode is used to encode Unicode characters into ASCII representations. For example, domaiñ.com contains a non-ASCII ñ character, so Punycode translates it to xn--domai-sta.com.

We've added DNS load balancer monitoring to DNS Check.

DNS load balancers are used to distribute load for performance and/or redundancy purposes.

You can use DNS Check to monitor both A record and AAAA record based load balancers:

Paid DNS Check accounts have the ability to monitor custom name servers. Up to this point, each DNS record group has been limited to a single custom name server. This has meant that if you wanted to monitor multiple name servers, you would have to create a DNS record group for each.

Today we've increased the number of custom name servers that a DNS record group can have from 1 to 10.

What should a DNS monitoring service do when it's configured to check multiple name servers, and provide a single pass/fail result? Here's what we came up with:

Update: the setting described in this post has since changed. See DNS SERVFAIL Errors for what SERVFAIL errors are, and how to configure DNS Check's current ServFail error notification threshold.

DNS record lookups can fail for a number of reasons, the most common of which is due what's called a "ServFail" error.

ServFail errors occur when there's an error communicating with a DNS server. This could have a number of causes, 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.