Monitoring DNS Records for Wildcard Values

Back in 2016, we added support for monitoring wildcard DNS records. Wildcard DNS records are used to serve requests for otherwise non-existent domain names. For example, if you created a wildcard record for *.example.com, but not a foo.example.com record, queries for foo.example.com would receive the IP addresses specified for *.example.com in response.

Today we’re pleased to announce that we’ve extended our support for using wildcards in DNS records monitoring. DNS Check now allows you to specify a wildcard (*) in place of some DNS record values, such as an A record’s IP address to indicate that any value is acceptable, but the record must exist.

Wildcard values are supported in the following areas:

  • A and AAAA records may have an IP address of * specified.
  • CNAME records may have a value of * specified to indicate that they may point to any domain.
  • MX records may have an exchange of * specified to indicate that any exchange is acceptable.
  • NS records may have a value of * specified to indicate that any nameserver is acceptable.
  • PTR records may have a value of * specified to indicate that any value is acceptable.

Here are a couple of example use cases:

Load Balancer Monitoring

Suppose you’re using a load balancer to split requests for your website - www.example.com between a pool of web servers. The pool is dynamic, so you don’t know ahead of time which IPs will be returned in response to each query, but you want to make sure that at least IP is returned.

You can do that by creating a new monitored DNS record with an IP address of *:

Add DNS A record with a wildcard value

In the above screenshot, www.example.com would pass as long as one or more IP addresses are returned in response to each query.

Toggling the above form’s “Exclusive” tag on would enforce a requirement that only one IP address is returned.

Similarly, toggling the above form’s “Exclusive” tag on, then creating a second identical monitored DNS record would enforce a requirement that exactly two IP addresses are returned.

G Suite DNS Record Monitoring

For our second example, suppose that your organization uses G Suite, and you wish to monitor the CNAME record that they asked you to create.

; Name            Type  Value
mail.example.com. CNAME ghs.googlehosted.com.

That’s simple enough. You can just create a CNAME record in DNS Check:

Monitoring a CNAME record pointing to ghs.googlehosted.com

Once the above monitored record is created, DNS Check will automatically check it every 5 minutes, and notify you if it changes.

But what about the ghs.googlehosted.com record that we’re pointing to? How do we know that it’s working?

Normally monitoring ghs.googlehosted.com would be difficult because Google could return any of their IP addresses in response to each query. With wildcard DNS records, you can just tell DNS Check that you want to make sure that ghs.googlehosted.com returns at least one IP, but don’t care which one it is:

Add DNS A record for G Suite with a wildcard value

Have any questions about how to use wildcards in your DNS record monitoring? Contact us. We’re happy to help.

Continue reading Monitoring DNS Records for Wildcard Values »

Upcoming Maintenance Rescheduled

We’ve moved the Sunday, February 25th maintenance window that was announced in the previous post to take place on Monday, February 26th between 16:00 and 17:00 UTC.

The maintenance window was rescheduled so that mitigations for the Spectre and Meltdown vulnerabilities can be put in place at the same time as the hardware upgrade.

We anticipate that this maintenance will cause 5-15 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.

Feel free to contact us if you have any questions.

Continue reading Upcoming Maintenance Rescheduled »

Upcoming Maintenance

We’re going to migrate DNS Check’s website to new and more powerful hardware on Sunday, February 25th starting at 1: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.

Feel free to contact us if you have any questions.

Continue reading Upcoming Maintenance »

Integration Updates

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.

Feel free to contact us if you have any questions.

Continue reading Integration Updates »

Upcoming Maintenance

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.

Feel free to contact us if you have any questions.

Continue reading Upcoming Maintenance »

Wildcard DNS Record Monitoring

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:

The Classic Approach

Until recently, we would have recommended picking a couple random records which match the wildcard expression, and which you’re unlikely to ever create non-wildcard records for, then monitor them. For example, you could verify that the following records exist as a proxy for the *.example.com DNS record shown above:

; Name              Record Type     IP Address
foo.example.com.    A               5.6.7.8
bar.example.com.    A               5.6.7.8

