Re: dnssec-policy makes BIND touch all key files every hour
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. -- Laurent Frigault | Free.org - BookMyName.com - ONLINE SAS - Registar ID 74 -- 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: getting answers from DNS queries
More specificity would help. OTOH you mentioned the word "compile"...
On Mon, 25 Apr 2022, King, Harold Clyde (Hal) via bind-users wrote:
I asked this last week, but I didn't an answer. Who can I tell if a DNS
query is refused or answered? Is it in the log files?
Not the latest version of BIND (9.12), but here's what I get in the log:
25-Apr-2022 06:54:33.353 debug 2: fetch completed at resolver.c:4176 for
time.nist.gov/A in 10.000446: timed out/success
[domain:nist.gov,referral:0,restart:1,qrysent:4,timeout:0,lame:0,quota:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0]
25-Apr-2022 06:56:21.593 debug 2: fetch completed at resolver.c:4176 for
time.nist.gov/A in 10.000430: timed out/success
[domain:nist.gov,referral:0,restart:2,qrysent:10,timeout:0,lame:0,quota:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0]
Here's the config for that:
// Must start named with -d 2 for this to be activated,
// otherwise it's just silent.
channel queryerrors {
file "bind-query-errors.log" versions 2 size 20m;
severity debug 2;
print-category no;
print-severity yes;
print-time yes;
};
I would expect the information you seek to be available via Dnstap.
--
Fred Morris, internet plumber
--
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: getting answers from DNS queries
That’s much better - you should search for dnstap, initial pointer might be: https://kb.isc.org/docs/aa-01342 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 25. 4. 2022, at 17:27, King, Harold Clyde (Hal) wrote: > > That's fair. I can see queries come into my DNS server, but I can't find > answers to thoughts queries. I have an RPZ zone and I get a log file that > says PASSTHROUGH or NXDOMAIN. That tells me that the request was served or > denied. I want something that will tell me the answer to each query. I have > my server set to denied requests for recursion. So I know those will be > denied, I want that for every query. I compile each new release and use that > for production. Is there something I can set at compile-time? Perhaps I add > an option to the logging statement? I kinda lost my google-fu on this one and > I really am thankful to y'all for any help that you might have. > > > -- > > Hal King - h...@utk.edu > Systems Administrator > Office of Information Technology > Shared Services > > The University of Tennessee > 103c5 Kingston Pike Building > 2309 Kingston Pk. Knoxville, TN 37996 > Phone: 974-1599 > > > From: Ondřej Surý > Sent: Monday, April 25, 2022 10:37 AM > To: King, Harold Clyde (Hal) > Cc: bind-users > Subject: Re: getting answers from DNS queries > > > I asked this last week, but I didn't an answer. > > Probably because I still don’t know what you mean. You need to better > articulate your problem and your question. > > 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 25. 4. 2022, at 16:11, King, Harold Clyde (Hal) via bind-users > > wrote: > > > > I asked this last week, but I didn't an answer. Who can I tell if a DNS > > query is refused or answered? Is it in the log files? Can a compile-time > > option help me access it? Sorry to repeat but I really need to know this. > > > > Thank in advance. > > > > > > -- > > > > Hal King - h...@utk.edu > > Systems Administrator > > Office of Information Technology > > Shared Services > > > > The University of Tennessee > > 103c5 Kingston Pike Building > > 2309 Kingston Pk. Knoxville, TN 37996 > > Phone: 974-1599 > > > > -- > > 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 signature.asc Description: Message signed with OpenPGP -- 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: getting answers from DNS queries
That's fair. I can see queries come into my DNS server, but I can't find answers to thoughts queries. I have an RPZ zone and I get a log file that says PASSTHROUGH or NXDOMAIN. That tells me that the request was served or denied. I want something that will tell me the answer to each query. I have my server set to denied requests for recursion. So I know those will be denied, I want that for every query. I compile each new release and use that for production. Is there something I can set at compile-time? Perhaps I add an option to the logging statement? I kinda lost my google-fu on this one and I really am thankful to y'all for any help that you might have. -- Hal King - h...@utk.edu Systems Administrator Office of Information Technology Shared Services The University of Tennessee 103c5 Kingston Pike Building 2309 Kingston Pk. Knoxville, TN 37996 Phone: 974-1599 [cid:f96c691b-14fb-43c3-81bb-27c0801dd170] From: Ondřej Surý Sent: Monday, April 25, 2022 10:37 AM To: King, Harold Clyde (Hal) Cc: bind-users Subject: Re: getting answers from DNS queries > I asked this last week, but I didn't an answer. Probably because I still don’t know what you mean. You need to better articulate your problem and your question. 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 25. 4. 2022, at 16:11, King, Harold Clyde (Hal) via bind-users > wrote: > > I asked this last week, but I didn't an answer. Who can I tell if a DNS query > is refused or answered? Is it in the log files? Can a compile-time option > help me access it? Sorry to repeat but I really need to know this. > > Thank in advance. > > > -- > > Hal King - h...@utk.edu > Systems Administrator > Office of Information Technology > Shared Services > > The University of Tennessee > 103c5 Kingston Pike Building > 2309 Kingston Pk. Knoxville, TN 37996 > Phone: 974-1599 > > -- > 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: getting answers from DNS queries
> > I asked this last week, but I didn't an answer. Who can I tell if a DNS > query is refused or answered? Is it in the log files? Can a compile-time > option help me access it? Sorry to repeat but I really need to know this. > > Thank in advance. > Hi Hal, I saw at least one reply to your query on the mailing list. However, I don't think it really answered your question. I also sent you a private email reply which you don't appear to have seen. Maybe check if anything has been stopped by an antispam system? My experience is there is little interest here in dealing with the subject of malicious, bogus queries etc. Regards, Peter Coghlan. > > -- > > Hal King - h...@utk.edu > Systems Administrator > Office of Information Technology > Shared Services > > The University of Tennessee > 103c5 Kingston Pike Building > 2309 Kingston Pk. Knoxville, TN 37996 > Phone: 974-1599 > [cid:00350bec-9764-4740-8d61-e8bec49334bc] -- 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: getting answers from DNS queries
> I asked this last week, but I didn't an answer. Probably because I still don’t know what you mean. You need to better articulate your problem and your question. 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 25. 4. 2022, at 16:11, King, Harold Clyde (Hal) via bind-users > wrote: > > I asked this last week, but I didn't an answer. Who can I tell if a DNS query > is refused or answered? Is it in the log files? Can a compile-time option > help me access it? Sorry to repeat but I really need to know this. > > Thank in advance. > > > -- > > Hal King - h...@utk.edu > Systems Administrator > Office of Information Technology > Shared Services > > The University of Tennessee > 103c5 Kingston Pike Building > 2309 Kingston Pk. Knoxville, TN 37996 > Phone: 974-1599 > > -- > 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 signature.asc Description: Message signed with OpenPGP -- 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
getting answers from DNS queries
I asked this last week, but I didn't an answer. Who can I tell if a DNS query is refused or answered? Is it in the log files? Can a compile-time option help me access it? Sorry to repeat but I really need to know this. Thank in advance. -- Hal King - h...@utk.edu Systems Administrator Office of Information Technology Shared Services The University of Tennessee 103c5 Kingston Pike Building 2309 Kingston Pk. Knoxville, TN 37996 Phone: 974-1599 [cid:00350bec-9764-4740-8d61-e8bec49334bc] -- 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
On 04/25/2022 8:31 am, The Doctor via bind-users wrote:
Any easy repices to get your domains DNSSEC compilant?
--
Member - Liberal International This is doctor@@nl2k.ab.ca Ici
doctor@@nl2k.ab.ca
Yahweh, Queen & country!Never Satan President Republic!Beware
AntiChrist rising!
Look at Psalms 14 and 53 on Atheism
https://www.empire.kred/ROOTNK?t=94a1f39b
God will not fix the vessel which insists it isn't broken. -unknown
Beware https://mindspring.com
I'm just using the dnssec-policy stuff with 9.18, and manually add the
DS records to my registrar
(Google in my case), and ARIN for my IPv4 block, and my provider for the
delegated IPv6 block.
dnssec-policy "ler2" {
keys {
ksk lifetime unlimited algorithm 13;
zsk lifetime 90d algorithm 13;
};
// Key timings
dnskey-ttl 3600;
publish-safety 1h;
retire-safety 1h;
purge-keys P90D;
// Signature timings
signatures-refresh 5d;
signatures-validity 14d;
signatures-validity-dnskey 14d;
// Zone parameters
max-zone-ttl 86400;
zone-propagation-delay 300;
// Parent parameters
parent-ds-ttl 3600;
parent-propagation-delay 300;
nsec3param iterations 0 salt-length 0;
};
If I can help, let me know.
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
--
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
DNSSEC
Any easy repices to get your domains DNSSEC compilant? -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b God will not fix the vessel which insists it isn't broken. -unknown Beware https://mindspring.com -- 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
Testing, please ignore
Testing, please ignore. -Dan -- -- 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
testing, please ignore
Sorry for the noise -- -- 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
test, please ignore
Thanks, subject is all. -- Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC FB: fb.com/DanielMahoneyIV LI: linkedin.com/in/gushi Site: http://www.gushi.org --- -- 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
Building contrib modules for 9.18.2 fails
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 -- 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: FIPS 140-3 mode on RHEL 9 and RSA validation of <2048 keys
On 25. 04. 22 11:49, Petr Menšík wrote: Forgot to add the bug link. - openssl: https://bugzilla.redhat.com/show_bug.cgi?id=2077884 - bind: https://bugzilla.redhat.com/show_bug.cgi?id=2077906 On 4/25/22 11:39, Petr Menšík wrote: Hello, I have sent already a notification about SHA-1 not validated in default configuration. However that was not end of the story. A new and even more severe issue has arisen. Our crypto team is responsible for preparing RHEL 9 for FIPS 140-3 certification. They said there is legal obligation to stop using all RSA signatures with keys shorter than 2048 bits. I expect many of you already know especially Zone Signing Keys often use 1280 or even 1024b keys without issues. Current RHEL 9 validates such signatures well, but there is a bug [1] filled to change that and start enforcing longer keys usage only. Because it would be enforced at crypto library level (openssl), common DNSSEC validation software would start failing. On quite a lot of domains. And failing to resolve such names. I am looking for the best way out of this. Once the above happens without any changes to used DNS(SEC) software, the only way to keep working DNS servers working would be either turning off FIPS more or DNSSEC validation. I know the result seems quite ridiculous, because all this has been done in order to increase the security. The only alternative without changes would be disabling all RSA altogether and providing a long list of ECDSA trust anchors for TLD domains, where at least ECDSA would offer protection. I think the only good way would be starting considering shorter keys as insecure in FIPS mode. Anything above those domains would be without DNSSEC protection, but at least single root key could be used. Do you think it would be safe once the DS digest is checked on the key, that key is then can be marked as insecure instead of bogus. Just as if the algorithm were unsupported, but after checking the length of key. Because the crypto library would refuse any operation, including signature validation, on the given key. I think the library would not even allow loading that key. I don't think described behavior is possible in any supported version of BIND9. I expect it would require not only small and self-contained change. Would you know any blockers, which would prevent behavior described in the above paragraph? Is it possible to consider all keys with short keys to become unsupported, but keys with long enough keys to be still validated as usual? Note: some companies and agencies have to use only FIPS 140-3 approved algorithms. Enabling FIPS mode in RHEL 9 is not optional for them. Fixing the problem by disabling FIPS mode is not possible for everyone. Any comments or suggestions welcome. I have my doubts about FIPS wisdom, but in general I think feature to "treat keys as insecure if their length falls below bit length threshold for a given algorithm" is a sensible request. Even if FIPS was not on face of Earth it makes sense to me to treat RSA keys with 512 bits as insecure. The threshold could go even higher... https://en.wikipedia.org/wiki/RSA_Factoring_Challenge -- Petr Špaček -- 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: FIPS 140-3 mode on RHEL 9 and RSA validation of <2048 keys
Forgot to add the bug link. - openssl: https://bugzilla.redhat.com/show_bug.cgi?id=2077884 - bind: https://bugzilla.redhat.com/show_bug.cgi?id=2077906 On 4/25/22 11:39, Petr Menšík wrote: > Hello, > > I have sent already a notification about SHA-1 not validated in default > configuration. However that was not end of the story. > > A new and even more severe issue has arisen. Our crypto team is > responsible for preparing RHEL 9 for FIPS 140-3 certification. They said > there is legal obligation to stop using all RSA signatures with keys > shorter than 2048 bits. I expect many of you already know especially > Zone Signing Keys often use 1280 or even 1024b keys without issues. > > Current RHEL 9 validates such signatures well, but there is a bug [1] > filled to change that and start enforcing longer keys usage only. > Because it would be enforced at crypto library level (openssl), common > DNSSEC validation software would start failing. On quite a lot of > domains. And failing to resolve such names. > > I am looking for the best way out of this. Once the above happens > without any changes to used DNS(SEC) software, the only way to keep > working DNS servers working would be either turning off FIPS more or > DNSSEC validation. I know the result seems quite ridiculous, because all > this has been done in order to increase the security. The only > alternative without changes would be disabling all RSA altogether and > providing a long list of ECDSA trust anchors for TLD domains, where at > least ECDSA would offer protection. > > I think the only good way would be starting considering shorter keys as > insecure in FIPS mode. Anything above those domains would be without > DNSSEC protection, but at least single root key could be used. Do you > think it would be safe once the DS digest is checked on the key, that > key is then can be marked as insecure instead of bogus. Just as if the > algorithm were unsupported, but after checking the length of key. > Because the crypto library would refuse any operation, including > signature validation, on the given key. I think the library would not > even allow loading that key. > > I don't think described behavior is possible in any supported version of > BIND9. I expect it would require not only small and self-contained change. > Would you know any blockers, which would prevent behavior described in > the above paragraph? Is it possible to consider all keys with short keys > to become unsupported, but keys with long enough keys to be still > validated as usual? > > Note: some companies and agencies have to use only FIPS 140-3 approved > algorithms. Enabling FIPS mode in RHEL 9 is not optional for them. Fixing > the problem by disabling FIPS mode is not possible for everyone. > > Any comments or suggestions welcome. > > Best Regards, > Petr Menšík > -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@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
FIPS 140-3 mode on RHEL 9 and RSA validation of <2048 keys
Hello, I have sent already a notification about SHA-1 not validated in default configuration. However that was not end of the story. A new and even more severe issue has arisen. Our crypto team is responsible for preparing RHEL 9 for FIPS 140-3 certification. They said there is legal obligation to stop using all RSA signatures with keys shorter than 2048 bits. I expect many of you already know especially Zone Signing Keys often use 1280 or even 1024b keys without issues. Current RHEL 9 validates such signatures well, but there is a bug [1] filled to change that and start enforcing longer keys usage only. Because it would be enforced at crypto library level (openssl), common DNSSEC validation software would start failing. On quite a lot of domains. And failing to resolve such names. I am looking for the best way out of this. Once the above happens without any changes to used DNS(SEC) software, the only way to keep working DNS servers working would be either turning off FIPS more or DNSSEC validation. I know the result seems quite ridiculous, because all this has been done in order to increase the security. The only alternative without changes would be disabling all RSA altogether and providing a long list of ECDSA trust anchors for TLD domains, where at least ECDSA would offer protection. I think the only good way would be starting considering shorter keys as insecure in FIPS mode. Anything above those domains would be without DNSSEC protection, but at least single root key could be used. Do you think it would be safe once the DS digest is checked on the key, that key is then can be marked as insecure instead of bogus. Just as if the algorithm were unsupported, but after checking the length of key. Because the crypto library would refuse any operation, including signature validation, on the given key. I think the library would not even allow loading that key. I don't think described behavior is possible in any supported version of BIND9. I expect it would require not only small and self-contained change. Would you know any blockers, which would prevent behavior described in the above paragraph? Is it possible to consider all keys with short keys to become unsupported, but keys with long enough keys to be still validated as usual? Note: some companies and agencies have to use only FIPS 140-3 approved algorithms. Enabling FIPS mode in RHEL 9 is not optional for them. Fixing the problem by disabling FIPS mode is not possible for everyone. Any comments or suggestions welcome. Best Regards, Petr Menšík -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@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
