Subject: Zone secure bit

From: Edward Lewis <[email-masked]>
Date: Mon, 10 Apr 2000 16:04:39 -0400

I am rewriting a draft on zone's security status and have a question for
which I'd like some feedback.  Without going into gory details and special
cases, which is preferred:

1) A proposal to use the KEY RR bit in a delegation points upper NXT to
signify a signed child zone key and to do away with the use NULL keys
altogher.  E.g., if the child's zone key has been signed by the parent, the
bit is on, the child's key is optionally held by the parent (recommendation
is not to).  If there is no signed zone key for the the child, the bit is
zero, and neither the parent nor child holds a signed NULL key.  In this
case, the KEY RR bit in the upper NXT signifies whether or not the zone is
secured.

2) The previous proposal plus the option that the parent may choose to hold
and sign a NULL key for an unsigned child.  In this case, the KEY RR bit in
the upper NXT signifies that "there is a key for the child somewhere."

3) No changes to 2535.

Case #1 is cleaner than case #2, but case #2 offers backwards compatibility
to the early DNSSEC software.

Case #3 is offered to those who don't agree with any of this.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

"Trying is the first step to failure." - Homer Simpson
"No! Try not. Do... or do not. There is no try." - Yoda
"It takes years of training to know when to do nothing" - Dogbert 1/21/00

Opinions expressed are property of my evil twin, not my employer.

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Brian Wellington <[email-masked]>
Date: Mon, 10 Apr 2000 17:19:42 -0400 (EDT)

> the upper NXT signifies that "there is a key for the child somewhere."

I agree with #2, with a small modification - the KEY RR bit signifies that
the parent has signed a KEY set for the child.  There's no reason for the
parent to insert a NULL key for an unsigned child, since if a resolver
obtains (and verifies) the child's KEY set, it can easily notice if there
is no zone key present and determine that the zone is not signed.

Brian

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 11 Apr 2000 08:43:31 +0200

One of my fundamental gripes with NXT is the fact that we've now enshrined
a situation where there are 2 records that say "name NXT bitmap name",
where BOTH are "valid", they are NOT part of the same RR set, and they live
on different servers, but the caches aren't smart enough to know which to 
cache, so you have to do special gymnosophistry to get the "right" one.

Having the security status interpretation depend on this ugliness seems to
me to be a considerably less elegant "solution" than the NULL KEY record.

My vote for #3.

                          Harald
--
Harald Tveit Alvestrand, EDB Maxware, Norway
[email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Tue, 11 Apr 2000 09:09:28 -0400

>My vote for #3.

Here's a comparison of option 1 & 2 and 3.

Options 1 and 2 complicate the processing of NXT's, which are already a
dicey proposal.  (More on that later.)  The complication is:

1) The setting of the bit (in the parent zone) depends on the previous
setting, not on types currently present.  Mitigating this is that at a
delegation point, there should only ever be a few types - NS and the
DNSSSEC types, KEY, SIG, and NXT.  'Course future types could be here.  So,
we're talking a difference of either "NS KEY SIG NXT" or "NS SIG NXT" at
the delegation point.

2) Having two NXT sets at a domain name is a problem, one that is
independent of this change.  (More later.)

3) These options request a change in the dynamic update rule against
changing NXT's.  When a key is validated for a child, the parent zone needs
to be updated to reflect this.  Dynamic update is a convienent mechanism
for this.

However, options 1 & 2:

1) Eliminate the need for the parent to ever have a key set for the child.
Currently, for an unsecurable child (which will be the majority of zones at
least in the near future), a delegation point is:

       name NS
            NS
            KEY  <NULL>
            SIG  KEY
            NXT
            SIG  NXT

Making use of the bit makes this:

       name NS
            NS
            NXT
            SIG  NXT

The big motivation has been to reduce the status of a zone to a binary
question (secured/unsecured), which can be represented in a bit.  A signed
NULL KEY could be on the order of a 100 bytes (estimate).  Such a savings
is significant to the upper zones - which are crucial to the roll out of
DNSSEC.

Now, on the evil of NXT's.  Many folks don't like them, but no one has been
able to find an improvement.  Here are approaches to the problem:

1 - The NXT, which shows the requester the two names and data at one
surrounding the request, in order to "prove" that the data doesn't exist.
This provides fine grained security, but easily exposes the zone's (public)
data.

1a - Substitute hashes for the real names in the NXT's.  (Hashing
everything would help with I18N too. ;))  I've forgotten the reasons why
this idea faded away.

