Subject: Re: WGLC for DNSSECbis docs

From: Simon Josefsson <[email-masked]>
Date: Wed, 02 Jun 2004 11:57:03 +0200

[email-masked] (Ted Lindgreen) writes:

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

My tool iterate over each RRset.  How would you get all records,
otherwise?  ANY queries aren't reliable, as far as I know.

> Error 3:
>  To walk NSECs, one needs the answer on a previous query, before one
>  can construct the next one.

Sorry, no, it is possible to parallelize it.  Send 10^10 queries for
uniformly distributed name/type/class, under the target zone, and
piece together the replies.  If by inspecting the NSEC chain, you
realize you didn't get everything, get those specifically, possibly by
querying for uniformly distributed name/type/class in the interesting
area.  Or just increase the initial amount to 10^11 queries for
uniformly distributed name/type/class, until you do get everything.

Thanks,
Simon

--
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: [email-masked]
Date: Wed, 2 Jun 2004 12:09:00 +0200 (CEST)

Don't fight FUD with FUD. Playing number games is not to be taken lightly.
Ask your average Big Corp Accountant Fall Guy. (If you don't know who that
is, you're probably the Fall Guy :).

Below I've put some references together and my attempt to number games.

My conclusion about this attempt is that load concerns definitly are
valid.

1) Performance statistics on BIND and NSD:
   http://www.nlnetlabs.nl/nsd/presentations/ripe47/mgp00010.html It is
   hard to see from this statistic to see the qps for BIND9 at 99 or 100%
   response rate, but I guess around 4000 would be right.

2) Currently, co.uk resides on 9 nameservers, 7 of which are bind 9.2.3
   (2 of which are UltraDNS Version 2.7.3.1 Build 989)

3) Nominet statistics, registrations under co.uk:
   http://www.nominet.org.uk/Statistics/RegistrationStatistics/
   5624944 registrations under co.uk on 31st of May this year, with an
   average growth of 80000 per month.

4) Proof of concept tool at: http://www.josefsson.org/walker/
   Queries individual records PLUS the NSEC records. For a delegation only
   zone, this would be delegation*2+3 (the 3 are the SOA/NSEC/NS at the
   apex).

5) Assuming that one can build a non-parallel, slow lookup thinghy that
   can do at most 1728000 queries a day, while a 500 Mhz Athlon or Pentium
   class system with off the shelf PCs in 2000, can serve 2592000000
   queries is just naive.

What this boils down to is, when I run 'walker', pointing at a single
authoritative server on a currently signed co.uk: 11249891 queries.

There is an average load on co.uk of 100.000.000 a day (according to Jay's
mail), with the help of 10 script kiddies/spammers this would double the
load.

200M queries a day may not shake an average TLD, but this exercise assumes
just 10 kiddies or spammers are interested in the co.uk zone.

Roy

---

From: "Jay Daley" <[email-masked]>
Date: Wed, 2 Jun 2004 10:41:22 +0100

Ted

ted wrote on 02/06/2004 09:24:38:

> 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.

I think you have forgotten that we do run a TLD and therefore have 
considerable real-life experience.  FUD is not the way we work and it is 
unfortunate that you see it that way.

> 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,.

You are confusing capacity with load.  My point is that it takes only a 
very small number of people to create a very large percentage increase in 
load.

>  records per domainname, so here goes another factor.

My terminology was imprecise - I meant 4 million domain names.
 
>  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.

To parallelise this is trivial, just start at different points in the 
alphabet, use multiple IP addresses and multiple servers.  That has the 
added advantage of making it harder to detect.

Jay

---

From: Derek Atkins <[email-masked]>
Date: Wed, 02 Jun 2004 10:35:59 -0400

