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 (8.8.8.8) gives me an IP address only once in a while and SERVFAIL the rest of the time. Using dig with Cloudfare (1.1.1.1) 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…
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.
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.
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
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 @8.8.8.8 mydomain.eu ds’ I get the DS record returned. As expected.
But if I query my MIAB DNS (dig @ns1.box.mydomain.eu mydomain.eu ds’) I do not get the DS record. Other queries (e.g. ‘dig @ns1.box.mydomain.eu mydomain.eu aaaa’) return expected values.
Also if I query the DNS slave server on my domain (‘dig @ns6.gandi.net mydomain.eu ds’) I fail to get a DS record. Other queries to the slave (e.g. ‘dig @ns6.gandi.net mydomain.eu aaaa’) return expected values.
Is this expected behavior? Can someone with DNSSEC active try this for me?
This is expected behaviour. The ns1.box. 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.
; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> +trace a ravenstar68.co.uk @8.8.8.8
;; global options: +cmd
. 78128 IN NS d.root-servers.net.
. 78128 IN NS c.root-servers.net.
. 78128 IN NS a.root-servers.net.
. 78128 IN NS j.root-servers.net.
. 78128 IN NS h.root-servers.net.
. 78128 IN NS b.root-servers.net.
. 78128 IN NS l.root-servers.net.
. 78128 IN NS k.root-servers.net.
. 78128 IN NS i.root-servers.net.
. 78128 IN NS m.root-servers.net.
. 78128 IN NS f.root-servers.net.
. 78128 IN NS e.root-servers.net.
. 78128 IN NS g.root-servers.net.
. 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 8.8.8.8#53(8.8.8.8) in 20 ms
uk. 172800 IN NS nsa.nic.uk.
uk. 172800 IN NS dns4.nic.uk.
uk. 172800 IN NS nsc.nic.uk.
uk. 172800 IN NS dns3.nic.uk.
uk. 172800 IN NS dns1.nic.uk.
uk. 172800 IN NS dns2.nic.uk.
uk. 172800 IN NS nsd.nic.uk.
uk. 172800 IN NS nsb.nic.uk.
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(k.root-servers.net) in 275 ms
ravenstar68.co.uk. 172800 IN NS ns1.box.timothydutton.co.uk.
ravenstar68.co.uk. 172800 IN NS puck.nether.net.
ravenstar68.co.uk. 3600 IN DS 15321 7 2 955FE55BC347842C995A5B5215985D0C0AD9A4CE4AC5267338849E7E D0DD35F2
ravenstar68.co.uk. 3600 IN RRSIG DS 8 3 3600 20200611003559 20200507001500 33621 co.uk. BpcyJ61+a1n+Pfpib/1wBxSConwNQXfKvm/ELxO1xzbQ0g+sp672WqUI NOLhkDuqb/T8LpGs0mdVe6CbaIvrS25OeO4tQpGKj1wNFeTVpT4HBUVC hsXqCmahOphncah/CPLBbD6nUdmW2qOXDreckircn0MKSJb5OYmNAmzu UvM=
;; Received 340 bytes from 43.230.48.1#53(dns4.nic.uk) in 23 ms
ravenstar68.co.uk. 1800 IN A 77.68.89.100
ravenstar68.co.uk. 1800 IN RRSIG A 7 3 1800 20200528000000 20200428052503 15974 ravenstar68.co.uk. ZY5Tz8UPrwx8dhQ0Q/X6L08YGoTxtp9FcPKYqvR3qSqOEMohck679aaC HwFnUoPbpRipl0HIfj++Ge5A4LfFLbz2xyNMiDK3Jzz5dyB4Ox0fy69x 9P7xCuKzBXDFUrfRZu21FT/0WeQRaiCgGWw90RyelaAtY3ilMcjjg+VW mX0=
ravenstar68.co.uk. 1800 IN NS ns1.box.timothydutton.co.uk.
ravenstar68.co.uk. 1800 IN NS puck.nether.net.
ravenstar68.co.uk. 1800 IN RRSIG NS 7 3 1800 20200528000000 20200428052503 15974 ravenstar68.co.uk. vQ6t8pYCZaNLVflU+7CfQ/4ApztuW7U8emyrN/Fe2v8VTm9RGZ1Jrgo0 zKRifiV2kWpuQ7D1ROsT00QICFKim86npOglANnMwtjDBbaJ1s/Qt8uK Ge3+LB786MiYOW31x18pKogmPir7K6sCj5fUA30Nyakbb9MLVi15TGCT vM4=
;; Received 481 bytes from 77.68.89.100#53(ns1.box.timothydutton.co.uk) in 22 ms
The DS Key is here:
ravenstar68.co.uk. 3600 IN DS 15321 7 2 955FE55BC347842C995A5B5215985D0C0AD9A4CE4AC5267338849E7E D0DD35F2
And is served from:
;; Received 340 bytes from 43.230.48.1#53(dns4.nic.uk) 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(k.root-servers.net) 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).
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.