2 - Signing a unique reply to a request would put a onerous load on the
server.  In light of recent DDOS attacks, this would be a bad idea.  An
attacker could issue a stream of missing data requests, locking the server
into signing replies.

3 - Signing an SOA-like record, repeating it for each absent data result.
This is subject to a replay attack.

4 - Leave absent data unprotected.

What else am I missing?

Summary:
1 - "Here's what I got, do you see what you want?"
2 - "What you want (name,data) I ain't got."
3 - "I ain't got whatever you want."
4 - No change from current.

Is there a "philosophical" approach missing?

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 12 Apr 2000 08:36:21 +0200

At 09:09 11.04.2000 -0400, Edward Lewis wrote:

>able to find an improvement.

well.....

>Is there a "philosophical" approach missing?

possibly. The ability of people to generate ideas is aw{ful,esome}.

Wild, looney rave:

- NXT performs 3 jobs, none of them well.
   One is "what RR sets are present for this name".
   Another is "how big is this hole", where the "other side" of the hole
   may be at any naming level, but is forced to be in the same delegation
   level.
   A third one is something vaguely related to delegation
   (Section 5.5 of RFC 2535, the "handwaving" section).

- NS records do 2 jobs: Delegation point and zone info.
   It's possible to have the same NS in parent and child, but it is not
   enforced. (Query: Should it be?)

Answer: Take out the knives, and carve.

- The RRSETFLAG RR is the NXT minus the name.
   It is a DATA indicator, not a ZONE indicator. A parent zone WILL NOT
   hold its own RRSETFLAG RR, because what it's supposed to hold is supposed
   to be a subset (?) of the data held by the child zone.

- The NEXT RR is the NXT minus the bitmap. It ALWAYS points to the next
   name ON THE SAME LEVEL OF DELEGATION.
   There is no special magic to what it does at a zone delegation point; the
   question of whether a next-name exists or not is not affected by the zone
   boundary.

- The FIRSTCHILD RR is the NXT for the domain start, and indicates what goes
   on at the level BELOW.

- (Do we need to do something to the SOA/NS workaholic at the same time?)

Thus, if example.com and foo.example.com exist, with some junk, we have:

- example.com RRSETFLAG <lots of junk here>
- example.com NEXT example2.com (of interest to the parent zone only)
   (replacing the parent zone NXT)
- example.com FIRSTCHILD foo.example2.com
   (replacing the child zone NXT)
- foo.example.com NEXT <null>

If you need to signal the presence of a.b.c.d.example.com, you need to
add:

example.com FIRSTCHILD d.example.com
d.example.com FIRSTCHILD c.d.example.com
b.c.d.example.com FIRSTCHILD a.b.c.d.example.com

which is a bit more than adding
example.com NXT a.b.c.d.example.com

but it's all automagically generated anyway.....

We can now replace NEXT and FIRSTCHILD with a hash mechanism without
affecting RRSETFLAG. Separation of concerns achieved.

None of the records are different in the parent than in the child.

You ask for other proposals, you get other proposals :-)

The point of the exercise: If you keep the current NULL KEY mechanism, or 
at minimum don't involve the NXT record in signalling the parent's opinion 
of the child's security, none of this is relevant to zone security status.

I don't want the zone secure bit in the NXT record.

                        Harald

---

From: Edward Lewis <[email-masked]>
Date: Wed, 12 Apr 2000 09:18:28 -0400

>You ask for other proposals, you get other proposals :-)

Seriously, I like to see them.  I'm not religious about the NXT, I'm just
resigned to it.

The problem I see with breaking the NXT into multiple records is the
increase of SIG records to cover the new sets (hence the size of the zone).

>   enforced. (Query: Should it be?)

What does this mean?

PS - from http://www.ietf.org/internet-drafts/draft-iab-ntwlyrws-over-02.txt:
>
>3.5 Recommendations on DNS
>
>   ...It is
>   therefore recommended to the IETF that, except for those changes
>   that are already in progress and will support easier renumbering of
>   networks and improved security, no fundamental changes or additions
>   to the DNS be made for the foreseeable future.
>
Does this mean we are stuck with the NXT for the time being?

---

From: Randy Bush <[email-masked]>
Date: Wed, 12 Apr 2000 07:25:47 -0700

> Does this mean we are stuck with the NXT for the time being?

this is the minute of a workshop, not a formal iesg position.  

