Re: Merging DNS servers
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 warrant such a server. My goal is > to merge what remains of the domain/subnet into an existing server which is > master for other domains/subnets. My current thinking is to: > > freeze changes on the server being retired (fortunately DHCP's DDNS won't > be an issue by that point) > shut down that server > take the data files (forward and reverse zone with associated journal > files) and place them on the remaining server > make sure the data file types are consistent > change the the remaining server's type from slave to master for the zones > in question > restart the remaining server > > Is this a good plan? If not, how should I proceed? > Anything I'm missing? > > Thanks in advance for your input. > -- > > Sounds good to me. If you use "rndc freeze", then you should not need to copy the journal files. If there are any other secondary servers (and you almost always want more than just the master), then change those to pull from the new server, and make sure that is working, before starting the steps you listed. -- Bob Harold -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Merging DNS servers
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 which is master for other domains/subnets. My current thinking is to: freeze changes on the server being retired (fortunately DHCP's DDNS won't be an issue by that point)shut down that servertake the data files (forward and reverse zone with associated journal files) and place them on the remaining servermake sure the data file types are consistentchange the the remaining server's type from slave to master for the zones in questionrestart the remaining server Is this a good plan? If not, how should I proceed?Anything I'm missing? Thanks in advance for your input.-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnssec-policy makes BIND touch all key files every hour
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 then see a "DsPublish" line in the state file and wait for DS TTL and parent propagation delay time to see the state switch to "omnipresent". If there are multiple keys eligible you need to specify the key id with "-key id". Thanks. Yes, that was the solution. Glad to hear that worked. Pretty obvious now that I know :-) We can view the initial bootstrapping as "half a KSK rollover". FWIW, I followed the dnssec-policy migration instructions at https://kb.isc.org/docs/dnssec-key-and-signing-policy , which also includes KSK rollover instructions. But I still didn't manage to put that puzzle together. Maybe you could include an explicit hint for those of us who are too slow to figure out these things by ourselves? Makes sense to me. I have added a note at the end of the "Key states" section. Best regards, Matthijs -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnssec-policy makes BIND touch all key files every hour
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 the state file and wait for DS TTL and parent propagation > delay time to see the state switch to "omnipresent". > > If there are multiple keys eligible you need to specify the key id > with "-key id". Thanks. Yes, that was the solution. Pretty obvious now that I know :-) We can view the initial bootstrapping as "half a KSK rollover". FWIW, I followed the dnssec-policy migration instructions at https://kb.isc.org/docs/dnssec-key-and-signing-policy , which also includes KSK rollover instructions. But I still didn't manage to put that puzzle together. Maybe you could include an explicit hint for those of us who are too slow to figure out these things by ourselves? Bjørn -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Building contrib modules for 9.18.2 fails
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 "FALLTHROUGH" and "UNREACHABLE()", whose use is new in 9.18.2, defined. I tried to solve this by including and adding "-I../../../../lib/isc/include" to the CFLAGS in the Makefile but that then fails because the modules have a simpler definition of "isc_result_t" My code to build the modules is: # special build for the plugins for d in contrib/dlz/modules/*; do [ -e $d/Makefile ] && make -C $d done Any tips/hints what I'm doing wrong? Thanks in advance, Josef Looks like issue with commits 128c550a955635e4ff78f120eb6c94411a2f163d and c62a94363d7707f0354a2291de546d7f87ea58d9 we did not catch because we don't build contrib/ in the CI. The stuff in the directory in not supported, but will be fixed as time permits, if you file an issue to GitLab. I'll make a note to do that. As a stopgap measure you can revert those two commits above just for the contrib/dlz/modules/wildcard/dlz_wildcard_dynamic.c file. Then it builds for me. BTDT ;-) It wasn't too difficult to figure out. Thanks, Josef -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Building contrib modules for 9.18.2 fails
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 is new in 9.18.2, defined. I tried to solve this by including and adding "-I../../../../lib/isc/include" to the CFLAGS in the Makefile but that then fails because the modules have a simpler definition of "isc_result_t" My code to build the modules is: # special build for the plugins for d in contrib/dlz/modules/*; do [ -e $d/Makefile ] && make -C $d done Any tips/hints what I'm doing wrong? Thanks in advance, Josef Looks like issue with commits 128c550a955635e4ff78f120eb6c94411a2f163d and c62a94363d7707f0354a2291de546d7f87ea58d9 we did not catch because we don't build contrib/ in the CI. The stuff in the directory in not supported, but will be fixed as time permits, if you file an issue to GitLab. As a stopgap measure you can revert those two commits above just for the contrib/dlz/modules/wildcard/dlz_wildcard_dynamic.c file. Then it builds for me. Michal -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnssec-policy makes BIND touch all key files every hour
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, BIND examines the "SyncPublish" time and checks it against
the current time (when migrating). If enough time has passed since
"SyncPublish" the "DSState" will be set to "omnipresent", otherwise it
will be "rumoured":
if (syncpub <= now && ret == ISC_R_SUCCESS) {
dns_ttl_t ds_ttl = dns_kasp_dsttl(kasp);
ds_ttl += dns_kasp_parentpropagationdelay(kasp);
if ((syncpub + ds_ttl) <= now) {
ds_state = OMNIPRESENT;
} else {
ds_state = RUMOURED;
}
goal_state = OMNIPRESENT;
}
I am not sure what the "SyncPublish" value is in your key file, but
maybe this is a hint to why the "DSState" is set to "rumoured".
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 the state file and wait for DS TTL and parent propagation delay time
to see the state switch to "omnipresent".
If there are multiple keys eligible you need to specify the key id with
"-key id".
Hope this helps, and if not, please let me know.
Best regards,
Matthijs
On 26-04-2022 10:50, Bjørn Mork wrote:
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
scheduled next.
But yes, each time the keymgr runs for a zone, the key files are
written out for that zone. You are right that this is unnecessary. I
have created a GitLab issue for this to fix it.
https://gitlab.isc.org/isc-projects/bind9/-/issues/3302
Thanks for explaining. This makes sense.
I guess that the event the keymgr is waiting for must be DSState update
for the active KSK? Which is another thing I haven't been able to
figure out.
Since I have only migrated existing keys, all states are either "hidden"
(for deleted keys) or "omnipresent". Except for DSState which is
"rumoured". And I don't understand why, or what I can do to change that.
For example:
bjorn@louie:~$ grep . /etc/bind/dnssec/dyn.mork.no/Kdyn.mork.no.+013+63342.state
; This is the state of key 63342, for dyn.mork.no.
Algorithm: 13
Length: 256
Lifetime: 0
KSK: yes
ZSK: no
Generated: 20181012184125 (Fri Oct 12 19:41:25 2018)
Published: 20181012184500 (Fri Oct 12 19:45:00 2018)
Active: 20181012184500 (Fri Oct 12 19:45:00 2018)
PublishCDS: 20181013195000 (Sat Oct 13 20:50:00 2018)
DNSKEYChange: 20220405085059 (Tue Apr 5 09:50:59 2022)
KRRSIGChange: 20220405085059 (Tue Apr 5 09:50:59 2022)
DSChange: 20220405085059 (Tue Apr 5 09:50:59 2022)
DNSKEYState: omnipresent
KRRSIGState: omnipresent
DSState: rumoured
GoalState: omnipresent
The DS records for all these zones have been active for years. I see
that BIND created new and mostly (except for TTL) matching CDS records
when I migrated to dnssec-policy. Is the TTL mismatch the problem? Or
is BIND waiting for something else to happen to this (C)DS record?
I guess I could try to sync the TTL for the internal delegations. But
this is rarely an option for most of the zones with externally managed
parents.
I found https://gitlab.isc.org/isc-projects/bind9/-/issues/2544
describing this problem, but the solutions is still unclear to me.
Maybe it's just a transitional problem when migrating to dnssec-policy?
Bjørn
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: dnssec-policy makes BIND touch all key files every hour
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 > scheduled next. > > But yes, each time the keymgr runs for a zone, the key files are > written out for that zone. You are right that this is unnecessary. I > have created a GitLab issue for this to fix it. > > https://gitlab.isc.org/isc-projects/bind9/-/issues/3302 Thanks for explaining. This makes sense. I guess that the event the keymgr is waiting for must be DSState update for the active KSK? Which is another thing I haven't been able to figure out. Since I have only migrated existing keys, all states are either "hidden" (for deleted keys) or "omnipresent". Except for DSState which is "rumoured". And I don't understand why, or what I can do to change that. For example: bjorn@louie:~$ grep . /etc/bind/dnssec/dyn.mork.no/Kdyn.mork.no.+013+63342.state ; This is the state of key 63342, for dyn.mork.no. Algorithm: 13 Length: 256 Lifetime: 0 KSK: yes ZSK: no Generated: 20181012184125 (Fri Oct 12 19:41:25 2018) Published: 20181012184500 (Fri Oct 12 19:45:00 2018) Active: 20181012184500 (Fri Oct 12 19:45:00 2018) PublishCDS: 20181013195000 (Sat Oct 13 20:50:00 2018) DNSKEYChange: 20220405085059 (Tue Apr 5 09:50:59 2022) KRRSIGChange: 20220405085059 (Tue Apr 5 09:50:59 2022) DSChange: 20220405085059 (Tue Apr 5 09:50:59 2022) DNSKEYState: omnipresent KRRSIGState: omnipresent DSState: rumoured GoalState: omnipresent The DS records for all these zones have been active for years. I see that BIND created new and mostly (except for TTL) matching CDS records when I migrated to dnssec-policy. Is the TTL mismatch the problem? Or is BIND waiting for something else to happen to this (C)DS record? I guess I could try to sync the TTL for the internal delegations. But this is rarely an option for most of the zones with externally managed parents. I found https://gitlab.isc.org/isc-projects/bind9/-/issues/2544 describing this problem, but the solutions is still unclear to me. Maybe it's just a transitional problem when migrating to dnssec-policy? Bjørn -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnssec-policy makes BIND touch all key files every hour
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, each time the keymgr runs for a zone, the key files are written out for that zone. You are right that this is unnecessary. I have created a GitLab issue for this to fix it. https://gitlab.isc.org/isc-projects/bind9/-/issues/3302 Best regards, Matthijs On 25-04-2022 18:49, Laurent Frigault wrote: On Sun, Apr 24, 2022 at 11:58:44AM +0200, Bjørn Mork wrote: Hello, I recently moved a few zones from "auto-dnssec maintain" to "dnssec-policy ..." to prepare for simpler/automatic key rotation in the future. For the time being I have configured my policy with separate KSK and ZSK and unlimited key life times to replicate the old setup as closely as possible. I also had a few old and outdated keys lying around, and would like to keep those, so my policy has "purge-keys 0". All other policy settings are default. The setup is mostly working as expected - which is great. But there is one issue which has suprised me, and which is slightly annoying since it tends to set off a few security warnings: All the key related files are now touched by BIND once an hour, whether they are modified or not. Which they obviously nevery should be, given my current policy. I discover the same issue with bind 9.16.27 and FreeBSD 13.0 This is particularily surprising wrt the deleted keys. But it's equally unnecessary with the current keys. And touching those is actually more annoying since it's an unexpected file system operation with real security implications. Or at least it feels that way... My test server run only a few zones and only one with dnssec-policy but I have a production serveur with more than 70 000 zones. This issue would generate avec very high IO load on such server. Is this expected or am I doing something wrong? And if this is expected, then why? Good question. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
