To follow-up,
Migration from existing keys to dnssec-policy was indeed not working
properly, because the internal key states were not initialized properly.
Key states were always initialized as "HIDDEN" and that is why the
keymgr thought it could delete those keys immediately.
The fix is to look
On 2020-03-27 00:34, Shumon Huque wrote:
In fact, "rndc zonestatus" reports the same for a very simple
dnssec-policy test on a local zone I did:
$ rndc zonestatus foo.test
name: foo.test
type: master
files: zones/foo.test/zonefile
serial: 100251
signed serial: 100257
nodes: 5
last
On Thu, Mar 26, 2020 at 7:27 PM Håkan Lindqvist via bind-users <
bind-users@lists.isc.org> wrote:
> On 2020-03-26 23:00, Mark Andrews wrote:
> > dnssec-policy should be independent of inline-signing. If it isn’t then
> it is a bug.
> >
> > It just people like editing master files rather than
On 2020-03-26 23:00, Mark Andrews wrote:
dnssec-policy should be independent of inline-signing. If it isn’t then it is
a bug.
It just people like editing master files rather than using nsupdate to make
changes.
Ok, thank you for clarifying what should be expected.
I guess that leaves the
dnssec-policy should be independent of inline-signing. If it isn’t then it is
a bug.
It just people like editing master files rather than using nsupdate to make
changes.
> On 27 Mar 2020, at 08:02, Shumon Huque wrote:
>
> On Thu, Mar 26, 2020 at 3:35 PM Håkan Lindqvist via bind-users
>
On Thu, Mar 26, 2020 at 3:35 PM Håkan Lindqvist via bind-users <
bind-users@lists.isc.org> wrote:
>
> A related thing that I've noticed in my tests is that "dnssec-policy x"
> seems to also imply "inline-signing yes"?
> Is this intended as a strict requirement, it seems a little awkward?
>
I'm
I reported a bug with the requested details:
https://gitlab.isc.org/isc-projects/bind9/issues/1706
A related thing that I've noticed in my tests is that "dnssec-policy x"
seems to also imply "inline-signing yes"?
Is this intended as a strict requirement, it seems a little awkward?
On that
Thanks for the information Matthijs.
We were actually looking forward to this particular feature in 9.16.x for
easier key rolls. So, if you have any idea yet about the timeframe to
develop and backport the NSEC3 support to 9.16, let us know.
Thanks!
Shumon.
On Wed, Mar 25, 2020 at 4:09 PM
Hi Shumon,
The "NOT IMPLEMENTED YET" is still accurate. It means that if you use
dnssec-policy, your zones will be signed with NSEC. Any attempts to make
it work with NSEC3 (with Dynamic Update for example) have undefined
behavior.
You are right that at this moment dnssec-policy is not yet
On Wed, Mar 25, 2020 at 9:04 AM Matthijs Mekking wrote:
> Hi Håkan,
>
> First of all, thanks for trying out the new dnssec-policy feature.
>
> I'll admit there is insufficient documentation and tooling around
> migration to dnssec-policy, possibly there is a bug too.
>
[...]
HI Matthijs,
We
On 2020-03-25 14:03, Matthijs Mekking wrote:
Existing keys do not have a .state file, and so named will try to match
those keys with the policy by looking at the data in the .key and
.private files. However, perhaps some metadata is different? If so the
keys don't match the policy and named will
Hi Håkan,
First of all, thanks for trying out the new dnssec-policy feature.
I'll admit there is insufficient documentation and tooling around
migration to dnssec-policy, possibly there is a bug too.
Existing keys do not have a .state file, and so named will try to match
those keys with the
Hello,
I have seen essentially this same question/problem posed by others in
other forums but never seen any proper answers to it.
I have now tried this myself with BIND 9.16.1 and faced the exact same
issue that I had previously read about.
How does one migrate an already signed zone from
13 matches
Mail list logo
