Subject: Re: NSEC2- and an Authenticated Denial Mechanism Flag

From: Marcos Sanz/Denic <[email-masked]>
Date: Wed, 26 May 2004 13:08:13 +0200

Jim,

> Marcos> http://www.centr.org/technical/zone-access.html
> 
> This doesn't really help. It just shows that a bunch of TLDs restrict
> AXFR to their slave servers and sometimes to trusted third parties.

Point taken. However, I think these TLDs aren't placing the zipped zone at 
everyone's disposal via anonymous FTP either.

Regards,
Marcos

--
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, 26 May 2004 13:36:36 +0200

> AXFR to their slave servers and sometimes to trusted third parties. It
> doesn't say why they do this. For instance, I can understand why DeNIC
> wouldn't want random users to be able to slurp the 1GB or so of the
> .de zone, guzzling bandwidth and needlessly loading the TLD's name
> servers.

But it's okay to let random users enumerate the zone by following
NSEC RRs?

Steinar Haug, Nethelp consulting, [email-masked]

---

From: Jim Reid <[email-masked]>
Date: Wed, 26 May 2004 12:46:18 +0100

>>>>> "sthaug" == sthaug  <[email-masked]> writes:

    >> This doesn't really help. It just shows that a bunch of TLDs
    >> restrict AXFR to their slave servers and sometimes to trusted
    >> third parties. It doesn't say why they do this. For instance, I
    >> can understand why DeNIC wouldn't want random users to be able
    >> to slurp the 1GB or so of the .de zone, guzzling bandwidth and
    >> needlessly loading the TLD's name servers.

    sthaug> But it's okay to let random users enumerate the zone by
    sthaug> following NSEC RRs?

IMO, yes. UDP traffic to an already active socket has to be better for
the name server and underlying OS than carrying the same traffic over
freshly-created TCP connections, all other things being equal. Not
that I care about enumeration anyway, however it's done.

---

From: Robert Elz <[email-masked]>
Date: Fri, 28 May 2004 17:51:16 +0700

Date:        Wed, 26 May 2004 13:36:36 +0200
    From:        [email-masked]
    Message-ID:  <[email-masked]>

[quoting someone...]
  | > For instance, I can understand why DeNIC
  | > wouldn't want random users to be able to slurp the 1GB or so of the
  | > .de zone, guzzling bandwidth and needlessly loading the TLD's name
  | > servers.
  | 
  | But it's okay to let random users enumerate the zone by following
  | NSEC RRs?

There's a big difference (and Jim, it isn't TCP vs UDP, for a zone
transfer, the extra overhead of TCP is in the noise).

The "problem" of AXFR is that it requires a stable zone image to transfer,
and so the server must (somehow) create that stable zone, when the AXFR
request is made, and then transfer the zone as it was at the instant the
initial SOA of the response was sent - regardless of any later changes that
are made to the zone.

Since the server has no idea whether or not any changes may be made to the
zone while the transfer is in progress, it has to do something to prepare for
the possibility that they may occur (as it also has no way to know how long
the zone transfer will take to complete, it also can't just delay updates
until after that has happened - that could be hours, or more, into the future).

This is what makes AXFR costly, and is certainly why I disabled it for
non-secondaries when I was running zones for which it made a difference.

The extra load of some number of random people doing zone slurps
(especially using an NSEC type technique, where each subsequent query has
to wait till the reply to the former is received, as that's where the
qname for the next query comes from) when compared to the normal load on
a busy server of handling "normal" queries (the ones that succeed, and
even more, the ones that end up failing) is barely going to be noticeable.
You'd need to postulate hundreds, or more likely, thousands, of people
all deciding to walk the chain at the same time before the query rate would
really start to be noticeable.  [Yes, I know, the really busy servers don't
want any unnecessary queries, but there are better things to try and stop
than this I suspect].

It is also worth noting that the oft made claim that NSEC allows pristine
zone copies to be made is false - it improves the chances of that happening
over some other methods, but it is certainly not a technique that will
guarantee the successful transfer of a zone.

kre

ps: apologies for the bogus copyright law noise I sent in an earlier
message, it has been a long time since I needed to look at that stuff.
Copyright was created initially as a means to encourage publication,
so that was a requirement to get the protection - beats me why that
requirement was dropped, but apparently it has been.