DNSKEY and RRSIG

Managed DNS Hosting
1

Hello all,

As an owner of a domain, it is in my very own interest that the
data belonging to my domain and which I publish on the Internet
via the DNS under my domain – under my own name, if you will –
is under my exclusive control. I would also like the consumers
of that data to be assured, that this data is in fact under
my exclusive control, or more formally, that it is authentic
w.r.t. my identity. To the best of my knowledge, and what I
could understand from studying the relevant RFCs, DNSSEC is
precisely the set of mechanisms allowing to establish this
relationship in the DNS via publishing the signatures and
the public component(s) of a PK pair or pairs along with
the actual data in the form of RRsets having been signed.

However, after reading the documentation, I was disappointed
to find that with deSEC, I can not sign my own data with my own
keys and have them published in the DNS.

While I am fully aware of the operational justifications for
that particular way of implementing DNSECaaS, the original goal
of allowing to establish the authenticity relationship is missed.

A fairly simple solution to this dilemma for the DNSECaaS provider
consists of having the owner of a domain provide the public component(s)
to their PK pairs either with their registration or during domain
management (preferred), and then verifying the relevant RRSIGs during
RRset management, which, with the algorithms in current general use,
is computationally equivalent to what must be done already to
produce the RRSIGs with the keys provided by deSEC.

Are there any plans for allowing domain owners to authentically
publish their own data in the DNS with deSEC?

Thanks!

2

Hi momodhs,

Thank you for your message, and welcome to deSEC! :slight_smile:

The goal of deSEC is to enable people to use DNSSEC who do not have the know-how to compute signatures themselves and provision them somewhere. Our efforts so far have been focused on making DNSSEC easy to use for this audience. In short, our mission rests on a different set of assumptions than your use case.

While your points are of course justified, we nevertheless do believe that the service we are providing is needed urgently. We infer that from the general fact that only a very low number of domains is secured with DNSSEC.

User-provided DNSSEC keys or signatures have therefore not been a priority, and are currently not supported (as you already discovered in the documentation). There are several ways forward:

  • You can deploy your own deSEC instance, and have everything under your control.
  • What you need is actually not a Managed DNSSEC provider, but a DNS CDN. There are lots of them out there that you could use, without requiring a specific degree of trust on your side.
  • You can create a Feature Request issue on our GitHub page, and we will see where the discussion with the community leads. Note, however, that other things on our roadmap have higher priority (such as 2FA, token scoping etc.). We also welcome pull requests, in case you would like to make a contribution for your feature.

Stay secure,
Peter

3

Hello Peter,

Thank you for your quick reply.

The goal of deSEC is to enable people to use DNSSEC who do not have the know-how to compute signatures themselves and provision them somewhere. Our efforts so far have been focused on making DNSSEC easy to use for this audience. In short, our mission rests on a different set of assumptions than your use case.

By limiting deSEC’s target group to those who have neither knowledge nor the means to operate their own anycast DNS/DNSSEC infrastructure, deSEC is excluding a key group of people. The constituents of that particular group, having the knowledge, but merely lacking the means and interest for, and I cannot stress this enough, actual operation of the service, are the ideal canditates to become advocates for precisely what deSEC is setting out to achieve.

So, in the spirit of inclusion, I would like to ask deSEC to reevaluate
its mission, since digital sovereignty is the bedrock of a free and
civilised Internet, and the technicalities are rather trivial.

While your points are of course justified, we nevertheless do believe that the service we are providing is needed urgently. We infer that from the general fact that only a very low number of domains is secured with DNSSEC.

The observation that DNSSEC isn’t deployed across a broad spectrum, by itself, does have many more causes than people not being adept at or interested in digital identity management, as alarming as that is.

I can personally attest to the particular lack of managed DNS/DNSSEC offerings with full sovereignty and DANE support such as OPENPGPKEY and friends. DNS being critical infrastructure for the Internet, the most important reasons for lack of adoption are operational complexity and cost, corporate dominance, as well as too much politics, of course.

There are a number of reasonably priced anycast DNS/DNSSECaaS offerings by large and powerful operators with at least the same level of sovereignty and comfort that deSEC is currently offering. Whether providing the service gratis makes it more attractive for SMEs and individuals remains to be seen, everybody who actually /needs/ DNS would like the thing to just work. And I don’t mind paying for solid quality service.

User-provided DNSSEC keys or signatures have therefore not been a priority, and are currently not supported (as you already discovered in the documentation). There are several ways forward:

There is actually a third and much simpler option that has the
potential to satisfy everybody at minimal effort. Someone else already
hinted at managed secondary DNS in another thread titled “DNS Slave support”. The beauty of this approach is that it relies on established Internet standards and practices alone, no code needs to be written other than the one to add and delete the name of the zone and make it known to PowerDNS, the same goes for REST interaction with all its awkwardness, and that works transparently even for zone updates necessitated by a key roll-over, since glue like DS RRsets always go to the registrar. For added trust between the secondary and the hidden master, TSIG should be employed, and IXFRs for added efficiency. That’s all there is to it.

