I switched to deSEC because they allow you to create tokens for DNS-01 validation which are tightly scoped to a single subdomain. This means I have a VM running "service1.foo.example.com" which is not publicly available but can still get certs from letsencrypt, but with a token that can't be used to issue certs for other domains.
I signed up and saw they only allowed a single subdomain for DDNS, with docs saying to contact support if you needed more. I emailed asking for just 1 more subdomain and support told me that for my usecase I should just use CloudFlare.
I had this issue with cloudns and a single record with an IPv4 and IPv6 address. They only allowed one free ddns record which covered exactly one protocol. On top of that, they added records to resolve unknown names for advertising purposes.
I get that it costs money to run a DNS service but it seems like it should be a lot cheaper at scale than a lot of companies are providing.
That’s good to know! I was actually very excited when I first found them; I was surprised that there aren’t many free/open public DNS hosting services.
support told me that for my usecase I should just use CloudFlare
Not true. When users ask for multiple domains under .dedyn.io, we send them the following text:
Unfortunately, deSEC accounts are limited to 1 .dedyn.io domain.
>
> However, you can create additional subdomains under your existing domain, by creating a record in our web interface and putting the subdomain name into the "subname" field. For example, if you have domain.dedyn.io, and you create a record with "subname: internal", then the record will apply to internal.domain.dedyn.io.
>
> You can also purchase another domain elsewhere, and then bring it to deSEC for DNS hosting. Please let me know if you would like to go that route.
>
> Does that help?
When I last tried deSEC, the service was reliable and well worth the price of admission, but the web UI and API were both quite rough, and propagation tended to be quite slow. It was annoying to do an ACME DNS01 challenge on it, for example. IIRC, the API didn't have a complete set of replace/edit endpoints, so even DNSControl (https://github.com/DNSControl/dnscontrol) would leave records nonexistent for a while while during updates.
As an aside (though this certainly applies to deSEC) it's strange to me how so many DNS services (free or paid) struggle to import simple Bind zone files, often either giving a vague error ("one or more records could not be imported"), mangling records, or even just silently omitting records. Parsing a zone file has some gotchas, but it doesn't seem like it should be that hard.
A problem there is needing to temporarily delete the entire domain just to update using a zone file. I don't manage the DNS for anything remotely critical, but if I did, it would be unacceptable. Either way, the workflow feels deeply incorrect (though most users likely will use the record editor or the API instead; even I'd use the API through DNSControl, now).
Logging back into deSEC right now, it seems like the parser does work better than it used to, but TTL inheritance is still spotty. As an extreme example, the following input:
@ 7777 IN SOA x. x. 1 9999 9999 9999 9999
A 203.0.113.1
4444 AAAA 2001:db8::1
www A 203.0.113.1
... correctly gets parsed by BIND (with the addition of a dummy NS record) as:
@ 7777 IN A 203.0.113.1
@ 4444 IN AAAA 2001:db8::1
www 4444 IN A 203.0.113.1
... but deSEC parses:
@ 9999 IN A 203.0.113.1
@ 4444 IN AAAA 2001:db8::1
www 9999 IN A 203.0.113.1
... where 9999 is a $TTL value from a different zone file, from a different domain, that I'd imported in a completely different session. The value is permanently (?) stuck to the entire account. This is ultimately almost a squabble since there's simple workarounds, but it did affect me when I used deSEC, and it's the sort of problem that I constantly run into with other managed DNS services too.
First, I guess it would be a good idea to report discontent about things feeling "deeply incorrect" to our issue tracker. Just lamenting about the state of things won't change it.
Unless I happen to swing by. -- We use dnspython for zone parsing, and it turns out that this is legacy (pre RFC 2308) behavior implemented there. You could say it's a bug there. We've created a patch: https://github.com/rthalley/dnspython/pull/1300
When it gets merged, we'll update our API to use the new TTL inheritance mode (tracked at https://github.com/desec-io/desec-stack/issues/1262).
Call me cynical, but I've long stopped taking the time to report minor edge case bugs if I can't also provide a solution or patch, as such reports usually get ignored or sit at the bottom of a bugtracker forever. I likely didn't realize that deSEC was a FOSS stack at the time, or I might have looked into the zone file parsing further.
As for the zone file based workflow requiring zone deletion/recreation, perhaps a report/discussion would have led to something, but I was in the middle of testing managed DNS providers to get rid of my BIND servers and I didn't have any investment in deSEC, so it didn't occur to me to take the time. My initial post on here was less lamentation and more conveying personal experience to (possibly) save someone else some time.
In any case, none of these things were showstoppers for me (I went to another (paid) provider because I need very short TTL on some records for testing purposes), but I'm glad you took the time to look into the parser; it almost certainly will benefit others.
That rebuttal held water 10 years ago, but fortunately we have made a lot of advancements since then.
DNSSEC was a solution trying to solve the problem of DNS security while still maintaining transparency for DNS operators to spy on queries. At the time, passive DNS was one of the tent poles of tracking malware and responding to security incidents.
We have since committed entirely to transport security in the form of DoH and friends. It solves the vast majority of problems we actually have.
DoH only secures the connection between the DoH provider and the client, not the response from the authoritative DNS server. It also isn't sufficient for DANE or similar. So DoH doesn't completely solve the problems DNSSEC tried to.
Authentication is precisely the problem DNSSEC is supposed to solve. And authentication is part of transport security.
TLS usually does provide authentication. The certificate is signed by a chain that leads up to a trusted CA, and content of the stream is authenticated using an AEAD encryption algorithm. But RFC 9539 specifically doesn't require the certificate to be signed by a CA (and recommends using a self signed cert) or the client to verify the authenticity of the certificate used by the server.
This means that an active MitM could return whatever it wanted to the recursive resolver. Pulling that off is admittedly more difficult than a MitM on a public wifi network at a coffee shop, but it's still a gap in security.
And no, you can't just use Web PKI to verify connections to authoritative DNS servers, because Web PKI relies on DNS to confirm domain ownership.
The rebuttal is old because the criticism is old. If you give more up-to-date criticism, then more modern rebuttals are available.
”DNS security” can mean many things, but DNSSEC was meant to solve the problem of verification of DNS data, while still allowing for offline signing and secondary DNS servers serving pre-signed zones, without distributing the key everywhere. DoH/DoT do not solve this; they solve different problems.
It is not surprising that European registrars have added millions of new names nobody is ever going to visit, all of them signed by default at their registrars. That's not meaningful.
Had DNSSEC been deployed 5 years ago, Muammar Gaddafi would have controlled BIT.LY’s TLS keys.
Yupp. Which is why using bit.ly is a terrible idea unless you live in Lybia
Did you read the article? It's saying that DNSSEC as an implementation to prevent MITM is flawed; other solutions that protect against MITM are proposed.
We found deSEC to be the only affordable DNS supplier in the EU that complies with state of the art secure DNSSEC.
I mean, if your definition of "affordable" is free, then sure.
But for the record there are other affordable EU suppliers who do DNSSEC:
- Bunny DNS[0] is "free" – i.e. only subject to their minimum $1/month account spend fee.
- RcodeZero is very affordable[1] plus added bonus it is run by the `.at` registry so the infrastructure is solid – business customers only, no private individuals
- Netnod (only via resellers[2] unless you are a big company or government) – Netnod host the I Root Servers and their public hosting DNSSEC service will soon feature HSM-bound DNSSEC keys
I happen to run an affordable EU supplier who does DNSSEC, and also AXFR (incoming and outgoing). I offer a free plan from time to time, but not at the moment to preserve resources for paying customer.
We have a support ticket at Bunny that has been open for months precisely because they don’t provide state-of-the-art DNSSEC. We had to move to another provider, as we have a deadline to comply with at the end of this month. I don’t know what the issue is off the top of my head.
Netnod.se uses a DNSKEY that is too small on their main domain.
Sure: zonemaster[1] is the tool we use [2]. It checks for keylengths and other things and allows policies to be defined on them. It comes with a fairly well defined / modern policy but in our Dutch .foundation article you can read that one should be a bit stricter. However, the default policy of zonemaster warns about the keylength of netnod.se [3]
Internet.nl does not look at DNSSEC that extensively, allowing poorer quality configurations to pass. You can see what they check in the explanations of both DNSSEC metrics [4]. See [5] for discussions about keylength.
Verisign does check for key validity but not for key strength / length as seen in your link.
Recently migrated to deSEC, great experience so far, except for hitting the API rate limit when using Tofu to plan and apply changes with around a 100 domains. For now I'm using `-parallelism=1` which seems to work.
I literally just switched away from Hurricane Electric to deSEC. The only real issue that I had with HE, but it's a big one, is that they don't allow wildcard CNAMEs. I consider that important for the security of some sensitive endpoints that I have no choice but to expose publicly. Those endpoints are well protected with 2FA and heavily monitored, but I wanted to be able to use randomized subdomains to at least have some obfuscation on top.
I have been using deSEC for a couple of years without any issues. I mostly just do not want my DNS handled by my registrar so that I can easily transfer domains without worrying about DNS as well, and I do not like how centralized the internet is becoming around Cloudflare.
These are completely different types of services. One is a DoH recursive DNS resolver for use by clients. The other is a DNSSEC enabled DNS hosting provider for domain owners. The encryption in use is completely different with different goals.
After recent US shenanigans why would you spend effort to migrate to yet another Five Eyes controlled service, especially if they do the full "privacy from Germany" circus.
What kind of security threat does a migration to such a service actually mitigate?
If they were truly a "sovereign EU" kind of project then they'd be on .eu domain, not have security advisors from Virginia, and so on.
Nevertheless it's good to see that the decoupling-from-your-allies movement that US citizens have initiated is so scary that they have to set up these kind of fake EU alternatives with some local figureheads.
My solution was to self-host PowerDNS and then sign up for the free DNS mirroring from hurricane electric. That way, I can administer my DNS records any way I want (these days I usually just manually edit PowerDNS's sqlite database) and if/when my PowerDNS server goes down, hurricane electric is still serving my records so the domain keeps resolving fine.
Unbound is caching, not authoritative. Zones with dns records are served from authoritative DNS servers such as bind. Unbound asks authoritative servers for records and caches them locally, giving faster response and reducing load on authoritative servers.
Comments
I switched to deSEC because they allow you to create tokens for DNS-01 validation which are tightly scoped to a single subdomain. This means I have a VM running "service1.foo.example.com" which is not publicly available but can still get certs from letsencrypt, but with a token that can't be used to issue certs for other domains.
It works great!
I signed up and saw they only allowed a single subdomain for DDNS, with docs saying to contact support if you needed more. I emailed asking for just 1 more subdomain and support told me that for my usecase I should just use CloudFlare.
So I did. No silly miniscule restrictions.
I had this issue with cloudns and a single record with an IPv4 and IPv6 address. They only allowed one free ddns record which covered exactly one protocol. On top of that, they added records to resolve unknown names for advertising purposes.
I get that it costs money to run a DNS service but it seems like it should be a lot cheaper at scale than a lot of companies are providing.
doubt
Similar story: asked for an increase and got told
Wanting to increase the adoption of DNSSEC is fair, but couldn’t this be all self-serve? It’s almost as if they don’t want people to use them.
They've actually just done that, your limit automatically gets increased if all your domains are secured.
That’s good to know! I was actually very excited when I first found them; I was surprised that there aren’t many free/open public DNS hosting services.
Not true. When users ask for multiple domains under .dedyn.io, we send them the following text:
(Disclosure: I'm CTO at deSEC.)
When I last tried deSEC, the service was reliable and well worth the price of admission, but the web UI and API were both quite rough, and propagation tended to be quite slow. It was annoying to do an ACME DNS01 challenge on it, for example. IIRC, the API didn't have a complete set of replace/edit endpoints, so even DNSControl (https://github.com/DNSControl/dnscontrol) would leave records nonexistent for a while while during updates.
As an aside (though this certainly applies to deSEC) it's strange to me how so many DNS services (free or paid) struggle to import simple Bind zone files, often either giving a vague error ("one or more records could not be imported"), mangling records, or even just silently omitting records. Parsing a zone file has some gotchas, but it doesn't seem like it should be that hard.
In deSEC's GUI, when you add a domain, you can expand an "Advanced" section and paste your zonefile.
You can do the same via the REST API using the "zonefile" parameter in your request.
When there's an issue, the response will tell you which line it was. Perhaps that can be improved - we'd appreciate feature requests about that.
We omit records that we manage ourselves, that is: SOA, NS, DNSKEY, RRSIG. Everything else is retained, and in fact deSEC has unusually broad record type support (see https://desec.readthedocs.io/en/latest/dns/rrsets.html#recor...).
(Disclosure: I'm CTO at deSEC.)
A problem there is needing to temporarily delete the entire domain just to update using a zone file. I don't manage the DNS for anything remotely critical, but if I did, it would be unacceptable. Either way, the workflow feels deeply incorrect (though most users likely will use the record editor or the API instead; even I'd use the API through DNSControl, now).
Logging back into deSEC right now, it seems like the parser does work better than it used to, but TTL inheritance is still spotty. As an extreme example, the following input:
... correctly gets parsed by BIND (with the addition of a dummy NS record) as: ... but deSEC parses: ... where 9999 is a $TTL value from a different zone file, from a different domain, that I'd imported in a completely different session. The value is permanently (?) stuck to the entire account. This is ultimately almost a squabble since there's simple workarounds, but it did affect me when I used deSEC, and it's the sort of problem that I constantly run into with other managed DNS services too.Hopefully this helps in some way.
First, I guess it would be a good idea to report discontent about things feeling "deeply incorrect" to our issue tracker. Just lamenting about the state of things won't change it.
Unless I happen to swing by. -- We use dnspython for zone parsing, and it turns out that this is legacy (pre RFC 2308) behavior implemented there. You could say it's a bug there. We've created a patch: https://github.com/rthalley/dnspython/pull/1300 When it gets merged, we'll update our API to use the new TTL inheritance mode (tracked at https://github.com/desec-io/desec-stack/issues/1262).
Call me cynical, but I've long stopped taking the time to report minor edge case bugs if I can't also provide a solution or patch, as such reports usually get ignored or sit at the bottom of a bugtracker forever. I likely didn't realize that deSEC was a FOSS stack at the time, or I might have looked into the zone file parsing further.
As for the zone file based workflow requiring zone deletion/recreation, perhaps a report/discussion would have led to something, but I was in the middle of testing managed DNS providers to get rid of my BIND servers and I didn't have any investment in deSEC, so it didn't occur to me to take the time. My initial post on here was less lamentation and more conveying personal experience to (possibly) save someone else some time.
In any case, none of these things were showstoppers for me (I went to another (paid) provider because I need very short TTL on some records for testing purposes), but I'm glad you took the time to look into the parser; it almost certainly will benefit others.
You're welcome!
A strange thing to say about something that is free
I wrote a little cli to import a zone file into deSEC: https://git.sr.ht/~whynothugo/zone2desec
I can also show a delta when you've made changes and asks for confirmation before applying.
We found deSEC to be the only affordable DNS supplier in the EU that complies with state of the art secure DNSSEC. Highly recommended.
DNSSEC support is an anti-feature, it is dead/dying and the faster we can unburden ourselves from it the faster we can move on to better solutions.
https://sockpuppet.org/blog/2015/01/15/against-dnssec/
Rebuttal: <https://easydns.com/blog/2015/08/06/for-dnssec/>
That rebuttal held water 10 years ago, but fortunately we have made a lot of advancements since then.
DNSSEC was a solution trying to solve the problem of DNS security while still maintaining transparency for DNS operators to spy on queries. At the time, passive DNS was one of the tent poles of tracking malware and responding to security incidents.
We have since committed entirely to transport security in the form of DoH and friends. It solves the vast majority of problems we actually have.
DoH only secures the connection between the DoH provider and the client, not the response from the authoritative DNS server. It also isn't sufficient for DANE or similar. So DoH doesn't completely solve the problems DNSSEC tried to.
Exactly. And now there's <https://datatracker.ietf.org/doc/html/rfc9539> that allows encrypted DNS between authoritative and recursive servers as well.
That provides privacy, but not authentication.
Authentication was never the problem, transport security was.
This is why we pushed to deploy TLS everywhere instead of focusing on a scheme to PGP sign every webpage on the internet.
Authentication is precisely the problem DNSSEC is supposed to solve. And authentication is part of transport security.
TLS usually does provide authentication. The certificate is signed by a chain that leads up to a trusted CA, and content of the stream is authenticated using an AEAD encryption algorithm. But RFC 9539 specifically doesn't require the certificate to be signed by a CA (and recommends using a self signed cert) or the client to verify the authenticity of the certificate used by the server.
This means that an active MitM could return whatever it wanted to the recursive resolver. Pulling that off is admittedly more difficult than a MitM on a public wifi network at a coffee shop, but it's still a gap in security.
And no, you can't just use Web PKI to verify connections to authoritative DNS servers, because Web PKI relies on DNS to confirm domain ownership.
The rebuttal is old because the criticism is old. If you give more up-to-date criticism, then more modern rebuttals are available.
”DNS security” can mean many things, but DNSSEC was meant to solve the problem of verification of DNS data, while still allowing for offline signing and secondary DNS servers serving pre-signed zones, without distributing the key everywhere. DoH/DoT do not solve this; they solve different problems.
You don't seem to be sharing any of the modern rebuttals. I think it's telling that the old criticisms still basically stand.
You don’t seem to be giving any up-to-date criticism. I think it’s telling that the old rebuttals still basically stand.
Which of the criticisms in that article don't stand? What's changed? Adoption of DNSSEC has barely budged since I wrote it.
Which of the rebuttals in the link I gave don’t stand?
According to this graph, DNSSEC adoption seems to now be roughly 16×, i.e. 1600%, of what it was when you wrote it:
https://www.verisign.com/resources/dnssec-tools/dnssec-score...
See the comment from 'dsl upthread.
As for stats: https://dnssecmenot.fly.dev/
It is not surprising that European registrars have added millions of new names nobody is ever going to visit, all of them signed by default at their registrars. That's not meaningful.
Such as? And do those solve the same thing? The post lists 8 headlines why it should be abolished.
So DNS should be open to MITM attackers?
Even with DNSSEC, it still is. Example: https://blog.cloudflare.com/de-tld-outage-dnssec/
Did you read the article? It's saying that DNSSEC as an implementation to prevent MITM is flawed; other solutions that protect against MITM are proposed.
I mean, if your definition of "affordable" is free, then sure.
But for the record there are other affordable EU suppliers who do DNSSEC:
[0] https://bunny.net/dns/ [1] https://www.rcodezero.at/solutions/enterprise [2] https://www.netnod.se/dns/find-a-partnerI happen to run an affordable EU supplier who does DNSSEC, and also AXFR (incoming and outgoing). I offer a free plan from time to time, but not at the moment to preserve resources for paying customer.
https://www.ptrdns.net/
Are you aware that the child zone A(AAAA) records for danube.ns.ptrdns.net differs from the parent zone A(AAA) glue records for danube.ns.ptrdns.net?
Looks like it's the glue records that point to the actual server?
Thanks for letting me know!
This is fixed now, I'll look into why the monitoring tools didn't catch this one as they should have.
We have a support ticket at Bunny that has been open for months precisely because they don’t provide state-of-the-art DNSSEC. We had to move to another provider, as we have a deadline to comply with at the end of this month. I don’t know what the issue is off the top of my head.
Netnod.se uses a DNSKEY that is too small on their main domain.
Rcodezero.at might indeed be something. Thanks.
We donate to deSEC, so it’s not free for us.
Interesting, could you expand on that ?
I ran netnod.se through the Verisign[1] and internet.nl[2] and it passes DNSSEC tests ?
[1] https://dnssec-analyzer.verisignlabs.com/netnod.se [2] https://internet.nl/site/netnod.se
Sure: zonemaster[1] is the tool we use [2]. It checks for keylengths and other things and allows policies to be defined on them. It comes with a fairly well defined / modern policy but in our Dutch .foundation article you can read that one should be a bit stricter. However, the default policy of zonemaster warns about the keylength of netnod.se [3]
Internet.nl does not look at DNSSEC that extensively, allowing poorer quality configurations to pass. You can see what they check in the explanations of both DNSSEC metrics [4]. See [5] for discussions about keylength.
Verisign does check for key validity but not for key strength / length as seen in your link.
[1] https://zonemaster.se [2] https://internetcleanup.foundation/2026/04/bijgewerkte-dnsse... [3] https://zonemaster.se/en/result/cf3ef2fc83f27eb6/ [4] https://internet.nl/site/internet.nl/4280424/#control-panel-... [5] https://github.com/internetstandards/Internet.nl/issues/1176
Super, thanks. zonemaster added to my bookmarks !
Also have a look at gonemaster, the modern replacement: https://gonemaster.evilbit.de/
One who doesn't is frustratingly Hetzner.
Recently migrated to deSEC, great experience so far, except for hitting the API rate limit when using Tofu to plan and apply changes with around a 100 domains. For now I'm using `-parallelism=1` which seems to work.
How did you get access to 100 domains on there?
I literally just switched away from Hurricane Electric to deSEC. The only real issue that I had with HE, but it's a big one, is that they don't allow wildcard CNAMEs. I consider that important for the security of some sensitive endpoints that I have no choice but to expose publicly. Those endpoints are well protected with 2FA and heavily monitored, but I wanted to be able to use randomized subdomains to at least have some obfuscation on top.
I was pleased to discover that a Terraform/OpenTofu provider is available.
https://registry.terraform.io/providers/Valodim/desec/latest
https://search.opentofu.org/provider/valodim/desec/latest
Homepage looks busted on Orion iOS. Signup form has you entering your email address within the yellow “Create Account” button.
Happy deSec user, use them for all my domains. Had quick thoughtful replies from Peter if I had any questions.
I have been using deSEC for a couple of years without any issues. I mostly just do not want my DNS handled by my registrar so that I can easily transfer domains without worrying about DNS as well, and I do not like how centralized the internet is becoming around Cloudflare.
Is this somehow related to the other post about another service shutting down its encrypted DNS?
https://news.ycombinator.com/item?id=49568579
Weird timing?
These are completely different types of services. One is a DoH recursive DNS resolver for use by clients. The other is a DNSSEC enabled DNS hosting provider for domain owners. The encryption in use is completely different with different goals.
After recent US shenanigans why would you spend effort to migrate to yet another Five Eyes controlled service, especially if they do the full "privacy from Germany" circus.
What kind of security threat does a migration to such a service actually mitigate?
If they were truly a "sovereign EU" kind of project then they'd be on .eu domain, not have security advisors from Virginia, and so on.
Nevertheless it's good to see that the decoupling-from-your-allies movement that US citizens have initiated is so scary that they have to set up these kind of fake EU alternatives with some local figureheads.
Seems legit, but how can I trust them to survive if they're not collecting revenue?
Some of them are located in Virginia, don't worry they'll be funded forever.
Just use unbound
My solution was to self-host PowerDNS and then sign up for the free DNS mirroring from hurricane electric. That way, I can administer my DNS records any way I want (these days I usually just manually edit PowerDNS's sqlite database) and if/when my PowerDNS server goes down, hurricane electric is still serving my records so the domain keeps resolving fine.
Completely different thing
What is this if not a DNS service?
Unbound is caching, not authoritative. Zones with dns records are served from authoritative DNS servers such as bind. Unbound asks authoritative servers for records and caches them locally, giving faster response and reducing load on authoritative servers.
Just use bind :)
Does not support AXFR :(
That's a bummer.
It looks like they are open to adding the feature and open to outside contributions: https://github.com/desec-io/desec-stack/issues/579
do what's best.