>    zone, this would be delegation*2+3 (the 3 are the SOA/NSEC/NS at the

Note that this assumes all your children are signed.  Remember that NS
and Glue records are not signed.  If your children are not signed then
there is no authoritative data and therefore no NSEC.  This means is a
delegation-only zone you're only signing the SOA and DS records.  This
definitely limits the walkability of the full zone, as the NSEC tree
is limited to the DS content.

Unless, of course, you're actually serving non-delegation data in your
zone?

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Olaf Kolkman <[email-masked]>
Date: Wed, 2 Jun 2004 16:47:20 +0200

> Unless, of course, you're actually serving non-delegation data in your

There are NSECs proofing that there is no DS above the delegation point 
for each unsecured child.

--Olaf

---

From: [email-masked]
Date: Wed, 2 Jun 2004 16:53:23 +0200 (CEST)

On Wed, 2 Jun 2004, Derek Atkins wrote:

> there is no authoritative data and therefore no NSEC.

Errr no.

If your children are not signed, you have a NSEC with the DS bit clear in
the type bit map to proof the child is not signed.

The way the tool works is that it queries for NSEC, followed by queries
listed in the type-bit-map of the queried NSEC.

> This means is a delegation-only zone you're only signing the SOA and DS
> records.  This definitely limits the walkability of the full zone, as
> the NSEC tree is limited to the DS content.

Are you talking opt-in?

Roy

---

From: David Blacka <[email-masked]>
Date: Wed, 2 Jun 2004 10:55:40 -0400

On Wednesday 02 June 2004 10:35 am, Derek Atkins wrote:
> >    Queries individual records PLUS the NSEC records. For a delegation
> > only zone, this would be delegation*2+3 (the 3 are the SOA/NSEC/NS at the
> > apex).
>

Delegation NS records get an NSEC.  This is a basic rule spelled out in 
-protocol.

However, what you are describing isn't a bad idea, IMHO.   It is called 
"Opt-In".

-- 
David Blacka    <[email-masked]> 
Sr. Engineer    VeriSign Applied Research

---

From: Derek Atkins <[email-masked]>
Date: Wed, 02 Jun 2004 10:59:29 -0400

Olaf Kolkman <[email-masked]> writes:

> There are NSECs proofing that there is no DS above the delegation
> point for each unsecured child.

Yes, but unless things have changed yet again, NS delegation records
are not authoritative data, which means you shouldn't need an NSEC at
the name to prove that no DS exists.  E.g.:

@ = example.

a NS ..
  DS ..
  SIG(DS) ..
  NSEC c ...
  SIG(NSEC)

b NS ..

c NS ..
  DS ..
  SIG(DS) ..
  NSEC . ..
  SIG(NSEC)

"b NS" isn't authoritative so you don't need an NSEC at the node.  The
'a NSEC c' proves that no DS exists for b.  From
draft-ietf-dnsext-nsec-rdata-06 section 2.1.1:

    Owner names of RRsets not authoritative for the given zone (such as
    glue records) MUST NOT be listed in the Next Domain Name unless at
    least one authoritative RRset exists at the same owner name.

Neither NS delegations nor glue A records are authoritative data.

-derek

---

From: Derek Atkins <[email-masked]>
Date: Wed, 02 Jun 2004 11:09:16 -0400

> Delegation NS records get an NSEC.  This is a basic rule spelled out in 

Hmm.. Then -nsec needs to get corrected because it's less clear there.
The -nsec spec says you only need NSECs for authoritative data (of
which an NS delegation is not).  You are correct that -protocol
explicitly specifies authoritative data AND NS delegations (section
2.3).

If -protocol is the correct "will of the people" than -nsec should be
changed to match.

> However, what you are describing isn't a bad idea, IMHO.   It is called 

I thought we had agreed that NS delegations did not NEED to be part of
the NSEC chain, but clearly I had too much Guiness that night.  :(

-derek

---

From: Don Stokes <[email-masked]>
Date: Thu, 03 Jun 2004 17:04:05 +1200

>just 10 kiddies or spammers are interested in the co.uk zone.

If NSEC2 or something a lot like it is deployed, I don't think this will
get rid of spammers/scammers/script kiddies doing NSEC2 walks.

If you download the entire NSEC2 chain you can do direct dictionary
attacks on the zone, without requiring network traffic.  

Quick tests suggest that even my baby desktop box can do something like
6,000,000 SHA1 hashes per second.  A local outfit here was selling
second-hand PII/400s for about NZ$40 each -- at that kind of price I can
get a *lot* of compute power for very little money.

Out of curiosity, I did some experiments today, taking an old copy of a
TLD zone, and subjecting it to tests for susceptibility to dictionary
attacks.  (Note that this is the reverse of actually performing the
attack, and, uh, somewhat faster.)  

These tests suggest I could find 50% of names in a zone in the space of
a few hours, on one box, using a fairly dumb dictionary attack on a
stored list of hashes.  More sophisticated attacks could get better hit
rates for more time.  While cranking up the NSECINFO iteration count
would slow the ratbags down (at the expense of legitimate hash
calculations), I fear that NSEC2 will not solve the problem of data
mining via traversal of authenticated denial records. It'll be only a
matter of time before even script-kiddies are doing NSEC2 traversals and
launching dictionary attacks on large zones for fun and profit.

-- don

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 3 Jun 2004 11:15:09 +0200

On Wed, 02 Jun 2004 11:09:16 -0400
Derek Atkins <[email-masked]> wrote:

> which an NS delegation is not).  

The details are further addressed in proto. These issues have been the
subject of a number of questions that where posted to the mailinglist
over the last few months. Let us not re-iterate.

Relevant text is in proto-2.3

   The bitmap for the NSEC RR at a delegation point requires special
   attention.  Bits corresponding to the delegation NS RRset and the RR
   types for which the parent zone has authoritative data MUST be set to
   1; bits corresponding to any non-NS RRset for which the parent is not
   authoritative MUST be set to 0.

in proto-3.1.4:

   If no DS RRset is present at the delegation point, the name server
   MUST return both the NSEC RR which proves that the DS RRset is not
   present and the NSEC RR's associated RRSIG RR(s) along with the NS
   RRset.  The name server MUST place the NS RRset before the NSEC RRset
   and its associated RRSIG RR(s).

in proto-3.1.5

   NSEC RRs appear in both the parent and child zones at a zone cut, and

   are authoritative data in both the parent and child zones.  The
   parental and child NSEC RRs at a zone cut are never identical to each
   other, since the NSEC RR in the child zone's apex will always
   indicate the presence of the child zone's SOA RR while the parental
   NSEC RR at the zone cut will never indicate the presence of an SOA
   RR.  As with any other authoritative RRs, NSEC RRs MUST be included
   in zone transfers of the zone in which they are authoritative data:
   the parental NSEC RR at a zone cut MUST be included zone transfers of
   the parent zone, while the NSEC at the zone apex of the child zone
   MUST be included in zone transfers of the child zone.

and in 

-- 

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC

---

From: Roy Badami <[email-masked]>
Date: Thu, 3 Jun 2004 12:31:46 +0100

>>>>> "Olaf" == Olaf M Kolkman <[email-masked]> writes:

    Olaf> The details are further addressed in proto. These issues
    Olaf> have been the subject of a number of questions that where
    Olaf> posted to the mailinglist over the last few months. Let us
    Olaf> not re-iterate.

I have to say that as someone reading the doc set for the first time,
I this point confusing.  -protocol clearly states (2.3) that
delegation points require NSEC records.

But -records states that the NSEC RR contains the owner name of the
next authoritate RRset (section 4, and again in 4.1.1) and as Derek
points out this is not true, since an insecure delegation contains no
authoritative data.

This seems to me to be an editorial error in -records

     -roy

---

From: Rob Austein <[email-masked]>
Date: Thu, 03 Jun 2004 12:17:34 -0400

> points out this is not true, since an insecure delegation contains no

The NSEC RR at the delegtion point is authoritative.