Subject: Resolver efficiency - a NEW technical argument

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 17 Jan 2002 09:28:39 -0800

All,

	So far the discussion has centered on the operations center side
issues for OPTIN. There are also efficiency benefits on the resolver side.

	The point is that with a sparsely secured zone OPTIN NXT records may
be cached. If the cache tracks the fact that signature validation has taken
place, that may also be cached. Thus the cost of supporting OPTIN in the
servers is reduced to a factor roughly proportional to the proportion of
secured names in the zone rather than a fixed overhead on every lookup.

	This might have a significant impact on uptake of DNSSEC at the
resolution end. Although the impact of DNSSEC on modern hardware is not
high, many installations do not use modern hardware. DNS load can often be
easilly supported on an ageing Sun SLC that would otherwise have gone in the
skip.

	Deployment of DNSSEC on the servers will take considerably longer if
it requires new hardware to be purchased, particularly in the initial stages
when uptake is low. There is a potential chicken and egg problem in which
people don't deploy DNSSEC until the servers do and vice versa.

	For example say we were running DNS on 10 year old Sun SLC. The load
is low and so even though the machine only has a 20MHz processor lookup
latency is acceptable. Turning DNSSEC on forces the server to do a signature
validation on practically every lookup, even if the number of secure zones
will initially be negligible.

	With opt in however the impact of DNSSEC is very much lower. Say
there are 10 million dotcom names of which 1,000 are secured. The server
looks up 10,000 unique names each day but only needs to check 1000
signatures at worst to respond to queries for insecure zones.

	People are more likely to deploy DNSSEC lookups despite sparse
deployment if the impact is small. There are a lot of ISPs etc where we need
to persuade them to deploy DNSSEC on lookups even though they may not secure
their own zone (or even have a proper zone of their own).

		Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
[email-masked]
781 245 6996 x227

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 17 Jan 2002 19:12:38 +0100

On Thu, 17 Jan 2002 09:28:39 -0800
"Hallam-Baker, Phillip" <[email-masked]> wrote:

> issues for OPTIN. 

No the discussion hasn't centered on that; my, previously voiced,
worries are about cost/benefit at the resolver side.

> There are also efficiency benefits on the resolver side.

I agree with your analysis with respect to increased load.  Although
my feeling that the costs involved in training somebody to deploy at
the 'client' side is probably more than upgrading to a new machine.

Operational deployment of DNSSEC in resolvers involves understanding
and errors will be made that will render parts of the tree invisible,
misconfigured secure entry points and such. I still think introducing
granularity will increase the complexity for the guys that have to
operate the client side.

The 'delegation only' compromise still addresses your worries as well
as mine.

--Olaf

P.S. Although I am still digesting it, I liked your "statement of
work" posting. Do you have references available to the "European Space
Agency requirements analysis methodology and the SAS 70 audit method",
such as books or the like?

--------------------------------------------| Olaf M. Kolkman
                                            | www.ripe.net/disi

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.