Re: Transition from 2535 to opt-in

[Ólafur Guðmundsson <ogud@ogud.com>]

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 ?

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".
Forcing all Opt-in zones keys to be configured, preferably tagged
as opt-in keys.
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.

         Olafur


         Olafur




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