Subject: Re: bis inconsistency: grandparent problem

From: Robert Elz <[email-masked]>
Date: Fri, 01 Oct 2004 17:48:00 +0700

Date:        Thu, 30 Sep 2004 13:47:45 -0400 (EDT)
    From:        Samuel Weiler <[email-masked]>
    Message-ID:  <Pine.GSO.4.55.0409301343200.26585@filbert>

  | -protocol section C.8 suggests

Sorry, I'm not sure what doc you're meaning here (I assume, since your
message is cc'd to dnssec-editors, it is one of the "dnssec" type ones,
which I would rarely read), but this in your message caught my eye...

  | Section 4.2 of the same document suggests using NS queries.

Anything in any doc that is even suggesting that anything should ever
do an NS query (for any purpose other than debugging, or checking DNS
delegation consistency, etc) should be expunged from the face of the
universe as rapidly as we can find it.

NS records get used as a side effect of the normal lookup procedures,
they shouldn't ever be sought explicitly as part of any algorithm, doing
so requires guessing where zone cuts actually happen, for which there is
neither any sane method defined (until after the NS records are already
known anyway), nor any need.

kre

--
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: Samuel Weiler <[email-masked]>
Date: Fri, 1 Oct 2004 11:10:23 -0400 (EDT)

>   | -protocol section C.8 suggests

draft-ietf-dnsext-dnssec-protocol-08.txt

>   | Section 4.2 of the same document suggests using NS queries.
...
> NS records get used as a side effect of the normal lookup
> procedures, they shouldn't ever be sought explicitly as part of any
> algorithm, doing so requires guessing where zone cuts actually
> happen, for which there is neither any sane method defined (until
> after the NS records are already known anyway), nor any need.

Actually, DS, as the only RR type existing only at the parent side of
a zone cut, creates such a need to guess where zone cuts are.  There
is a method defined (in the -protocol document, sections 4.2 and C,8,
and in RFC3658, section 2.2.1.2); you can decide for yourself whether
or not it's sane.

This was introduced in response to the "DS grandparent" or "DS
ancestor" problem, a relative of another protocol bug, colloquially
called the "DS Lameness Bug", discovered during a workshop at ISI East
in August 2002.  The problem there was that properly-signed zones
could be (made) invisible to certain legacy resolvers.  It made
signing unsafe -- would you sign your zone if it meant you could
easily be knocked off the net?
http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01535.html

Unfortunately, the chosen fix to the DS Lameness Bug created a problem
when a zone and it's non-parent ancestor share an authoritative
server.  (ie. root-servers.net and the root being served by a server
that is not also authoritative for net)  We discovered that particular
ugliness in the fall of 2002, it got some airing at the workshop in
Atlanta, and version 12 of the DS draft proposed an algorithm for
addressing it.  Here's a lengthier discussion of it:
http://www.cafax.se/dnssec/maillist/2002-11/msg00030.html

And here's another proposed fix for both problems that was rejected:
http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01901.html
http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01663.html

-- Sam