Subject: Re: type codes (Re: wildcard optimization and b/w incompatibility )

From: Jaap Akkerhuis <[email-masked]>
Date: Fri, 22 Nov 2002 04:21:26 +0100

PS (non US) The A-Team was a TV show in the 80's where a band of ex-military
    misfits solve problems with wierd plans that always worked, no matter how
    silly/crazy/outlandish.

The show hit Europe as well. We get the best of american culture:
A-team, McDonalds, etc :-).

Yes, I too have always wondered why people are so hang-up on
compatabilaty with 2535, a propossed standard, hardly been deployed
and according to the rules should not be deployed for disruption-sensitive
producting work. (RFC 2026, secton 4.1.1).

	jaap

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 21 Nov 2002 22:52:00 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Scott" == Scott Rose <[email-masked]> writes:
    Scott> But I still have some doubts.  That will help identify the "true" security
    Scott> aware servers/resolvers, but will it help the problem of a non-DS aware
    Scott> cache between the resolver and authoritative server?  If a recursive
    Scott> forwarder doesn't know where to ask for the DS record, it doesn't matter
    Scott> what the type code is.

  Bingo.

  Fundamentally, both DS and pre-DS KEY are broken because they are defined to live
in the parent zone. (SIG is even more bizarre...)

  As such, they need specific behaviour to make them work with caches that
are unaware of their special nature. 

  pre-DS KEY lived in both places, but like NS, the child is considered the 
authoritative respository for the record and the parent just has some
"hints". 

  We could have solved this by having the child pull the records out of the
parent zone, and then insisting that the parent has to maintain the old
KEY/SIG records for some long time.
  This could work, and with a lot more thought I think that we can make the 
KEY rollover work as well.

  However, I think that DS is probably a good seperation for zone cuts.
If we can simply make the child pull records from the parent again, then we
might find a resolution to this problem. The stub zone stuff that bind has
might be a good model - pull it down when you can and save it. 

  If you are offline and can not speak to the zone's parent during a key
rollover is a clear problem here.

  So, we either find a way to put the DS record CLEARLY in the parent, or
a way for the CHILD to get a copy of it.

  BTW: NS also lives in both places, BUT, we don't have failures if the
child and parent disagree. In fact, this is often a feature for some.

    Scott> Scott
    Scott> PS (non US) The A-Team was a TV show in the 80's where a band of ex-military
    Scott> misfits solve problems with wierd plans that always worked, no matter how
    Scott> silly/crazy/outlandish.

  _I love it when a plan comes together_
  I watch it more often than I'd like to admit... 6pm on DejaView.

]                   At IETF55 in Atlanta, GA                    |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] printk("Just another Debian GNU/Linux using, kernel hacking, security guy");[