Subject: Re: third-party servers: DNS load, HTTP load, etc.

From: "D. J. Bernstein" <[email-masked]>
Date: 6 Jul 2003 15:19:14 -0000

Jim, how exactly do you claim that European users can register glue for
their (big, direct from RIPE) in-addr.arpa delegations?

http://www.ripe.net/reverse/howtoreverse.html specifically states ``IP
address not allowed here'' for the ``nserver'' part of an in-addr.arpa
delegation request. There's no other line allowing a server IP address.

You claim that e164.arpa and in-addr.arpa have ``identical'' procedures.
Evidently you are claiming that, since e164.arpa allows IP addresses on
the nserver line, in-addr.arpa must also allow them; in short, that the
RIPE web page is wrong. Do you have any evidence to back up this claim?

Of course, even if RIPE and ARIN do fix their procedures someday to
_allow_ glue, the considerable extra load from reverse lookups will
continue until most people _use_ glue. If your company truly cares about
DNS load, why is it encouraging people to set up glueless delegations?

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

--
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: Masataka Ohta <[email-masked]>
Date: Sat, 12 Jul 2003 20:34:24 +0859 ()

DJB;

> Masataka Ohta writes:
> > nothing to do with "third party servers"
> 
> Adding third-party servers has several minor effects, positive and
> negative, on DNS load. Someone whined about one of these effects, while
> ignoring the _much_ larger effect that gluelessness has on DNS load.

Issues caused by complicated relationships between servers operated
by a single party has nothing to to with "third party servers", even
if the same issues can be caused by complicated relationships between
servers operated by multiple servers.

> Small efficiency issues have to be viewed in the context of larger
> efficiency issues. It's silly to claim that one has ``nothing to do
> with'' the other.

See above.

						Masataka Ohta