Please let me know how I can help making this work. I should mention, though, that wading through someone else’s code when I haven’t been involved in its production isn’t my strong suit.

Thanks!

1 Like
4

AFAICS your mission is to bring DNSsec into the field. At my side the missing motivation to bring DNSsec into the field is to find suitable Secondaries.

As you wrote, there must be lots. However I am apparently unable to just find a single one which suits my needs. Where are they? Where do they hide? Where can I find those who match my needs?

I am looking for over an hour now. But 0 results. Perhaps because none meets the most important criterion:

The CDN must be operated under and controlled by German law. Like yours!

So please, can you provide me a list with providers from Germany, who offers secondary Anycast DNS for 500+ Domains for a reasonable price? Not for domains. The domains are all registered and must not be transferred. All that should change is: The DNS.

Without Anycast I can continue to do it myself. But this might take a few years. So no DNSsec for now. Because there are more important things to do than to improve a DNS infrastructure which just works. But getting rid of 3 of my 4 NS would be something completely different. A very firm motivation to start migrating to DNSsec as fast as possible. Am I really the only one who sees it this way?

Also please think again due to following:

On this planet things get hacked. So if you ever get hacked - I do not hope this ever happens - then most of your zones might get compromized at the same time because the signing key (or option to create signatures with the HSM) falls into the hands of the attacker. A sneaky attack even only add some DNS records which are hidden to your API. Well, you do not offer warranty. However I am German. Therefor I know that you still are liable for things like Grobe Fahrlässigkeit as you cannot exclude that in Germany. And what this means is nothing you decide. This will be a court ruling.

A clever lawyer could say that you are responsible for the problem, as “not offering Secondaries” means, that you - willfully - endanger all those who could have used a Hidden Primary, as those with Hidden Primaries would not have been affected from a hack at your side. IANAL. But I would not take this risk. Really. OTOH if you have Hidden Primary support, your lawyer could argue, that those, who are affected by the hack, could have run a Hidden Primary, and as they did not, they are responsible for the damage themself.

Hence I would offer Hidden Primary support. Not via the general interface. But via contact to the service. So the people are a bit more motivated to do this only when donating … :slight_smile:

Just my 2 cents.
-Tino
PS: Please do not get me wrong:

Thank you very much for what you do! It is very inspiring. I am sure I can move a lot Domains to your service to improve their service (even that they are so unimportant, that they do not need this), perhaps I could even hand them over to the owner and get rid of some support. And I consider to do a recurring donation, because if your service manages to lower the effort at my side the saved costs can very well be yours. (But only after all the move is done and with 500+ domains. This may take years, depending on motivation.)

  • I am currently operating privately (I am no company) 4 Nameservers in 3 different zones, thanks to the lucky situation that I can host bind on most machines nearly for free thanks to friends (and the like). And no, I do not own all of those domains. All I do is providing DNS for all those domains for free to friends (and the like), such that they do not need to do it or worry about it. I do this for over 20 years now. Because I can. Because it does not cost me much more than the effort to install and run bind. Mostly, as I need DNS for myself anyway.

  • To be safe for the next 20+ years, I want to go IPv6+DNSsec+Hidden Master+Improved security. And as I am getting older best would be to get things more and more independent of me. Your service looks like a possible solution to that.

  • Also 2 of “my” machines are on IPv4-only sites (yes, it’s 2022 and some locations still do not offer IPv6 in a forseeable future).

  • Most importantly, I want to keep everything free. (Where free means: If somebody pays for it, this is me, nobody else. As I must pay this from my pocket, I need it to be as cost effective as possible for an as-long time as possible.) No, I do not offer my DNS to the general public. Just to friends, colleagues, ex-colleagues, companies, project etc. I happened to work with in the last 25+ years.

Also note:

  • I am German and therefor crucially need a provider from Germany. Germany only!
    • Companies like CloudFlare or DynDNS are ruled out due to this
    • But I am apparently unable to find a German CDN providing Secondary DNS with Multicast in all important regions of this planet.
  • This is due to DSGVO and the ruling of EuGH that IP address are being considered privacy data in DE
    • Hence in my reading this means, that DNS queries of German IPs must not cross the legislation border
    • So they must not be answered by Servers not owned by a company which falls under German law

But all domains should be reachable from any computer as fast as possible, not only from close Germany. Hence Anycast would be a nice to have. But DSGVO wins over Anycast. And (my) lazieness (if I am not motivated due to missing Anycast) wins over DNSsec. Checkmate :wink:

5

Hi tino,

welcome to deSEC!

This is still true two years later: deSEC is open to discussion the technical details of such a solution on GitHub. :slight_smile:

I’m no lawyer, but I do not see a way to operate globally distributed servers exclusively under German law.

Note that there is no guarantee that DNS queries made from German IPs against deSEC name servers will be answered by servers physically located in Germany. In a typical setting, it is the DNS resolver (your ISP, Quad9, Google, or similar) that does such a query, so no end-user IP address is involved.

Cheers,
Nils