The above approach works, but:

  1. It’s not obvious from looking at what’s being monitored that the two records are proxies for a wildcard record. I like my monitoring systems to be stupid-simple, so that if I get paged at 2 am, I’ll be able to easily tell in my half-asleep state what the problem is.
  2. You’re at the mercy of randomly selected records continuing to exist only as wildcard records.
  3. It’s more work to setup than the next option.

Check Wildcard DNS Records Directly

We recently added a feature to DNS Check which enables you to monitor wildcard DNS records directly. To use this feature, just enter the wildcard record’s name as it would appear in the zone file, including its asterisk (*):

New Wildcard DNS Record Form

In order to comply with RFC 4592, we support wildcards in the leftmost portion of the domain. So for example, you can use this feature to monitor *.example.com or *.foo.example.com, but not foo.*.example.com. This is similar to BIND’s treatment of wildcard records.

Here’s how this works behind the scenes once the monitored record is created:

Each time DNS Check tests a wildcard record, it generates a random 20-character string, then inserts it in place of the wildcard. For example, *.example.com may be replaced with jcjmwpdddykdmafpltbj.example.com. A new random string gets generated for each check, so if somehow a random sequence which is actually used by a non-wildcard record gets generated for one check, a different sequence will be generated for the next check.

We’ve added wildcard support to all of our supported DNS record types, including A, AAAA, CNAME, MX and NS records.

I hope this feature helps you to improve your DNS record monitoring. If aren’t already using DNS Check, please feel free to sign up for an account. Having an account enables you to import your entire zone file, then get notified automatically if any of your DNS records stop returning the value(s) that your zone file says they should. You can also individually add or edit DNS records that you wish to monitor.

Continue reading Wildcard DNS Record Monitoring »

Announcing DNS Check / Basecamp 3 Integration

DNS Check / Basecamp 3 Integration

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:

Example DNS Check Campfire Chat reporting on a DNS record that started failing, then passing

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.

Interested in trying out DNS Check’s DNS monitoring service, and our integration with Basecamp 3? Sign up for a free DNS Check account. Free accounts can monitor up to 10 DNS records and have no expiration date. You’re welcome to use your free account for as long as you like.

You can upgrade to a professional DNS Check account at any time to monitor additional DNS records, and enable advanced features, like the ability to query custom name servers, and monitor DNS load balancers.

Continue reading Announcing DNS Check / Basecamp 3 Integration »

DNS CNAME Load Balancer Monitoring

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:

Check CNAME load balancer with DNS Check

Each load balancer check can be configured with up to ten IP addresses or CNAME records.

DNS load balancer monitoring is available for paid accounts only.

You can find more details on DNS load balancers, including information on how to monitor them on our Check DNS Load Balancer Records page.

Continue reading DNS CNAME Load Balancer Monitoring »

SPF Record Monitoring

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:

  • TXT resource records - these are general purpose DNS records that map a domain to a string of text. These have a number of uses including SPF, DKIM and DMARC authentication.
  • SPF resource records - these are specialized DNS records that map a domain to a string of text for the purposes of SPF authentication

DNS Check has supported monitoring TXT resource records since June 2015, so technically, you could use our service to monitor SPF records that were published using TXT resource records before today. What we added in today was support for checking SPF resource records:

SPF Record Check

The historic recommendation was to publish SPF records using both the TXT and SPF resource record types. This has changed. RFC 7208 states that SPF records must be published as TXT resource records only.

We recommend following RFC 7208, and replacing your SPF resource records with TXT resource records. That said, you may have reasons for not making the switch immediately, so we support monitoring both resource record types.

You can find more information on SPF records, including information on how to monitor them on our Check DNS SPF Records page.

Continue reading SPF Record Monitoring »

Internationalized Domain Name (IDN) Monitoring with DNS Check and Punycode

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.

Modern web browsers usually perform the Punycode translation for you behind the scenes. Similarly, DNS Check will automatically apply Punycode encoding for you as you add domains using non-ASCII characters. Of if you’ve also encoded your domains, you can enter them in that format.

After each international domain is entered into DNS Check, it’s displayed using Punycode encoding. We’re doing this to reduce ambiguity, since different Unicode characters can look very similar to one another, or even to plain ASCII characters.

Continue reading Internationalized Domain Name (IDN) Monitoring with DNS Check and Punycode »

Subscribe via RSS