Re: [ifwp] Re: The Non-Profit Issue Again

[Jeff Williams <jwkckid1@ix.netcom.com>]

Greg and all,

  I suppose that we are at completely opposite ends of this argument as
it relates to increased costs for registration fees if there are new TLD's
added to the current root structure.  We believe that increased competition
with the addition of new "Name Spaces" i.e., TLD's, will force down costs
rather than increase them. The addition of TLD's will also provide for
more choices from which the market place has to choose from.

  As to Keith Moore's excerpt that you kindly provided, we have some
problems with definitive statements not based on reasonable research
and definitive documentation other than existing BINDv4 and BINDv8
implementations and the current Legacy Root server architecture, that is
fairly old at this stage.  No raw simulated data that I am aware of
by the IETF is available for a in depth evaluation.  Hence this led us (Myself
in particular), to deduce that possible a new and innovative approach may] be
in order back in 1995. In september of that year we finished two vastly
design and archtechualy different products that compliment each other,
SROOTS and Bindles.  Under vigorous simulated testing and some 30
current implementations, we have found that the caching performance
of Bindles to be several orders of magnitude improvement to
either BINDv4, especially and BINDv8, to a slightly lesser degree.
Combining Bindles and our SROOTS, we have come to the two
following preliminary conclusions, that are partly behind some of the debate
and discussion regarding DNS.

1.) Using current DNS architecture, and the current BINDv4 or BINDv8
     now from ISC, definitely may reach some limitation in TLD addition
     too the current ROOT structure, even given that additional ROOT
    servers are added to the current ROOT structure, due to Caching
    performance issues.  The currently excepted perception (FACT) that
    this is indeed the case, there is a need to improve caching performance
    and add additional Root servers to the DNS.  Form statements from
    ISC's David Conrad, BINDv9 may provide the caching improvements.
    It is not known definitively whether additional ROOT servers will be
    added, however if new TLD's are added this would be a wise thing
    to do.  Hence we believe that as one possibility that both improvements
    in caching performance and new ROOT servers in the current DNS
    architecture should be done.

2.) We believe based on our extensive simulated testing that the DNS
     architecture migration to a Shared Roots/registry system would better
     serve the internet community in the areas of both performance and
     redundancy/stability.  Hence our decision to develop SROOTS.


Greg Skinner wrote:

> Kent Crispin <kent@songbird.com> wrote:
>
> >But caching performance depends on other factors as well, some of
> >them at the leaf resolver.  If the working set at the leaf starts to
> >be larger than the cache size, things can deteriorate very quickly.
> >But the leaf resolver cache size is dependent on leaf node hardware
> >and software, and the number of entries in that cache depend on user
> >and software behavior.  [For example, it is my impression (though I
> >can't point to hard data) that the percentage of inverse lookups has
> >increased a lot in the past year or two because of security concerns
> >about ip addresses that aren't in dns.]
>
> I don't have any hard data either, but from my experience in the
> firewall community and subsequent interactions with people developing
> anti-spamming software, this is true.  This aside, the proliferation
> of spiders, bots, etc. will make increasing demands on the DNS as a
> whole.
>
> In the process of looking over some of the DNS comments at the NTIA
> site, I found another argument against adding thousands of new TLDs by
> Keith Moore.  I quote below:
>
>      With the current DNS protocols, for various reasons related to
>      performance, it is important to limit the number of branches at the
>      top level of the domain name tree. Efficient operation of DNS
>      requires that a client application, or a DNS server operating as a
>      proxy on behalf of the client, be able to cache intermediate lookups.
>      For example, a proxy server that already knows which DNS server
>      can be consulted to find names in .COM, need not consult a root
>      server again to find this out. Similarly, if the name servers for
>      XYZ.COM are already known, it is not necessary to ask the .COM
>      domain servers where to find them, in order to look up the name
>      WWW.XYZ.COM.  However, with a very large number of top level
>      domains, there would be only a small chance that a proxy DNS
>      server already knew where to find information about of some
>      domain ".XYZ", and would thus have to consult one of the few root
>      servers to determine this. This would increase the load on the
>      root servers, and create a demand for more root servers. This
>      both increases the cost of operating the DNS root servers and
>      decreases the reliability of any Internet application which uses
>      multiple domains names under different gTLDs.
>
>      It is also important to limit the number of servers for any DNS
>      domain: when there are too few servers, performance will suffer
>      and there will be no recovery from failures; and when there are
>      too many servers, it will be difficult to keep them all
>      synchronized.
>
> This all seems reasonable to me.  Increased costs would be a concern
> to customers as well, who would see increases in registration fees.
>
> Is anyone doing any research into this?  It seems like a good master's
> thesis project, at least.
>
> --gregbo
>
> __________________________________________________
> To view the archive of this list, go to:
> http://lists.interactivehq.org/scripts/lyris.pl?enter=ifwp
>
> To receive the digest version instead, send a
> blank email to ifwp-digest@lists.interactivehq.org
>
> To SUBSCRIBE forward this message to:
> subscribe-IFWP@lists.interactivehq.org
>
> To UNSUBSCRIBE, forward this message to:
> unsubscribe-ifwp@lists.interactivehq.org
>
> Problems/suggestions regarding this list? Email andy@interactivehq.org.
> ___END____________________________________________

 Regards,

--
Jeffrey A. Williams
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail jwkckid1@ix.netcom.com
Contact Number:  972-447-1894