When DNSSEC is Semi-Configured

Preface

Years ago I bought my DNS domain name with a DNS registrar in The Netherlands. They also offered DNS hosting so I naturally hosted my zone there also. Years passed without any serious DNS issues and then, a few weeks ago, I decided to move my DNS zone to Microsoft Office 365.

I wanted to move my zone to Office 365 because of several advantages:

  • I can determine the TTL for my DNS records, my DNS registrar does not have that option.
  • Propagation is faster than with my DNS registrar. This is always helpful when adding or changing DNS records.
  • Last but certainly not least: Office 365 prefills the zone with the DNS records needed for the various Office 365 services to work, such as Exchange Online, Skype for Business and Mobile Device Management. BTW: on top of that you can also add your own custom records.
Moving my DNS zone to Office 365

I have an Office E3 subscription and when I started using it I added my DNS domain to the subscription so that mail can be delivered to my domain, etc.

Within Office 365 you can decide to manage your own DNS records using an external provider (like I did at that time) or to let Office 365 manage your DNS.

I choose to let Microsoft Office 365 manage my DNS (option Set up my online services for me). At some point in the process the wizard tells you to change the name servers for your DNS zone to Office 365’s DNS server.

I logged on to my DNS registrar and changed the name servers for my domain.

After doing that I waited for an hour and proceeded with the DNS wizard in Office 365. Office 365 verified that the delegation settings were correct, offered the option to import my custom DNS records which I did and then my domain was managed by Microsoft.

I then performed a DNS check using the web site MXToolbox and everything seemed to be in order (except for some SOA Serial Number Format error).

DNS Problems

Some days passe by and then started I noticing that mail messages to certain e-mail domains could not be delivered. Mail messages to other domains arrived without any problem. Looking through my Exchange Online message tracing I discovered that the receiving servers could not verify my sending Office 365 server or were complaining that they could not connect to DNS at all.

At around the same time Atlassian (which is the SaaS provider for applications Jira and Confluence) began sending me messages telling me they could not verify a certain TXT-record in my DNS zone which they check periodically to validate that I am indeed the owner of the domain.

So something certainly looked wrong. I verified the existence of the TXT-record myself using the web site DigWebInterface. Using this web site (which is graphical representation of the DNS tool Dig) I was able to query the most important DNS servers around the world at the same time. The result showed that some DNS servers could see my DNS-records and some did not!

Using web site DNSViz I found out that there were problems with DNSSEC settings on my zone. And the Verisign Labs web site showed me the details.

At that time I had already opened support tickets with my registrar, my DNS hosting provider Office 365 and with the TLD registrar for the .nl zone (SIDN).

The only solution my DNS registrar wanted to discuss was me moving my zone back to them. Out of curiosity I eventually did that and the DNS problems went away after a day or so. Hoping that something had been reset I decided to move my domain back to Office 365 again which made my registrar quite angry with me (“It is working now so how can you be so foolish to move to Office again? There will be no support from us!”).

The DNS problems started again. I waited a few days but it did not go away.

Solution

I filed a problem ticket with Microsoft again, pointed them to the DNSSEC issue and after a few days they told me:

The name servers for ictnsure.nl are ns{1-4}.bdm.microsoftonline.com., which are running on Azure DNS. The problem looks to be that the ictnsure.nl domain has a DS record for DNSSEC, which will cause failures in a lot of major resolvers due to failing to validate DNSSEC which is not supported in Azure DNS. The fix here would be to remove the DS record for the zone from domain registrar.

This conclusion was validated by SIDN:

As far as I can see it would be sufficient to remove the current key material from our Domain Registration system. Your registrar should be able to do this.

I asked my registrar (kindly!) to remove the DNSSEC DS-record from SIDN’s systems. A few moments after they executed this request my mail was working and TXT-records showed up all around the world.

So the problem seemed to be that when I buy a domein my registrar is setting my zone up for DNSSEC. This includes configuration at the TLD .nl and in the zone itself.

But whenever I move my zone to a DNS hosting provider that does not support DNSSEC the DNSSEC information in my zone gets removed. So now we have a half configured DNSSEC situation which apparently confuses some DNS servers in the world.

The solution is to remove the DNSSEC configuration completely by removing the DS-record at the TLD registar.

BTW: After removal of the DS-record the DNSSEC diagnostics looks like in the screenshot below. My zone does not have any DNSSEC configuration now.

TL;DR

My DNS registrar did not remove the DNSSEC DS-rcord from the systems of the .nl TLD registrar when I moved my DNS zone to Office 365. Office 365 DNS servers do not support DNSSEC and therefore the configuration of my DNS zone was broken. As a result some (not all) DNS servers worldwide could not get to the DNS records of my zone resulting in mail not being delivered to some e-mail domains and other issues.

This issue was resolved as soon as my registrar removed the DS-record.

Leave a Reply

Your email address will not be published. Required fields are marked *