I understand that Linode supports DNSSEC when used as a slave, but it would be nice if it could be supported as master.

I will admit, I don't know everything I should about DNSSEC, but I'm assuming you are required to input a key password each time you update a zone or record within a zone. IMHO it should be relatively simple to prompt the user for the key password when making a zone change or add a field to the API to send the password at record addition/modification.

There is no inherent requirement that it would need to involve entering a password every time you make an update.

However, a couple of issues that I can see that prevents zone-signing (as opposed to just serving a zone already signed by the customer) from being a straightforward thing to add into a managed service like this are:

• It would essentially require the customers to hand over their keys to the service provider (or use keys generated by the service provider), which defeats part of the purpose
• Key rollovers - in particular KSK rollovers are a bit tricky to deal with as they require the delegation to be updated with a new DS record (by the customer, through their registrar)
• Quite possibly a support nightmare as many have a very poor understanding of DNSSEC and don't necessarily realize that their domain is not supposed to resolve at all if the signatures don't check out

All in all, I don't think the current "you do the signing!" approach is necessarily a bad thing.

Using Linode's nameservers as slaves with your own master server (not even necessarily exposed to the public) also has the additional benefits of immediate updates instead updating every 15 minutes as well as allowing any (valid) zone contents as opposed to the restrictions set by the DNS Manager UI or API (some of which are rather strange).

I don't disagree with you on most of that. The reason I brought up the password to make an update is that the encrypted private key would be stored at Linode, so if you make a change to your DNS zone then you could type in your password for the key. It's not perfect, but its better than an unencrypted key.

I also use Linode's API for DNS as part of my server build process. I could run my own DNS server and have Bind pull the record information from MySQL so I can programmatically make changes, but that requires even more effort and expense on my end.

As far as the support nightmare statement, I think that is part of the benefit of having the Manager handle DNSSEC. You change your DNS record, the signature is updated automatically.

If they were to have an encrypted key that they don't have (or at least save) the passphrase for, the customer must come back on a regular basis, whether they make any changes or not, to allow for updating of expiring signatures. (I'm not sure I fully understand what you had in mind for the key management.)



BIND supports the standardized DNS update protocol, so at least if you are making changes to existing zones it's absolutely possible to programmatically make changes out of the box. No proprietary stuff and no MySQL needed.



The automatic signing happens with BIND as well (auto-dnssec maintain), can be used both with dynamically updated zones as well as static zones (inline signing).

How often do signatures expire? I did not realize you'd have to update the signature more often than just making changes.



I was not aware of that. I'll look into it.

Every 7 days, which would be quite annoying, since their rotation is usually staggered



Standard nsupdate stuff; I use it for all of my zones, and let BIND handle the magic behind the scenes, including updating zone files, bumping SOA, etc.

_________________
Disclaimer: I am no longer employed by Linode; opinions are my own alone.