You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One of the things I was planning for this year was to provide DNSSEC support in NetBox DNS. Over the last few weeks, I considered ways to assess that issue and I must admit that I'm stuck in some sense. Some bullet points:
Signing/Key Management
IMHO it does not make much sense to have NetBox DNS handle the key storage, signing, key rotation etc. as this is normally done elsewhere for a number of reasons.
Software such as BIND handle automatic zone signing and key rotation for ZSKs pretty well.
Key storage would require additional effort in terms of security (e.g. using the netbox-secrets plugin) and would still not solve a general use case as the requirements and solutions for key storage vary widely across enterprises.
Controlling signing and key maintenance operations is IMHO out of scope for a source of truth-like instrument like NetBox.
Key Parametrisation
So my next approach was to include DNSSEC Key parameters such as the algorithm, key length, usage (ZSK/KSK/CSK), an NSEC3 flag etc. and make it possible to assign them to zones, as an input for automation mechanisms to control the generation of keys. That is a considerably lesser goal, but I'm not sure if it makes sense at all, so I thought I ask here.
Do you use DNSSEC at all?
Do you actually use different parameters for DNSSEC keys for different zones, or is it more or less a hard-coded setup in your automation workflow (it is in mine, but I'm not sure if it is generally wide-spread)
What, if anything, do you need in terms of DNSSEC support?
For my part I currently use a boolean dynamic field "Enable DNSSEC" on Zone objects and that's fine. But if there are more sophisticated requirements out in the wild (that means you :-)) I'd like to know and see what I can do to make it easier.
Otherwise DNSSEC support might end up as an additional boolean field for zones, which looks pretty lame to me (but, as I said above, is fully sufficient for my case).
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
DNSSEC Support for NetBox DNS
One of the things I was planning for this year was to provide DNSSEC support in NetBox DNS. Over the last few weeks, I considered ways to assess that issue and I must admit that I'm stuck in some sense. Some bullet points:
Signing/Key Management
IMHO it does not make much sense to have NetBox DNS handle the key storage, signing, key rotation etc. as this is normally done elsewhere for a number of reasons.
netbox-secrets
plugin) and would still not solve a general use case as the requirements and solutions for key storage vary widely across enterprises.Key Parametrisation
So my next approach was to include DNSSEC Key parameters such as the algorithm, key length, usage (ZSK/KSK/CSK), an NSEC3 flag etc. and make it possible to assign them to zones, as an input for automation mechanisms to control the generation of keys. That is a considerably lesser goal, but I'm not sure if it makes sense at all, so I thought I ask here.
For my part I currently use a boolean dynamic field "Enable DNSSEC" on
Zone
objects and that's fine. But if there are more sophisticated requirements out in the wild (that means you :-)) I'd like to know and see what I can do to make it easier.Otherwise DNSSEC support might end up as an additional boolean field for zones, which looks pretty lame to me (but, as I said above, is fully sufficient for my case).
Beta Was this translation helpful? Give feedback.
All reactions