even if it was, imiho (as an individual non-contributor) simplifying dnssec
so that folk could actually understand it well enough to feel comfortable
would seem to fit right under "improved security."

randy

---

From: Jerry Scharf <[email-masked]>
Date: Wed, 12 Apr 2000 10:01:39 -0700

Harald,

I like this proposal on the whole.

I see the impacts for the zones as small:

for the parent, it's a wash or minor gain, replace NXT with NEXT. Same zone 
size, similar number/size of responses.

for the child, replace NXT with RRSETFLAG and FIRSTCHILD flags associated with 
the SOA. Adds one SIG record to the child. Could hurt the 100,000 zone master 
servers. Doesn't change number/size of responses much (you can only get one of 
the two for any query.) The difference in zone file creation effort is a small 
improvement in logic and sometimes creating one more SIG, but it mostly a 
wash. I would like to find a better name for the RRSETFLAG, but that's minor.

I think the resolver code becomes simpler, but the server code becomes more 
complex to handle backwards compatibility.

while you have these open, we could add the capabilities of hash and name 
based FIRST/NEXT in if that's still desired. I liked it alot and don't 
remember why it got lost.

Now for the sticky widget of backwards compatibility. There is no way 
currently to tell whether the resolver (or recursive server) expects old NXTs 
or the new proposal. We probably need to add something to the query (in EDNS0 
space?) that says we can understand FIRST/NEXT/RRSETFLAG. If it's there, then 
the server can respond with those, and if not will need to synthesize the old 
NXTs. We can make other new DNSSEC functions tied to this, but I believe we 
will need to support the current DNSSEC specs for a long time.

As for NSs, I think we have that sorted out and so we shouldn't "fix" it. It 
is very useful to not have forced coherence between parent and child on NS 
lists. Often times it has been very hard to get the parent to rapidly and 
correctly make changes to the NS list, and caching the child's "better" NS 
list has been an important way to help this.

Now for the real issue to discuss, which is when to take this on. We have yet 
to deploy DNSSEC on any significant scale. Some would say it's better to fix 
it now, but I think we need to get it up and running in major production first 
and see what's going to work and not work, then take on changes like this. 
Given there is about to be a release of BIND with DNSSEC implemented as is and 
that is going to go into a significant number of O/S resolver distributions, 
we can't fix it before it gets out.

I would recommend that the community learn more before embarking on the next 
round. No matter when we take this on, we need to sort out all the details of 
interoperability between this new scheme and the existing ones.

jerry

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 12 Apr 2000 21:56:28 +0200

>will need to support the current DNSSEC specs for a long time.

If NXT is really fatally flawed, we should recommend that people stop 
sending it ASAP.
I think backwards compatibility can then be limited to:

- Clients must be able to ignore it
- Servers must be able to not crash when asked for it

A scheme that generated signed NXT records on the fly would:

- Require on-line, real-time signatures
- Provide all the complexity of the new stuff, all the complexity of the
   old stuff, AND the complexity of the mapping function

That seems an awful lot of work to go thorugh to support the existing 
client applications that use the NXT record sensibly.

                             Harald

---

From: Jerry Scharf <[email-masked]>
Date: Wed, 12 Apr 2000 16:22:01 -0700

> - Servers must be able to not crash when asked for it

If a current DNSSEC aware resolver sets CD and the result is a NXDOM or NXRR 
without a NXT record, what does current spec/code do? If it can accept the 
record as valid, then we are OK. If not and it tosses the response, then we 
may have a problem. Could people with current DNSSEC resolvers comment?

> - Require on-line, real-time signatures

Actually I misrepresented this. You would have both FIRST/NEXT/RRSETFLAGs and 
NXTs generated at zone signing time, and send out one or the other.

>    old stuff, AND the complexity of the mapping function

yup. The mapping function happens at zone signing time, so that's at least 
separable.

> client applications that use the NXT record sensibly.

Violating backwards compatability is a big deal to me, so I wanted the 
discussion of this aspect out in the open. If it is decided that tossing it is 
the right thing to do, and people getting ready to deploy secure resolvers 
don't pitch a fit, then it should be done that way.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 12 Apr 2000 21:51:32 -0400

> If NXT is really fatally flawed, we should recommend that people stop

The NXT is hardly "fatally flawed."  There are some folks unhappy with it,
but it does not cause serious problems.  That there are two distinct RRsets
at a delegation point is a nuisance that has been properly handled in at
least two implementations.  That the NXT makes "walking" the zone easy, it
is not exposing data that would not otherwise be available.  (What's worse,
my requesting your zone NXT's or repeatedly banging your server for all
possible label names to get the same information, or possibly quessing at
names to confirm/deny hunches?)

