After having forwarded NS and DS records to my provider he informed me that DS records wouldn’t be supported. Well then?
@bbaade, your message is a bit sparse but I gather you have a domain, e.g. "example.com.“, registered with provider X and you wanted to delegate the DNS hosting to deSEC?
If so, you need to know that the zone file currently active at provider X would cease to be relevant after delegation. So any records added to that zone, including NS and DS records would become irrelevant. So it does not matter wether provider X supports DS records in that zone file or not.
What you actually want is setting the NS glue records and the DS record for “example.com.” in the parent zone, e.g. "com.“. Now usually you don’t have direct access to TLD registries. So your current provider/registrar would have to communicate the changes to them.
Some domain registrars have an interface or an API for this but probably not all. If your provider can’t help you there then you will either need to move your domain to a provider that supports this or forget about using deSEC (or any other DNS hoster) for your domain. (You could still register a subdomain under dedyn.io and put a CNAME into your domain. But that would not be fully secure as the CNAME itself would not be secured.)
Note: If my initial assumption is false, and you want to delegate a subdomain, e.g. "sub.example.com.“ to deSEC then you will have a different problem:
Your parent domain is now "example.com.“ and you would need to add the NS glue and DS records to the zone of that domain. Unless your current provider supports DNSSEC for “example.com.” any DS records in the domain "example.com.“ would be insecure and thus your delegated subdomain would remain insecure (and probably non-functional for many clients behind validating resolvers). The chain of trust from “.” → “com.” → “example.com.” → “sub.example.com.” would be broken.
HTH
fiwswe
Hi bbaade,
Thanks for your message, and welcome to deSEC! 
I suspect you have a .de domain and you sent your DS records to your registrar to enable DNSSEC. Unfortunately, .de domain don’t support DS records, and you need to provide a DNSKEY record instead. You can query it via our API, but the web interface currently does not display it.
Most top-level domains support DS; the .de domain is an exception. We recently learned about this and will soon adapt our web interface to be more helpful.
If you are unable to use our API, please shoot us an email with your domain name so that we can help you.
Stay secure,
Peter
Or you could use the command line tool dig:
$ dig example.com DNSKEY
fiwswe
While that’s true, the result will not be authenticated.
~Peter
Right (for the general case), so ask someone who knows for sure:
dig @ns1.desec.io example.com DNSKEY
In my case I have gotten used to running my own unbound with settings to validate the answers. And my upstream VDSL DNS resolver also validates. So I have gotten lazy. 
fiwswe
Guys,
great support by now, thx a lot.
@fiwswe Sorry for being so sparse. I am a Northerner …
@peter There is a .de and a .net domain to be reconfigured. Because it seems that my provider doesn’t support DS rec. neither for .de nor for .net, .com etc. I’ll try it with the DNSKEY records instead of DS for both (tomorrow…). I’ll keep you posted.
Thanks again, Bernd
Even then, the answer cannot be validated unless the parent zone has a signed delegation (DS record) to establish the chain of trust – which it doesn’t: it’s precisely what the OP is trying to set up.
Of course, you can query our nameservers manually, and even get the signatures (+dnssec). But without the chain of trust, you can’t know whether somebody on the wire is tampering with the response, including the signature. It is conceivable that you are retrieving a fake DNSKEY provided by someone performing a MITM attack.
In practice, the likelihood is low (as is mostly the case with DNS) – but the impact may be high. That’s why the point of DNSSEC is to establish trust all the way, so I suggest to retrieve DNSKEY from the API.
Stay secure,
Peter
Wait, I thought the goal was to retrieve the DNSKEY from the zone file at deSEC (even if that zone file is not active on the Internet, i.e. delegated to deSEC, yet)? Are you saying that asking a deSEC nameserver directly is potentially insecure?
Ok, thinking about it I think I see your point. So my solution would only be secure once the domain is properly delegated, which it isn’t at this point.
Thanks! It’s discussions like these that present really great learning opportunities. 
fiwswe
We updated the web interface, and it now also displays the DNSKEY record.
Stay secure,
Peter
Peter,
that’s great! I didn’t have the time so far to set up full access to interface so this extended data display is extremely helpful!
Thx again, Bernd
Latest news from my provider, they do not support neither DS nor DNSSEC records. Or, other way round: Only A-Records, AAAA-Records, CNAME oder TXT can be placed there.(which are from my understanding not relevant in the discussed context)
Does it mean that it’s not possible to use DESEC service?
Hi Bernd,
If your domain registration provider supports neither DS nor DNSKEY records, then you cannot enable DNSSEC. You can still use deSEC as your DNS provider, but you will not be able to benefit from the DNSSEC security guarantees.
If you would like to enable DNSSEC, it sounds like you would have to transfer your domain to another registration provider.
Stay secure,
Peter
Thanks Peter, for confirming my assumption - and in general for your very helpful hints. I guess that I’ll do so.
All the best, Bernd
Please correct me if I’m wrong but my understanding is that when any part of DNSSEC is broken — including the chain of trust — then any validating resolver will refuse to answer queries?
So using deSEC as a DNS provider without the correct DS record in the parent domain would result in the domain being virtually invisible to many resolvers?
fiwswe
Guys, this behaviour would make sense for me - otherwise the service wouldn’t be reliable. (Only) if it is of note for you I could offer a “test domain” to check it out in reality…
Bernd
Hi,
In a sense, this is correct – but the situation at hand (DS/DNSKEY records missing) is not a “broken part of DNSSEC”: If your domain registration provider does not forward your DS or DNSKEY records to the registry (e.g. DENIC), then the registry will sign (!) the fact that your domain has no such records. This is a cryptographic statement that your domain has DNSSEC disabled, and resolvers will accept it.*
The situation is different from a broken chain of trust, where the registry does publish your DS or DNSKEY records, and the downstream signatures don’t match. The chain of trust is broken when the following conditions are fulfilled:
- the parent domain publishes a DNSSEC configuration for your domain
- your domain’s DNS information contradict this configuration (in particular, invalid signatures)
In the case at hand, however, the situation is:
- the parent domain publishes that no DNSSEC signatures are required for your domain (this claim itself is verifiable via the parent domain’s DNSSEC setup)
- as a consequence, resolvers will not care whether your domain has signatures or not (they treat is as a deliberately insecure domain)
deSEC still signs your DNS records. This way, the signatures are already in place when you decide to turn on DNSSEC for your domain (i.e. publish DS/DNSKEY records at the parent domain).
*: You can, of course, set up a resolver that requires DNSSEC for everything, and will refuse to resolve queries which don’t provide a full chain of trust. However, this is not how resolvers usually work, as this would render > 90% of domains unusable. We can hope that in some far future, DNSSEC will be ubiquitous, and that a DNSSEC chain of trust will be enforced everywhere – but this is not how it is today.
Stay secure,
Peter
Thanks! That makes sense.
fiwswe