[Dnssec-deployment] Expired RRSIGs for .be
olaf at NLnetLabs.nl
Mon Oct 11 04:48:19 EDT 2010
On Oct 11, 2010, at 8:09 AM, bert hubert wrote:
> On Mon, Oct 11, 2010 at 01:35:02AM -0400, Paul Wouters wrote:
>> In the near future, they will notice the severe lack of emails from ANYONE......
> A word from the operational internet access provider world - as long as this
> kind of signature expiry thing keeps happening, validation will not be
> turned on.
Hey, a spokesperson ;-)
> A single customer outage interaction is costed at upwards of $10. Annual
> profits per subscriber are in the same dimension as that amount.
> So do not count on large scale validation to force people to clean up their
I agree with you. If the costs caused by false positives is outweighing the benefits from failing on true positives then the system as a whole will fail.
Since the benefits are long term and sometimes not immediately visible (I've put a lock on my bike and now I have not seen anybody attempting to steal it) while the costs of false positives are immediate and direct it is of importance to drive those false positive costs down.
In other words, still agreeing, there is some misalignment in cost and incentives: At the onset of deployment the validating side gets the support calls, the authoritative side hardly feels any damage. When DNSSEC is deployed wider, the authoritative side will suffer from loss of customers. I believe it will take a few years to reach that point. Until then my bets are on tools, documentation, and education.
> It is more the other way around, as long as DNSSEC causes outages for
> validators, commercial access providers will not turn on validation.
> I punted the 'negative/null TAR' idea at ICANN in Brussels where domains
> could centrally publish, in an authenticated fashion, that they've messed up
> their DNSSEC and would like a free pass instantly until they've figured it
I am not immediately enthusiastic. The idea introduces new code paths, and new things to troubleshoot when there are problems. And, introduces another attack surface. The scaling properties of a flat TAR, but more importantly the security policies surrounding registrations in this TAR, would probably only restrict this TAR to TLDs and fortune 1000.
I think offering a good set of tools to maintain zones, keys, and signatures including appropriate monitoring tools, and operational guidance, is the key here. With DNSSEC in place DNS operations have become more of a specialist trade. It used to be the case that DNS just worked, now you have to understand just a little more about the underlying timing effects. In other words authoritative serving of zones became a little bit more of a specialist job. By providing 'expert systems' we might be able to push DNS maintenance back to the most junior engineer.
Olaf M. Kolkman NLnet Labs
Science Park 140,
http://www.nlnetlabs.nl/ 1098 XG Amsterdam
More information about the Dnssec-deployment