The NXT's requirement that a zone be sorted is a bear.  However, no other
alternative has removed this need without replacing it with an even greater
performance problem.

I'm not about to support tinkering further with the NXT (beyone the zone
sec status bit) unless the result is a major gain.  This is why I keep an
eye on the "philosophical underpinnings" of the problem - maybe there's
some law of physics that is being overlooked.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 13 Apr 2000 08:20:06 +0200

At 21:51 12.04.2000 -0400, Edward Lewis wrote:
>but it does not cause serious problems.

Yet. Our current bogeyman example of deploying a complex specification
is SNMP version 2.

>   That there are two distinct RRsets
>least two implementations.

and a violation of the DNS architectural model, IMHO, since it enshrines
the idea of 2 different, valid RRsets for the same name and RR type.

>  That the NXT makes "walking" the zone easy, it

The fact that the sort specified is more than a little strange, and does not
extend naturally to non-ASCII, doesn't help much either.

>some law of physics that is being overlooked.

I agree about not tinkering with it now.
It's the only choice we have where we've worked out its good and bad sides.
But I don't agree about adding the zone sec status bit, since a) that is a 
change, and b) it makes the zone security function dependent on NXT.

I think we're going to replace it later (that is - invent a new mechanism, 
run both in parallel for a while, and then deprecate NXT); we should make 
sure doing so doesn't hurt more than it has to.

                    Harald

---

From: Edward Lewis <[email-masked]>
Date: Thu, 13 Apr 2000 09:01:31 -0400

>change, and b) it makes the zone security function dependent on NXT.

The reason for adding the bit is that this change will cause a significant
shrinkage of the data processed at widely delegated zones.  Assuming that
there will be a lot of unsecured zones for the time to come, a zone like
".com" (the usual whipping child it seems) would fill up on signed NULL KEY
RR records.  Given that a delegation might have 2 NS RR's (unsigned), an
signed NXT RR regardless of whether we make the proposed change, it looks
like adding the change would save on the order of 40% in memory
requirements for these zones.  I think that such a significant savings
would speed the adoption of the protocol - so we can then justify mucking
with it sooner.

The downside of the change pales in comparison.  In terms of
implementation, the information that is needed to set the bit appropriately
is also needed to know whether or not to insert a NULL KEY RR in the master
file.  Hence, there is no new information flow causing an increase in
complexity.

As far as the issue that the bit is misleading, here's what might happen.
A delegation point in .test might be:

   zubsone  NS  ns1.zubsone.test.
            NS  ns1.zubsone.test.
            NXT zuppersone NS KEY SIG NXT
            SIG NXT ....

Now, when a resolver asks for the KEY set one of two things could happen.
The server returns the NXT set because there is no KEY set at the server
(assuming the zones are not sharing the server).  The resolver would see
that it got a negative answer, but the answer says the data is available.
The resolver would then have to know to go get the KEY from the
authoritative source.

On the other hand, the server could see in the NXT that the KEY set exists.
The server could either respond by treating this as a recursive operation
(is recursion is allowed) or respond with a referral answer to the
resolver.  I'd prefer the latter, this would be nicer to older resolvers.
Opinions from the server implementers?

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 13 Apr 2000 15:39:55 +0200

At 09:01 13.04.2000 -0400, Edward Lewis wrote:
>RR records.

Let's do numbers; I dislike terms like "fill up".

Current size of .com: 12 million records.

Assumed typical entry in master zone:
- 2 NS records, each of 20 bytes
- 2 A records, each of 10 bytes (assuming full glue)
total 60 bytes. Total for .com zone: 720 Mbytes.

Added for security:
- 1 NXT record, approx. 20 bytes
- 3 SIG records, approx 50 bytes each (with DSA and keysize T=1)
total 170 bytes. Total for .com zone: 2 Gbytes.

Added to support NULL KEY:
- 1 NULL KEY record, approx 20 bytes
- 1 SIG record, approx 50 bytes
total 70 bytes. Total for .com zone: 840 Mbytes.

We quadruple(???) the memory footprint instead of "just" tripling it.

So NULL KEY adds about 30% to the hardware cost of going DNSSEC, compared
to the KEY bit. Might be more expensive if it flips over architectural 
limits in the server host machines.

