DNS monitoring
Every site that gets added to Oh Dear can have its DNS records automatically monitored.
How we perform DNS monitoring
Your DNS records are a crucial component to the availability of your website. Should they suddenly stop working, your site will be offline. If they change without your knowing, it could indicate someone has taken control of your domain name.
For that reason, our DNS monitoring is focussed on monitoring these key areas:
- DNS changes made to your domain
- Availability of your nameservers
- Validating all your nameservers return the same answers
Your site(s) added to Oh Dear can be configured to monitor your DNS at frequent intervals. We'll check every nameserver and every record for you every few hours.
Determining which DNS records to monitor
Monitoring DNS records can lead you down a rabbithole pretty quickly. For that reason, we've taken a pragmatic approach to monitoring your DNS records.
If you monitor the domain awesome-site.tld, we will monitor all DNS records we could find on that domain only.
That means we'll check for A, AAAA, CNAME, MX, ... records on awesome-site.tld, but not on www.awesome-site.tld or any other subdomain.
If you have other sites or sub-domains that are of interest, you can add specifically add them to Oh Dear. Since what we monitor can be toggled on/off, you can add secretpage.awesome-site.tld to Oh Dear and just enable the DNS monitoring if you prefer.
If you'd like to monitor the DNS records of your main site and 3 subdomains, you can add those 4 sites into Oh Dear.
Monitoring Cloudflare nameservers
Because it is so common to use Cloudflare's DDoS protection when you are using their DNS, we have add an extra rule in place when we detect that a domain is using Cloudflare.
If a domain is using Cloudflare nameservers, we will automatically ignore any A and AAAA records when determining whether DNS records have been changed or whether nameservers are in sync.
Fine-tuning which records you care about
There are instances when your DNS records change all the time, and it's normal. If you're using a service that provides DDoS Protection, such as Akamai, it's common for them to change your DNS records to redirect you away from an ongoing attack.
This may still interest you to receive notifications about, but at the same time, it can get a little noisy.
For this use case, you can head over to the DNS Settings of your site and choose which records you care about. You could disable monitoring A or AAAA records but leave on the monitoring of TXT, MX, NS, ... records.
From there, you have the ability to pick exactly which DNS record you want to monitor.
Monitoring CNAME records
CNAME records are a special kind of DNS record. They are used to alias or symlink to another record. These CNAME records will not be discovered automatically by Oh Dear. Instead, you can add them manually.
For example, if you're monitoring freek.dev and you want to monitor the CNAME record custom-cname.freek.dev, you can add that record manually in the DNS check settings.
A look into which nameservers are incorrect
One frequent problem to encounter is that not all nameservers are considered equal. Normally, if you change the DNS records at your hosting or domain name provider, you change them on what is a called a "main" or "master" nameserver.
That nameserver will then propagate the DNS changes to other, "secondary" or "slave", nameservers. On more than one occassion, not every secondary nameserver picks up that change.
That can leave you with a DNS change that is active on 3 out of your 4 nameservers. And this, can lead to immense headaches when trying to debug why something doesn't work all the time. After all, if a client happens to hit that 4th, incorrect, nameserver and your debug efforts are hitting one of the first 3, you're looking at different things. We've been there and it isn't fun.
This is why we look at the responses every one of your nameservers returns. And if there's an anomaly, you will be able to do 2 things:
- Get alerts when your nameservers are out-of-sync
- See clearly which nameserver isn't in-sync and which records they're returning differently
This can be a lifesaver when it comes to debugging DNS!
DNS Record Types explained
A records
The purpose of a DNS A record
The goal of an A record is to point a domain name to a specific IP address. You could argue the A record is the most important one, since eventually every DNS record has to end up at an IP address - regardless if it's for a website, a mailserver or a third-party service.
The A-record will translate the domain record ohdear.app to the IP address 217.19.225.103, so your computer knows what server it has to make a connection to.
This can be for websites but also for mailservers. An A record would also translate the mailserver defined at aspmx.l.google.com. to IP address 173.194.69.26, so your mailserver knows where to deliver the e-mail to.
What does it mean if an A record changes?
If you get a notification that an A record has changed, it means that the IP address behind it is now different.
For a website or API, it means that the server the client would connect to, is now different.
This can be intentional for a number of reasons:
- You're migrating the site or API to a new system and have changed the IP
- You're using a DDoS protection service and they're moving your website across different servers to ensure availability and mitigate an ongoing DDoS attack
If you received a DNS change notification and the above two topics don't apply, it could mean there has either been a mistake in the DNS configuration or someone has changed the DNS on your behalf - without your authorization.
In those cases, it is advised to investigate further by contacting your domain or nameserver provider.
The structure of a DNS A record
The A record is relatively simple in set-up. Here's an example:
ohdear.app. 3600 IN A 217.19.225.103
The structure of that record follows a pre-defined format:
IN A
You define the host name that this record applies to, the TTL and the IPv4 address the record should point to.
Special use cases of DNS A records
There's 2 interesting things to know about DNS a records.
The apex - or root - domain should point to a DNS a record.
Our domain for instance, ohdear.app, should point to an A record directly. It should not point to a CNAME record that in turn translates to an A record.
This is a convention that's currently getting some attention to revise, because it also means it's harder for DDoS protection services like Cloudflare to easily provide their clients with a CNAME to use, because CNAME's aren't allowed as the root domain.
This is also one of the reasons the www. subdomain is still so actively used for bigger websites, since a www. subdomain can point to a CNAME.
Alternatives that are being looked at for this are ALIAS records to solve this, but their adoption is still low.
In most circumstances, a domain points to a single IP address. However, there's also a technique called "DNS round robin" that allows you to have multiple IPs behind a domain name.
This could look like this:
microsoft.com. 2378 IN A 40.76.4.15 microsoft.com. 2378 IN A 13.77.161.179 microsoft.com. 2378 IN A 40.112.72.205 microsoft.com. 2378 IN A 104.215.148.63 microsoft.com. 2378 IN A 40.113.200.201
The domain microsoft.com does not return a single IP address as its A record, but multiple.
The client, ie the web browser or the mailserver, can pick any one of those IP addresses to connect to. They are all considered equal and will be picked randomly - or, round robin.
This allows a website administrator to provide multiple IPs to reach the site, in case one of them goes down.
AAAA records
An AAAA record is very similar to the A record. The only meaningful difference is that an AAAA record is used to describe an IPv6 address instead of an IPv4 address.
Much like the A record tells the client where to find the server over IPv4, the AAAA record will tell the client where to find the server over the IPv6 network.
What does it mean if an A record changes?
The same as if it would be an A record, so we kindly refer to to the explanation of what it means if an A record changes.
The structure of a DNS AAAA record
This too is similar to the A record:
ma.ttias.be. 300 IN AAAA 2a03:b0c0:2:d0::b:d001
It follows the same structure as other DNS records:
IN A
Special use cases of DNS AAAA records
See the same examples shown in DNS A records, as they are almost identical.
CAA records
The CAA record - or Certification Authority Authorization - is used to define which certificate authority can issue a certificate for that particular hostname.
It can be used to say that, for instance, Let's Encrypt can issue a certificate for ohdear.app, but no one else. That would prohibit certificate providers like Globalsign or Cloudflare from issuing certificates for that particular domain.
Why would you use this? It's a security improvement that could prevent a bad actor from trying to get a certificate for your domain and issue a man-in-the-middle attack on your site. If a bad actor could hijack connections to your site (say: on a public, insecure WiFi or via a proxy server he controls), he could use his maliciously obtained SSL certificate to still provide a valid & secure connections for your users.
Your users would never know they were being served a different SSL certificate.
The CAA record limits the potential security risk by only allowing those certificate providers you explicitly authorize.
What does it mean if a CAA record changes?
A change could indicate that there is about to be a SSL certificate change from a different Certificate Authority.
Either a new Certificate Authority is being granted allowance to issue certificates, an existing Certificate Authority could be removed from the allowance list or you could have changed the notification options for new certificates.
The structure of a DNS CAA record
The CAA record has a few special flags that can be set in the DNS record. Here's an example of the 3 available flags you can use in CAA records:
ohdear.app. 3600 IN CAA 0 iodef "mailto:[email protected]" ohdear.app. 3600 IN CAA 0 issue "letsencrypt.org" ohdear.app. 3600 IN CAA 0 issuewild "letsencrypt.org"
As for other DNS records, it follows the similar structure:
IN CAA
In the first example, this would translate to:
- Flag: 0
- Tag: iodef
- Value: "mailto:[email protected]"
The CAA flag
For now, this is almost always set to 0. It is a signaling system that could, in the future, be used for extensions to the CAA protocol.
The only extra flag currently defined is the value 128 which instructs certificate authorities (ie: Let's Encrypt, Globalsign, ...) that they must understand the corresponding property tag before issuing a certificate.
The CAA tag
The tag in CAA records determins what kind of value is being provided in that record. You'll notice in the example above we have a tag called "iodef", "issue" and "issuewild". The value that follows is specific to that particular tag.
The following are valid CAA tags:
- issue: this determines which Certificate Authority(ies) can issue domain certificates for this host
- issuewild: this determines which Certificate Authority(ies) can issue wildcard certificates for this host
- iodef: you can define how (and if) you want to be notified if a Certificate Authority received a request to issue a certificate for your domain, but was denied from doing so by your issue or issuewild tags.
- contactemail: this allows you to publish contact information in DNS
- contactphone: same as email, but for your phone number(s)
The CAA value
The value property determines the value for each of the tags you can specify.
For instance, if you want to only allow Let's Encrypt to issue certificates for your domain, you would set the value of the issue tag to be "letsencrypt.org":
ohdear.app. 3600 IN CAA 0 issue "letsencrypt.org"
Each tag has specific syntax you can use in the value, depending on what you want to convey to the Certificate Authority.
CNAME records
The purpose of a DNS CNAME record
The CNAME record is a special kind of DNS record. If can be looked at as an alias or - in Linux terms - a symlink to another record.
A CNAME isn't just an alias for a single record type, but for the entire host that it applies to. Let's explain that when diving into the structure of a CNAME record next.
The structure of a DNS CNAME record
This is an example of a CNAME record:
www.ohdear.app. 60 IN CNAME ohdear.app.
With this, we have instructed that every DNS lookup for www.ohdear.app should be forwarded to ohdear.app instead. As a result, when a client (ie: your webbrowser) wants to resolve www.ohdear.app, it will make another DNS query to ohdear.app and use that response as the canonical value (= CNAME) of the www.-subdomain.
The structure is similar to A or CNAME records:
IN CNAME
A CNAME must point to another domain name, never to an IP address.
Special notes on DNS CNAME records
This kind of record can be a little confusing. There's one important note on CNAME records, and that is that once you define a CNAME record for a host record, no other record can be present.
For instance, this isn't allowed:
www.ohdear.app. 60 IN CNAME ohdear.app. www.ohdear.app. 60 IN MX 10 mailserver.ohdear.app. www.ohdear.app. 60 IN TXT "google-site-verification=123".
Because a CNAME was issued for www.ohdear.app, you cannot define a MX or TXT record.
Instead, the CNAME instructs every other resource record to be found at the target (in this case: ohdear.app) instead.
If you were to request the MX record for www.ohdear.app in the above example, you would get back the MX record defined at the CNAME target instead: ohdear.app. This is why there can be no overlap with CNAME records.
MX records
The MX record tells a mailserver which server they can connect to in order to deliver the e-mails for that domain.
The value of an MX record is almost always a domain name, that in turn will be an A record to translate to an IP address.
What does it mean if an MX record changes?
Changes to the MX records could indicate a change in your e-mail provider setup. If you're migrating to a new e-mail provider or have received instructions from your e-mail provider to change MX records, this could be intentional.
If you did not expect a change to your MX records, it could be that someone has changed them on your behalf and could now control all incoming e-mail sent to your domain name.
Given how important our relience on e-mail is (2FA or password resets, authorization, authentication, ...) this should be investigated with high priority by contacting your domain or nameserver provider.
The structure of a DNS MX record
Here's an example of an MX record for our own domain name:
ohdear.app. 3600 IN MX 10 mx.mailprotect.be. ohdear.app. 3600 IN MX 50 mx.backup.mailprotect.be.
The structure of the record follows a simple format:
IN MX
There are two special values when it comes to creating an MX record:
- priority: the priority indicates a preference, the lower the priority, the more that mailserver is preferred to be used
- value: this contains the hostname of the mailserver to connect to
The priority should be seen as a preference, not a guarantee. The sending mailserver will first try to deliver e-mail on the lowest priority mailserver.
Should that fail, it can try the next priority, and so on. This allows you to specify a preferred mailserver and a back-up mailserver.
Special use cases of DNS MX records
Has to point to an A or AAA record
An MX record has to point directly to either an A record or a AAAA record.
The MX record can not point to a CNAME but instead has to point to a hostname that can be instantly queried for either the IPv4 or IPv6 record.
MX null records
A special value for MX records can be a "null record" or a "no service MX record". Null records are MX records that tell the client this domain accepts no e-mail.
If we wanted to indicate, explicitly, that our domain would never accept e-mail, we would create a record like this:
ohdear.app. 3600 IN MX 0 .
The priority would be 0 and the value would be a single dot ".".
Fun fact: the domain example.com - which is often used in testing or example documentation, has to explicitly indicate that it doesn't accept email just to avoid millions of emails trying to get delivered:
example.com. 86400 IN MX 0 .
Imagine not having that null record option and trying to deliver all those emails!
NS records
The NS record allows you to delegate further DNS records to different nameservers.
The NS record stands for "nameserver".
Complex NS record structures are often used for very large domain names or organisations, where some (sub)domains can be delegated to different nameservers that are managed by different teams or technology stacks.
The structure of a DNS NS record
The NS records follow a similar, simple, structure like A or AAAA records.
ohdear.app. 3600 IN NS ns4.combell.net. ohdear.app. 3600 IN NS ns3.combell.net.
This example indicates that DNS records for our domain should be found on either ns4.combell.net or ns3.combell.net. This is always "round robin", each nameserver has a similar weight or preference and can be chosen randomly.
Unlike MX records, where you can provide a priority or preference for those records, the NS records are always to be treated equal.
Special use cases of DNS NS records
The NS records allow you to delegate portions of your domain to other nameservers.
For instance, take the following example:
sub.domain.ohdear.app. 3600 IN NS ns1.otherprovider.tld. sub.domain.ohdear.app. 3600 IN NS ns2.otherprovider.tld.
If a client wants to know where example.sub.domain.ohdear.app can be found, it'll have to walk up the DNS tree to find that all DNS queries for *.sub.domain.ohdear.app should be queried from one of the two NS records defined higher.
SOA records
SOA stands for Start of Authority and is an administrative DNS record that described more information about the zone that is being described.
It's mostly important in environments where zone transfers are used, which restricts its relevance for the most part to DNS system administrators. Mind you, for DNS administrators, the SOA record is crucial.
The structure of a DNS SOA record
The SOA record is one of the lengthier DNS records as it contains a lot of different options. Here's an example of the SOA record for our own domain:
ohdear.app. 3600 IN SOA ns3.combell.net. hostmaster.ohdear.app. 2020082810 10800 3600 604800 40000
There's lots to unpack there! This is the DNS record structure:
IN SOA
Here's what those different options mean:
- mname: this defines the primary (or "master") nameserver for this zone
- rname: in a weird format, this is the e-mail address for the administrator of the zone (the e-mail address is encoded as a domain name)
- serial: an ever-increasing number that indicates to secondary or slave nameservers when an update to the zone is made available. If a secondary nameserver has a version of this zonefile that is lower than the current serial, it will request an update
- refresh: how often secondary nameservers should query the main nameserver for updates
- retry: if a refresh fails, this indicates how long a secondary nameserver should wait to try again
- expire: if the main nameserver stops responding, this will indicate number of seconds after which the secondary nameserver should stop answering request for this zone
- ttl: Time to live for purposes of negative caching
PTR records
A PTR record is used to communicate the IP address of the domain.
It's main use is to prevent spam. Some spam filters use this record to check the domain names of email addresses.
The structure of a DNS PTR record
Here's an example of a PTR record:
217.19.225.103.in-addr.arpa. 3600 IN PTR ohdear.app.
The structure of that record follows a pre-defined format:
.in-addr.arpa. IN A
SRV records
SRV stands for "service". The SRV records can be useful to help services auto-discover configuration or connection settings.
For example, a well-configured SRV record can help mailserver auto-determine the settings for POP3 or IMAP mailservers. Or it can help telephones determine the SIP details to connect to the voice-over-IP server.
The structure of a DNS SRV record
The SRV records contain a fairly complex structure, here's an example:
_sip._tcp.example.com. 86400 IN SRV 0 5 5060 sipserver.example.com.
There's several flags that can be provided to a SRV record:
. . IN SRV
The first portion, everything before the TTL, is unique in this record that it also contains meta information about the service you're describing.
TXT records
The TXT record is one of the most free DNS records available. The format is very simple but it can contain all sorts of information, ranging from authentication for Google's Site Verification or alternatives to SPF records and many more.
While the format in DNS is simple, the content it can contain is not. For instance, for SPF (Sender Policy Framework), a unique format for the data is used inside the TXT record.
What does it mean if an MX record changes?
In most cases, it's because an external service has requested either some kind of authorization that you control the domain name. For instance, if you want to add your site to Google's Indexing tools, one of the authentication methods is adding a custom TXT record.
Changes to the SPF records could indicate a new service is allowed to e-mail on behalf of your domain and should be treated with caution and skepticism to avoid anyone impersonating your e-mails.
The structure of a DNS TXT record
Here's the TXT record of Oh Dear itself:
ohdear.app. 3600 IN TXT "v=spf1 a mx include:email.freshdesk.com -all" ohdear.app. 3600 IN TXT "google-site-verification=jIujgqEVQyUbkwSXgE4227mQZPqdrcHsPymDWvt4pwI" ohdear.app. 3600 IN TXT "have-i-been-pwned-verification=8c3c98faa5fbef9d7bce7b1dbb898d1d"
It contains our Sender Policy Framework settings (which determine who can send on behalf the ohdear.app domain) as well as our Google Site Verification and Have I Been Pwned domain verification.
The structure itself is fairly simple:
IN TXT
The value portion can be wild-ranging though, depending on the service that's being referred to.
Time To Live
The Time To Live (TTL) record defines how long a DNS record should be considered valid before it has to be requested again.
Time To Live examples
A TTL value can be as low as 1 second or as long as 10 years, or anything in between.
These values are all valid.
An example of 1hr time to live value:
ohdear.app. 3600 IN A 217.19.225.103
Or 1 second:
ohdear.app. 1 IN A 217.19.225.103
Or 5 years:
ohdear.app. 157680000 IN A 217.19.225.103
As long as it's a positive natural number - not a decimal/float - it's a valid TTL.
What are TTLs used for?
The Time To Live record defines how long a client - your computer, your webbrowser or your mailserver - can go without having to refresh the DNS record.
If your browser requested the IP address behind ohdear.app and it found a TTL of 3600, it doesn't have to request a new value for the next 1hr. In other words, it's cached on the client for the next 1hr.
The TTL is used as a means of speeding up DNS requests (by requiring fewer requests) and offloading nameservers, by making sure the client keeps a local copy of the DNS record for a predefined amount of time.
Feel free to reach out via [email protected] or on Twitter via @OhDearApp if you have any other questions. We'd love to help!
