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.