Re: DNSSEC inline/auto - burst of resigning/updates ?
Named splits the re-signing load up into small chunks so that all the cpu isn’t
consumed signing the zone and the server can still answer question, accept
updates,
etc. It does this by randomly reducing the expiry time by a small amount for
each
chunk it signs, the exception to this is the SOA record that is always signed
with
the full validity interval as it acts as a sentinel indicating the zone has been
fully processed.
Also if you are doing dynamic updates to the same machine that is signing the
zone
I would recommend NOT using inline signing. All it does is complicate the
process
and consume more memory for no benefit.
Mark
> On 7 Sep 2019, at 9:24 am, Brandon Applegate wrote:
>
> Hello,
>
> I just very recently set up all my zones for inline signing + auto maintain.
> Prior to this I had cron jobs resigning and it was working okay. But after I
> read up on inline/auto I thought it to be much more elegant.
>
> Anyway, basically the behavior I expect and observe is that bind periodically
> resigns my zones based on the sig-validity-interval values. Also, if I push
> a DDNS update (I do this for my home firewall for remote access (dynamic IP)
> as well as rotating my DKIM keys), I expect the zone to get resigned and my
> slaves get NOTIFYs and pull it. All of this happens.
>
> Tonight though in about an hour, the serial number was incremented 12 times
> and NOTIFYs sent. My home firewall is stable, and my DKIM rotation happens
> monthly via cron. So there’s nothing in the logs regarding a DDNS update.
>
> My question is - what could prompt these changes ? I don’t see a pattern in
> time or anything else in the logs.
>
> Also if there’s some debug I can toggle or increase I’m all ears…
>
> Here’s the zone in question and it’s config stanza:
>
>zone "burn.net" IN {
>type master;
>file "burn.net.zone";
>update-policy {
>grant vom.burn.net. zonesub A TXT;
>};
>key-directory "/var/cache/bind/keys";
>auto-dnssec maintain;
>inline-signing yes;
>sig-validity-interval 14 9;
>};
>
> # grep -i burn.net /var/log/syslog | grep notifies
> Sep 6 17:54:43 orbital named[9857]: zone burn.net/IN (signed): sending
> notifies (serial 2019082736)
> Sep 6 17:57:41 orbital named[9857]: zone burn.net/IN (signed): sending
> notifies (serial 2019082737)
> Sep 6 18:11:02 orbital named[9857]: zone burn.net/IN (signed): sending
> notifies (serial 2019082738)
> Sep 6 18:16:42 orbital named[9857]: zone burn.net/IN (signed): sending
> notifies (serial 2019082739)
> Sep 6 18:22:07 orbital named[9857]: zone burn.net/IN (signed): sending
> notifies (serial 2019082740)
> Sep 6 18:28:51 orbital named[9857]: zone burn.net/IN (signed): sending
> notifies (serial 2019082741)
> Sep 6 18:31:27 orbital named[9857]: zone burn.net/IN (signed): sending
> notifies (serial 2019082742)
> Sep 6 18:40:07 orbital named[9857]: zone burn.net/IN (signed): sending
> notifies (serial 2019082743)
> Sep 6 18:50:25 orbital named[9857]: zone burn.net/IN (signed): sending
> notifies (serial 2019082744)
> Sep 6 18:55:03 orbital named[9857]: zone burn.net/IN (signed): sending
> notifies (serial 2019082745)
> Sep 6 18:57:27 orbital named[9857]: zone burn.net/IN (signed): sending
> notifies (serial 2019082746)
> Sep 6 18:58:24 orbital named[9857]: zone burn.net/IN (signed): sending
> notifies (serial 2019082747)
> Sep 6 19:04:37 orbital named[9857]: zone burn.net/IN (signed): sending
> notifies (serial 2019082748)
>
> Thanks.
>
> --
> Brandon Applegate - CCIE 10273
> PGP Key fingerprint:
> 0641 D285 A36F 533A 73E5 2541 4920 533C C616 703A
> "For thousands of years men dreamed of pacts with demons.
> Only now are such things possible."
>
> ___
> 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
DNSSEC inline/auto - burst of resigning/updates ?
Hello,
I just very recently set up all my zones for inline signing + auto maintain.
Prior to this I had cron jobs resigning and it was working okay. But after I
read up on inline/auto I thought it to be much more elegant.
Anyway, basically the behavior I expect and observe is that bind periodically
resigns my zones based on the sig-validity-interval values. Also, if I push a
DDNS update (I do this for my home firewall for remote access (dynamic IP) as
well as rotating my DKIM keys), I expect the zone to get resigned and my slaves
get NOTIFYs and pull it. All of this happens.
Tonight though in about an hour, the serial number was incremented 12 times and
NOTIFYs sent. My home firewall is stable, and my DKIM rotation happens monthly
via cron. So there’s nothing in the logs regarding a DDNS update.
My question is - what could prompt these changes ? I don’t see a pattern in
time or anything else in the logs.
Also if there’s some debug I can toggle or increase I’m all ears…
Here’s the zone in question and it’s config stanza:
zone "burn.net" IN {
type master;
file "burn.net.zone";
update-policy {
grant vom.burn.net. zonesub A TXT;
};
key-directory "/var/cache/bind/keys";
auto-dnssec maintain;
inline-signing yes;
sig-validity-interval 14 9;
};
# grep -i burn.net /var/log/syslog | grep notifies
Sep 6 17:54:43 orbital named[9857]: zone burn.net/IN (signed): sending
notifies (serial 2019082736)
Sep 6 17:57:41 orbital named[9857]: zone burn.net/IN (signed): sending
notifies (serial 2019082737)
Sep 6 18:11:02 orbital named[9857]: zone burn.net/IN (signed): sending
notifies (serial 2019082738)
Sep 6 18:16:42 orbital named[9857]: zone burn.net/IN (signed): sending
notifies (serial 2019082739)
Sep 6 18:22:07 orbital named[9857]: zone burn.net/IN (signed): sending
notifies (serial 2019082740)
Sep 6 18:28:51 orbital named[9857]: zone burn.net/IN (signed): sending
notifies (serial 2019082741)
Sep 6 18:31:27 orbital named[9857]: zone burn.net/IN (signed): sending
notifies (serial 2019082742)
Sep 6 18:40:07 orbital named[9857]: zone burn.net/IN (signed): sending
notifies (serial 2019082743)
Sep 6 18:50:25 orbital named[9857]: zone burn.net/IN (signed): sending
notifies (serial 2019082744)
Sep 6 18:55:03 orbital named[9857]: zone burn.net/IN (signed): sending
notifies (serial 2019082745)
Sep 6 18:57:27 orbital named[9857]: zone burn.net/IN (signed): sending
notifies (serial 2019082746)
Sep 6 18:58:24 orbital named[9857]: zone burn.net/IN (signed): sending
notifies (serial 2019082747)
Sep 6 19:04:37 orbital named[9857]: zone burn.net/IN (signed): sending
notifies (serial 2019082748)
Thanks.
--
Brandon Applegate - CCIE 10273
PGP Key fingerprint:
0641 D285 A36F 533A 73E5 2541 4920 533C C616 703A
"For thousands of years men dreamed of pacts with demons.
Only now are such things possible."
signature.asc
Description: Message signed with OpenPGP
___
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
Re: Status of experimental COPR packages
> On Sep 6, 2019, at 10:18 AM, John Thurston wrote: > > Back in Sept, 2018 we got word of packages published by ISC for a few common > linux distributions. > https://www.isc.org/blogs/bind-9-packages/ > > There have been a couple of trickles of news on this mailing list since then. > I'm interested in the prospects, plans, etc for these packages. > > I really like what I'm seeing with the COPR distribution: > https://copr.fedorainfracloud.org/coprs/isc/ > The description there still states "..USE AT YOUR OWN RISK.” John- Do you still see those messages? I don’t see them. I thought I removed all those comments about ‘experimental’ and ‘use at your own risk’ a while ago. > I see the August update to 9.11.10 is available there. > Where do I go to learn the planned path for this? > > Are there plans to stabilize it? > Are there outstanding feature requests to be addressed? > Is there a timeline somewhere? The reason these were marked as experimental was, we were waiting to get more feedback from users. It seems as if we aren’t going to get any, which is why I reventually removed those comments. The main package ‘feature’ we were trying to implement, was support for the software collections approach to managing dependencies (we have quite a few due to wanting to provide support for DNSTAP). That work is finished, and i am not aware of any other ‘outstanding feature requests.’ So I think the packages are pretty stable. We did recently start setting up another site, Cloudsmith.io, for some of our packages. We need a site we can control for non-public stuff, like the BIND subscription edition, and private patches, and Cloudsmith allows us to put packages for multiple different OSes in one repo. I need to find out whether we plan to continue updating the COPR site or not. I think we do,(because of course it is easier to ‘find’ than Cloudsmith) but we haven’t discussed it explicitly. I should have a more complete answer next week - the people working on this are already on their weekend. Vicky > > -- > Do things because you should, not just because you can. > > John Thurston907-465-8591 > john.thurs...@alaska.gov > Department of Administration > State of Alaska > ___ > 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 Victoria Risk Product Manager Internet Systems Consortium vi...@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
Status of experimental COPR packages
Back in Sept, 2018 we got word of packages published by ISC for a few common linux distributions. https://www.isc.org/blogs/bind-9-packages/ There have been a couple of trickles of news on this mailing list since then. I'm interested in the prospects, plans, etc for these packages. I really like what I'm seeing with the COPR distribution: https://copr.fedorainfracloud.org/coprs/isc/ The description there still states "..USE AT YOUR OWN RISK." I see the August update to 9.11.10 is available there. Where do I go to learn the planned path for this? Are there plans to stabilize it? Are there outstanding feature requests to be addressed? Is there a timeline somewhere? -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska ___ 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
