Remarks on opt-in-09, was Re: Remarks on draft-stjohns-dnssec-sigonly

[Mike StJohns <Mike.StJohns@nominum.com>]

Sorry - I missed this section on a quick read-through, but the 
section isn't sufficient.

At 06:19 PM 12/20/2006, Roy Arends wrote:

> > The document is silent on the treatment of other records in the "opt in
> span".
>
> >From
> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt-in-09.txt
>
> 4.1.1.  Delegations Only
>
>    This specification dictates that only insecure delegations may exist
>    between the owner and "next" names of an Opt-In tagged NSEC record.
>    Signing tools MUST NOT generate signed zones that violate this
>    restriction.  Servers MUST refuse to load and/or serve zones that
>    violate this restriction.  Servers also MUST reject AXFR or IXFR
>    responses that violate this restriction.

There's a number of problems with the way this is stated.  Zones 
aren't actually signed - records are.  Zones aren't necessarily 
loaded monolithically.  For example, as I understand IXFR - you might 
not actually get all the right records during a given interaction to 
ensure this restriction is maintained.  The originating zone may 
maintain this set of restrictions, but the IXFR transaction isn't 
atomic to the zone so the receiving zone might only get part of the 
information (e.g. a new record is added to the gap, but the deletion 
of the optin NSEC isn't included in that specific transaction, or the 
optin NSEC is deleted before the addition of the in-the-gap 
records.)  And finally, people aren't protocol elements and may build 
zones by hand by adding records one at a time rather than loading the 
zone in its entirety.

What you really need to do here is state the behavior of the 
resolver, not of the server.

Consider a zone with opt-in with multiple servers using IXFR.
Consider a range in the zone from "optedout" to "pzone" with an opt-out nsec

Zone owner adds an A record "optedoutnew" to the zone at the master 
and re-writes the NSEC records
(So for some period of time the master and the secondaries are out of sync)

Depending on when a client asks the question, the client can be told 
that the answer doesn't exist (old optin NSEC), that it does exist 
(signed A record), or that it should exist but doesn't (new NSECs but 
no signed data).

It gets worse.  Say the client has the signed optedoutnew in its 
cache.  It now asks for "optedoutagain" and because of the vagaries 
of how DNS works ends up getting the old optin record (from a 
secondary with the original data) which says that "optedout" to 
"pzone" was empty - - but that conflicts with the cached signed optedoutnew.

What does the a caching name server with this data do when asked a 
question in this space?  If there's a covering non-existence NSEC, 
does a caching resolver even attempt to retrieve data in the covered 
non-existence arc?

One possible solution is something like:

a) All data gets cached for its TTL
b) In the conflict between validated existing data and non-existence 
proofs, the existing data is considered valid.
c) Validated existing data without related NSEC records is considered 
valid only for the specific RR type.
d) non-existence is only cached for a specific type and name queried 
and refers back to the NSEC - but the presence of the NSEC is never 
considered as negative caching for any other covered names.  (E.g. if 
you got a covering NSEC for asking about "foo" that also covers 
"bar", you still attempt to query for "bar" - each are negatively 
cached separately).

or something like this.


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