at their
decisions are always the best.
Your truth? I believe you need to figure out that one yourself.
Just my two cents.
--
Med venlig hilsen / Kind regards,
Arne Jensen
they had the strongest
possible algorithms on it.
NB: The reason I'm writing 14 4, a.k.a. ECDSAP384SHA384 all along is
that I've seen DNSSEC signatures with 14 2 (ECDSAP384SHA256), which I
would find quite weird.
Just my two cents.
--
Med venlig hilsen / Kind regards,
Arne Jensen
quot;cloudflare.net" in this case.
Or if "cdn.cloudflare.net" had been a sub-delegation, then at that point...
--
Med venlig hilsen / Kind regards,
Arne Jensen
300 seconds TTL on ALL RECORDS that
are proxied through them (and cannot be changed for those). Even on
proxied records that have been the same for like 7 years, and easily
could have been 86400, or even longer (although longer might be ignored
by some resolvers). :'(
--
Med venlig hilsen / Kind regards,
Arne Jensen
t how to mitigate / override,
if necessary, - and not something you should potentially be reducing the
"security levels" from your end, to fix their (potentially crappy)
implementations.
That's just a few things you could look at fixing, which would
definitely be improving your *chan
(insecure) responses take effect anyway.
--
Med venlig hilsen / Kind regards,
Arne Jensen
Den 08-12-2021 kl. 16:23 skrev Masataka Ohta:
Arne Jensen wrote:
It is my understanding that the CNAME should never have been followed,
Wrong.
Hmm, okay.
-> https://www.rfc-editor.org/rfc/rfc4034.txt
Section 3, "The RRSIG Resource Record", at the third phrase:
Den 08-12-2021 kl. 15:32 skrev Niels Bakker:
* darkde...@darkdevil.dk (Arne Jensen) [Wed 08 Dec 2021, 15:23 CET]:
To me, that part of it also points towards a broken implementation at
CloudFlare, letting a bogus (insecure) responses take effect anyway.
Or they prefer allowing people to visit
8 matches
Mail list logo
