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

Re: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN

On Wednesday, April 30, 2003, at 02:24  PM, Sam Weiler wrote:


On Wed, 30 Apr 2003, Roy Arends wrote:

Protection against your deletion ("spoof a zone out of existence") attack:
sign the delegated zone.

A secured delegation to an unsecured zone is as practical as an unsecured
delegation.
Roy,

As Dan so ably points out, signing a child zone won't protect it from
someone corrupting the NS glue, whether or not there's a DS in the
parent.  But adding the NXT to the parent, with or without a DS,
signals the existence of the delegation.  A client seeing an NXT at
least knows that the delegation exists.  It may not know how to find
it, for inability to get the glue or because it was fed bad glue, but
it knows that it's there.
in other words, you know that the parent thinks a delegation exists and have a proof there is now way you can every be sure you have reached a real server for that delegation. so what?

That's a different and more informative
failure mode, and there may be ways of recovering from it.
such as??

perhaps I'm not understanding your claim, but it reads to me as there may be some yet to be thought of way to use DNSSEC to help recover from errors reaching unsigned zones and we should not deploy opt-in because it may interfere with this yet to be thought protection for unsigned zones.

I view DNS security adding value to signed zones. if you want to avoid various problems, sign the zone.

using DNSSEC to try and recover from problems with unsigned zones is dangerous at best in my view. a system that adds value to unsigned zones is a different problem from DNSSEC and I have not seen any justification or even promising approaches that applying to DNSSEC to unsigned zones would be helpful. I would also say that trying to use the DNSSEC RRs to infer things about unsigned zones is something we should recommend strongly against (isn't one justification for changing the type codes based on the use of an NXT RR that can not be authenticated?)

Dan


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