Subject: Re: was Re: Avoiding collisions

From: Paul Vixie <[email-masked]>
Date: Sun, 19 Sep 2004 03:54:32 +0000

ed lewis wrote, as his way of demonstrating that he has me in his KILL
file and hasn't read a thing i've posted to namedroppers this year:

> ...
> 
> So far just about all of the "complaining" (for lack of a better word)
> about zone enumeration seems to have come from large registries.
> Question: is zone enumeration a more general "problem?"

no.

> I ask this because if zone enumeration is only a problem for large
> registries, can it be assumed that a solution that is heavy-handed be
> acceptable?

yes.

> ...
> 
> Digging further, if the assumption can be made that the only
> organizations that will need to "defend" against zone enumeration are
> well-funded to do so, an approach like on-line signing appears to be a
> start to a solution.

exactly right.

if one principle of good engineering is to minimize cost in the average case,
then dnssec-bis is nearly complete as-is, and the only thing that's needed
is to ensure that online signing isn't a "white lie" but rather signalled
unambiguously in the protocol.  people who fear enumeration will use "views"
if they are a registrant (which they are already doing, according to me),
or online signing if they are a registry.  people who don't fear enumeration
will run vanilla dnssec-bis with no special stuff.  everybody will be happy
except the registry operators who didn't want to pay extra megabucks for the
online signing capability, and nobody will sympathize because we all know
they will just pass these costs on to the registrants, or reduce their
operating margins, or both.

--
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: Paul Vixie <[email-masked]>
Date: Tue, 21 Sep 2004 14:12:07 +0000

this was settled in RFC 2136.

> My point of view - I've not come across a zone that mixed classes. ...

1034/1035 were, as stated here recently and often elsewhere previously,
inconsistent in their treatment of classes.  half of the text indicates
that a multi-class zone can exist; the other half of the text indicates
that each class has its own delegation hierarchy with potentially unique
(within the class) zone cut boundaries, and its own set of root servers.

historically, BIND4 was similarly inconsistent.  which meant that neither
interpretation would fully work, and meant that in practice there could
only be one delegation hierarchy.  other classes were essentially hard
coded (for example, hesiod and chaos).  after some long talks with PVM
in which i learned that classes were a late editorial change rather than
an original basic idea of DNS, i decided that the separate-hierarchy
interpretation was the correct one.  BIND8 and BIND9 do classes that way,
though BIND8 doesn't support more than one class of roots so there's
still a lot of hardcoding to support multiple classes using BIND8.

this became very significant during the development of what's now RFC 2136,
and there was discussion in the DNSIND working group as to what multiple
classes meant, and the group's decision for the protocol echoed the one
i had made earlier concerning the BIND implementation -- each class has
its own delegation hierarchy.  you can see this all over RFC 2136 by noting
that it takes the tuple <zone,class> to denote a zone, not just a zone name.
you can also see it in section 7.1, which says:

   7.1. Using metavalues for CLASS is possible only because all RRs in
   the packet are assumed to be in the same zone, and CLASS is an
   attribute of a zone rather than of an RRset.  (It is for this reason
   that the Zone Section is not optional.)

so, from a protocol-lawyer standpoint, the question of whether a zone can
mix classes has already been settled.  it can't.  note that this simplifies
the wildcard algorythm by a lot.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 22 Sep 2004 16:28:52 +0000

> ...
> As far as on-line signing as an option, he replied that that was not a big
> deal for him.  "What's the difference between managing extra zone keys and
> managing TSIG keys for XFR's?"

word on the street is, online signing isn't allowed in the dnssec-bis spec.
given that i'd been presenting it as a workaround, i now apologize to all
for misunderstanding the protocol.  getting online signing of negative
responses would apparently require the same transition pain as NSECxx, so
we can stop talking about it separately, and fold it into the NSECxx thread,
which is blocked on a requirements definition, to which ed's words apply:

> I spoke with a person who used to be a DNS administrator at a well-known
> content provider (non-ISP, non-registry, etc.).  He told be that when he
> was at that job, he would not have been able to justify the deployment of
> DNSSEC because of zone enumeration.  The rationale for this is "the usual"
> - nothing other than not wanting to put certain information "so easily"
> available on the Internet.

---

From: Jim Reid <[email-masked]>
Date: Thu, 23 Sep 2004 10:26:01 +0100

>>>>> "Edward" == Edward Lewis <[email-masked]> writes:

    >> At 16:28 +0000 9/22/04, Paul Vixie wrote:

    Edward> What about a signed zone that is dynamically updated -
    Edward> doesn't that physically require on-line signing?

I suppose a throwaway zone signing key could be on-line for on the fly
signing of the updates and a strong key signing key kept off-line.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 23 Sep 2004 22:56:28 +0000

> What about a signed zone that is dynamically updated - doesn't that
> physically require on-line signing?

i meant online signing of negative responses, without precomputed NSECs.