On Tue, Apr 26, 2022 at 11:36 AM Leroy Tennison via bind-users <
bind-users@lists.isc.org> wrote:
> I am working on shutting down a site which has an isc-bind server that is
> master for a domain and subnet which will exist elsewhere once the site is
> closed. The few remaining systems don't warr
I am working on shutting down a site which has an isc-bind server that is
master for a domain and subnet which will exist elsewhere once the site is
closed. The few remaining systems don't warrant such a server. My goal is to
merge what remains of the domain/subnet into an existing server whic
On 26-04-2022 14:25, Bjørn Mork wrote:
Matthijs Mekking writes:
What can you do to get it to "omnipresent"? Tell BIND that the DS is
in the parent (only do so if it is true of course). You can run
rndc dnssec -checkds published your.zone
And it should update the keyfile. You should
Matthijs Mekking writes:
> What can you do to get it to "omnipresent"? Tell BIND that the DS is
> in the parent (only do so if it is true of course). You can run
>
> rndc dnssec -checkds published your.zone
>
> And it should update the keyfile. You should then see a "DsPublish"
> line in
On 26.04.22 12:25, Michal Nowak wrote:
On 25/04/2022 12:20, Josef Moellers wrote:
Hi,
I'm trying to build bind 9.18.2 with the contrib modules, but this
fails for contrib/dlz/modules/wildcard.
Without any modifications to the spec file used for 9.18.1, it fails
because it does not have "FAL
On 25/04/2022 12:20, Josef Moellers wrote:
Hi,
I'm trying to build bind 9.18.2 with the contrib modules, but this fails
for contrib/dlz/modules/wildcard.
Without any modifications to the spec file used for 9.18.1, it fails
because it does not have "FALLTHROUGH" and "UNREACHABLE()", whose use
Bjørn,
Perhaps you hit another quirk in the migration. I'll try to explain what
is happening, or what is supposed to happen.
When migrating to dnssec-policy, there are no state files. BIND tries to
deduce the state from the timing metadata and the durations from
dnssec-policy.
For the DS,
Matthijs Mekking writes:
> To be precise, BIND updates the key files each keymgr run. But If the
> keymgr waits for an event (rather than a duration), it will retry
> every refresh key interval, which defaults to an hour.
>
> You can check the logs for "next key event" to see when the keymgr is
>
Hi,
To be precise, BIND updates the key files each keymgr run. But If the
keymgr waits for an event (rather than a duration), it will retry every
refresh key interval, which defaults to an hour.
You can check the logs for "next key event" to see when the keymgr is
scheduled next.
But yes,
9 matches
Mail list logo
