Subject: WGLC for DNSSECbis docs

From: [email-masked] (Geoffrey Sisson)
Date: Tue, 1 Jun 2004 14:27:58 +0100 (BST)

I speak for myself and on behalf and Nominet UK.

I believe the use of NSEC RRs is entirely suitable for many DNSSEC
applications.  In particular, a compelling case exists for their use in
zones under {in-addr,ipv6,e164}.arpa where meaningful enumeration is
already trivial.  I don't believe that an authenticated denial of
existence ("negative answer") scheme that is designed to be
enumeration-resistant, such as NO or NSEC2, should replace NSEC, but
should be available strictly as an alternative, for use in zones where
the risk or operational impact of enumeration presents special
problems.

I understand that it would be impractical at this time to insist upon
the inclusion of an alternative negative answer scheme in DNSSECbis.
However I believe that it's essential to defer the approval of the
current drafts long enough to consider what might be done to make them
"friendly" to the future incorporation of an alternative negative
answer scheme, in particular, possibly adding a version (or at least
MBZ) field to the NSEC RR RDATA field.

While the discussion so far appears to be undecided as to whether
DNSSECbis can be non-invasively extended to accommodate multiple
methods for negative answers, I believe it is preferable to have rough
consensus on this issue *before* the current docset goes to the IESG.
This shouldn't require a one-year delay, as some of the more
pessimistic projections have put it.

I sincerely hope the dnsext WG chairs, the Internet Area ADs, and the
IESG will recognise that a DNSSEC specification that meets its original
design goals but fails to satisfy the operational requirements of a
number of significant DNS operators, such as Nominet UK (.uk ccTLD
registry) and DeNIC (.de ccTLD registry), will be a serious impediment
to the deployment of the protocol.  Moreover, I suspect that NSEC RR
elaboration will become an operational nuisance even for registries
with relatively weak privacy requirements, such as the ICANN gNSO
member registries, which may potentially further erode support for the
protocol.

In short, I request the WGLC be extended at least long enough to
establish rough consensus on whether an alternate negative reply scheme
can be incorporated into DNSSECbis, or if DNSSECter will be required
instead.

I've followed the work of this group for a number of years; it would be
an understatement to say that I respect and admire the authors and
supporting cast for the DNSSECbis docset.  So it's painful to find
myself having to take sides against some of you.  But, under the
circumstances, I believe I have little choice.

Regards

Geoffrey Sisson
Nominet UK

--
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, 01 Jun 2004 14:38:09 +0000

> MBZ) field to the NSEC RR RDATA field.

they are already friendly, in terms of a new edns0 flag bit having end-to-end
caching/forwarding treatment, and new type codes.  MBZ on the other hand would
open a can that contains a large number of worms.  would the whole RDATA be
able to change based on this MBZ not being zero?  if so, then an implementor
who ignored the MBZness would not be penalized until several years had gone
by, which has usually been a recipe for disaster.

> ...

i think that this has already been achieved, but i'm writing it up anyway.

> ...

adding an MBZ would absolutely have that effect on the schedule.

---

From: [email-masked] (Geoffrey Sisson)
Date: Tue, 1 Jun 2004 18:06:13 +0100 (BST)

Paul Vixie <[email-masked]> writes:

> able to change based on this MBZ not being zero?

With something resembling NSEC2 it would be likely.

>                                                   if so, then an implementor

There aren't many implementations that would have a significant impact
if MBZness is ignored, which hopefully makes vigilence a viable
solution.  But I'm curious: is it reasonable to design protocols to
compensate for the rich diversity of ways in which they might be
mis-implemented?  Or does MBZ/version/reserved for future use/etc.
represent a special case?

Yesterday you said:

>                            unless the change to dnssec-bis were as
> simple as "add an MBZ octet to DS, DNSKEY, RRSIG, and require current
> implementations to ignore RRs where this octet has a nonzero value"
> then we're not going to see "production software ready to go" again in
> 2004.

. . . which I interpreted to mean you believed MBZ might not be so
costly.

I wouldn't wish to challenge your estimate of a one-year delay, but
I would be interested to learn of previous instances where this has
happened.

Regards

Geoff

---

From: Paul Vixie <[email-masked]>
Date: Tue, 01 Jun 2004 17:20:31 +0000

> > ... MBZ on the other hand would open a can that contains a large
> > number of worms.  would the whole RDATA be able to change based on
> > this MBZ not being zero?
> 
> >                           if so, then an implementor who ignored the
> > MBZness would not be penalized until several years had gone by,
> > which has usually been a recipe for disaster.
> 
> ... I'm curious: is it reasonable to design protocols to compensate
> for the rich diversity of ways in which they might be mis-implemented?
> Or does MBZ/version/reserved for future use/etc.  represent a special
> case?

when extending a protocol, it's good to first consider changes to an
element that you know existing implementations have to look at.  BIND
has been especially damaging in this area, for example by copying bits
in the header flag from query to response rather than ignoring them and
making sure they were set to zero in responses.  this essentially "used
up" the last two flag bits in the dns header, without returning value.

