Validating DNS Entries with dig
I describe a UNIX tool, called dig
, that checks if DNS entries are
propagating properly.
I walk through a situation where I need to make DNS CNAME entries to
match on specified by a provider for an integration. When there were
problems with DNS entries I made and the third party specification, I
used dig
to validate where was the mismatch.
To validate DNS entries and if the third party system isn’t giving
detailed feedback, dig
is the tool to get feedback yourself!
This article will take about six minutes to read.
Introduction
I was migrating to a new email provider for my newsletters and the provider has an integration for sending emails.
The requirement for the integration: specific DNS entries on my domain must match the values provided by the provider..
Easy-peasy, right?
Problem
Well, I spent more than two minutes and I was still stuck. I just had to copy-paste entries from the provider to my hosting service’s DNS entry. The email provider had a verification button on the site to validate configuration.
Every time I pressed the verification button, the response was:
DNS Entry Not Configured
WHAT THE?!
I am copy-pasting the exact entry! What is wrong?! I triple checked the entry. It matches!!!
I know with DNS entries, there’s a TTL, time-to-live, for the changes to propagate on the Internet. The Internet is a marvelous and complex piece of machinery. Maybe the DNS entries will work after an hour (the TTL value). I will step away for a bit and let the Internet do its thing.
An hour later…
Well, I waited longer than the TTL (one hour) and the DNS change should have propagated across the whole Internet.
I press the verification button on the email provider’s site and the response is:
DNS Entry Not Configured
YOU HAVE GOT TO BE KIDDING ME!
OK, there’s something else missing or I’m missing something. I need to find out what’s really going on.
I need a tool to look up DNS entries to find out if I’m wrong or my hostname provider is wrong or the email provider is wrong or whatever.
Enter: dig
the “domain information groper”
There are tools on the web that can look up DNS entries for you, which I started with.
I dig a bit further and find dig
, domain information groper, a local
UNIX tool to validate DNS entries to be the best. (Yes, pun intended
;-))
To check the DNS entry for a hostname, run the dig
command as:
Let’s go through what a misconfigured CNAME DNS entry would return and compare that to a properly configured CNAME DNS entry would be.
Misconfigured DNS CNAME
Normally, one would start with a working example and see what’s wrong. In my case, the email host’s tool was telling me the DNS entry was invalid.
Let’s start with: what does a misconfigured CNAME entry look like?
Using dig
to lookup a DNS entry for one that does not have a CNAME
entry: em5478.redgreenrepeat.com
The easiest way to tell the DNS CNAME is not configured is seeing
there is no ANSWER SECTION
. It’s not immediately obvious because
that section does not appear at all.
To know if a DNS CNAME entry is valid, we require “insider knowledge” of a valid CNAME entry.
Let’s look at a valid CNAME DNS entry.
Properly Configured DNS CNAME entry
We need a valid DNS CNAME entry to see dig
results to validate
whether another entry is invalid.
Let’s see what the dig
result is for:
https://www.redgreenrepeat.com,
which definitely works.
Just to highlight the ANSWER SECTION
, which is here now and not in
the misconfigured DNS CNAME entry in the previous
section in the response as it contains:
and the first line:
Is the CNAME entry, which is saying www.redgreenrepeat.com
points
to: redgreenrepeat.github.io
. (Yes, this is how this whole website
operates.)
Solving the Original Problem
With this information, I found out the problem: copy and pasting the whole entry is not what the email provider needs as the DNS CNAME entry.
The email provider said to copy and make this entry:
The website’s copy button copied the whole line.
I pasted that as a CNAME DNS entry into my hostname DNS.
Well, my hostname DNS provider would take: CNAME
em5477.redgreenrepeat.com
and map it as:
em5477.redgreenrepeat.com.redgreenrepeat.com
Checking the em5477.redgreenrepeat.com.redgreenrepeat.com
value
using dig
:
(facepalm)
Things were working on the hostname side, it’s just that the email
provider expects: em5477.redgreenrepeat.com
Let’s make that DNS CNAME entry, em5477
, and see the result:
There’s an ANSWER SECTION
and it contains:
NOW when I push the “verify” button on my email provider it says:
CONFIGURED
Yes.
Conclusion
Networking is hard. It’s one aspect of the Internet that intimidates me as getting configurations wrong just doesn’t yield any result, at least from the tools I know.
This is where it’s important to find the right tools in the
domain. dig
is on every UNIX system, yet this is the first time I
had to use it to solve an actual problem.
Without dig
, I may never would have figured out this configuration
mismatch.
Thank You dig
!