At 11:43 PM 7/18/99 -0700, you wrote:
>
>> >In other words, if there were to be established a viable non-ICANN root
>> >system, then all this effort to establish advisory committees, Supporting
>> >Organizations, WIPO rules, ADR, taxes/fees, etc would all exist only on
>> >those things willing to voluntarily accept the rules derived from the
>> >ICANN root (and possibly the ICANN TLDs). Everyone and everything else
>> >would be exempt.
>
>...
>
>> Which certainly has its appealing aspects. But 'splain something: I'm
>> sitting here on, say, a xxx.com or a xxx.net ISP, and I want to search a
>> .per or a .biz
Good piece of work, Karl. So my surmise was in large correct, although as
Gene pointed out, if I understand this correctly, that at least in some cases
I, as the end user, would be selecting which ones of what you call the
"resolving servers" to point to.
>
>In general we need to begin by distinguishing between the typical end user
>machine and an intermediary machine that I'll call a resolving server.
>
>In general when one configures a user machine one of the configuration
>parameters is one or more IP addresses for one or more resolving servers.
>(This is often done via DHCP, so the user never even sees it happening.)
Don't know what DHCP means, but I'll take your word for it.
>
>These intermediary servers do the real heaving DNS lifting on behalf of
>the end user machines.
>
>These intermediary machines are usually operated by an ISP or a corporate
>or organizational administration. Some of us techies run our own.
>
>In any case, these intermediary machines are where the knowlege of which
>root system to use is to be found. Generally this is a file named
>"named.cache", or "cache.db" or something like that.
>
>I'll attach a copy of a commonly used one at the end of this note.
>
>This file tells the intermediary server what root servers to use.
>
>If the intermediary uses a file that lists root servers that know about
>.per and .biz, as well as the normal TLDs, .com/.edu/.net/.org ... and the
>various ccTLDs, then you will have no problem resolving any name in any of
>that set of TLDs.
>
>If the intermediary uses a file that lists root servers that don't know
>about the TLD you are uttering in your query, then you will get an answer
>that says "we dunno".
>
>It all comes down to what I have been calling the "inventory" of TLD
>references that are adopted by the operator of the root server group which
>your intermediary server points to.
Analogous to what news groups are contained within whatever news server
my "intermediary server" or ISP connects to. Hmm?
>
>If the root server group operator has a big inventory, you can resolve
>lots of TLDs. If the root server operator has a small inventory, your
>name resolution experience will be diminished.
>
>It takes only a short period of time (usually tens of seconds) to re-aim
>one of those intermediary servers from one root system to another -
>generally one simply copies a new cache.db file and then executes a very
>simple three word command.
>
>As a general matter, those who operate root or TLD servers do not allow
>those servers to accept "recursive" queries. Rather the work of walking
>down through the DNS label hierarchy is expected to be done by the
>intermediary server and not by the root or TLD servers.
>
>That may be a bit cryptic, but it means that as a general matter, an end
>user computer needs to use an intermediary server that is willing to do
>the "recursion". Fortunately virtually all intermediary servers are
>willing to do this.
No, that's not cryptic at all. The TLD server expects the intermediary to
do its own walking through that TLD server's files: when I file a patent
application with the USPTO and refer to prior patents, I have to send to
the USPTO the copies of ITS patents that I've cited!
>
>But it does mean that the end user tends to have to select which root
>server group (and hence the inventory of TLDs) by the indirect method of
>selecting an intermediary server that, in turn, points to the desired root
>group.
So it makes a difference which ISP one uses in the limited sense that
the one selected should point to the root group one will usually want to
have queried, but given two ISPs that point to the same root group, then
which ISP was used would NOT make any difference.
>
>It is easy and relatively inexpensive, however, to set up intermediary
>servers. The main problem typically being administrations that have
>firewalls that limit the passage of outgoing DNS queries to packets
>originating from a limited set of machines. In those cases, some
>additional doors may have to be configured into the firewall.
I don't have a firewall problem.
>
>Much of this may sound a bit complicated. But it's really not all that
>hard to do in practice.
(I can make my way through just about any good explanation, and yours
is a good one. Good explanations are my specialty, as also is recognizing
bull shit: I write patent applications, including a good many in engineering,
and it is a constant battle on my part to extract anything meaningful from
inventors: go to http://164.195.100.11/netahtml/search-bool.html and do a
search on William Lovell in the attorney/agent field and you'll see the high/
low tech crap I deal with. :-) (One of the latest was my own computer
security invention -- a hardware partial solution to a problem: I call it my
"Randall Schwartz" invention: does that mean anything to anyone here?)
>
>Below is a copy of the file that intermediary servers use to find the
>"legacy" set of root servers.
By "legacy" do you mean the set passed on down from DARPA and all that?
And thanks, Karl. The reason I am NOT being a typical (I don't care how it
works, just make it work) end user, even though I often speak on behalf of
same, is that this particular stuff relates to another invention I am
personally
working on, hence I need to pin down this "prior art."
>
>To change the roots that one uses, one simply drops in a different version
>of this file and pokes the DNS server software to say "new configuration
>is available, use it".
Got it.
>
>(An somewhat different method, which I won't get into here, and which is a
>bit harder, but more flexible, is for a user with a box with a real
>operating system, to run their own root with their own favorite inventory
>of TLDs.)
I might end up there after I get onto ADSL (and Linux?) and could give better
service.
And thanks again.
Bill Lovell
>
> --karl--
>
>
>; This file holds the information on root name servers needed to
>; initialize cache of Internet domain name servers
>; (e.g. reference this file in the "cache . <file>"
>; configuration file of BIND domain name servers).
>;
>; This file is made available by InterNIC registration services
>; under anonymous FTP as
>; file /domain/named.root
>; on server FTP.RS.INTERNIC.NET
>; -OR- under Gopher at RS.INTERNIC.NET
>; under menu InterNIC Registration Services (NSI)
>; submenu InterNIC Registration Archives
>; file named.root
>;
>; last update: Aug 22, 1997
>; related version of root zone: 1997082200
>;
>;
>; formerly NS.INTERNIC.NET
>;
>. 3600000 IN NS A.ROOT-SERVERS.NET.
>A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
>;
>; formerly NS1.ISI.EDU
>;
>. 3600000 NS B.ROOT-SERVERS.NET.
>B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107
>;
>; formerly C.PSI.NET
>;
>. 3600000 NS C.ROOT-SERVERS.NET.
>C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12
>;
>; formerly TERP.UMD.EDU
>;
>. 3600000 NS D.ROOT-SERVERS.NET.
>D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90
>;
>; formerly NS.NASA.GOV
>;
>. 3600000 NS E.ROOT-SERVERS.NET.
>E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10
>;
>; formerly NS.ISC.ORG
>;
>. 3600000 NS F.ROOT-SERVERS.NET.
>F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241
>;
>; formerly NS.NIC.DDN.MIL
>;
>. 3600000 NS G.ROOT-SERVERS.NET.
>G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4
>;
>; formerly AOS.ARL.ARMY.MIL
>;
>. 3600000 NS H.ROOT-SERVERS.NET.
>H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53
>;
>; formerly NIC.NORDU.NET
>;
>. 3600000 NS I.ROOT-SERVERS.NET.
>I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17
>;
>; temporarily housed at NSI (InterNIC)
>;
>. 3600000 NS J.ROOT-SERVERS.NET.
>J.ROOT-SERVERS.NET. 3600000 A 198.41.0.10
>;
>; housed in LINX, operated by RIPE NCC
>;
>. 3600000 NS K.ROOT-SERVERS.NET.
>K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129
>;
>; temporarily housed at ISI (IANA)
>;
>. 3600000 NS L.ROOT-SERVERS.NET.
>L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12
>;
>; housed in Japan, operated by WIDE
>;
>. 3600000 NS M.ROOT-SERVERS.NET.
>M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33
>; End of File
>
