Subject: Re: On dynamic NSEC

From: Paul Vixie <[email-masked]>
Date: Fri, 12 Nov 2004 01:00:47 +0000

> > ... your argument pertains to a zone signer, which changes zone
> > content. in the case of an on-the-fly signer, which does not change
> > zone content, it is very possible to get exactly the treatment we'll
> > probably want, without invalidating any conforming clients of the
> > dnssec-bis protocol.
> 
> Assuming we cache NSEC records, which is presumably desirable, what
> prevents a caching resolver relying on a cached NSEC to fail to match
> an otherwise closest enclosing wildcard?

caches don't match wildcards.  only an authority server can do that.
otherwise a server who had cached "*.dom" and "foo.dom" might decide
that a query for "bar.dom" matched the while card, even if in the
authority server, "bar.dom" actually exists.

(not that a synthetic rr would have a nonzero ttl in the first place.)

> I agree if there is a hole in the original spec (i.e. the original
> spec is too prescriptive) we can drive a truck through it, but I thought
> the original prescription that NSEC records only exist where other
> non-NSEC labels exist was there for a well-defined reason (so not to
> break wildcards) - IE I don't think this /is/ a hole.

nope.  it was an oversight.  at least two editors admitted this to me in
person when i said "hey wait, we can't ship this to the iesg without
relaxing the parts that proscribe synthetic epsilon-named nsec rr's" but
the second of the two was able to explain how, actually, we could and must.

--
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: Paul Vixie <[email-masked]>
Date: Fri, 12 Nov 2004 17:34:37 +0000

> > ...
> OK. Let me simplify a bit, drop the caching nameservers:
> 
> Take a zone example.com:
> *		MX	foo
> bar		MX	baz
> dummy		NULL
> dummy2	TXT	"fred"
> 
> It uses NSEC epsilon.  That means for every possible label, there is a
> synthetic NSEC record, and per Rob's proposal, also a synthetic NULL
> record.  Synthetic I am taking to mean "not in the original zone
> loaded into the nameserver, but created algorithmically so it appears
> under all other circumstances to be in the zone"

with the proviso that i didn't understand the need for a NULL RR, i'm
tracking you so far.

> I then make the following queries:
> 1. type=NSEC, label=xxx.example.com
> 2. type=MX, label=xxx.example.com
> 3. type=ANY, label=xxx.example.com
> 4. type=MX, label=dummy.example.com
> 5. type=MX, label=dummy2.example.com
> 
> What do I get?
> 
> Surely type 1 HAS to return (at least)
> 	xxx	IN	NSEC	S(xxx)
> or the whole epsilon NSEC stuff doesn't work

given that there is a wildcard, there will be no NXDOMAINs for this zone.
therefore every NSEC will have a real owner name.  so, i'm with you so far.

each of queries (1), (2), and (3) will produce the same NSEC result, but
with different RRtypes claimed at the ownername.  which is another very fine
reason why client-side negative caching based on previously cached NSEC RRs
won't work, and thus i renew my claim that wildcarding should be done on the
client side rather than the server side.  (but that's a different windmill.)

> Surely (2) is indistinguishable from (4) if there is a NULL record
> synthesized?

i don't know why you'd ever synthesize a NULL RR.  i don't like NULL RRs at
all, but in your example you made the NULL RR a real RR, not a synthetic one.
therefore query (4) would get a NOERROR/NODATA reply and the wildcard would
not be part of the choice of what to return -- because the qname actually
does exist.

> Surely (2) is indistinguishable from (4) and (5) unless NSECs are
> processed differently from NULL's in the wildcard algorithm?

response to (5) would be NOERROR/NODATA as with (4).  i appear to be lost.
can we have this discussion over again, except this time can you do it without
the synthetic NULL RRs, and can you explain the non-dnssec parts of each reply
so i'll know what covering dnssec metadata will be applied?

---

From: Paul Vixie <[email-masked]>
Date: Sat, 13 Nov 2004 20:43:51 +0000

> ...
> With epsilon signing, there is an NSEC record for every possible label
> query (either synthesized or not).

no, it matters whether it's synthesized or not.  if there's a real nsec rr
then it would have an impact on the wildcard search algorythm.  a synthetic
nsec rr, being made from whole cloth, can be defined as having no impact on
the wildcard search algorythm.  this is possible only because the synthesis
and the wildcard search are both done in the authority server.

> ... The solution of course is for the server NOT to count NSEC records
> (or at least synthetic NSEC records) as closest enclosers.

yes.

> If no NSEC records are considered closest enclosers (at least for
> QTYPES other than NSEC), then 2.3 can be dropped in its entirety as
> far as I can see, and this also helps with some of the arguments
> against hashed NSEC' sharing the same namespace and interfering with
> wildcards.

not unless the hashed nsec's were synthetic.  we REALLY needed slabs before
security, to keep all the security metadata completely out of the dns world
view.  if you want to define NSEC2/NSEC3/whatever as having no effect on the
wildcard search algorythm, you'll have to do so explicitly, and carefully.

> Perhaps I'm making some mistake here.

your thinking on this topic is very creative.  i'm only able to fault you
on matters of terminology and for occasionally forgetting which constraints
will be in effect under which circumstances.  please do continue.

> My point to Rob was that adding NULL RR's to give technical
> conformance of synthentic NSEC's to 2.3 does not help as they equally
> break wildcards and cannot be excepted in the same manner from closest
> encloser rules (i.e. it makes things worse).

i don't think rob intended his offhand mention of NULL RRs to be given as
much scrutiny as you have done.  if it's not a helpful approach, abandon it.

---

From: Paul Vixie <[email-masked]>
Date: Sun, 14 Nov 2004 20:02:36 +0000

> > then it would have an impact on the wildcard search algorythm.  a
> > synthetic nsec rr, being made from whole cloth, can be defined as having
> > no impact on the wildcard search algorythm.  this is possible only
> > because the synthesis and the wildcard search are both done in the
> > authority server. [1]
> 
> OK. I am now going to play your game of driving a truck but this time
> through a hole you created :-) If you are correct with [1] above, and
> there is no reason to doubt you,  ...

