[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Q-10: Reaction to "Silly" NXT's



On Tue, 27 May 2003, Edward Lewis wrote:

<snap>

> When a verifier sees a 0 in EITHER the NXT OR the SIG positions, the
> verifier will take corrective action.  This proposal recommends the
> following action be specified as a MUST:  the verifier will first
> validate the NXT according to local policy, with the intent that the
> presence of the DS RR at the parent points eventually to a zone key
> that verifies the SIG (NXT).  Once the NXT is proven valid, the
> verifier then treats the remainder of the query as if the DS RR did
> not exist - essentially treating the query as traversing through or
> being answered from an unsigned zone.

Okay:

So we have

a.example. IN A
a.example. IN SIG (A)
a.example. IN NXT  d.example. A SIG !NXT     ; aka silly state
a.example. IN SIG (NXT)
b.example. IN A
d.example. IN A
d.example. IN SIG (A)
d.example. IN NXT  example. A SIG NXT
d.example. IN SIG (NXT)

One queries for (b.example.,A,IN,dnssec-ok)
Response:

   NOERROR
   b.example. IN A
   a.example. IN NXT d.example. A !nxt !sig
   a.example. IN SIG (NXT).

corrective action:
   verify NXT record by verifying SIG(NXT). NXT record is okay: remainder
   is unsigned, i.e. b.example. IN A is treated as unsigned.

> Discussion.
>
> There are four options I have considered for a reaction to a silly
> state NXT.  One is to "fall back" to unsecured DNS, which is what I
> have chosen to propose.  The rationale is that this permits
> enhancements to happen, if they prove to be beneficial.  I did not
> pick this because it resembles opt-in, as some have noted.  Although
> it resembles opt-in, it is not opt-in as that has more rules and
> considerations to follow.  I.e., this proposal does not cover the
> rules of generating silly state NXT's - they are forbidden in the
> First Rule.

Okay,

Essentially you propose to have corrective action ('treat as unsecured')
in case of silly state (NXT or SIG bit = 0).

I support this proposal !

Roy

Déjà vu encore une fois

--
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/>