Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag

From: Paul Vixie <[email-masked]>
Date: Wed, 26 May 2004 05:13:00 +0000

>     Roy> So a simplified NSEC2 that prohibited wild cards in the zone
>     Roy> might well satisfy the concerns of the vast majority of TLD
>     Roy> operators, and perhaps others, too.

last time this was proposed, i wondered whether use of such signalling
on a zone that actually did have a wildcard would be "invalid," and who
would be hurt by it if a zone was published that "invalid" way, and
whether validators, if among those hurt, could even detect the condition.

in other words, would we be providing a way to turn on both the heat and
air conditioning at the same time, or is there an interlock preventing this?
and if there's no interlock, who pays the cost of all the wasted energy,
or does the house just blow up, and are my children in it at the time?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Wed, 26 May 2004 11:48:10 +0200

> > One ccTLD operator I've talked to has said that their views are pretty
> > well covered by what Nominet people on this list have expressed so 
far.
> > I agree that it would be good to have explicit reactions from the TLD
> > operators.
>
> In terms of European (by which I really mean RIPE area) ccTLDs, you
> are probably best asking this at some CENTR event. I am not sure a
> large number of ccTLD people are on this list, and even to the extent
> they are, they are probably technical people rather than technical plus
> policy people.

Perhaps this link might illustrate the magnitude of the issue within CENTR 
area:
http://www.centr.org/technical/zone-access.html

Regards,
Marcos

---

From: [email-masked] (Geoffrey Sisson)
Date: Wed, 26 May 2004 18:24:32 +0100 (BST)

Jim Reid <[email-masked]> writes:

>                               For instance, I can understand why DeNIC
> wouldn't want random users to be able to slurp the 1GB or so of the
> .de zone, guzzling bandwidth and needlessly loading the TLD's name
> servers.

The same `random users' which might be interested in `guzzling
bandwidth' with zone transfers will probably also be interested in
using scripts which effect NSEC RR elaboration, with even more
deleterious impact on resource utilisation.  This is of course also
possible with NSEC2 RRs, but will probably be interesting only to a
significantly smaller audience.

Regards

Geoff

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Thu, 27 May 2004 11:30:11 +0200

> > Point taken. However, I think these TLDs aren't placing the zipped
> > zone at everyone's disposal via anonymous FTP either.
>
> well, they ought to.

In virtue of what?

Regards,
Marcos

---

From: [email-masked] (Geoffrey Sisson)
Date: Thu, 27 May 2004 10:52:01 +0100 (BST)

Paul Vixie <[email-masked]> writes:

> but i guess every generation wants to learn that security through obscurity
> is an illusion, the hard way.

NSEC2 RRs are intended to prevent the zone from being _trivially_
elaborated.

It's one thing to park a car unlocked with the keys in the ignition;
it's another to park it in a garage, lock the doors, and remove the
key.

Also, NSEC2 uses strong encryption, so it isn't entirely justifiable to
charactarise it as security through obscurity.

Regards

Geoff

---

From: [email-masked]
Date: Thu, 27 May 2004 14:02:00 +0000

> charactarise it as security through obscurity.

	DNS use of "strong encryption" is not to provide
	confidentiality.  We're not hiding anything here.
	We're providing integrity.

--bill

---

From: [email-masked] (Geoffrey Sisson)
Date: Fri, 28 May 2004 12:48:43 +0100 (BST)

Robert Elz <[email-masked]> writes:

> The extra load of some number of random people doing zone slurps
> (especially using an NSEC type technique, where each subsequent query has
> to wait till the reply to the former is received, as that's where the
> qname for the next query comes from) when compared to the normal load on
> a busy server of handling "normal" queries (the ones that succeed, and
> even more, the ones that end up failing) is barely going to be noticeable.

It would be surprising if NSEC RR elaboration techniques didn't
incorporate considerable parallelism, especially for large zones.  This
could impose arbitrarily high loads on a busy nameserver.  For example,
multiple simultaneous elaborations could be run, one starting at
'aaa.co.uk', another starting at 'aab.co.uk', and so on.

This isn't idle speculation: prior to incorporating token bucket into
the WHOIS server at whois.nic.uk [note: reference to WHOIS for
illustrative purposes only!] we used to have a one-second sleep to
limit the impact of scripts.  Impatient data miners designed tools
which sent queries in parallel -- sometimes hundreds per second -- in
order to collect data at higher rates.  The consequences to server
performance were, well, predictable . . .

Regards

Geoff