I simply overlooked to create one DNS record in my virtual lab. The good news is that I quickly resolved the problem and even better I prepared the new story on my blog. Here is the detailed (step-by-step) troubleshooting guide for the similar DNS problems.
Let’s begin!
As I already shared with you, I had a problem with a few VMs in my lab. The solution was to delete them all, reinstall the master (template) VM and to recreate them. Of course, after I recreated those machines, I needed to configure them too.
One of those machines is the DNS server for the “public” Contoso zone, named dns1.contoso.com (with its IP address 198.51.100.5). I installed the Microsoft DNS Server role on the server, opened the DNS Administrator GUI tool and added all “A” records in the newly created zone.
This task is very close to that one explained in details in the article about the Linux BIND zone file.
Spotting the problem
As they said – the devil is in details. I made all basic records yet I forgot that one MX record. Why I didn’t notice that immediately? Simply. During the test phase, I perform all tests inside the local network segment. As all hosts are configured to directly use that mail server, I didn’t spot the problem yet.
After a while, I launched the next advanced simulation and I used both e-mail servers in my lab – already named mail.contoso.com (198.51.100.3) and mail.megaisp.net (203.0.113.11). While troubleshooting other problem, I spotted that second email server cannot resolve the name of this first one.
My first reaction was – that’s impossible! Maybe there is the problem with the local DNS servers – bind1.megaisp.net and bind2.megaisp.net.
I recently changed their IPs from 203.0.113.4 to 203.0.113.8 and 203.0.113.5 to 203.0.113.9 respectively, as I’m planning some expansions in the MegaISP network segment. Oh yes, more interesting stories to come!
Here’s my advice – do not rush in the similar situation!
Cool down, take a short break to refresh your mind and be systematic. The rule of thumb is to start checking with the simplest items, like is cord plugged in the outlet and is there power in the outlet. Do not assume!
Bear in mind, when things stop working something is changed from the previous state and many times that is one small change. The “butterfly effect” can make miracles.
Checking the email server first
The first step was to check the local IP parameters on the mail server itself. After all, that server reported the problem and now it’s the great starting point for our investigation.
Although I was sure that I updated the IPs of both DNS servers, this is always the first step you should perform in the similar situation. Do not assume!
I opened the command prompt and typed:
ipconfig /all
As you can see, both DNS servers are correct. However, we still don’t know can we use those DNS servers.
Clear the local DNS cache first
Before I proceeded further, I cleared the local DNS cache. On the Windows machines, you need to open the command prompt window and type
ipconfig /flushdns
The system should respond with
Windows IP Configuration Successfully flushed the DNS Resolver Cache.
This simple trick can resolve many connectivity problems and always do this step in the first place.
There is no equivalent command on the Linux platform as Linuxes don’t utilise the local DNS cache. Only the DNS servers will cache results to speed up operations.
Testing local DNS resolver with the empty cache
The next step was the DNS test with the nslookup command:
nslookup
It should respond with the text like:
Default Server: bind1.megaisp.net Address: 203.0.113.8
Now we will give the command to select only the MX records from domain
> set type=mx
There will be no any information, just > is back. Type here the name of the domain:
> contoso.com
It should replay with the text starting with
Server: bind1.megaisp.net Address: 203.0.113.8
The rest of the output depends on the results and soon you will see the difference. As you can see from the screenshot above, we received only the information about the domain and authoritative DNS server.
contoso.com primary name server = dns1.contoso.com responsible mail addr = admin.contoso.com serial = 6 refresh = 900 (15 mins) retry = 600 (10 mins) expire = 86400 (1 day) default TTL = 3600 (1 hour)
Those information are correct in essence, yet we expect here the name of the email server – mail.contoso.com.
Checking if DNS can process any other zone
Now, to check if the DNS server processing request correctly, I typed the name of the domain managed by that server:
> fabrikam.com
Contrary to the previous situation, I got the correct response:
Server: bind1.megaisp.net Address: 203.0.113.8 fabrikam.com MX preference = 10, mail exchanger = mail.fabrikam.com fabrikam.com nameserver = bind1.megaisp.net fabrikam.com nameserver = bind2.megaisp.net mail.fabrikam.com internet address = 203.0.113.11 bind1.megaisp.net internet address = 203.0.113.8 bind2.megaisp.net internet address = 203.0.113.9
Now, I can be sure that:
- the IP layer of my email server is correctly configured,
- my email server can communicate with the DNS server,
- the DNS server will respond on the remote DNS requests
Let’s proceed to the next step.
Checking the DNS resolver on the related DNS server itself
Maybe this step isn’t necessary, yet I wanted to be sure that I correctly configured the DNS server itself. Remember, the devil is in details. One small detail can crash the whole system. And believe me – it’s always something small and virtually unimportant!
I logged on to the MegaISP DNS server over SSH and performed the same test. Yes, nslookup is actually command originated from the UNIX platform, as many other TCP/IP tools and utilities.
The output of the Linux version is slightly different.
tc@bind1:~$ nslookup > set type=mx > contoso.com Server: 127.0.0.1 Address: 127.0.0.1#53 Non-authoritative answer: *** Can't find contoso.com: No answer Authoritative answers can be found from: contoso.com origin = dns1.contoso.com mail addr = admin.contoso.com serial = 6 refresh = 900 retry = 600 expire = 86400 minimum = 3600 > fabrikam.com Server: 127.0.0.1 Address: 127.0.0.1#53 fabrikam.com mail exchanger = 10 mail.fabrikam.com. >
As you can see:
- I’m now using that DNS machine as any other DNS client
- it will connect to itself as its own DNS server and
- it will issue all requests from the terminal application named nslookup to the locally running BIND DNS server
- the DNS server listen on the UDP port 53 (or 53U in short).
The response from the dns1.contoso.com was interesting – No answer! But all other details are there. I defined that zone as the stub zone, meaning that bind1.megaisp.net will forward all queries to dns1.contoso.com.
In the same time, it will properly return the MX record for the fabrikam.com zone. On top of that, there is no errors in the log.
Checking the authoritative DNS server
The authoritative DNS server (i.e. the server that holds the zone file) for the contoso domain is dns1.contoso.com. I jumped to it and performed the same tests on it.
First, I ran the nslookup command:
And again, the DNS server’s IP is correct (the server itself) yet there is not expected answer. Let’s check how DNS works with other domain.
As it was expected, it resolved the MX record for the fabrikam.com domain. Now, we can say that problem is inside this DNS server.
Checking the DNS zone records
I opened the DNS GUI and navigate to the CONTOSO Forward Looking Zone. Bingo!
As you can see, I completely forgot to add the MX record. Let’s create one.
Adding the MX record
Although I’m using the older Windows Server version in my lab, such process it the same for any Windows Server version from 2000 to 2019. Now, on top of my head, I think that this could apply even for older Windows NT 3.51 and 4.0 Servers.
Right click in the empty space and the new context menu will open. Choose the option named New Mail Exchanger…
The new window will pop-up. On that window, you can add some information and one of them is to specify the host name – the field named Mail server.
There’s the [ Browse… ] button right to that field. Now, you can either type the full DNS name or navigate to it through the GUI. Bear in mind that such host need to be previously defined as the A record in your zone.
As you can see from the screenshot above, when you choose the A record, the FQDN name is automatically filled in the field named Selection. That name will be used in our zone.
When you’re satisfied with your choice, just click [ OK ] and that information will be filled on the first window.
Now, just click [ OK ] again and the new MX record is added in our zone.
If you need to add more than one MX record, just increase the value in the field Mail server priority. It’s common to assign priority of 10 to the first server, 20 to the second and so on, yet you can give them any values here. Bear in mind that two servers in the same domain should not have the same priority.
Testing the newly added record
We will test this new record using the same method with nslookup command.
The first test is on the DNS server itself. You can always clear the local cache before this test.
As you can see, the DNS server now returned the correct information. Let’s check other machines.
OK, as this is my lab, I cheated a bit. I restarted the named process on bind1.megaisp.net and flushed the local cache on mail.megaisp.net to speed up operations. Otherwise, I will need to wait until locally cached information expired and both machines issue the new DNS query.
I performed the test from the mail.megaisp.net server and now it works fine:
After a while, the email server got positive response and started the mail exchange process:
Eventually, all emails were delivered to the local user mailbox.
What we learned here?
All of us can make mistakes, but it’s more important to consider such mistake as an opportunity to learn something new.
I rebuilt that part of my lab from the scratch and I manually restored the configuration. During that process, I lost sight of that one record. That leads us to the other important topic – the backup.
As this is my lab where I’m testing different concepts or recreate any interesting scenario from the real life (remember that I cannot reveal the real names of customers, servers, etc.), I never consider it important enough to make a backup. My bad!
Nonetheless, even if there’s no backup, we can always create the configuration scripts. I didn’t made it as I consider this very simple, as generally speaking – it is. However, this situation taught me that I should made one.
Yes, it’s possible to configure many Windows services through the command line scripts. Although you had limited capabilities in older Windows versions, starting with Windows 2000, Microsoft continuously adding more and more command line tools and shells.
Even better, this article could be your guide during the process of adding new MX (or generally speaking – any other) record in your zone. I focused here only on that specific record, yet the process for other types is very similar. Again, those procedures are universal for any Windows server version.
In case that you’re coming from the Linux world, you can still learn a lot from this situation. Check out the articles related to the Linux BIND server, its configuration file and related zone files. Bear in mind that I’m mostly using Tiny Core Linux and that the file paths/locations are different comparing to other larger distributions, like Debian, Ubuntu, RedHat, CentOS, openSUSE – to name a few, yet all other information is universal.
In case that you have any specific question or would like to read more about similar subjects, feel free to comment below or to contact me.
Stay tuned.
MiViLiSNet 