RE: MagicType draft

["Scott Rose" <scottr@nist.gov>]

> -----Original Message-----
> From: Samuel Weiler [mailto:weiler@tislabs.com]
>
> What does the auth server do when it's advertising (via DS/DS') that
> both kinds of non-existence proofs are available?  On name errors,
> return both a BERT RR and an NSEC RR (proving that the BERT RR doesn't
> exist)?  It doesn't know whether the resolver asking the query wants
> NSEC-type proofs or BERT-type proofs -- it has to provide an answer
> that works for both.  And that answer has to be completely
> backwards-compatible with DNSSECbis resolvers.
>
I don't know, kind of why I asked.  If I read that correctly, you believe
that magic type and DNSSECbis can't co-exist in a zone?  I think that might
be the case as well.  My comment was that it would be nice to have a way for
a DNSSECbis resolver to get/validate positive DNSSEC responses from a zone
that does magic type.  If we use an algorithm code in the DS, the resolver
will make the zone as "unsecure" (I hope) and continue, but be unable to
verify even if the response was positive and uses a RRSIG algorithm the
validator understands normally.

> I think the answer to Ed's question of "What happens if there is a mix
> of DNSSECbis and 'this method' keys in a DS set" is: the world ends.
> Depending on the resolver's mood, do something either kind and gentle
> (treat the zone as unsigned), colorful (treat the zone as not
> existing), or punitive (see draft-ietf-dnsop-bad-dns-res-03.txt, now
> in WGLC, for creative ideas).
>
> -- Sam
>


Scott


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