> ...which I interpreted to mean you believed MBZ might not be so costly.

overnight i realized three things.

1. an MBZ isn't enforceable in current/proposed implementations.
2. an MBZ would take significant docset and software work to define.
3. a TCR is always possible and is proof against any existing misdesign.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 02 Jun 2004 06:31:50 +0000

> ...
> I believe that NSEC RR traversal will be *so* much more attractive than
> any other form of information gathering that it will become pervasive.

I agree.  Unless the servers also offer the zone by FTP and AXFR, that is.

(Ooops, I think my skirt is showing.)

> It's lossless and simple.

It's not lossless.  If a zone changes during an AXFR, then either the AXFR
is TCP-RST'd (BIND4, BIND8, most nonBINDs) or it continues but using the old
zone contents (BIND9), but if a zone changes during an NSEC traversal, there
will almost certainly be some data loss due to the rewritten NSEC chain.

> ...
> The only way I see to mitigate this is to make the same information
> available via less expensive facilities, e.g. unrestricted FTP/HTTP
> access.  This may be an option for some operators of nameservers with
> large zones but, unfortunately, it's not an option for us.

Your position is quite well understood.  For the record, did anyone from
Nominet comment during the January WGLC on the design goals of DNSSEC-BIS?

> ...
> I appreciate that this message comes late in the day.  I regret that
> we've not shared our operational experiences prior to now.  And it is
> no doubt extremely frustrating to those who have poured a lot of effort
> into DNSSEC and DNSSECbis to hear it only as the current drafts go to
> WGLC.

For my part, it's not frustration but rather sadness.  DNSSEC-BIS will be
deployed, and some parts of the DNS tree won't benefit from it, and that's
how it has to be, but I don't have to like it and in fact I don't like it.

Onward to DNSSEC-TER.

---

From: [email-masked] (Ted Lindgreen)
Date: Wed, 2 Jun 2004 10:24:38 +0200

[Quoting Geoffrey Sisson, on Jun  2,  1:59, in "Re: WGLC for DNSSECb ..."]
...
> I hope that, if nothing else, one key point isn't entirely lost: my
> concerns about NSEC RRs are not limited to information leakage, but
> also to the potential resource implications of abuse.  Do TLDs really
> want to have to provision substantial additional capacity just to serve
> the data mining "community"?  As Jay mentioned, it's not inconceivable
> that were we to deploy DNSSECbis, well over half of all DNS queries
> might be associated with NSEC RR traversal activity.  ...

Please, let's stay to facts based on real measurements and don't get
excited by FUD based on gross miscalculations.

The message from Jay you are refering to contains at least 3 errors
and should therefore not be taken seriously.
I expected that this was immediately clear to everybody whois dealing
with real-life root or TLD operations, but appearently the FUD did
stick by some.

[Quoting "Jay Daley", on May 31, 23:37, in "Re: Proposal to fix  ..."]
....
> Let me just put this one in perspective.  Each of our nameservers has an 
> average load of 100 million queries per day with about 4 million records 
> in our zone files.  That means it will take only 25 spammers doing a full 
> walk in one day to double the load on that server (this is on top of the 
> huge increase in traffic that DNSSEC means).  As we have on average 3,000 
> new domains registered per day we can safely expect these spammers to do 
> this every day.  Once the script kiddie tools are out then we can expect 
> many, many more than just 25.
> 
> Jay

In short:
 "4 million records x 25 spammers" == 100 million queries per day
 hugely increases the load on the UK nameservers.

Error 1:
 A load of 100 million queries per day is not something to get excited
 about. See the real measurements by CAIDA, RIPE, and NLnet Labs on root
 and TLD nameserver loads.
 For your information:
   with 500 Mhz Athlon or Pentium class systems (off the shelf PC's
   in 2000), both BIND-8 and BIND-9 can easily handle 6000 queries
   per second, with NSD this is some 30000.
   That amounts to 2592000000 per day, or 25 times your current
   query load,.

Error 2:
 NSEC walking goes by domainname, not by record. There are multiple
 records per domainname, so here goes another factor.

Error 3:
 To walk NSECs, one needs the answer on a previous query, before one
 can construct the next one. Depending on network, both nameserver
 and walking systems, and nameserver software implementation, there
 is a delay of several tens of milliseconds.
 Lets say 50, then, one walk can do at most 1728000 lookups per day.

In conclusion: the load caused by zonewalkers can be neglected,
even if hundreds of spammers are doing it simultaneously.

-- ted

---

From: [email-masked] (Ted Lindgreen)
Date: Wed, 2 Jun 2004 10:36:29 +0200

[Quoting Geoffrey Sisson, on Jun  2,  9:56, in "Re: WGLC for DNSSECb ..."]

> I also may have under-represented the case of DNS end-users, for whom
> simple privacy is the principal concern.  Even using split DNS, they
> may have information they'd prefer not to broadcast.

Really, this is plain nonsense!

The purpose of DNS is to publish information. And split DNS is
invented to differentiate between audiences.

If an end-user does not want certain information to be published
to certain audiences, this end-user should not put it in the
public part of their split DNS system.

-- ted