Hello Mark,
many thanks for your clarification.
Then how to determine an optimal count of nodes for sig-signing-nodes <
integer> (default should be 100); in the case when my biggest zone has 737
nodes (rndc zonestatus) and the optimal number for signatures for sig-
signing-signatures <integer>; (default should be 10)?
Is there a general suggestion?
Best regards,
--
Smil Milan Jeskyňka Kazatel
---------- Původní e-mail ----------
Od: Mark Andrews <ma...@isc.org>
Komu: Milan Jeskynka Kazatel <kazat...@seznam.cz>
Datum: 11. 3. 2020 2:28:41
Předmět: Re: Bind Resign Zone behavior
"
> On 11 Mar 2020, at 00:54, Milan Jeskynka Kazatel <kazat...@seznam.cz>
wrote:
>
> Hello Community,
>
> I would like to figure out how to describe a Bind behavior when the zone
is repeatedly resigned. The Bind continuously did a resign process and
automatically increase the zone serial number which causes unexpected AXFR/
IXFR traffic on slave servers.
It’s not repeatedly re-signed. It is incrementally re-signed. Nothing in
DNSSEC requires that a zone be signed all at once. Named performs
incremental signing as it had other roles to perform, like answering queries
and accepting updates of records, and it is actually easier to do that and
sign the zone if signing is done in small chunks. It also performs
incremental re-signing and spreads out re-signing times to try to prevent
the server becoming overloaded with RRSIG maintenance.
As for AXFR/IXFR traffic you told named to manage DNSSEC. That requires
named to generate and re-generate RRSIG periodically. Those signature need
to be transferred to the other servers for the zone. The total number of
records transferred is marginally more that if the entire zone was signed in
a single hit. There would be a couple of extra SOA records and their RRSIG
transferred for each delta and that is all.
> The zone has 180 records and the signed part seems to be unpredictable
between 1 and 57 records from the zone, which is visible in the stripped
log. The server time is not in GMT. My question is regarding configuration,
how to achieve the whole zone sign in the one-step? Bind version on Centos 7
- BIND 9.11.4-P2-RedHat-9.11.4-9.P2.el7 (Extended Support Version) Exists a
configuration variable?
Actually it is entirely predictable. The zone is processed in DNSSEC order
and there are limits on the number of nodes processed and the numbers of
signatures generated in each increment. These are controlled by the
following
options.
sig-signing-nodes <integer>;
sig-signing-signatures <integer>;
Mark
> rndc zonestatus 45.10.0.10.in-addr.arpa
> name: 45.10.0.10.in-addr.arpa
> type: master
> files: 45.10.0.10.in-addr.arpa
> serial: 2018111342
> signed serial: 2018112075
> nodes: 173
> last loaded: Mon, 17 Feb 2020 09:28:28 GMT
> secure: yes
> inline signing: yes
> key maintenance: automatic
> next key event: Tue, 10 Mar 2020 13:44:01 GMT
> next resign node: 35.45.10.0.10.in-addr.arpa/NSEC
> next resign time: Tue, 10 Mar 2020 13:25:06 GMT
> dynamic: no
> reconfigurable via modzone: no
>
> rndc zonestatus 45.10.0.10.in-addr.arpa
> name: 45.10.0.10.in-addr.arpa
> type: master
> files: 45.10.0.10.in-addr.arpa
> serial: 2018111342
> signed serial: 2018112076
> nodes: 173
> last loaded: Mon, 17 Feb 2020 09:28:28 GMT
> secure: yes
> inline signing: yes
> key maintenance: automatic
> next key event: Tue, 10 Mar 2020 13:44:01 GMT
> next resign node: 92.45.10.0.10.in-addr.arpa/NSEC
> next resign time: Tue, 10 Mar 2020 14:18:11 GMT
> dynamic: no
> reconfigurable via modzone: no
>
> Mar 10 14:03:47 testdnsserver01 named[16277]: client @0x7d61b00b7690
172.29.62.4#41088 (45.10.0.10.in-addr.arpa): transfer of '45.10.0.10.in-
addr.arpa/IN': IXFR started (serial 2018112072 -> 2018112073)
> Mar 10 14:03:47 testdnsserver01 named[16277]: client @0x7d61b00b7690
172.29.62.4#41088 (45.10.0.10.in-addr.arpa): transfer of '45.10.0.10.in-
addr.arpa/IN': IXFR ended
> Mar 10 14:11:33 testdnsserver01 named[16277]: zone 45.10.0.10.in-addr.
arpa/IN (signed): sending notifies (serial 2018112074)
> Mar 10 14:11:33 testdnsserver01 named[16277]: client @0x7d61c801d000
172.29.61.4#40137 (45.10.0.10.in-addr.arpa): transfer of '45.10.0.10.in-
addr.arpa/IN': IXFR started (serial 2018112073 -> 2018112074)
> Mar 10 14:11:33 testdnsserver01 named[16277]: client @0x7d61c801d000
172.29.61.4#40137 (45.10.0.10.in-addr.arpa): transfer of '45.10.0.10.in-
addr.arpa/IN': IXFR ended
> Mar 10 14:14:10 testdnsserver01 named[16277]: client @0x7d61c80cd960
172.29.62.4#41930 (45.10.0.10.in-addr.arpa): transfer of '45.10.0.10.in-
addr.arpa/IN': IXFR started (serial 2018112073 -> 2018112074)
> Mar 10 14:14:10 testdnsserver01 named[16277]: client @0x7d61c80cd960
172.29.62.4#41930 (45.10.0.10.in-addr.arpa): transfer of '45.10.0.10.in-
addr.arpa/IN': IXFR ended
> Mar 10 14:17:38 testdnsserver01 named[16277]: zone 45.10.0.10.in-addr.
arpa/IN (signed): sending notifies (serial 2018112075)
> Mar 10 14:17:38 testdnsserver01 named[16277]: client @0x7d61c8019550
172.29.61.4#37636 (45.10.0.10.in-addr.arpa): transfer of '45.10.0.10.in-
addr.arpa/IN': IXFR started (serial 2018112074 -> 2018112075)
> Mar 10 14:17:38 testdnsserver01 named[16277]: client @0x7d61c8019550
172.29.61.4#37636 (45.10.0.10.in-addr.arpa): transfer of '45.10.0.10.in-
addr.arpa/IN': IXFR ended
> Mar 10 14:18:09 testdnsserver01 named[16277]: client @0x7d61c801d000
172.29.62.4#43508 (45.10.0.10.in-addr.arpa): transfer of '45.10.0.10.in-
addr.arpa/IN': IXFR started (serial 2018112074 -> 2018112075)
> Mar 10 14:18:09 testdnsserver01 named[16277]: client @0x7d61c801d000
172.29.62.4#43508 (45.10.0.10.in-addr.arpa): transfer of '45.10.0.10.in-
addr.arpa/IN': IXFR ended
>
> Best regards,
> --
> Smil Milan Jeskyňka Kazatel
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
"
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
