Clear path requirement
Edward Lewis
At 17:08 -0500 11/20/02, Matt Larson wrote:
>I'm sorry, but I don't understand. BIND 9.2 is not DS-aware, so it
>can't be used as a recursive resolver to retrieve DS records. Even
>though it has support for unknown types, there'll be the problems that
>you pointed out in your recent posting on the DNSSEC list. And do we
>really expect someone to try to use BIND 9.2 as an authoritative server
>for a zone hosting DS records, again in light of the issues you pointed
>out?
A BIND 9.2 caching server might be in use on a proxy firewall. If a
BIND 9.3 resolver asks it for the DS set, the 9.2 can be forced to
"misbehave."
>I still think the need for a DS-aware flag is obviated by the flag day.
Hmmm, has anyone ever defined what is meant by a "flag day?" It's
not like the old days when we switched all of our routers from all
0's broadcast to all 1's broadcast.
>I think you're assuming that we'd require DS records whose owner name
>was mangled to be inserted in responses for other QNAMEs by a server.
>I'm pointing out that name-mangled DS records need not invoke additional
>section processing--all the knowledge of this could be done in the
>resolver. But maybe I'm just not understanding your comment.
If you are relying on using a query to a second name to get the
additional data, you will incur more round trips (times) to get the
answer. Not much detail in this answer.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-703-227-9854
ARIN Research Engineer
--
to unsubscribe send a message to namedroppe...@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
Sam Weiler
On Wed, 20 Nov 2002, Edward Lewis wrote:
>
> >I still think the need for a DS-aware flag is obviated by the flag day.
>
> Hmmm, has anyone ever defined what is meant by a "flag day?"
I presumed it meant "anyone signing with 2535 will potentially see
things break and they will stop signing with 2535 if that's necessary
to keep other things from breaking". Or "we can deprecate any and all
code that deals with 2535-signed zones". We can't assume all
2535-aware resolvers will go away, just like we can't assume that all
older resolvers will go away. At the time, I don't think we
recognized how interesting the legacy resolver interactions would be.
-- Sam
Paul Vixie
> >
> > Hmmm, has anyone ever defined what is meant by a "flag day?"
>
> I presumed it meant "anyone signing with 2535 will potentially see
> things break and they will stop signing with 2535 if that's necessary
i'm the one who keeps bringing it up so i'll say what i've been meaning
by the term "flag day." a flag day is when everyone who wants to continue
to have functionality of some type has to upgrade. ncp->tcp was a flag
day. sure, there were islands of ncp after the flag day, but none today.
when you make an incompatible change to the on-the-wire format of a
protocol, you invalidate a set of older clients. by "incompatible" i
don't mean breaking older implementations of a looser spec, nor anything
for which being liberal in what you accept is an antidote. i mean "the
people who had this functionality before the date, will have to change
their software or configuration in order to ever have it again after the
date."
in dnssec terms, we have at least one flag day coming, due to DS or whatever
we use instead of DS if we can't make DS work. the thing we don't know yet
is whether that will be our last flag day. why not? because we are still
doing basic research on what kind of data model will work for dns security.
after three or four times of saying "NOW we've got it, THIS TIME for sure"
there's finally some humility in the picture... "wonder if THIS'll work?"
for comparison purposes, it's hard (bordering on beyond impossible) to
imagine declaring another flag day for IPv6, such that all pre-flagday
implementations would become obsolete and incompatible until upgraded.
whereas, for DNSSEC, the opposite is far from false: it's impossible to
know how many more flag days we'll have before it's safe to burn ROMs
that marshall and unmarshall the DNSSEC related RR's, or follow chains
trying to validate signatures. it sure isn't plain old SIG+KEY, and
it sure isn't DS as currently specified. when will it be? we don't know.
what has to happen before we will know? we don't know that either.
right now i'm ready to treat "that was our last flag day" as a victory,
even if the specs and tools are a little rough on that particular day.
i'm interested in seeing a clear list of things that have to happen before
we will know what has to happen before our final DNSSEC flag day.
2535 is already dead and buried. there is no installed base. we're
starting from scratch. that's both a boon and a curse.