every extension to every protocol relies on creative interpretation of
what were previously undefined or illegal symbol patterns.  EDNS depends
on ADCOUNT>0 in initiatorgrams (queries, updates, etc), which was not a
legal pattern in DNS.  once you've figured out a way to signal something
that will only be visible and valid to participants who understand it,
you've got your loophole.  everything after that is just whiteboarding.

>                             ...  then your assertion works because
> the epsilon NSECs are created by the authority server according to
> a specific algorithm. Provided that the algorithm is used, the resolver
> would have no way of telling whether they are in fact synthetic NSECs,
> or whether they aren't.

now you're getting into the spirit of this thing.  welcome to the dark side.

what you have to define is how the authority servers will act.  given dns's
insane notion of authority-side-synthesis for wildcards, you just have to
make sure that the synthesis of wildcards and the sythesis of NSECs are done
in a way that queriers see what you want them to see.  it will require that
all authority servers for a given zone understand the same zone semantics,
but DNSSEC-bis also has this requirement, so extending it to cover synthetic
NSEC (and later, DNSSEC-ter) is completely reasonable.  you may have to add
some kind of format versioning, so that old-semantics authority servers will
refuse to load and serve new-semantics zones.  (we didn't do this in
DNSSEC-bis, and a lot of master/slave relationships are going to become
stressful as a result.)

> So, for example, the zone I create and give to the authority server
> could have (and I'm assuming S(foo)=foo\000, S(foo\000)=foo\000\000 etc.)
> 	*		IN	MX	2.2.2.2
> 	foo		IN	A	1.1.1.1
> 	foo		IN	NSEC	foo\000		[A]
> 	foo\000	IN	NSEC	foo\000\000		[B]
> 
> The authority server would produce synthetic NSECs (for instance
> 	foo\000\000	IN	NSEC	fooo\000\000\000	[C]
> 
> But I can't see a resolver can tell the difference. That doesn't matter
> because (as you say) the wildcard search (which is the only thing it
> matters to we think) is carried out on the authoritative server.

yup.  being able to take advantage of the authority-side wildcard synthesis
insanity is a wonderful benefit after all the pain and cost that's been paid
by DNSSEC for said insanity up until now.

> Now given these NSEC records have to be signed, there is nothing (it seems
> to me) to stop us saying hashed NSEC' records are the same. They could all
> be created on the authoritative server, and all signed on the authoritative
> server. In that way, the authoritative server can exclude them from the
> wildcard lookup algorithm.

yes.

> And if that's the case, then you can use the same argument I've used above
> to say that NSEC' records could IN FACT not be synthesized - they could
> come from the original zone, and still omitted from the wildcard lookup
> algorithm - the resolver wouldn't be able to tell the difference.

yes.

> IE, if you can get away with an authoritative server treating synthetic
> NSEC epsilon records differently in terms of the wildcard lookup
> algorithm, then as far as I can see, logically the same must be
> true of non-synthetic NSEC' hash records.

yes.

> In which case we know that removing the requirement in 2.3 and amending
> the wildcard search algorithm to remove hashed NSEC' records is not
> going to be problematic.

right.

> I would add that you might as well remove the requirement for NSEC
> records (as opposed to hashed NSEC' records) to be treated that way,
> except that in the above example there is I suppose a theoretical need
> for a QTYPE=MX query on the zone to produce a different result for
> QLABEL=foo\000 and QLABEL=foo\000\000 (as only one is synthetic).

also, it's too late.  this is one of many ideas that might have improved
DNSSEC-bis but would have added more years to its schedule, so while we
will miss the functionality, we will not be sorry we shipped without it.

> [Note, side argument: I am not sure that we should not in that case not
> have put a note to the effect that resolvers should not rely on servers
> following 2.3: just as we are driving a truck through what we think
> an open hole in that 2.3 can be violated because the resolvers must
> fulfil other parts of the specification and not, for instance, do
> their own local optimizations for wildcard searches by relying on
> (say) cached records, others writing from the resolver end may conclude
> that in fact THAT restriction is a whole in the spec THEY can drive
> a truck through because it doesn't matter if they violate rule (X) because
> all servers will be following the restrictions in 2.3 so breaking
> rule X won't damage anything will it? - visions of 2 trucks driving
> through dark holes and colliding in the middle]

the DNSSEC-bis documents overspecify a number of things, including this,
and i expect they will be edited to be more minimal before they can reach
the next bus-stop on the standards track.