--On Tuesday, 30 July, 2002 15:41 -0500 "Eric A. Hall"
<ehall@ehsco.com> wrote:
>
> on 7/30/2002 3:04 PM Keith Moore wrote:
>
>> you're simply wrong. until you can understand the math, I
>> don't see any point in continuing this discussion.
>
> Do you honestly believe that the root servers get the same
> number of cache hits per day for (say) .re as they do for .com?
>
> You are somehow trying to argue that .bar will raise to the
> same size as .foo but that the overall number of queries will
> be static. With that restriction, .foo and .bar can only reach
> parity if half of the delegations migrate into .bar from .foo,
> or from some other zone(s). Once those zones shrink, they will
> get less queries (cf, .re).
>
> The only way out of the hole you have dug for yourself is to
> increase the overall number of queries.
Eric,
Let me see if I can explain the math I think Keith is using, on
the assumption that maybe Keith and I (and others) can pass the
"patience" baton around.
Assume that neither COM (or FOO) nor BAR rotates out of a given
cache during a TTL interval. If it does (they do), it makes the
explanation below a tad more complex, but doesn't fundamentally
change anything. Also assume that most or all of the DNS
resolver and server software on the network conforms to the
specs (that is known to be false, but is a separate problem).
For a given user or, more often, a given forwarding-target
server with a cache, the number of inquiries about, say, COM
that is needed to keep the local cache full for a TTL interval
is one. How often the user/ server queries for COM during that
TTL interval doesn't count, the only thing that is important is
whether or not one such query occurs. Now, to pick a perfectly
arbitrary number, assume that the root servers see 50
kiloqueries per TTL for ".FOO" before ".BAR" in introduced.
While the number of subdomains of FOO most likely influence the
odds of getting to 50 kiloqueries, that number ultimately
represents the number of servers that need to find out about the
location of the nameservers for FOO, and not the number of
entities in FOO or how often _they_ are queried. If each of
those servers sees 50% fewer requests involving FOO, or even 90%
fewer, the 50 kiloquery number for the root servers will be
unchanged.
Now, we introduce BAR and BAR's existence does just exactly what
you posit -- it reduced the number of subdomains of FOO that are
queried by some number, and produces some numbers for BAR. But,
unless it is sufficiently successful to cause some of the
servers to lose interest in FOO entirely, it won't impact the
root load due to FOO at all. It will, however, increase the
root load due to the introduction of BAR. From the root
standpoint, the worst case is that the introduction of BAR
reduces the number of queries for FOO to each forwarding server
by 50 or 75%, while getting each of them at least one query for
a subdomain of BAR. That means 50 kiloqueries on the root for
FOO and 50 kiloqueries on the root for BAR.
And what happens to ".re" relative to ".com" has nothing to do
with the story.
At least that is the theory.
john