Add algorithm selection for DNSSEC

Added Feature Request label

@tbrehm Per Zone, right? I will look into another Issue regarding DNSSEC which has been reported to me. I will look into this, too and create second MR when I find the time.

Btw... Bit of OT: What about key replication? Is some encryption implemented now or is this still on agenda? (#4179)

A selector per zone might be optimum, but a general selector would probably be fine as well. Two-way encryption is still on the todo list, but we definitely need this for ISPConfig 3.2.

Well as we need a DB change anyways I will check if per-zone-selector makes things much more complicated. I think per-zone is better because you can then always chose the most secure algo supported by the underlying registry

The dutch registrar considers 7 to be unsafe now. Would it be possible to upgrade to a newer algorithm? If per zone is difficult, it should be done globally.

Although all keys must be uploaded again to the registrar, so some kind of transition is needed where the old algorithm is still valid.

https://blog.apnic.net/2020/01/17/sha-1-chosen-prefix-collisions-and-dnssec/

Key points:

Attackers can use a SHAmbles prefix collision to spoof the DNS despite DNSSEC.
Whenever a DNS zone is signed with a SHA-1 DNSKEY algorithm it is vulnerable to chosen prefix collision attacks.
Zones using algorithm numbers 7 or less should be upgraded. The recommended algorithms are 13 (ECDSAP256SHA256) or 8 (RSASHA256, with 2048 bit keys).
For extra protection against chosen prefix collision attacks, zones should not share keys, and they should have separate ZSKs and KSKs.
Software implementing CDNSKEY and CDS checks must ensure that the records are properly signed by a KSK, not just a ZSK.

openprovider.org also sends out warnings now. Can you please indicate if this will be addressed in the forseeable future?

If not, that's fine too. I can find different solutions for the problem. I just don't want to implement those if this will be addressed by your awesome product anyhow.

added git-stable label

I've assigned it to stable-3.1 branch as we have to solve this if it causes issues now.

Hi there,

as the original developer of the DNSSEC integration I wanted to say sorry. I started this project and got a bit stuck at the point of replication for quite a long time as of lack of support for encrypting the key in ISPConfig DB. Unfortunately since then I shut down my ISP services completely so I got no direct demand on this anymore and my time needed to be reassigned.

Currently I am working full-time in a hospital as well as an indie game developer in my spare time. This is why I can't find the time to come back to this issue - Especially as I got not testing environment set up anymore.

I hope to get your understanding that I cant continue developing the DNSSEC integration and I hope that I did not leave a too big construction place open here.

Thanks for your great work on the implementation :D If you change your mind and want to look into this, I can set you up with a testing environment.

Hi Alex,

thank you for the status update and for all the development you did with the DNSSEC implementation! I will have a look at the code and see how to implement additional hashing algorithms.

Thanks Till. If possible a simple select box with the different algorithms at each domain, so we can migrate each domain individually, depending on the algorithms available for each TLD and Registrar.

The 'sign zone'-checkbox can be removed, and a pull down with 'None' and all available algorithms could be added. An official list can be found here: https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml

In terms of database, the new field that holds the algorithm, should be set to 7 for all existing domains which are dnssec-enabled, before deleting the old-checkbox database column.

When changing the algorithm, the old keys should probably be removed and new ones created.

It would also be great if this would work from the API.

There should also be a key rollover function, because people that are using DNSSEC already and want to change their keys (because of a leak or to change the algorithm) should be able to do this without any downtime.

Let's not overdesign this, as you still need to upload the keys to registry yourself. It's difficult enough already, so I vote against a complicated, error prone overlapping system.

You can simply delete the keys at the registry, wait for that to spread, change in ISPConfig the key type, wait for the new DNS Zone file to spread and then upload the new keys to the registry to re-activate the complete DNS-Sec stack.

If you delete the key at the registry you are depending on this to propagate, meanwhile you keep serving your zone over DNSSEC without the proper keys. Also, there are people that don't want to disable DNSSEC for their domain, even for a short time period.

You can serve your zone with DNSSec entries without keys at the registry without problems. Only the other way round causes trouble.

A system where you can have two algorithms in ISPConfig for one zone is overly complicated and error prone.

Setting a low ttl and coordinating the switch, means little to now downtime for DNSSec anyways.

Hi Till,

Sorry to ask again, I hate it too when people do this, but it's getting crucial for us now. OpenProvider does not allow any updates to the zone anymore without changing the algorithm, which we can not do within ISPConfig. So our zone files are basically frozen as it is, besides disabling DNSSec.

Can you please indicate if this will be addressed in the forseeable future? If not, that's fine too. I can find different solutions for the problem. I just don't want to implement those if this will be addressed by your awesome product anyhow.

@tbrehm I can still edit my zones, but I'm also receiving warnings about the algorithm.

The best thing would be if you or someone else could have a look into the code and implement and submit the needed changes. I'm currently working on Ubuntu 20.04 support and centOS 8 support plus various bugfixes for 3.1.16, so not sure when I'll be able to look into implementing another hashing algo for DNSSEC.

I think it would be easy to implement a new hashing algo by changing line 117 in server/plugins-available/bind_plugin.inc.php to $app->system->exec_safe('cd ?; dnssec-keygen -3 -a ECDSAP256SHA256 -n ZONE ?; dnssec-keygen -f KSK -3 -a ECDSAP256SHA256 -n ZONE ?', $dns_config['bind_zonefiles_dir'], $domain, $domain); The difficult part would (or could) be the transition. Because zones need to be resigned, all zones would automatically start using a different algorithm, which means users that are unaware of this would have zones that can't be resolved anymore. Maybe somebody else has a good idea of how to implement this, however, I don't think I can do this.

Just an idea...

You would need to create a second key with the new algo and sign the zone with BOTH keys for a few days or let's say a week to be sure. The user must upload the new AND the old key to the registrar. After this amount of "grace" time the old key could be deleted by a cronjob or something like that and the zone be resigned with the new key only.

However - This should be implemented as a general feature, not tied to algo changes as one could possibly be required to exchange the key e.g. after it got compromitted. The perfect interface would be a "create new key" button next to an algorhitm field.

As I said unfortunately I got no spare time currentyly where I could work on this :(

The quick&dirty solution would be to remove the key in the parent zone, wait a few days, change the algo in the IPSC-code manually, resign and uplaod the new key. So you would not roll-over but un- and resign instead. But remember that this might also have impact on CAA or DNSKEY and probably even SPF and DKIM records afaik.

Written from my mind with no warranties.

Maybe as a first step, we could add a selector for both hashing algorithms and default to the new one for new installations. That way, admins can at least choose the new algorithm even if they have to deal with the key exchange for existing zones manually for the start.

In the next step, we can then implement a mechanism to handle the key exchange.

What yo you think?

Or we add checkboxes for the hashing algorithm to the zone details like:

[x] DNSSEC SHA1 [x] DNSSEC SHA256

So the admin or user can actually choose if the zone by none, one or both algorithms?

Does anyone know how other panels are handling this?

and @thom and @darkalex : Do we have to change the sha1 in line 149 too?

I think a selector would be the best, Plesk seems to do this: https://docs.plesk.com/en-US/onyx/customer-guide/websites-and-domains/domains-and-dns/configuring-dnssec-for-a-domain.76433/ This seems (almost) perfect...

@darkalex thanks for taking your time to think about this with us :)

Are you talking about this? 'dnssec-signzone -A -e +1382400 -3 $(head -c 1000 /dev/random | sha1sum | cut -b 1-16) -N increment -o '.escapeshellcmd($domain).' -t '.$filespre.escapeshellcmd($domain));

