Re: Fully automated DNSSEC with BIND 9.16
Hi Håvard Odd, it works for me. Try a literal copy/paste of the link below. Or go to https://kb.isc.org and search for packages: https://kb.isc.org/docs/isc-packages-for-bind-9 Cheers, Greg On Wed, 19 Apr 2023 at 12:03, Havard Eidnes via bind-users < bind-users@lists.isc.org> wrote: > >>and if I run straight "upstream" code, it's fairly straight- > >>forward to upgrade to this version, modulo, of course, the fact > >>that this involves building it from source. > > > > It may not be necessary to build from source. There are packages for > > some distros maintained by ISC > > (https://kb.isc.org/docs/isc-packages-for-bind-9). > > I stand corrected, thanks for reminding me. I come from the > non-Linux open source side, so needs this reminder from time to > time. > > BTW, if someone from ISC is listening in, the above KB URL > currently returns > >The request is blocked. > > > 04Mk/ZADbZIhApAs8So/u0PGqLpjUU1ZHMjBFREdFMDYyMgAxMTU1ZGM4Yy1kNzdiLTQ3YzQtOThjNS02NzBhNjQ3MGRhNzE= > > Best regards, > > - Håvard > -- > 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 > -- 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: Fully automated DNSSEC with BIND 9.16
>>and if I run straight "upstream" code, it's fairly straight- >>forward to upgrade to this version, modulo, of course, the fact >>that this involves building it from source. > > It may not be necessary to build from source. There are packages for > some distros maintained by ISC > (https://kb.isc.org/docs/isc-packages-for-bind-9). I stand corrected, thanks for reminding me. I come from the non-Linux open source side, so needs this reminder from time to time. BTW, if someone from ISC is listening in, the above KB URL currently returns The request is blocked. 04Mk/ZADbZIhApAs8So/u0PGqLpjUU1ZHMjBFREdFMDYyMgAxMTU1ZGM4Yy1kNzdiLTQ3YzQtOThjNS02NzBhNjQ3MGRhNzE= Best regards, - Håvard -- 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: Fully automated DNSSEC with BIND 9.16
For CVEs, we have own site listing each and what is affected, what is not and whether fix is already available. CVE-2022-3924 [1] is not yet released in RHEL. Of course if you look into upstream notes to check what we have fixed in our distribution, it won't work well. Watching your own distribution announces might help too, such as centos-announce list [2]. [1] https://access.redhat.com/security/cve/CVE-2022-3924 [2] https://lists.centos.org/pipermail/centos-announce/2023-March/thread.html On 18. 04. 23 9:20, Havard Eidnes wrote: You do not have to sift through lists. That depends entirely what one wants to do. I see a couple of scenarios where that may be required: 1) Let's say someone has flagged to you as a BIND administrator that your BIND installatin is susceptible to CVE-2022-3924. This could be done via an "external scan" and based on the BIND version returned (if your BIND is configured to reveal such details), or via other means. How do you as an administrator figure out if the version you actually run has the fix for this CVE included? From the BIND change log, I can see --- 9.16.37 released --- 6067. [security] Fix serve-stale crash when recursive clients soft quota is reached. (CVE-2022-3924) [GL #3619] and if I run straight "upstream" code, it's fairly straight- forward to upgrade to this version, modulo, of course, the fact that this involves building it from source. On the other hand, looking at a version produced by a package maintainer (RedHat, Debian, ...), and where the package maintainer insists on sticking with whatever base version they started from (strictly based on timing, in all probability) and selectively applying patches, it will be much harder to figure out whether the fix is actually included. And ... if the fix is indeed included, you'll as administrator in all probability have to mark the issue as "false positive" after having assured yourself that the fix is included. However, getting to this assurance can be quite a bit of work. 2) You will end up with a somewhat similar scenario for non-security-related functionality fixes -- you may hit a problem which has been fixed upstream since your distributor forked off BIND, and you may be able to find the entry for the fix in BIND's upstream change log, but figuring out if that fix is indeed included in the code you run will make it necessary to rummage through the "patch list" of the package administrator. Yes, that indeed is a bit tiresome. Our bugs often reference upstream bugs if they fix them by upstream change backport. Or they are at least related. But I do not know if our bugs can be searched by upstream bug reference. It makes sense it should be possible and useful in few cases. Useful especially for community distributions, because our customers can just ask our support and they try to find it also in upstream issues. And requests to include that fix. But I guess filling duplicate bugs is not what we engineers would like, just because they were unable to find already requested or fixed issue. Yes, we should try to improve that, thank you for a suggestion! It seems it can work on issues.redhat.com somehow, but bugzilla.redhat.com does not offer simple way to search by upstream issue link. Even if that is included in our bug. We provide quite detailed git branch with each change we make. It has references to bugs related too. I admit changes listed in release notes of bind9 releases are nicer. But we do not hide what and why we do changes, publish them quite nice way for c9s [1]. It would be the same c8s as well soon. For important changes they are mentioned in release notes of the minor release. But I admit we do not mention explicitly each bug we fix the way ISC does. It would make our documentation unreadable. In any case, even if we fall behind a couple of releases, any our packages of bind 9.16 are capable of automated DNSSEC deployment just fine. Sure, even we do not support it for RHEL7 or older. [1] https://gitlab.com/redhat/centos-stream/rpms/bind/-/commits/c9s I certainly do appreciate that this is a considerable effort, and that you do this as well as you can with all good intentions. Now, even though the change log is available as stated (which is good, of course) does not necessarily make it easy to find. And ... solving the above two issues still requires a detailed sift through the lists. Regards, - Håvard Sure, in the end there is always some work required to do. We could improve some things to require less work, but cannot eliminate it altogether. I guess that is what you have meant. Regards, Petr -- Petr Menšík Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this
Re: Fully automated DNSSEC with BIND 9.16
On Tue, Apr 18, 2023 at 3:20 AM Havard Eidnes via bind-users wrote: >and if I run straight "upstream" code, it's fairly straight- >forward to upgrade to this version, modulo, of course, the fact >that this involves building it from source. > It may not be necessary to build from source. There are packages for some distros maintained by ISC (https://kb.isc.org/docs/isc-packages-for-bind-9). -- 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: Fully automated DNSSEC with BIND 9.16
> You do not have to sift through lists. That depends entirely what one wants to do. I see a couple of scenarios where that may be required: 1) Let's say someone has flagged to you as a BIND administrator that your BIND installatin is susceptible to CVE-2022-3924. This could be done via an "external scan" and based on the BIND version returned (if your BIND is configured to reveal such details), or via other means. How do you as an administrator figure out if the version you actually run has the fix for this CVE included? From the BIND change log, I can see --- 9.16.37 released --- 6067. [security] Fix serve-stale crash when recursive clients soft quota is reached. (CVE-2022-3924) [GL #3619] and if I run straight "upstream" code, it's fairly straight- forward to upgrade to this version, modulo, of course, the fact that this involves building it from source. On the other hand, looking at a version produced by a package maintainer (RedHat, Debian, ...), and where the package maintainer insists on sticking with whatever base version they started from (strictly based on timing, in all probability) and selectively applying patches, it will be much harder to figure out whether the fix is actually included. And ... if the fix is indeed included, you'll as administrator in all probability have to mark the issue as "false positive" after having assured yourself that the fix is included. However, getting to this assurance can be quite a bit of work. 2) You will end up with a somewhat similar scenario for non-security-related functionality fixes -- you may hit a problem which has been fixed upstream since your distributor forked off BIND, and you may be able to find the entry for the fix in BIND's upstream change log, but figuring out if that fix is indeed included in the code you run will make it necessary to rummage through the "patch list" of the package administrator. > We provide quite detailed git branch with each change we > make. It has references to bugs related too. I admit changes > listed in release notes of bind9 releases are nicer. But we do > not hide what and why we do changes, publish them quite nice > way for c9s [1]. It would be the same c8s as well soon. > > For important changes they are mentioned in release notes of the minor > release. But I admit we do not mention explicitly each bug we fix the > way ISC does. It would make our documentation unreadable. > > In any case, even if we fall behind a couple of releases, any our > packages of bind 9.16 are capable of automated DNSSEC deployment just > fine. Sure, even we do not support it for RHEL7 or older. > > [1] https://gitlab.com/redhat/centos-stream/rpms/bind/-/commits/c9s I certainly do appreciate that this is a considerable effort, and that you do this as well as you can with all good intentions. Now, even though the change log is available as stated (which is good, of course) does not necessarily make it easy to find. And ... solving the above two issues still requires a detailed sift through the lists. Regards, - Håvard -- 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: Fully automated DNSSEC with BIND 9.16
Le 17/04/2023 à 20:40, Petr Menšík a écrit : Ondřej, it would be awesome if we could choose a higher quality release instead to use for our longer support. But we lack any good metric to choose one. So we update from time to time unless there is something stopping us. How could you elaborate or argument later after such a statement ? It simply prove (and the rest of your answer confirm it) that you did not event take the time to read the ISC release numbering/policy or if you need "facts" the release notes of the 9.16 release(*) series and/or that you never operate "real" production grade Bind server. Don't take the "you" for yourself. As the email used, you represent RH here. The truth is that there is a market for RH like release policy choices. You work for this business. Perfect. 98% of your clients choose this release model for wrong, non technical reasons: that a/my personal strong opinion based on my latest 25 years of professional experience. So don't ask people to stop asking to install latest ISC release on one of the still supported branch to get free technical support. All people on this list get no direct revenues for helping others, even ISC employee. Otherwise, the only fair answer that we could give to the people asking for help on RH or derivative distribution would be: ask your distributor support. I even was one time in this position, with a payed RH support contract with lots of zero at the end. The answer was go away or if your problem is really solved by a new release (and do the analyses yourself) , pay for a custom package. [*]On the 9.16 release front, a lots of critical operational fixes where made on the fully automated signing process since your latest point release. Regards, Emmanuel. -- 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: Fully automated DNSSEC with BIND 9.16
Ondřej, it would be awesome if we could choose a higher quality release instead to use for our longer support. But we lack any good metric to choose one. So we update from time to time unless there is something stopping us. On 4/17/23 14:49, Ondřej Surý wrote: Petr, while I understand that you are trying to do a great job maintaining the BIND 9 packages for RHEL, it is what it is - a random snapshot defined not by the quality of the chosen version but by the time availability. This is made even more complicated by applying a set of patches where the set is defined by the downstream maintainer. The whole idea that something frozen in time with patches applied by distribution maintainer must be more stable than the software actively developed by upstream developers is wrong. This could perhaps work for slow-paced low complex software, but for anything that's reasonably complex (as various network servers and clients are) it's doomed to fail. Well, depends on how you define "stable". The less changes made makes it more stable in my opinion. Of course that is not necessary better, but it suits some people. For people with special demands every release might bring something important. But most people needs just something that works and does not require attention often. I do not think our RHEL is low complex software. And what's even worse that people will come, use the distribution package of BIND 9 and think this is the "best" quality they can get. Quality of the package is hard to measure. We spend more time with integrating bind into the whole system. I admit we lack people working on each DNS peculiarities, we spend more time dealing with strange interactions in some conditions. I think that has also its value. I think distributions provide good enough packages often. It may not suit everyone, but it did not seem to me this were that case. If he wanted bleeding edge This narrative is wrong. I am not recommending people to run the latest development release - that would be "bleeding edge". Okay, bleeding edge were wrong word. Anyway, original question were not about the latest feature added. Our version can provide automated dnssec service just fine. By the way, we have packaged even development version on Fedora under package bind9-next. Because it conflicts with bind system package, it were not allowed into EPEL (yet). Until I prepare a package that does not conflict, my copr can be used for EPEL 8 or 9: https://copr.fedorainfracloud.org/coprs/pemensik/bind9-next/ The latest stable BIND 9 version is not bleeding edge. You are trying to frame it as it's something dangerous to use the latest version provided by the upstream developers who are in all due respect more knowledgeable about the upstream source code than any downstream package maintainer could be. Sure, that doesn't mean that mistakes doesn't happen, they do, but running latest upstream patch release (or latest stable release) is considerably more safe for BIND 9 than running BIND 9 release that's many version behind, often EOL and with considerable amount of patches[1] applied. Sure, we have quite long list of patches on top of bind 9.11. We still support dhcp server and client in RHEL8. That depends on bind libraries functionality, which is not provided by bind 9.16 anymore. We have not stayed on old version because we are lazy, but because more recent version does not provide compatible interface anymore. You know that. I admit knowledge of BIND9 internals is far more advanced at ISC than at Red Hat, it has to be. I do not ask you to support our old versions. But just don't tell people to avoid vendor version, just because they are not sure how to configure relative basic thing. If that does not work when it should, okay, blame us. We deserve it often. This is not the case IMHO. So, no, I am not going to stop telling people to stop using packages bundled with a distribution unless the distribution follows the latest patch release. They do on Fedora, would you recommend that? If latest stable release is what you want, Fedora Server can provide it. If people choose some "stable" distribution, they usually want to limit number of changes for some reason. Alternatively, the RedHat can dedicate a support team to triage, answer and fix problems in these versions (taken from DistroWatch): * RHEL 7 - BIND 9.11.4 - released on 2018-07-11 - 33 patch releases behind - EOL since March 2022[2] * RHEL 8 - BIND 9.11.36 - released on 2021-10-27 - 1 patch release behind - EOL since March 2022[2] * RHEL 9 - BIND 9.16.23 - released on 2021-11-17 - 16 patch releases behind And since this is not really going to happen, I will continue people to use upstream sanctioned packages because that will not waste the user time and it will not waste the developers time. You still can tell the user what would work on latest stable version. If it does not work in our version, tell them where to find more recent
Re: Fully automated DNSSEC with BIND 9.16
You do not have to sift through lists. We provide quite detailed git branch with each change we make. It has references to bugs related too. I admit changes listed in release notes of bind9 releases are nicer. But we do not hide what and why we do changes, publish them quite nice way for c9s [1]. It would be the same c8s as well soon. For important changes they are mentioned in release notes of the minor release. But I admit we do not mention explicitly each bug we fix the way ISC does. It would make our documentation unreadable. In any case, even if we fall behind a couple of releases, any our packages of bind 9.16 are capable of automated DNSSEC deployment just fine. Sure, even we do not support it for RHEL7 or older. [1] https://gitlab.com/redhat/centos-stream/rpms/bind/-/commits/c9s On 4/17/23 15:10, Havard Eidnes wrote: Our CentOS/RHEL 8 package are not just random BIND 9 snapshot. Then please let me suggest that there is possibly an issue with identification (customer said "9.16.23") and documentation of the actual changes that are incorprorated in your distribution, compared to the upstream-maintained patch releases published since that release. Sifting through those two lists and juding what's "needed" and what isn't quite quickly becomes an unmanageable task. Stability of the base version of BIND (perhaps in particular) should not be mis-interpreted as an indication of continuing operational safety. Otherwise I have sympathy with Ondřey Surý's message. Best regards, - Håvard -- Petr Menšík Software Engineer, RHEL Red Hat, https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB -- 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: Fully automated DNSSEC with BIND 9.16
> Our CentOS/RHEL 8 package are not just random BIND 9 snapshot. Then please let me suggest that there is possibly an issue with identification (customer said "9.16.23") and documentation of the actual changes that are incorprorated in your distribution, compared to the upstream-maintained patch releases published since that release. Sifting through those two lists and juding what's "needed" and what isn't quite quickly becomes an unmanageable task. Stability of the base version of BIND (perhaps in particular) should not be mis-interpreted as an indication of continuing operational safety. Otherwise I have sympathy with Ondřey Surý's message. Best regards, - Håvard -- 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: Fully automated DNSSEC with BIND 9.16
Petr, while I understand that you are trying to do a great job maintaining the BIND 9 packages for RHEL, it is what it is - a random snapshot defined not by the quality of the chosen version but by the time availability. This is made even more complicated by applying a set of patches where the set is defined by the downstream maintainer. The whole idea that something frozen in time with patches applied by distribution maintainer must be more stable than the software actively developed by upstream developers is wrong. This could perhaps work for slow-paced low complex software, but for anything that's reasonably complex (as various network servers and clients are) it's doomed to fail. And what's even worse that people will come, use the distribution package of BIND 9 and think this is the "best" quality they can get. > If he wanted bleeding edge This narrative is wrong. I am not recommending people to run the latest development release - that would be "bleeding edge". The latest stable BIND 9 version is not bleeding edge. You are trying to frame it as it's something dangerous to use the latest version provided by the upstream developers who are in all due respect more knowledgeable about the upstream source code than any downstream package maintainer could be. Sure, that doesn't mean that mistakes doesn't happen, they do, but running latest upstream patch release (or latest stable release) is considerably more safe for BIND 9 than running BIND 9 release that's many version behind, often EOL and with considerable amount of patches[1] applied. So, no, I am not going to stop telling people to stop using packages bundled with a distribution unless the distribution follows the latest patch release. Alternatively, the RedHat can dedicate a support team to triage, answer and fix problems in these versions (taken from DistroWatch): * RHEL 7 - BIND 9.11.4 - released on 2018-07-11 - 33 patch releases behind - EOL since March 2022[2] * RHEL 8 - BIND 9.11.36 - released on 2021-10-27 - 1 patch release behind - EOL since March 2022[2] * RHEL 9 - BIND 9.16.23 - released on 2021-11-17 - 16 patch releases behind And since this is not really going to happen, I will continue people to use upstream sanctioned packages because that will not waste the user time and it will not waste the developers time. > if the only issue in our version is unrelated to the problem investigated? There were 448 merge requests between BIND version 9.16.23 and 9.16.39, and 963 commits. So, how do you know that? I don't and I am certainly not willing to spend my already spread-thin time investigating whether any issue has been fixed in the last year and half, but I would be thrilled to fix any issue found in the latest stable BIND release. We don't make changes to BIND 9 just because we can, there's (usually) a good reason behind every commit and every merge request. 1. https://git.centos.org/rpms/bind/blob/c8s/f/SOURCES 2. https://lists.isc.org/pipermail/bind-announce/2022-March/001210.html Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 17. 4. 2023, at 13:57, Petr Menšík wrote: > > Our CentOS/RHEL 8 package are not just random BIND 9 snapshot. If he wanted > bleeding edge, he would use RHEL 9 or even Fedora. But he uses conservative > package I am looking after. While it may have some known issues, it has all > important fixes it needs. Can you please stop telling people to not use our > packages, if the only issue in our version is unrelated to the problem > investigated? > > But I admit we should update to more recent BIND 9.16 release already. > > Cheers, > Petr > > On 4/13/23 15:40, Ondřej Surý wrote: >>> On 13. 4. 2023, at 15:25, David Carvalho via bind-users >>> wrote: >>> >>> I'm using 9.16.23 >> Just don't. >> >> ISC provides packages for major linux distributions >> (https://www.isc.org/download/), >> so there's really no reason to shoot yourself into foot to use a random BIND >> 9 >> snapshot provided by your distro. >> >> And while you are at it - upgrade straight to latest 9.18, your experience >> will be much >> smoother. >> >> Ondrej >> -- >> Ondřej Surý (He/Him) >> ond...@isc.org >> >> My working hours and your working hours may be different. Please do not feel >> obligated to reply outside your normal working hours. >> > -- > Petr Menšík > Software Engineer, RHEL > Red Hat, https://www.redhat.com/ > PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB > > -- > 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 -- Visit
Re: Fully automated DNSSEC with BIND 9.16
If you have enabled SELinux and the package uses selinux policy to restrict file access of named, I think named-chroot is not necessary. It just complicates the usage and maintenance. But I think packages of ISC do not have similar SELinux protection as Red Hat supported bind or bind9.16 packages. ISC packages to not offer chroot helpers either. You would have to prepare it yourself. On 4/13/23 18:17, David Carvalho via bind-users wrote: Hello and thank you for the reply. I can confirm my current dns servers have already EPEL repo enabled and jemalloc package is available. I'll setup my test machine accordingly to be able to install BIND 9.18. Will it also provide named-chroot (is it really necessary?) Thanks! David -Original Message- From: Anand Buddhdev Sent: 13 April 2023 16:48 To: David Carvalho Cc: 'Bind Users Mailing List' Subject: Re: Fully automated DNSSEC with BIND 9.16 On 13/04/2023 17:17, David Carvalho via bind-users wrote: Hi David, Hello and thanks for the reply. I enabled this repo in Oracle Linux 8 with: dnf copr enable isc/bind Then I tried to install (dnf install isc-bind) but I got: Error: Problem: package isc-bind-1:2-3.el8.x86_64 requires isc-bind-bind, but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires libbind9-9.18.13.so()(64bit), but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires libdns-9.18.13.so()(64bit), but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires libisc-9.18.13.so()(64bit), but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires libisccc-9.18.13.so()(64bit), but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires libisccfg-9.18.13.so()(64bit), but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires libns-9.18.13.so()(64bit), but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires isc-bind-bind-libs = 9.18.13, but none of the providers can be installed - conflicting requests - nothing provides libjemalloc.so.2()(64bit) needed by isc-bind-bind-libs-9.18.13-1.1.el8.x86_64 (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) BIND 9.18 and newer require jemalloc, but this package isn't part of Redhat base. You also need to enable the EPEL repository for this. I think it is not required by all 9.18 builds. It is recommended, but can be omitted. It has to be configured at the build time however. configure --without-jemalloc is still supported. It is still possible to build even 9.18 without jemalloc. With Oracle Linux, there are 2 different EPELs available. Oracle's own rebuild of EPEL packages, and the Fedora EPEL. My personal preference is the Fedora EPEL repo, which you can install with: dnf -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm Then you should be able to install the ISC BIND packages. Regards, Anand Interesting. I did not know Oracle rebuilds also EPEL packages. Are they also 100% compatible rebuilds like RHEL packages? Do they at least document how to contribute to EPEL anywhere? -- Petr Menšík Software Engineer, RHEL Red Hat, https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB -- 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: Fully automated DNSSEC with BIND 9.16
Our CentOS/RHEL 8 package are not just random BIND 9 snapshot. If he wanted bleeding edge, he would use RHEL 9 or even Fedora. But he uses conservative package I am looking after. While it may have some known issues, it has all important fixes it needs. Can you please stop telling people to not use our packages, if the only issue in our version is unrelated to the problem investigated? But I admit we should update to more recent BIND 9.16 release already. Cheers, Petr On 4/13/23 15:40, Ondřej Surý wrote: On 13. 4. 2023, at 15:25, David Carvalho via bind-users wrote: I'm using 9.16.23 Just don't. ISC provides packages for major linux distributions (https://www.isc.org/download/), so there's really no reason to shoot yourself into foot to use a random BIND 9 snapshot provided by your distro. And while you are at it - upgrade straight to latest 9.18, your experience will be much smoother. Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. -- Petr Menšík Software Engineer, RHEL Red Hat, https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB -- 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: Fully automated DNSSEC with BIND 9.16
Hello and thank you for the reply. I can confirm my current dns servers have already EPEL repo enabled and jemalloc package is available. I'll setup my test machine accordingly to be able to install BIND 9.18. Will it also provide named-chroot (is it really necessary?) Thanks! David -Original Message- From: Anand Buddhdev Sent: 13 April 2023 16:48 To: David Carvalho Cc: 'Bind Users Mailing List' Subject: Re: Fully automated DNSSEC with BIND 9.16 On 13/04/2023 17:17, David Carvalho via bind-users wrote: Hi David, > Hello and thanks for the reply. > I enabled this repo in Oracle Linux 8 with: dnf copr enable isc/bind > > Then I tried to install (dnf install isc-bind) but I got: > Error: > Problem: package isc-bind-1:2-3.el8.x86_64 requires isc-bind-bind, but none > of the providers can be installed >- package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires > libbind9-9.18.13.so()(64bit), but none of the providers can be installed >- package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires > libdns-9.18.13.so()(64bit), but none of the providers can be installed >- package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires > libisc-9.18.13.so()(64bit), but none of the providers can be installed >- package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires > libisccc-9.18.13.so()(64bit), but none of the providers can be installed >- package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires > libisccfg-9.18.13.so()(64bit), but none of the providers can be installed >- package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires > libns-9.18.13.so()(64bit), but none of the providers can be installed >- package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires isc-bind-bind-libs > = 9.18.13, but none of the providers can be installed >- conflicting requests >- nothing provides libjemalloc.so.2()(64bit) needed by > isc-bind-bind-libs-9.18.13-1.1.el8.x86_64 > (try to add '--skip-broken' to skip uninstallable packages or > '--nobest' to use not only best candidate packages) BIND 9.18 and newer require jemalloc, but this package isn't part of Redhat base. You also need to enable the EPEL repository for this. With Oracle Linux, there are 2 different EPELs available. Oracle's own rebuild of EPEL packages, and the Fedora EPEL. My personal preference is the Fedora EPEL repo, which you can install with: dnf -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm Then you should be able to install the ISC BIND packages. Regards, Anand -- 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: Fully automated DNSSEC with BIND 9.16
On 13/04/2023 17:17, David Carvalho via bind-users wrote: Hi David, Hello and thanks for the reply. I enabled this repo in Oracle Linux 8 with: dnf copr enable isc/bind Then I tried to install (dnf install isc-bind) but I got: Error: Problem: package isc-bind-1:2-3.el8.x86_64 requires isc-bind-bind, but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires libbind9-9.18.13.so()(64bit), but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires libdns-9.18.13.so()(64bit), but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires libisc-9.18.13.so()(64bit), but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires libisccc-9.18.13.so()(64bit), but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires libisccfg-9.18.13.so()(64bit), but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires libns-9.18.13.so()(64bit), but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires isc-bind-bind-libs = 9.18.13, but none of the providers can be installed - conflicting requests - nothing provides libjemalloc.so.2()(64bit) needed by isc-bind-bind-libs-9.18.13-1.1.el8.x86_64 (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) BIND 9.18 and newer require jemalloc, but this package isn't part of Redhat base. You also need to enable the EPEL repository for this. With Oracle Linux, there are 2 different EPELs available. Oracle's own rebuild of EPEL packages, and the Fedora EPEL. My personal preference is the Fedora EPEL repo, which you can install with: dnf -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm Then you should be able to install the ISC BIND packages. Regards, Anand -- 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: Fully automated DNSSEC with BIND 9.16
Hello and thanks for the reply. I enabled this repo in Oracle Linux 8 with: dnf copr enable isc/bind Then I tried to install (dnf install isc-bind) but I got: Error: Problem: package isc-bind-1:2-3.el8.x86_64 requires isc-bind-bind, but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires libbind9-9.18.13.so()(64bit), but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires libdns-9.18.13.so()(64bit), but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires libisc-9.18.13.so()(64bit), but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires libisccc-9.18.13.so()(64bit), but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires libisccfg-9.18.13.so()(64bit), but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires libns-9.18.13.so()(64bit), but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires isc-bind-bind-libs = 9.18.13, but none of the providers can be installed - conflicting requests - nothing provides libjemalloc.so.2()(64bit) needed by isc-bind-bind-libs-9.18.13-1.1.el8.x86_64 (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) This is the main reason I usually stick with provided packages. Kind regards David -Original Message- From: Ondřej Surý Sent: 13 April 2023 14:40 To: David Carvalho Cc: Bind Users Mailing List Subject: Re: Fully automated DNSSEC with BIND 9.16 > On 13. 4. 2023, at 15:25, David Carvalho via bind-users > wrote: > > I'm using 9.16.23 Just don't. ISC provides packages for major linux distributions (https://www.isc.org/download/), so there's really no reason to shoot yourself into foot to use a random BIND 9 snapshot provided by your distro. And while you are at it - upgrade straight to latest 9.18, your experience will be much smoother. Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. -- 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: Fully automated DNSSEC with BIND 9.16
> On 13. 4. 2023, at 15:25, David Carvalho via bind-users > wrote: > > I'm using 9.16.23 Just don't. ISC provides packages for major linux distributions (https://www.isc.org/download/), so there's really no reason to shoot yourself into foot to use a random BIND 9 snapshot provided by your distro. And while you are at it - upgrade straight to latest 9.18, your experience will be much smoother. Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. -- 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: Fully automated DNSSEC with BIND 9.16
Hello. Both content and timestamps. I've been told previously here that there is a bug prior to version 9.16.30. I'm using 9.16.23, no update available yet. No, not removing Regards David -Original Message- From: bind-users On Behalf Of Jan-Piet Mens Sent: 13 April 2023 11:12 To: bind-users@lists.isc.org Subject: Re: Fully automated DNSSEC with BIND 9.16 >1. Everytime I restart the service, it seems all these files are recreated. How did you observe this? Just by file timestamps or actual content? And just to be sure to ask the obvious: you are not manually removing these files are you? :) -JP -- 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 -- 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: Fully automated DNSSEC with BIND 9.16
1. Everytime I restart the service, it seems all these files are recreated. How did you observe this? Just by file timestamps or actual content? And just to be sure to ask the obvious: you are not manually removing these files are you? :) -JP -- 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: Fully automated DNSSEC with BIND 9.16
Thank you so much! Regards David -Original Message- From: bind-users On Behalf Of Matthijs Mekking Sent: 11 April 2023 13:03 To: bind-users@lists.isc.org Subject: Re: Fully automated DNSSEC with BIND 9.16 On 4/11/23 13:14, David Carvalho wrote: > Hello and thank you so much for your help. Regarding question 1, My > version is 9.16-9.1623-0.9.el8...so I got the bug. No update available > from Oracle Linux yet, so I'll create a folder and maintain a copy of > those files there. > > In which situation should I be required to resend my key to the top > domain? I'll have to read more about ZSK, KSK and CSK rollovers. All > of this is new to me so far. I think it would be useful to read this knowledge base article if all is new to you: https://kb.isc.org/v1/docs/en/dnssec-key-and-signing-policy Basically in the following two scenarios you need to publish the public key to the parent domain: 1. Enabling DNSSEC 2. KSK rollover With the default policy, KSK rollover is not scheduled, so only after you manually roll the key you need to publish (and withdraw) the DS records from the parent. When exactly? You can check with 'rndc dnssec -status '. If the DS state is rumoured it is safe to submit the DS to the parent. Best regards, Matthijs > > Thanks! David Carvalho > > > > -Original Message- From: bind-users > On Behalf Of Matthijs Mekking > Sent: 11 April 2023 11:16 To: bind-users@lists.isc.org Subject: Re: > Fully automated DNSSEC with BIND 9.16 > > Hello David, > > On 4/11/23 12:02, David Carvalho via bind-users wrote: >> Hello, hope everyone is fine. >> >> So it seems that going to Bind version 9.16 was the right call as it >> simplifies DNSSEC a lot. >> >> Nevertheless, I would like to clarify some things because our >> organization has a parent domain and I host my own e-mail servers. >> I know they had problems while implementing DNSSEC on the top domain, >> and some configurations had to be made to let subdomain e-mail >> servers to still work after DNSSEC. >> >> Following RedHat tutorial, all I had to do was add “*dnssec-policy >> default;”* into one of my zones for testing purposes. I’m not testing >> Reverse zones yet. >> >> After this, 3 files “Kmy.domain***” were created: >> >> “.key” >> >> “.private” >> >> “.state”. >> >> Three files regarding my zone were also created: >> >> My.domain.signed >> >> And the following 2, which I’m not sure what their purpose is >> >> *My.domain*.*jbk* and*my.domain.signed.jnl* > > The .jnl files are journal files and are created when a zone uses > dynamic update to store changes that are made to zone files. > > The .jbk files are truly temporary files and should be removed again > when writing the contents of the zone to file. > >> There are also “managed-keys.bind” and “managed-keys.bind.jnl” > > These are trust anchor files, and store the state of those keys. > These will be updated on a restart. > >> >> My questions: >> >> 1. Everytime I restart the service, it seems all these files are >> recreated. Does this mean that every time I make a change in the >> host zone, I need resend the public key to my top domain? > > No, the key files (.key, .private, .state) should also not be > recreated upon restart (a bug that would recreate key files every > keymgr run was fixed in 9.16.30). > > >> 2. Do Parental Agents help with this? > > Not in this case, because there is no need to send the public key to > the parent domain. Parental agents only help to automatically detect > if the corresponding DS has been published. > > Without parental agents configured you need to use 'rndc dnssec > -checkds' to tell BIND that a certain DS has been published/withdrawn > in order to continue key rollover. > > >> 3. Which format should I use when providing the key to the top level >> domain? >> >> * dnssec-dsfromkey >> /var/named/K/example.com.+013+61141/.key* >> >> or >> >> * grep DNSKEY /var/named/K*/*example.com.+013+61141.key*/ > > I assume you are submitting the public key to your registrar and it > depends on what format your registrar accepts. > > > 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 -- 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: Fully automated DNSSEC with BIND 9.16
On 4/11/23 13:14, David Carvalho wrote: Hello and thank you so much for your help. Regarding question 1, My version is 9.16-9.1623-0.9.el8...so I got the bug. No update available from Oracle Linux yet, so I'll create a folder and maintain a copy of those files there. In which situation should I be required to resend my key to the top domain? I'll have to read more about ZSK, KSK and CSK rollovers. All of this is new to me so far. I think it would be useful to read this knowledge base article if all is new to you: https://kb.isc.org/v1/docs/en/dnssec-key-and-signing-policy Basically in the following two scenarios you need to publish the public key to the parent domain: 1. Enabling DNSSEC 2. KSK rollover With the default policy, KSK rollover is not scheduled, so only after you manually roll the key you need to publish (and withdraw) the DS records from the parent. When exactly? You can check with 'rndc dnssec -status '. If the DS state is rumoured it is safe to submit the DS to the parent. Best regards, Matthijs Thanks! David Carvalho -Original Message- From: bind-users On Behalf Of Matthijs Mekking Sent: 11 April 2023 11:16 To: bind-users@lists.isc.org Subject: Re: Fully automated DNSSEC with BIND 9.16 Hello David, On 4/11/23 12:02, David Carvalho via bind-users wrote: Hello, hope everyone is fine. So it seems that going to Bind version 9.16 was the right call as it simplifies DNSSEC a lot. Nevertheless, I would like to clarify some things because our organization has a parent domain and I host my own e-mail servers. I know they had problems while implementing DNSSEC on the top domain, and some configurations had to be made to let subdomain e-mail servers to still work after DNSSEC. Following RedHat tutorial, all I had to do was add “*dnssec-policy default;”* into one of my zones for testing purposes. I’m not testing Reverse zones yet. After this, 3 files “Kmy.domain***” were created: “.key” “.private” “.state”. Three files regarding my zone were also created: My.domain.signed And the following 2, which I’m not sure what their purpose is *My.domain*.*jbk* and*my.domain.signed.jnl* The .jnl files are journal files and are created when a zone uses dynamic update to store changes that are made to zone files. The .jbk files are truly temporary files and should be removed again when writing the contents of the zone to file. There are also “managed-keys.bind” and “managed-keys.bind.jnl” These are trust anchor files, and store the state of those keys. These will be updated on a restart. My questions: 1. Everytime I restart the service, it seems all these files are recreated. Does this mean that every time I make a change in the host zone, I need resend the public key to my top domain? No, the key files (.key, .private, .state) should also not be recreated upon restart (a bug that would recreate key files every keymgr run was fixed in 9.16.30). 2. Do Parental Agents help with this? Not in this case, because there is no need to send the public key to the parent domain. Parental agents only help to automatically detect if the corresponding DS has been published. Without parental agents configured you need to use 'rndc dnssec -checkds' to tell BIND that a certain DS has been published/withdrawn in order to continue key rollover. 3. Which format should I use when providing the key to the top level domain? * dnssec-dsfromkey /var/named/K/example.com.+013+61141/.key* or * grep DNSKEY /var/named/K*/*example.com.+013+61141.key*/ I assume you are submitting the public key to your registrar and it depends on what format your registrar accepts. 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: Fully automated DNSSEC with BIND 9.16
Hello and thank you so much for your help. Regarding question 1, My version is 9.16-9.1623-0.9.el8...so I got the bug. No update available from Oracle Linux yet, so I'll create a folder and maintain a copy of those files there. In which situation should I be required to resend my key to the top domain? I'll have to read more about ZSK, KSK and CSK rollovers. All of this is new to me so far. Thanks! David Carvalho -Original Message- From: bind-users On Behalf Of Matthijs Mekking Sent: 11 April 2023 11:16 To: bind-users@lists.isc.org Subject: Re: Fully automated DNSSEC with BIND 9.16 Hello David, On 4/11/23 12:02, David Carvalho via bind-users wrote: > Hello, hope everyone is fine. > > So it seems that going to Bind version 9.16 was the right call as it > simplifies DNSSEC a lot. > > Nevertheless, I would like to clarify some things because our > organization has a parent domain and I host my own e-mail servers. I > know they had problems while implementing DNSSEC on the top domain, > and some configurations had to be made to let subdomain e-mail servers > to still work after DNSSEC. > > Following RedHat tutorial, all I had to do was add “*dnssec-policy > default;”* into one of my zones for testing purposes. I’m not testing > Reverse zones yet. > > After this, 3 files “Kmy.domain***” were created: > > “.key” > > “.private” > > “.state”. > > Three files regarding my zone were also created: > > My.domain.signed > > And the following 2, which I’m not sure what their purpose is > > *My.domain*.*jbk* and*my.domain.signed.jnl* The .jnl files are journal files and are created when a zone uses dynamic update to store changes that are made to zone files. The .jbk files are truly temporary files and should be removed again when writing the contents of the zone to file. > There are also “managed-keys.bind” and “managed-keys.bind.jnl” These are trust anchor files, and store the state of those keys. These will be updated on a restart. > > My questions: > > 1. Everytime I restart the service, it seems all these files are > recreated. Does this mean that every time I make a change in the > host zone, I need resend the public key to my top domain? No, the key files (.key, .private, .state) should also not be recreated upon restart (a bug that would recreate key files every keymgr run was fixed in 9.16.30). > 2. Do Parental Agents help with this? Not in this case, because there is no need to send the public key to the parent domain. Parental agents only help to automatically detect if the corresponding DS has been published. Without parental agents configured you need to use 'rndc dnssec -checkds' to tell BIND that a certain DS has been published/withdrawn in order to continue key rollover. > 3. Which format should I use when providing the key to the top level > domain? > > * dnssec-dsfromkey /var/named/K/example.com.+013+61141/.key* > > or > > * grep DNSKEY /var/named/K*/*example.com.+013+61141.key*/ I assume you are submitting the public key to your registrar and it depends on what format your registrar accepts. 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 -- 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: Fully automated DNSSEC with BIND 9.16
Hello David, On 4/11/23 12:02, David Carvalho via bind-users wrote: Hello, hope everyone is fine. So it seems that going to Bind version 9.16 was the right call as it simplifies DNSSEC a lot. Nevertheless, I would like to clarify some things because our organization has a parent domain and I host my own e-mail servers. I know they had problems while implementing DNSSEC on the top domain, and some configurations had to be made to let subdomain e-mail servers to still work after DNSSEC. Following RedHat tutorial, all I had to do was add “*dnssec-policy default;”* into one of my zones for testing purposes. I’m not testing Reverse zones yet. After this, 3 files “Kmy.domain***” were created: “.key” “.private” “.state”. Three files regarding my zone were also created: My.domain.signed And the following 2, which I’m not sure what their purpose is *My.domain*.*jbk* and*my.domain.signed.jnl* The .jnl files are journal files and are created when a zone uses dynamic update to store changes that are made to zone files. The .jbk files are truly temporary files and should be removed again when writing the contents of the zone to file. There are also “managed-keys.bind” and “managed-keys.bind.jnl” These are trust anchor files, and store the state of those keys. These will be updated on a restart. My questions: 1. Everytime I restart the service, it seems all these files are recreated. Does this mean that every time I make a change in the host zone, I need resend the public key to my top domain? No, the key files (.key, .private, .state) should also not be recreated upon restart (a bug that would recreate key files every keymgr run was fixed in 9.16.30). 2. Do Parental Agents help with this? Not in this case, because there is no need to send the public key to the parent domain. Parental agents only help to automatically detect if the corresponding DS has been published. Without parental agents configured you need to use 'rndc dnssec -checkds' to tell BIND that a certain DS has been published/withdrawn in order to continue key rollover. 3. Which format should I use when providing the key to the top level domain? * dnssec-dsfromkey /var/named/K/example.com.+013+61141/.key* or * grep DNSKEY /var/named/K*/*example.com.+013+61141.key*/ I assume you are submitting the public key to your registrar and it depends on what format your registrar accepts. 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
