On 27-05-2022 15:59, Matthijs Mekking wrote:
Yes, I would recommend key separation (that is use a different
key-directory per view).
I tried that, gracefully, by setting 'dnssec-policy' to insecure for the
internal view. That gave me some issues. Probably, because I had already
moved the key
Nick,
On 27-05-2022 10:27, Nick Tait via bind-users wrote:
On 26/05/22 20:34, Matthijs Mekking wrote:
What version are you using? We had a bug with dnssec-policy and views
(#2463), but that has been fixed.
Since 9.16.18 you should not be able to set the same key-directory for
the same zone i
Hi,
Sorry for not replying earlier (traveling).
Yes, I would recommend key separation (that is use a different
key-directory per view).
I am going to investigate your configuration more next week, to see if
there is a hidden bug.
Best regards,
Matthijs
On 26-05-2022 14:33, Sandro wrote:
On 26/05/22 20:34, Matthijs Mekking wrote:
What version are you using? We had a bug with dnssec-policy and views
(#2463), but that has been fixed.
Since 9.16.18 you should not be able to set the same key-directory for
the same zone in different views.
Hi Matthijs.
You got me worried just t
On 26-05-2022 12:00, Sandro wrote:
Thank you, Matthijs, for pointing out the bug. Do you have any
suggestion for what to try first, key separation or policy separation?
Well, I went for key separation. Let's see if it sticks. Last time I
restarted BIND everything seemed fine in the beginning
On 26-05-2022 11:05, Sandro wrote:
I'll take a look at the bug report in a minute.
Well, there are similarities between #2463 and my setup, but also
differences.
In my case, all zones are signed, internal and external. I have one
dnssec-policy defined in the options section, which is a ver
26-May-2022 10:06:14.458 debug 3: zone penguinpee.nl/IN/external:
zone_rekey failure: unexpected error (retry in 600 seconds)
One of the first things BIND does, if I'm reading lib/dns/zone.c correctly, is
to attempt to lock the keys, and if it fails it emits that diagnostic.
Assuming the signin
On 23-05-2022 16:12, Sandro wrote:
I'll do some more digging through the log files. I meanwhile increased
the severity to 'debug 3' for dnssec_debug.
I'm having some issues again. Not as severe as last time, since the
RRSIG records are all still within their validity period.
However, bind t
On 26-05-2022 10:34, Matthijs Mekking wrote:
What version are you using? We had a bug with dnssec-policy and views
(#2463), but that has been fixed.
I'm using BIND 9.16.28-RH on Fedora Server. I'll take a look at the bug
report in a minute.
Since 9.16.18 you should not be able to set the sa
Sandro,
What version are you using? We had a bug with dnssec-policy and views
(#2463), but that has been fixed.
Since 9.16.18 you should not be able to set the same key-directory for
the same zone in different views.
Matthijs
On 23-05-2022 16:12, Sandro wrote:
On 23-05-2022 15:48, Tony Fi
On 24-05-2022 20:57, Jan-Piet Mens via bind-users wrote:
Slightly off-topic, but I believe ISC reccomend using a custom policy
instead of `default' in case the default changes in future.
Yes, sort of. The documentation hints at the fact that the default
policy is subject to change. I meanwhil
dnssec-policy default;
Slightly off-topic, but I believe ISC reccomend using a custom policy instead
of `default' in case the default changes in future.
view "internal" {
zone "penguinpee.nl" {
typeprimary;
file"dynamic/penguinpee.nl.internal.zone";
};
};
view "
On 23-05-2022 16:12, Sandro wrote:
I'll do some more digging through the log files. I meanwhile increased
the severity to 'debug 3' for dnssec_debug.
Nothing really pops out. I have scrolled through all the logs since
rotation on Sunday at midnight. Since increasing verbosity on category
dns
On 23-05-2022 15:48, Tony Finch wrote:
The place I would look first is the log messages from `named`: is it
complaining about anything?
Plenty of:
zone penguinpee.nl/IN/external: reconfiguring zone keys
zone penguinpee.nl/IN/external: next key event: 22-May-2022 01:00:01.961
When the log fil
Sandro wrote:
>
> I was notified this morning by my registrar, that validation of my zone
> records failed. Upon inspection, it turned out that only the SOA record was
> still up to date. A and MX al returned RRSIG expired.
Yuck, that's painful.
> Since I want to avoid this happening again,
Hello,
I was notified this morning by my registrar, that validation of my zone
records failed. Upon inspection, it turned out that only the SOA record
was still up to date. A and MX al returned RRSIG expired.
I checked my logs and did not see any warning signs. I also tried to get
the z
16 matches
Mail list logo
