deSEC – Free Secure DNS
desec.io
desec.io
It works great!
So I did. No silly miniscule restrictions.
> […] our mission is to improve Internet security by increasing the adoption of DNSSEC. [We therefore expect users to enable DNSSEC for their domains.
> Would you be willing to do that?
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.
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
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?
(Disclosure: I'm CTO at deSEC.)
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 strange thing to say about something that is free
I can also show a delta when you've made changes and asks for confirmation before applying.
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.
> often either giving a vague error ("one or more records could not be imported"),
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.
> just silently omitting records
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.)
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
@ 7777 IN A 203.0.113.1
@ 4444 IN AAAA 2001:db8::1
www 4444 IN A 203.0.113.1
@ 9999 IN A 203.0.113.1
@ 4444 IN AAAA 2001:db8::1
www 9999 IN A 203.0.113.1
Hopefully this helps in some way.
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).
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.
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
Looks like it's the glue records that point to the actual server?
This is fixed now, I'll look into why the monitoring tools didn't catch this one as they should have.
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
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
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.
This is why we pushed to deploy TLS everywhere instead of focusing on a scheme to PGP sign every webpage on the internet.
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.
”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.
Which of the rebuttals in the link I gave don’t stand?
> Adoption of DNSSEC has barely budged since I wrote it.
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...
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.
That comment has recieved appropriate and adequate rebuttals, so I see no need to add anything further.
> As for stats: https://dnssecmenot.fly.dev/
You said “Adoption of DNSSEC has barely budged”, and that is what the graph which I linked shows to be hilarously false. I remember that you often used to link the same graph – until it stopped showing what you wanted, that is. Now you come peddling a different, explicitly biased, graph, which only shows what the top 1% is doing, but I really don’t care about what the top %1:ers are doing. Most people are concerned with popularity in general, not what Google and Amazon are doing. Most people are not Google and Amazon, and consequently should take no lessons from them concerning their own systems.
I cite the DNSSECMeNot thing now for two reasons:
(1) I wrote it.
(2) It's live: everything in the Tranco Top 1000 gets checked several times a day. I can tell you every site in that last that has changed DNSSEC status (turned it on or off) in the last year. Spoiler: you can count them on the fingers of two hands.
I don't know why you push on this statistics argument! It's really rough for you. If I was in your shoes I'd be trying to decrease their salience, not increase them.
What is this graph a reply to? Those graphs are for how many resolvers validating DNSSEC, not domains using DNSSEC. And here, your frequent pointing to Google and other large operators works against you, since all of them already validate DNSSEC!
Also, I find it highly questionable of you to link to a graph as part of an argument, without disclosing that you also made the software which makes the graph. (But the graph also wears its bias openly, so it’s at least honest about not being biased.)
> I don't know why you push on this statistics argument!
Notably, I did not bring it up. You brought it up, when you wrote “Adoption of DNSSEC has barely budged since [2015].” Which the graph from Verisign – which you also used to link to – shows to be utterly false.
The argument about DNSSEC with you always goes in circles. You claim that DNSSEC adoption is not rising. But the Verisign statistics show that more domains are DNSSEC signed than ever before, every day, both by numbers and percentage. Then you claim that the large masses of domains don’t count, but only the top 1% of 1% of popular domains, which are, notably, with some exceptions, not commonly DNSSEC signed. But those domains are used by Google and other infinitely large and alien actors, which have very different security models and threat models than most people with a domain name. Then you try to argue against the Verisign graph by posting a link to other graphs which claim to show “DNSSEC adoption”. But the graph you link to is not about domains, but about resolvers. However, the large and most popular resolvers are from Google, Cloudflare and the like, and all of those have done DNSSEC validation for a long time.
My arguments can be summarizes as follows: 1. The usage of DNSSEC is, contrary to your claim, going up, steadily. By number of domains signed, percentage of domains signed, and usage of DNSSEC-verifying resolvers. 2. Your argument seems to be that a) The increasing number and ratio of DNSSEC signed domains do not count, only big-name domains like Google are important (since many of those are still not DNSSEC signed), but b) big-name resolvers like Google are simultaneously not important, since those all do verify DNSSEC signatures. This argument is inconsistent. 3. Linking to, and trying to prove an argument by, your own biased graph using your own software, without disclosing that it is your graph and software, is scummy.
https://registry.terraform.io/providers/Valodim/desec/latest
https://news.ycombinator.com/item?id=49568579
Weird timing?
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.
It looks like they are open to adding the feature and open to outside contributions: https://github.com/desec-io/desec-stack/issues/579