It appears that Mark Andrews  <[email protected]> said:
>And when a single lookup results in nearly 100 fetches, results of which
>all need to be validated, that “It’s just one collision” really adds up
>fast if multiple validations strike it.  Lets say the zone for the nameservers
>for a zone has a single collision.  Thats 8 validation attempts each with
>a 50% verification rate on first attempt resulting in 8..16 crypto 
>verifications 
>for 4 servers with A and AAAA records.

With no collisions, you'd have 8 validations.  With a collision you'd have 16.

Where does the 100 come from? Sounds like another reason we need an 
informational
doc suggesting reasonable limits for validators.

R's,
John



































































>
>> On 14 Oct 2025, at 06:03, Philip Homburg <[email protected]> wrote:
>> 
>>> I think this is a false dilemma. There is more choice than just "no 
>>> document" or "a document prohibiting keytag conflicts".
>> 
>>> From the perspective of maintaining a validator I see it as binary:
>> - going from accepting zero collisions to accepting one or more collisions
>>  introduces complexity. Going from one to more than one has hardly
>>  any impact on complexity. So this is clearly binary. I don't really
>>  care about discussion whether we should accept one or two collisions.
>> - collisions are extremely rare. If you get two collisions then the chance is
>>  almost 100% that they were generated. So again it is binary. You accept
>>  zero collisions or you accept one collision. If you accept more than one
>>  collision it is just an invitation for attackers to DoS your validator.
>> 
>> 
>> _______________________________________________
>> DNSOP mailing list -- [email protected]
>> To unsubscribe send an email to [email protected]
>
>-- 
>Mark Andrews, ISC
>1 Seymour St., Dundas Valley, NSW 2117, Australia
>PHONE: +61 2 9871 4742              INTERNET: [email protected]
>


_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to