[dns-operations] 10% was Re: .mm ....

[Warren Kumari]

On Jan 21, 2013, at 5:26 AM, Jaroslav Benkovský <jaroslav.benkovsky at nic.cz> wrote:

> On 01/19/2013 09:28 PM, Matthäus Wander wrote:
>> I think it's more like "I'll tolerate an expired signature for 10% of
>> the original validity period and use that extra time to let other people
>> notice and fix it".
>> Assuming that 1) the majority of validators do *not* tolerate expired
>> signatures and 2) most DNSSEC failures are fixed within that 10%, it is
>> a way to trade off reliability vs. security.
> 
> That's rather reminiscent of parents who don't get their children
> vaccinated for fear of side-effects and instead rely on *other* children
> being vaccinated.
> 
> Being tolerant to garbled input is what caused the sorry mess of HTML,
> with its quirk parsing modes and incompatibilities.

Hmmm…

So, the issue is folk not resigning before the expiration.

Some resolvers are "loose" -- they stretch the expirations.
Other, more strict implementations mark the domain as bad when it expires -- this causes fallout / press / messages on dns-ops, and the domain admin notices and resigns.

This makes the loose implementations look "better" -- folk running the loose implementations avoided having thier customers get grumpy, saved the cost of support calls, etc.

So, basically the "loose" implementations are relying on the "strict" implementations to signal the domain admin (out of band) to resign.
This negatively affects the reputation of the strict implementations and, eventually, we may run into an issue where the loose implementations all increase the slop factor to look "better" than their competitors…

So, basically what is needed is a strong, out of band signal to the operators to resign… It seems that the only reliable way to do this is for the domain to go dark for some (non-insignificant) portion of users -- this triggers "Where the hell did my traffic go?" questions from the web server operators, news articles and eventually the pointy-haired boss types waking down the stairs and shouting….

So, obviously what is needed is a way to trigger these  sorts of responses, but without creating as much of an incentive for loose implementations  and slop factors…
So, here is my proposal:

1: Everyone does strict implementations.

2: When the signature expires everyone does the following:
A: You calculate by how much the zone has expired, normalize it, then multiply by 255 and call this EXPIRED-AMNT.
B: You take the primary IP of your recursive server, hash it, take the last octet of the hash and call it REF-HASH.
C: You hash the label of the zone apex, take the last octet and call it  ZA-HASH.

Now, if REF-HASH - ZA-HASH < EXPIRED-AMNT you can still answer the query. This means that initially only 1/255 resolvers will view the zone as bogus, but as time goes by (up to double the validity interval) more and more resolvers will mark it bad. This allows for increasingly strong signals to the operator, but doesn't favor any one implementation….

You're welcome…
W

(Mumbles something about job security, then runs off, giggling madly…)





> 
>> It's not cool to be one of the few resolvers suffering from DNSSEC
>> configuration errors that other people caused, while all the
>> non-validating resolvers seem to work fine. The security benefit is
>> hardly noticed by users outside of the DNS community as long as
>> applications are not showing green DNSSEC icons or other gizmos.
> 
> I used to work for the first major ISP here that switched DNSSEC
> validation on, so I can only commiserate with you :).
> 
> 
> Jarda Benkovsky
> 
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
> 

-- 
Do not meddle in the affairs of wizards, for they are subtle and quick to anger.  
    -- J.R.R. Tolkien