Subject: Re: NSEC+ and NO

From: Peter Koch <[email-masked]>
Date: Wed, 26 May 2004 09:42:49 +0200

[email-masked] wrote:

> But if I instead inserted:
> 
> 	a.example.	NSEC	a_.example.  ...	
> 	a_.example.	NSEC	a__.example. ... ; booby-trap
> 	a__.example.	NSEC	c.example.   ...
> 	c.example.	...
> 
> What if an explicit query to a_.example. triggered some kind of
> defensive response, such as a complete refusal to return the NSEC
> record?  In this example, because of the third NSEC, you would never get
> the booby-trap record except as the result of an attempt to walk the
> NSEC chain.

"NSEC" walking would usually not be done with explicit queries for NSEC RRs
(because that's too easy to answer with REFUSED, since there's probably no
need for those queries) but by asking for "random" names and interpreting
the NXDOMAIN responses (and the NSEC RRs therein). So, one wouldn't ask for
"a_.example." anyway but for e.g. the next name after "a_", say "a__".
Now you could protect this name by the booby-trap, but then I'd ask for "a___"
and the more traps you have the lesser NXDOMAIN responses you can really
support with NSEC, which sooner or later would hit an innocent requestor
who's not walking but just mistyped a domain name.

-Peter

--
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: Alex Bligh <[email-masked]>
Date: Wed, 26 May 2004 09:57:44 +0100

> the booby-trap record except as the result of an attempt to walk the

This only works if the querying person cannot distinguish the booby-trap
records (or those leading to them) from the real records. But you have
to (as you have illustrated) put your booby-trap records as close
as possible to the records themselves. For example if the records are:
	string.example	NSEC	string_.example
	string_.example	NSEC	string__.example ; booby trap
	string__.example	NSEC	struth.example
	struth.example...

then when you get the boobytrap result (for string_.example) you
just look up string_zzzzzzzzzzzzz.example instead, which will give you
a non-exist pointing to struth.example.

On a more theoretical level, what you are trying to do is introduce
small segments of the space "between" names that do not return useful
non-existence proof. You want to make that space as small as possible
in order that non-existence proof works elsewhere. But that makes it
trivially easy to ask instead for a name outside that small space but
in the larger space before the next "real" name.

Alex

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 26 May 2004 11:34:17 +0200 (CEST)

On Wed, 26 May 2004, Alex Bligh wrote:

> records (or those leading to them) from the real records.

note that the "person" will most probably be some sort of program.

> a non-exist pointing to struth.example.

you do not know if there are zero or more boobytraps in between.

this is in no way failsafe, but could probably be used to stop simple 
walking and plain enumeration by guessing labels. I think it should be 
explored further by those who might need it.

 	jakob

---

From: [email-masked]
Date: Thu, 27 May 2004 14:05:18 +1200

Alex Bligh <[email-masked]> wrote:
>non-existence proof. 

That's exactly what I'm suggesting.

>                      You want to make that space as small as possible

Is that actually the case?  Do we care about queries for domains that
don't exist?  Is there a problem with the following:

	a.example.	NS	ns1.isp.com.
			NS	ns2.isp.com.
			DS	...
			RRSIG	DS ...
			NSEC	a_.example. NS DS RRSIG NSEC
			RRSIG	NSEC ..
	b.example.	NS	ns1.isp.net.
			NS	ns2.isp.net.
			NSEC	b_.example. NS RRSIG NSEC
			RRSIG	NSEC ...
	d.example.	...

That is, if someone asks for foo.a.example with DNSSEC, they'll get a
referral with a signed DS record; if they ask for foo.b.example, they'll
get an referral with a signed NSEC record that securely marks the
delegation as insecure.

If they ask for foo.c.example, they'll get an NXDOMAIN.  Which is what
they'd have gut if DNSSEC wasn't in the picture.

In essence, only the parts of the zone containing the live domains
support authenticated denial; that is, from a registry's point of view,
we don't really care about what happens to a domain that doesn't exist
anyway, as long as we can give an authenticated "here is the DS record
for this delegation", or an authenticated "this domain doesn't have a DS
record".

Is this a compromise that will work for TLD registries?  Note that I'm
really focusing on registry domains; these have fairly specific
requirements (.museum notwithstanding).

-- don