-
Notifications
You must be signed in to change notification settings - Fork 907
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Auth (DNSSEC): a "hybrid" signing mode for serving RRSIG #14372
Comments
Can you check if https://doc.powerdns.com/authoritative/settings.html?highlight=direct%20dnskey#direct-dnskey helps your situation? |
Hi @Habbie, thanks for the reply 😺 I've checked out the Do correct my understanding on While it is definitely closer to something that we were hoping to be achieved, I do not think it is sufficient for our case. Just to give an overview of what we had tried. Setup:
When
When
The problem that we have with either approach is that both ultimately uses the ZSK's private key to sign the What we had in mind goes on something like the following (using remote backend again just as an example) Suppose we have a setup:
When resolving for
When resolving
In short, for a single zone, its Let me know if you have any other questions. I am not sure if PDNS supports this currently since I haven't found any mention on the docs regarding this kind of setup. cheers.. |
It should be doing both when enabled. |
right. I wonder if we could/should expand direct-dnskey to do this. |
Interesting. Now that you mentioned it, it does sound similar to the way Or, it might also be possible to have some sort of new configuration, something like |
@Habbie I'd like to come back to this issue if you don't mind. Have you guys started working on it? If not, I was wondering if I can open a PR on it, but I'd still need a second opinion if the approach is correct and/or if there are any concerns. Since you mentioned about the possibility of expanding The main change to the logic of the code should happen within the Personally, I have tested this and it seems to work. What do you think about this approach? |
@Habbie I'd like to ask your thoughts on another alternative approach and whether this is preferable to the earlier approach. Rather than expanding In terms of actual changes to the code, the main logical change will remain the same as what I mentioned earlier, that is modifying the checking within the |
I'm not picky about flag naming or the number of flags, for now; I find those things are easier to reason about once there is running code. As for that code, what you say makes sense I think. Would love to see a PR so we can test. |
Cool, I've opened the PR #14581 already. Looking forward for the review. |
Short description
A hybrid signing mode for a particular zone, where certain record types can be pre-signed while other types can be signed directly by PDNS.
Usecase
A mode where signatures of DNSKEY record types are provided by the backend pre-signed, while other record types are still signed directly by PDNS Auth by providing it the ZSK's private key.
Description
When using PDNS Auth's online signing mode, we can provide PDNS Auth with the private keys of ZSK and/or KSK. If we provide both KSK and ZSK, PDNS Auth will sign DNSKEY record with KSK while the other record types with ZSK; however, without providing the KSK (only the ZSK), PDNS Auth will also sign the DNSKEY record type with the ZSK.
We are currently in a situation where our KSK's private key must be held by a certain KMS Service outside of our control. In this arrangement, we only have access to the KSK's public key and also a
Sign
method provided by the KMS; so we can still pre-sign the DNSKEY records before storing it in our backend. With this scenario in mind, the only option that we have is to use the pre-signed mode since we cannot provide the private key of our KSK to PDNS Auth.We do manage the ZSK ourselves though, so we do have access to its private key. Technically with this, we can use the online signing mode, however, this will mean that we are not going to be utilising our KSK for the signing of the DNSKEY records, and we are not going to be using the pre-signed DNSKEY signatures generated from the KMS.
What we are proposing is some sort of hybrid mode between online signing and pre-signed.
The way we envisioned it is having DNSKEY signatures as pre-signed records provided by the backend, while for signatures of record types other than DNSKEY will be signed online by PDNS. This way, us that do not have access to the KSK's private key but still retain control over the ZSK, would still be able to take advantage of PDNS Auth's online signing mode, while allowing ourselves the option of having the DNSKEY signatures pre-signed by an external KMS.
The text was updated successfully, but these errors were encountered: