I would propose one line per protocol for disabled methods. This would
allow for easier log parsing
On 2022-09-13 06:28, Petr Špaček wrote:
On 02. 09. 22 15:49, Anand Buddhdev wrote: On 02/09/2022 13:53, Mark
Andrews wrote:
Hi Mark,
We don't log rsamd5 is disabled now ec or ed curves
> Can you propose log line?
>
> Should it be one line per algorithm? Or one line with all disabled? Or
> one one with all enabled? What log level? Log category? It it okay it
> will be almost always logging GOST? ...
I am not using Red Hat, but when debugging DNSSEC issues it would be helpful to
On 02. 09. 22 15:49, Anand Buddhdev wrote:
On 02/09/2022 13:53, Mark Andrews wrote:
Hi Mark,
We don’t log rsamd5 is disabled now ec or ed curves when they are
not supported by the crypto provider. Why should rsasha1 based algs be
special?
The problem I see with 9.18.6 is that at startup,
Mark Andrews writes:
> What records in paypal.com do you or your customers actually depend upon
> being signed? Paypal’s web servers depend on CAs not the DNS to provide
> trust anchors. It's not their SMTP servers as paypalcorp.com is not signed.
OK, let's just hope no CA runs Redhat then.
> On 5 Sep 2022, at 18:41, Bjørn Mork wrote:
>
> Petr Menšík writes:
>
>> It is suitable for all other algorithms so I disagree that
>> without algorithms 5 and 7 it is not usable at all. Majority of
>> secured domains use stronger algorithms already.
>
> Would it be the same if it worked
Petr,
care to prepare a MR for this? After all, it's RedHat who is making us all to
go through this mess.
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 5.
Petr Menšík writes:
> It is suitable for all other algorithms so I disagree that
> without algorithms 5 and 7 it is not usable at all. Majority of
> secured domains use stronger algorithms already.
Would it be the same if it worked for a majority of TLDs? Say "nz" as
an arbitrary example.
On 9/2/22 14:23, Bjørn Mork wrote:
Mark Andrews writes:
We don’t log rsamd5 is disabled now ec or ed curves when they are not
supported by the crypto provider. Why should rsasha1 based algs be
special?
Because RSASHA1 validation still is a MUST in RFC8624? MD5 is and ED is
not.
I don't know
On 02/09/2022 13:53, Mark Andrews wrote:
Hi Mark,
We don’t log rsamd5 is disabled now ec or ed curves when they are
not supported by the crypto provider. Why should rsasha1 based algs be
special?
The problem I see with 9.18.6 is that at startup, it is checking to see
if it can validate
Mark Andrews writes:
> We don’t log rsamd5 is disabled now ec or ed curves when they are not
> supported by the crypto provider. Why should rsasha1 based algs be
> special?
Because RSASHA1 validation still is a MUST in RFC8624? MD5 is and ED is
not.
I don't know if disabled EC curves is a real
We don’t log rsamd5 is disabled now ec or ed curves when they are not supported
by the crypto provider. Why should rsasha1 based algs be special?
--
Mark Andrews
> On 2 Sep 2022, at 20:37, Anand Buddhdev wrote:
>
> On 01/09/2022 23:19, Mark Andrews wrote:
>
> Hi Mark,
>
>> Yes. You will
On 01/09/2022 23:19, Mark Andrews wrote:
Hi Mark,
Yes. You will need to restart the server.
Okay, I'm trying out 9.18.6 on an Oracle Linux 9 server. When starting
BIND, it doesn't log anything about disabling RSASHA1. But when I query
it for ietf.org/SOA, I get an unvalidated response.
Yes. You will need to restart the server.
That all said if you are signing zones using RSASHA1 or NSEC3RSASHA1 you should
transition to a newer algorithm if you want to have your zone validated by as
many as possible.
--
Mark Andrews
> On 1 Sep 2022, at 22:59, Anand Buddhdev wrote:
>
>
Hi BIND developers,
The release notes for 9.18.6 say:
"The DNSSEC algorithms RSASHA1 and NSEC3RSASHA1 are now automatically
disabled on systems where they are disallowed by the security policy
(e.g. Red Hat Enterprise Linux 9)."
Does this happen at runtime when BIND starts?
If an
14 matches
Mail list logo
