DNS is incredibly flexible. One of the things that it allows you to do is enable load balancing and/or redundancy by creating multiple DNS records with the same name and record type. For example, you could create two A records for your company’s domain name to perform round robin load balancing between two web servers. Another example is creating multiple MX records, so that failure of a single mail server doesn’t take incoming email offline.

Unfortunately, this capability increases the complexity of monitoring DNS records, even if you’re not intentionally using it. Having an extra, invalid DNS record could cause impaired performance, a service outage, or enable a man in the middle attack.

Today we’re proud to announce an improvement to DNS Check which simplifies monitoring for these types of DNS issues.

The “Exclusive” Option

Each DNS record that’s monitored by DNS Check has an “Exclusive” option which you can turn on and off:

Editing an Exclusive DNS Record Check

When this option is turned on, DNS Check compares the full list of DNS records returned to the list of DNS records being monitored for the given record name / type combination. If the two sets of records match up exactly, the check passes. Otherwise, DNS Check will detect the error, and notify you about it.

This is an enhancement to DNS Check’s previous functionality. The “Exclusive” option was initially released in May 2015, but was limited verifying that only one DNS record existed for a given name / type combination. Today’s release removes the single record limitation. You can now specify that multiple “Exclusive” records should exist for the same name / type combination.

When the “Exclusive” option is turned off, DNS Check simply verifies that a DNS record exists with the value specified. It does not report any kind of error if additional records are returned.

We recommend turning the “Exclusive” option on whenever possible.

The next two sections show some example uses.

Multiple A and AAAA Records

A records map domain names to IPv4 IP addresses, while AAAA records map domain names to IPv6 IP address.

For example, google.com has multiple A records:

; Name       Type  IP address
google.com.  A
google.com.  A
google.com.  A
google.com.  A
google.com.  A
google.com.  A

The order in which the IP addresses listed above are returned by Google’s name servers is randomized, so different clients will attempt to connect to different IP addresses. If a web browser’s attempt to connect to the first IP address in its list times out, it can try the next IP.

What would happen if an extra, invalid DNS record pointing to the wrong IP addresses was added in?

; Name       Type  IP address
google.com.  A

Since there are six valid A records, and one invalid record, this would result in 1/7 requests going to the wrong IP address. What happens next depends on whether there’s a web server listening on the incorrectly referenced IP address:

  • If a web server is listening, then these requests would load the content for the wrong website.
  • If a web server is not listening, then these requests would time out. Most web browsers would eventually try the next IP address in the list, if its user waits around long enough.

The above is equally applicable to AAAA records.

Multiple MX Records

MX records specify which servers are responsible for receiving incoming email for a domain. It’s possible for a domain to only have a single MX record, but not recommended because creating multiple MX records for a domain provides redundancy for its incoming email. A domain with multiple MX records will continue to receive mail as long as at least one of the mail servers references by its MX records is online.

For example, if you lookup our MX record, you’ll see two records returned:

; Name       Type  Preference  Exchange
dnscheck.co. MX    10 mx.dnscheck.co.
dnscheck.co. MX    20 mx2.dnscheck.co.

The above MX records have different preferences configured, so this results in a configuration which provides redundancy. Mail servers will first attempt to deliver mail to mx.dnscheck.co. If they are unable to connect, they’ll try mx2.dnscheck.co next. As long as at least one of these mail servers are online, DNS Check will continue to receive incoming email.

If the above MX records had the same preference, then they would also enable load balancing, because sending mail servers would randomly pick one of the MX records for their first delivery attempt.

This technique is valuable, but it does carry some risk. What happens an MX record pointing to the wrong mail server is added?

; Name       Type  Preference  Exchange
dnscheck.co. MX    1           ASPMX.L.GOOGLE.COM.

In the above example, the MX record pointing to the ASPMX.L.GOOGLE.COM mail server has the lowest preference, so email senders would make their first delivery attempt to it. This server is not configured to receive mail for dnscheck.co, so messages sent to it would bounce.

See our Check Your DNS MX Records blog post for a more detailed discussion of MX records.