It seems that the get.desec.io / digga.desec.io (184.108.40.206) server is queryable via TCP via IPv4, but not UDP or IPv6. I’m assuming the actual issue is that this is the internal primary, and it shouldn’t be reachable at all?
Either way, this leads to some ugliness in reporting tools: Hardenize Report: desec.io
As always, thanks for your excellent service
I would also appreciate it if this ugly error message in the reports would disappear.
Unfortunately, I can’t judge how much effort that would take.
But it would be nice to get clean reports.
thanks for your message and welcome to deSEC!
TCP connections on desec.io:53 are used for replication of our zones to the DNS secondaries in the anycast network (details can be found on GitHub, this is also the precise place where UDP access could be enabled if you with to submit a pull request and take this discussion to GitHub). We do not need UDP connections on desec.io:53 and thus, following our policy of minimal exposure, did not enable access to it.
Not allowing UDP connections to desec.io:53 does not mean our service isn’t operational, the claim that this “require[s] your immediate attention” is incorrect. You may want to consider contacting Hardenize to update their tests.
Allowing UDP connections could increase attack surface, but – as far as I can tell – does not provide any benefit beyond a green light in this test.
as you suggested i contacted hardenize and thats the current answer.
From a quick look, I think we should be ignoring this problem. We already allow that SOA-only nameservers are not reachable, as you can see for the IPv6 IP address. So in this case it’s probably a bug.
I’ve opened a ticket to look into it properly and fix. We’ll let you know when we do.
they fixed it
FYI, we’ve fixed the problem you reported. Here’s the report in our staging environment: Hardenize Report: desec.io
The fix will be in production next week at the latest.
Many thanks for your report.