Numbers are nice. They are also probably wrong. But better than no numbers.

                Harald

---

From: Edward Lewis <[email-masked]>
Date: Thu, 13 Apr 2000 10:27:20 -0400

Why do you have 3 SIG records (added for security)?  The NS and glue sets
are not signed in the parent - if that is two of the three SIGs you
counted.  But perhaps I'm missing something.

If I'm right, we're looking at 70 bytes for NULL KEY divided by a total of
200 bytes [=60+70+70], which means removing the NULL KEY would save 35%
(corresponding to my guess of 40%).  If I'm wrong, the savings is 23%.  (In
other words, if I'm right, the cost of adding NULL keys is 53%, if I'm
wrong, 30%.)

BTW - The reason my guess was 40, and now calculated to be 35 is that I
took into account that many delegations share name servers, hence reducing
the amount of glue, making the NULL KEY a bigger hit than calculations here
show.

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 14 Apr 0 1:06:32 JST

Edward;

> Seriously, I like to see them.  I'm not religious about the NXT, I'm just

You have already seen the attached proposal. It is the original
proposal, which was badly modified by Donald into unusable NXT.

> increase of SIG records to cover the new sets (hence the size of the zone).

That is another silly proposal not worse commenting.

							Masataka Ohta
---
>From mohta Thu Jul 15 17:06:46 1999
Subject: On secure DNS update and NXT
To: [email-masked]
Date: Thu, 15 Jul 99 17:06:46 JST
X-Mailer: ELM [version 2.3 PL11]
Status: OR

Reading draft-ietf-dnsop-keyhand-00.txt, it is my pleasure to see
people working on DNSSEC finally understand DNS issues.

That is, it seems to be the time to revive:

> INTERNET DRAFT                                                   M. Ohta
> draft-ohta-simple-dns-01.txt               Tokyo Institute of Technology
>                                                            November 1994

>                         Simple Secure DNS

