Strange error with DNSSEC


Since a couple of days I am not able to send mail from my ISP mail server to any mail address on my MIAB server.

What seems to be the problem according to my ISP’s support is that the their mail server fails to get an IP address for my box due to a DNSSEC key mismatch. And indeed, if I perform a dig using their DNS server I get a SERVFAIL and no IP address each and every time. A dig using Google ( gives me an IP address only once in a while and SERVFAIL the rest of the time. Using dig with Cloudfare ( I get the IP address of my box each and every time. No problem.

Everything on my box is ‘in the green’. The DNSSEC key is set at my registrar (Gandi) and the box says the DS record is set correctly.

I did not change anything other than performing the odd update/upgrade every now and then. No configuration changes. Never had a problem with this, my box is humming fine for over 3 years now, until this problem started to show up the night of April 28-April 29.

I am on MIAB0.44 with all updates installed.

I have no idea where to look now so I welcome any thought…

Disable DNSSEC

Wait a day

Reenable DNSSEC (if you really must).

Will do.

Does the ‘if you must’ remark mean that DNSSEC is thought of as useless/premature/unstable?

A SERVFAIL message implies that your local DNS server is not responding (or not correctly). The resolving computer (your PC?) has got an address for your domain’s DNS server (from the “glue” records at Gandi), but couldn’t get a reply from your local DNS server, or maybe the reply is wrong.

I don’t have any magic place to look, but remember DNS can be very confusing because almost everything is cached. Some some servers will give you a cached but correct old response, some will give you a cached incorrect response, and some might actually query. “dig” to your own server to see what replies it is sending - and therefor what everyone else is caching.

My guess is that something has changed out there and stuff doesn’t match up any more. If completely lost, you could try the MIAB re-install process … get it to rebuild everything from the start??

DNSSEC is a nice idea, but it has not been uniformly accepted and implemented over the internet. It has been a major source of problems for people however. Personally, my thought is that a smaller domain really does not face the risk of someone poisioning their DNS unlike a majorly unpopular domain. Think the ‘Daily Stormer’ or some other controversial site. Here is an article from a bit over a year ago addressing some of the issues I raised.

One of the issues pointed out in the article is that the DNSSEC standard is poorly implemented by many DNS providers and even more registrars … MiaB has actually implemented DNSSEC absolutely perfectly and should be applauded for doing so.

And that can often be caused by DNSSEC issues.

The most major DNSSEC issue that I have seen here with MiaB users is when a user does NOT have email addresses on their root domain, thus the root domain is not properly configured for DNS.

So, always have an email address on your domain’s apex IF you are using MiaB as authoritative DNS for your domain.

I deleted the DNSSEC key at Gandi and am waiting for it to trickle down.

Obviously my box is now complaining 'This domain’s DNSSEC DS record is not set. ’

Where can I find the generated DNSSEC key in the MIAB setup? The keys I found in the nsd tree are not the same as the one reported in the system status check.

Click the ‘show more’ link.

In my opinion, that is something to ignore. :slight_smile:

I tinkered with this problem for the better part of the day.

First I removed the DNSSEC key at Gandi. That did not solve the problem, at least not in a few hours. I then created a second slave DNS. Created some custom DNS records for my domain in MIAB. Deleted them again. Checked the slave DNS’s, they were updated. But the problem persisted. Everything fine with Cloudfare’s DNS, not so fine with Google’s DNS, and far from fine with the DNS from my ISP.

Then, after lunch, suddenly some mail from 4 days ago started to appear. One by one. Newly created mails still were not delivered. Two hours later all my missing mail was delivered. Also the mail I created today. And if I now send a mail from my ISP address to one of my MIAB addresses, it is delivered right away.

So the problem just went away. Why? Maybe the DNSSEC key did the trick, but took some time. Or the tinkering with the slaves restarted something somewhere; this would explain why half of the DNS queries at Google were faulty while the other half returned an IP address.

I leave it at this for now, see if my automated mails later this night end up in my MIAB. And then tomorrow I re-eable DNSSEC again. See what happens. I am just curious…

Thanks everyone for offering advice; my understanding of DNS / nsd / slaves and dig became much better today :sunglasses:


I have another question on this.

This morning I reinstalled the DNSSEC key on my domain. I ‘digged’ around a bit and found something I don’t understand.

If I do a ‘dig @ ds’ I get the DS record returned. As expected.
But if I query my MIAB DNS (dig ds’) I do not get the DS record. Other queries (e.g. ‘dig aaaa’) return expected values.

Also if I query the DNS slave server on my domain (‘dig ds’) I fail to get a DS record. Other queries to the slave (e.g. ‘dig aaaa’) return expected values.

Is this expected behavior? Can someone with DNSSEC active try this for me?



I’ll try testing later today …

This is expected behaviour. The server is an authoritative server which only serves records from your zone.

The DS record is used to validate the RRSIGS in a zone and as such they are NOT served by your box itself, rather they are found in the parent zone. This is because the DS records are used to establish a chain of trust that extends all the way to the root DNS zones.

I’ll use one of my domains as an example -

Lets DIG using the +trace command

; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> +trace a @
;; global options: +cmd
.			78128	IN	NS
.			78128	IN	NS
.			78128	IN	NS
.			78128	IN	NS
.			78128	IN	NS
.			78128	IN	NS
.			78128	IN	NS
.			78128	IN	NS
.			78128	IN	NS
.			78128	IN	NS
.			78128	IN	NS
.			78128	IN	NS
.			78128	IN	NS
.			78128	IN	RRSIG	NS 8 0 518400 20200519210000 20200506200000 48903 . bSRmGXQUAZ+LjXcD7xIned6+sR+kTipMzaySMwnfjIpzcn2ui64mFokb 4hnz6gCPH3wd8WctFR9UHPRVwh+3jqGgLMbxq3xujJmTI1Kvcg+Fvzg2 7t1v1tVMdwgFyWvLdmdoEcK7jQx5KbKIKdRyKV7nfFuLDdljwVBjD4uV hZLjQpgM0JEHO4C3DEOHye8NmdpPzwGc5T5hvyl948ZzERlmWD4Yh2UZ 0wmfb6h05LPra70l73hKokzA5r8qLsi+0LjfM1XkS/pINd6YOw27/gMk EgWXscRxfvGG+AtVymi7kP5QnVy1GAnFIotW1kgTlQ1jq8Q6wGtW/c9n g/ksSA==
;; Received 525 bytes from in 20 ms

uk.			172800	IN	NS
uk.			172800	IN	NS
uk.			172800	IN	NS
uk.			172800	IN	NS
uk.			172800	IN	NS
uk.			172800	IN	NS
uk.			172800	IN	NS
uk.			172800	IN	NS
uk.			86400	IN	DS	43876 8 2 A107ED2AC1BD14D924173BC7E827A1153582072394F9272BA37E2353 BC659603
uk.			86400	IN	RRSIG	DS 8 1 86400 20200519210000 20200506200000 48903 . O2FOpTud5vgd5LIaGbXQDg/wSSvuFQjRu1NLTBx4vZMlEs26pQ5+rxh1 7MZ5BhDvA09J3VlZ8kB2lUHmdr3xYFWj8TvMhSEtdCuN7i4hYh43e/Vh FtKn/vEwyLKAyq3nfEyd3t7Jd21xUvzHQfCwOYoYjhnGaXS2CUjncjAJ thPZXsUQ7Y//jDJj9P+tEEGaTe6e3Lo0C+dIXMxm/6ZFWGVyJBN5/aPj vtOoqd/ckE8SywrN0iCV+bylXJFPDXYpGt4OFaPyXB04krsb/5n4TwWN udMB6F1Gx8J7tZrELCdrCSfr2YH38YDxO0aAehXK6NSEtPRPl/MhxKhj j8btcg==
;; Received 805 bytes from 2001:7fd::1#53( in 275 ms	172800	IN	NS	172800	IN	NS	3600	IN	DS	15321 7 2 955FE55BC347842C995A5B5215985D0C0AD9A4CE4AC5267338849E7E D0DD35F2	3600	IN	RRSIG	DS 8 3 3600 20200611003559 20200507001500 33621 BpcyJ61+a1n+Pfpib/1wBxSConwNQXfKvm/ELxO1xzbQ0g+sp672WqUI NOLhkDuqb/T8LpGs0mdVe6CbaIvrS25OeO4tQpGKj1wNFeTVpT4HBUVC hsXqCmahOphncah/CPLBbD6nUdmW2qOXDreckircn0MKSJb5OYmNAmzu UvM=
;; Received 340 bytes from in 23 ms	1800	IN	A	1800	IN	RRSIG	A 7 3 1800 20200528000000 20200428052503 15974 ZY5Tz8UPrwx8dhQ0Q/X6L08YGoTxtp9FcPKYqvR3qSqOEMohck679aaC HwFnUoPbpRipl0HIfj++Ge5A4LfFLbz2xyNMiDK3Jzz5dyB4Ox0fy69x 9P7xCuKzBXDFUrfRZu21FT/0WeQRaiCgGWw90RyelaAtY3ilMcjjg+VW mX0=	1800	IN	NS	1800	IN	NS	1800	IN	RRSIG	NS 7 3 1800 20200528000000 20200428052503 15974 vQ6t8pYCZaNLVflU+7CfQ/4ApztuW7U8emyrN/Fe2v8VTm9RGZ1Jrgo0 zKRifiV2kWpuQ7D1ROsT00QICFKim86npOglANnMwtjDBbaJ1s/Qt8uK Ge3+LB786MiYOW31x18pKogmPir7K6sCj5fUA30Nyakbb9MLVi15TGCT vM4=
;; Received 481 bytes from in 22 ms

The DS Key is here:	3600	IN	DS	15321 7 2 955FE55BC347842C995A5B5215985D0C0AD9A4CE4AC5267338849E7E D0DD35F2

And is served from:
;; Received 340 bytes from in 23 ms

This is Nominet’s DNS server (this is the parent registrar for all .uk domains).

The DS record is used to validate the RRSIGS in my zone. Likewise Nominet have their own DS record.

uk.			86400	IN	DS	43876 8 2 A107ED2AC1BD14D924173BC7E827A1153582072394F9272BA37E2353 BC659603

Which is held in the root zone

;; Received 805 bytes from 2001:7fd::1#53( in 275 ms

This is why you have to upload the DS records via your registrar - their system uploads them to the relevant TLD zone (or should do, I had issues with both 123reg and 1&1Ionos, Godaddy allowed me to add DS records but removing them wasn’t as easy as it should be).


Hi Tim,

I came to that conclusion more or less myself, as both my master NS and the two slaves did not return the DS records where every other DNS I tried did.

Thanks for the explanation!

In the meantime I re-enabled DNSSEC on my domain and that works nicely ever since. Al in all I have no idea why this problem occurred. Most likely caused by some quirk somewhere else.

Thanks again everyone for their input.



1 Like