https://git.ispconfig.org/ispconfig/ispconfig3/-/blob/master/server/plugins-available/bind_plugin.inc.php#L152

$(head -c 1000 /dev/random | sha1sum | cut -b 1-16) is just generating a salt used with the NSEC3 option so the hashing algo does not matter here.

Yes, that's what I meant. Thanks for the clarification.

I think the option to enable/disable both on demand is a good quick solution as you could enable the new key and remove the old one whenever you think is the right moment.

BUT I'd strongly advice to leave a big red warning when unchecking a checkbox that warn about the rollover period and possible iisues if done wrong or too quick. This is a critical change.

Plesk seems to automatically rollover the KSK and ZSK. I believe ISPConfig doesn't do this. I don't think we should implement this right now, but implementing this could come with the benefit that users are able to manually rollover the KSK and ZSK.

added Important label

@tbrehm I think 3.1.16 should be added as milestone, or even a 3.1.15p4 (depending on how far we are on 3.1.16), since there are several users that can't update their zones anymore (those using OpenProvider)

changed milestone to %3.2

Hello Ben,

Thank you for pointing us to this thread. I have checked with Till and it seems ISPConfig version 3.1.16 will "soon" be released in beta and shortly afterwards in production. With that release, support for SHA256 algorithms will be built in.

For that reason, we have just reenabled DNSSEC algorithm 7 (RSASHA1-NSEC3-SHA1) again for .nl domains on our Openprovider platform; management of your DNSSEC keys should be no problem anymore. We intend to disable this algorithm again after 3.1.16 is out in production, and we will let you know for of course through this topic.

If any other user is affected by our recent changes, please let us know in a response, telling us the specific extension for which you would like temporary reactivation of algorithm 7, so that we can see if we can solve this for you.

Kind regards,

Siemen Roorda

Openprovider

With the release of ISPconfig 3.2, other DNSSEC algorithms can be selected now. For that reason, will disable DNSSEC algorithm 7 (RSASHA1-NSEC3-SHA1) again for .nl domains on our Openprovider platform, as originally anticipated for the 11th of May 2020. We will do so on the 13th of January 2021. If any user is affected by our recent changes, please let us know in a response.

I think the default algorithm should be changed aswell. (!668 (closed) was a WIP on this)

Also, a normal key rollover should be easy to add when this is implemented.

mentioned in merge request !668 (closed)

created branch 4561-add-algorithm-selection-for-dnssec to address this issue

assigned to @tbrehm

mentioned in commit 906eaa19

mentioned in merge request !1089 (merged)

closed via merge request !1089 (merged)

mentioned in commit 1d15da38

changed the description

added Implemented label and removed git-stable label

Add algorithm selection for DNSSEC

Designs

Child items ...

Activity