Incorporation of some (all is better if you want to remove all the
complex tricks to implement and operate DNSSEC, but I'm so humble)
of it should not be too late.

On the dynamic update issue, it said:

   In
   cases where frequent and/or automatic update of a zone is desired, it
   is necessary to make signature generation mechanism of the zone
   accessible on-line.  Still, it is worthwhile to keep the secret
   information and secure time stamping mechanism of the zone off-line.
   To make it easier, the protocol is designed to let signed information
   have the consistent format about time stamping and signature
   generation.  Then, after the security of the signature generation
   mechanism is restored, signatures using the same secret information
   become reliable again.

In 1994 in DNSSEC WG, the need on frequent update was not
recognized very well.

On the NXT issue, it said:

   ZL (Zone List)

      data used to store sorted list of all the nodes in a zone.  The
      information is necessary for protection against denial of service
      attacks, that is, if a node does not appear in certain ZLs, a
      negative response that a queried node does not exist is
      authenticated.  The simplest way to authenticate negative answer
      that some data does not exist is to have an authenticated list of
      all the existing data.  But, unless the number of existing data is
      expected to be small, as in the case with [RRD], listing up is
      inefficient.  Especially, for a very large zone such as "com.",
      the size of the list is impractically large.  So, existing data
      are sorted in a certain order and segmented appropriately into
      multiple ZL records.  To authenticate the non-existence of a node,
      only a ZL RR containing the node (according to the sorting order)
      needs to be returned.  To not to cause UDP size overflow, ZL RRs
      are intended to be returned as a partial RR in the additional
      section of a negative answer with truncation bit set.  To
      authenticate a partial ZL RR, it is necessary to attach
      authentication signatures to individual ZL RRs.  With wildcarding,
      actual authentication is a little more complicated and is
      discussed in section 5.3: "Resolver Algorithm".

      ZL will have the following syntax.

            <zone> [ZL] <nttl> <first> <last> <n> <domain name #1> ...
                        <domain name #n> <timestamp> <expire>
                        <signature>

      where [ZL] is the RR name of ZL data, <nttl> is the number of
      seconds appropriate for negative caching, <n> is the number of
      domains covered by the record.  The record contains all the domain
      names of the zone (including the top level nodes of child zones
      but excluding the zone name itself) after (or including) <first>
      and before <last> sorted with dictionary order.  Cases of
      characters in <first>, <last> <domain name #1>... must be
      canonicalized to lower cases.  <first> and <last> is merely a
      separator and should not be interpreted that such a node exists
      unless explicitly listed as <domain name #1>.  Comparison is
      performed first label by label.  Top level labels are compared
      first and the leaf labels are compared last, which makes domain
      name compression work quite well.  Within labels, comparison are
      by dictionary oder, that is, first bytes are compared first.  For
      example, "a.b.c.", "a.c.b.", "a.c.", "ab.c.", "ac.b." and "c." are
      ordered as "ac.b.", "a.c.b.", "c.", "a.c.", "ab.c." and "a.b.c.".

      Thus, the name of the zone is ordered before all the other names
      in the domain.  For the comparison purpose, when the name of the
      zone itself appears as <last>, it is considered to be ordered
      after all the other names in the domain.  For example,

            <zone> [ZL] <nttl> <zone> <zone> 0 <timestamp> <expire>
                        <signature>

      represents a zone consisting of only a single node.

      <nttl> and <n> are two byte integers.  <first>, <last>, <domain
      name #1>, ..., <domain name #n> have the syntax of domain names.

      To make an authenticated response of non existent node resides
      within 512 byte UDP packet, it is recommeded that the length of a
      single [ZL] record be shorter than 400 bytes, after limited domain
      name compression (those information available within the record
      itself only, may be shared for compression).

      <timestamp>, <expire> and <signature> are the same as that of
      [NSIG] except that the signature covers the byte stream of the
      sequence of <timestamp> <expire> <nttl> <first> <last> <n> <domain
      name #1> ...  <domain name #n> contained in the [ZL] record
      itself.

In short, ZL is data belongs to the parent zone to authenticate
the non existence of a node.

							Masataka Ohta

---

From: Edward Lewis <[email-masked]>
Date: Thu, 13 Apr 2000 12:46:11 -0400

>proposal, which was badly modified by Donald into unusable NXT.
...
>That is another silly proposal not worse commenting.

Well said.

Your "Zone List" solves none of the problems with the NXT.  It makes
walking the zone easier (fewer queries).  It requires a sort (that is ASCII
based in the definition).  It does not cover absent data for a present name.

Your proposal failed to gain acceptance in the early days of DNSSEC (prior
my introduction to the problem, so I don't have a date) and again failed
last year.  Please bury this proposal once and for all.

---

From: "David R. Conrad" <[email-masked]>
Date: Thu, 13 Apr 2000 11:31:10 -0700

> Let's do numbers;

Umph. From http://www.centr.org/meetings/dnssec-20000328.html

	...
	
	There were many rumours of DNSSEC not scaling for large zones, but 
	there seemed to be a lack of empirical evidence upon which to base 
	these judgements. Zone files supposedly took weeks to generate and 
	inflated zone files by a factor of ten.

	NLnet Labs had conducted their own tests, and found that zone files 
	typically only grew by a factor of two or three. Even in the worst 
	case scenario, they could not get the zone file to grow by more 
	than a factor of five. Furthermore, a zone file with 10,000 records 
	and 1024-bit DSA keys could be generated in under five minutes using
	a 500 MHz Athlon-based PC. This meant that the .de zone file 
	(approximately two million records) could be generated in around 
	sixteen hours, and this would only need to be done once. Subsequent 
	updates would be incremental.

	...

[Kudos to the folks at NLNet Labs and CENTR for actually taking the time to do
empirical tests with the freely available tools]

Can we perhaps hold off a bit on radically revising DNSSEC until we actually
get a bit of field experience with a full implementation?  (I find it
distressing this would even need be asked).

Rgds,
-drc

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 13 Apr 2000 23:00:43 +0200

>counted.  But perhaps I'm missing something.
Why shouldn't they be signed by the parent, if the child is not going to 
sign them? Or - why should I, as superzone provider, leave the children 
open to an attack that I can stop by signing them?

but I admit to still thinking of the relationship between data in a 
superzone and data for the same name in a subzone as an area where the 
magic of the DNS is of a darker shade than usual; if you say that the 
superzone shouldn't sign them, I'll believe you.

BTW, I think my subject line fits the discussion quite well....we should
remember that what the base discussion we're having is a small change to 
the NXT record to be implemented (or not) in BIND 9 (I suppose), not 
deploying the alternative to NXT.

                     Harald

---

From: Edward Lewis <[email-masked]>
Date: Thu, 13 Apr 2000 18:04:59 -0400

>superzone shouldn't sign them, I'll believe you.

"Should"/"Should not" I don't know, but the specification calls for the
superzone not to sign the NS and glue.  I haven't personally questioned
this, as I agree with it on the surface.