DNSKEY and RRSIG

[monodhs]

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!

[peter]

Hi momodhs,

Thank you for your message, and welcome to deSEC!

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

[monodhs]

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!