3

I think we all know that running a CA is really hard to get right.

Now there's a "new" system that uses digital signatures to associate data with names: DNSSEC. DNSSEC signs the DNS records and therefore binds their values (f.ex. TLSA / A records) to the specific domain name.

For the question let's consider two scenarios:

  1. Some user sets their own BIND server up and uses DNSSEC only for his zone, of course he publishes the DS record in the appropriate zone.
  2. Some company offers a DNSSEC DNS service and takes care of all the configuration.

Now my question(s):

Is the task to run a DNSSEC server (in either of the above scenarios) as complex as running your own CA and requires the same amount of care?

Improve this question
2
  • A CA often involves signing keys from disparate users and systems, whereas a DNSSEC server is mostly self-contained. I imagine that'll cut down on the complexity... but I haven't done so so that's just a guess.
    – gowenfawr
    Commented Aug 7, 2015 at 13:14
  • 1
    The big difference in operations is that, you can shutdown the CA at anytime it will have 0 consequences for the certificates already issued and used on the field. However, in DNS, DNSSEC signatures have to be regenerated regularly (even if no zone content changes), and keys theoretically have to be rotated too. Which means DNSSEC implies regular maintenance, and this is even outside the cases of dynamic signing and things like white/black lies.
    – Patrick Mevzek
    Commented Aug 24, 2022 at 13:27

2 Answers 2

Reset to default
2

As we are running to 2 solution in for our company, here is a rather fair point of view.

When you are outsourcing the CA or DNSSEC service, all that's matter is how much trust do you have in the 3rd party company providing your the outsourced service. In order the outsource the complexity you'll have to rely on on the secure practices of the CA/DNSSEC provider.

For the 2 services, the main point you'll have to take about is the key management. You'll have to protect your private keys in order to prevent being compromised. As Kurt mentionned, it's perfectly fine to handle the KSK and the ZSK as stated.

But the experienced operational complexity for the 2 services is the following:

  • CA: The main tasks you'll have to achieve is the (re)issue and revoke certificate. These processes are rather simple because if you issue a wrong certificate just revoke it and issue a new one using your issuing certificate. If a service is disturbed, i.e. wrongly signed or invalid certificate, your service will be disturbed till the moment you'll put in place the new certificate.

  • DNSSEC: The main task to resign the zone (on time basis according to the validity lift time of the signed zone) and also re-sign when adding modification to your DNS zone. But if something goes wrong then your invalid DNSSEC zone will be cached in other DNS (i.e. clients, other companies) usually for 48 hours. As a example if your client are using google's DNS (8.8.8.8 & 8.8.4.4) your wrongly signed DNS zone won't be resolved trough google DNSs causing a huge service disruption. Your only chance will be to wait until your signed zone expires are other DNS will renew it.

Improve this answer
0

It's actually pretty simple since you only need two keys (the one Signing Key and the Key Signing Key). You use the Key Signing Key to sign your Zone Signing Key, you can then keep the Key Signing Key offline (you only need it when you deploy a new Zone Signing Key).

The Zone Signing Key is used to sign DNS information, you can in theory keep it offline, but it's obviously easier to keep it on your master DNS server and use to to automatically sign your DNS data as you add/modify DNS data for your zone(s).

You can easily change the Zone Signing Key out if there is a compromise. You can also change your Domain Signing Key, but you obviously want to avoid that.

Here is a good example on how to do this in Linux.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .