Re: Transition from 2535 to opt-in

[Brian Wellington <Brian.Wellington@nominum.com>]

On Fri, 30 Nov 2001, Ólafur Guðmundsson wrote:

> At 06:51 PM 11/29/2001, Brian Wellington wrote:
> >On Wed, 28 Nov 2001, Olaf Kolkman wrote:
> >
> > > Hi Roy, Mark & David
> > >
> > > I think that the transition issues need some attention in
> > > draft-ietf-dnsext-dnssec-opt-in.
> > >
> > > I am afraid that an RFC2535 verifiers (not opt-in aware) will not be
> > > able to see the non secured part of an opt-in zone.
> > >
> > >
> > > An example of that:
> > >
> > > Assume my RFC 2535 verifier is configured to use "example." as a root
> > > of security (Trusted-key in named.conf speak) or more general the zone
> > > is marked secure by it's parent.
> > >
> > > If I do a query for QNAME=unsigned.example QTYPE=mx I will get an answer
> > > as in your's example A.1:
> > >
> > >          RCODE=NOERROR
> > >
> > >          Answer Section:
> > >          UNSECURE.EXAMPLE.      MX    ...
> > >
> > >          Authority Section:
> > >          SECOND-SECURE.EXAMPLE. NXT   EXAMPLE. NS SIG KEY
> > >          SECOND-SECURE.EXAMPLE. SIG   NXT ...
> > >
> > >          Additional Section:
> > >          EXAMPLE.               KEY   ...
> > >          EXAMPLE.               SIG   KEY ...
> > >
> > > Since there is no SIG on unsecure.example I must mark this RR as BAD
> > > and discard it. Hence all unsecured records are not visible to an
> > > RFC2535 verifier.
> > >
> > > As for possible transition scenarios I am afraid that there is no
> > > smooth transition possible; it seems to be a 'flag-date' thing.
> >
> >I don't think that this is a problem.  If a TLD is opt-in and a resolver
> >is not opt-in capable, it shouldn't contain a trusted-key for that TLD.
> >
> >Trusted keys (in BIND, at least) need to be explicitly configured, and
> >there's no reason to configure a trusted key for an opt-in zone if the
> >resolver doesn't support opt-in.
>
>
> What if resolver is configured with key for  "." which follows RFC2535.
> "." signs ".example" key, and ".example" is using Opt-in.
>
> Will a RFC2535 compliant resolver discard "unsigned.example."  as bogus ?

Yes.

> If the answer is yes, then we MAY be forced to put in policies like
> "RFC2535 zone can not sign KEY for Opt-in zones".

I don't think this is a good idea.  Then if .com was opt-in (which it
should be, since .com is the whole reason for opt-in), the root could not
be RFC 2535 signed.

There's also the problem that with the newest opt-in draft, there's really
no concept of the entire zone being opt-in or RFC 2535, but a distinction
per NXT.

> Forcing all Opt-in zones keys to be configured, preferably tagged
> as opt-in keys.

This was in an earlier version of opt-in.  I don't fully understand why it
went away, but also don't think it would help.  If an RFC 2535 capabale
resolver wasn't updated to support opt-in, it likely also wouldn't
understand that a key indicated opt-in.

> As the number of opt-in zones, hopefully, will be small and all of them
> highly visible.
> If only the REAL LARGE delegating zones use Opt-in, this might be
> tolerable pain.

Exactly.  Realistically, the only zones that will use opt-in should be the
big gTLDs, and maybe a few ccTLDs.  Even if the root is signed, it doesn't
make sense for anyone with a non-opt-in capable resolver to add the root's
trusted key to their server's configuration.

Brian



to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.