--- Begin Message ---
I think the examples being used in this thread are too narrow. In RPZ a
firewall rule might trigger on something other than the QNAME. For
example the trigger could be one of the NSDNAMEs in the resolution path,
or on the address (A or ) associated with some NSDNAME in
On 2/8/24, 10:40, "dns-operations on behalf of Viktor Dukhovni"
wrote:
The chances of a remotely possibly event happening is 100% once it happens. __
So long as a hash is shorter than the data it covers, there's a chance there
will be a collision. Just a general statement.
>There is no
On Thu, Feb 08, 2024 at 12:24:08PM +, Edward Lewis wrote:
> Between non-unique key tags and the possibility of hash collisions,
> it's possible two DS resource records could share either a key tag or
> a hash representing different keys. From this, I wish we hadn't
> defined the key tag
In my data, I don't see the colliding key tags involved, but historically, RU
had two other keys share a key tag value - but not at the same time. Here are
parts of the data I have - the last shown field is the start of the public
key's bits (which show these are different keys).
Very interesting.
There have been two cases since 2011 of a TLD having two published DNSKEY
resource records sharing the same key_tag.
The first in 2018/2019 involved a TLD having a KSK and ZSK share. I didn't
notice while it was happening, but found it when testing some code I have to
--- Begin Message ---
On 06/02/2024 17.06, Peter Thomassen wrote:
Then, how to define a false positive rate?
Look at all blocked queries, and do a post-hoc investigation?
How about popularity -- should one factor in that blocking *.ddns.net
is more severe than blocking *.blank.page? I.e., is
On Wed, Jan 31, 2024 at 04:37:02PM +0200,
Phil Kulin wrote
a message of 56 lines which said:
> Done. New serial number 4058860. New active ZSK
> https://dnsviz.net/d/ru/ZbpWZg/dnssec/
There is now a detailed technical post-mortem. These official
explanations fit the facts that we observed.
