Re: Status of experimental COPR packages
>> 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. > > Which makes it sound like the future of the COPR distribution isn't yet > clear. This is a pretty important topic to us, and I'd welcome any > information you can offer. I'm not trying to drive your product offerings, > just trying to divine which way the wind is blowing. > > From my perspective, I'm quite pleased with how the COPR distribution is > working out. It was only a little bit of work to make the "software > collection" concept meet our needs, and I'd dearly like to be able to > consider it stable. Thanks for that feedback. I have a clarification. ISC plans to continue updating the ISC BIND 9 packages on COPR and Launchpad for the forseeable future. You should consider those to be stable and non-experimental. We are ALSO putting packages for Debian up on Cloudsmith.io, because Debian doesn’t provide a repo like COPR or Launchpad for projects to update their own packages. The ISC Debian packages on Cloudsmith.io use the same configuration as the official Debian packages, but are updated more frequently than the official Debian packages. So, if you are looking for fresher Debian packages, or for packages for the development and current stable branches of BIND 9, you might try the ones on Cloudsmith. (https://cloudsmith.io/~isc/repos/) Vicky ___ 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 9/6/2019 12:10 PM, Victoria Risk wrote: 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. No I don't . . . now that you call my attention to it. I had guessed there would be an announcement on the blog, or to the announce-list if its status had changed. Obviously, that wasn't a valid assumption. 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. Which makes it sound like the future of the COPR distribution isn't yet clear. This is a pretty important topic to us, and I'd welcome any information you can offer. I'm not trying to drive your product offerings, just trying to divine which way the wind is blowing. From my perspective, I'm quite pleased with how the COPR distribution is working out. It was only a little bit of work to make the "software collection" concept meet our needs, and I'd dearly like to be able to consider it stable. -- 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
Re: DNSSEC inline/auto - burst of resigning/updates ?
Shumon Huque wrote: > > In recent versions of BIND, the jitter is no longer 1 hour, but spread > out over the signature validity period. Oh, nice, I must have looked at a stale branch by accident :-) Tony. -- f.anthony.n.finchhttp://dotat.at/ Lundy, Fastnet, Irish Sea: North or northwest 6 or 7, decreasing 4 or 5 later. Slight or moderate, occasionally rough in Lundy and Fastnet at first. Showers, perhaps thundery. Moderate or good. ___ 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: DNSSEC inline/auto - burst of resigning/updates ?
On Mon, Sep 9, 2019 at 6:48 AM Tony Finch wrote: > [...] > You should find that re-signing gets spread out over time due to update > activity and because of the randomizing jitter that Mark mentioned. So on > a more mature zone you might not get such an intense flurry of signature > updates. The jitter is 1 hour (in normal configurations) and there isn't > a direct way to change it, unlike the -j option to `dnssec-signzone`. > In recent versions of BIND, the jitter is no longer 1 hour, but spread out over the signature validity period. I filed an enhancement request about a year ago on this topic, and why BIND should spread out the jitter: https://gitlab.isc.org/isc-projects/bind9/issues/418 The changes first appeared in BIND 9.12.3 I believe. Shumon Huque ___ 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: DNSSEC inline/auto - burst of resigning/updates ?
Brandon Applegate wrote: > > 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. The prompt would have been regular zone re-signing activity, which (as Mark says) is done in small chunks. You can control the size of the chunks with the `sig-signing-nodes` and `sig-signing-signatures` options. If you want to reduce NOTIFY / IXFR traffic, you might want to increase these options, though it's probably only a good idea if you have a hidden primary server that isn't answering other queries. You should find that re-signing gets spread out over time due to update activity and because of the randomizing jitter that Mark mentioned. So on a more mature zone you might not get such an intense flurry of signature updates. The jitter is 1 hour (in normal configurations) and there isn't a direct way to change it, unlike the -j option to `dnssec-signzone`. Tony. -- f.anthony.n.finchhttp://dotat.at/ Wight: South 4 to 6, becoming variable 3 or less. Slight, occasionally moderate at first. Showers, perhaps thundery. Moderate or good.___ 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
