Top Stories

• The number you have reached is not in service
• What Happened To WWW.FIDONET.ORG?

The number you have reached is not in service
Carl Austin Bennett 1:249/116

Much has been said over the last two weeks about all the various route lists. Entries were flagged with TOMBSTONE or MISSING HOP in one of the lists where routes once pointed to nodes that no longer exist; the other list had defaulted all of these to respective RC's.

All too easy to point fingers when it came to questions of accuracy.

Unfortunately, the need for a more accurate route list is only part of the problem. The nodelist itself is too often incorrect.

For instance, behind a routing entry like:

; 1:1/117 No route available TOMBSTONE

or the more euphemistic default route:

; 1:1/117 1:297/11 1:140/1 14 20010316 RC14

hides the rather embarassing reality that the underlying node most likely just does not exist and has been dead for more than a year.

1:1/117 was ex-RC14 Ray Brown's support site for Tom Jennings' original FidoBBS[tm] package. FidoBBS[tm] was created in the early 1980's and has long since been abandoned. It didn't survive Y2K.

TomJ had left the network many years ago; the RC14's FidoBBS site at 1:1/117 dropped offline in early 2000 never to operate again.

The node's still in the nodelist, although Ray's been gone for a year.

While an empty FIDOBBS support echo is still on the backbones, the original FidoBBS[tm] package itself is now virtually unusable.

Despite the efforts of subsequent co-ordinators, not only was an updated ROUTELST.R14 last seen in late 1999 but the nodelist itself contains a most awkward mix of some live nodes, many disconnected lines and even some just plain wrong numbers.

It's in this context, with both nodelists and regional routelists severely inaccurate in places, that the creators of these ERNROUTE and DIFF files attempted to determine who's still connected where.

As much as I hate to have to say it, that isn't going to be an easy task.

The problems go beyond the routelist. In many places FidoNet has no idea whether some systems or even entire nets even still exist. The use of a regional "default route" - sending their mail to RC's or REC's if no valid path exists - might help to hide the problems, but it is not a solution.

The original idea when the St. Louis-format nodelist was created in the mid-1980's was to split the task of maintaining nodelists among various co-ordinators so that each could ensure the accuracy of their local segment. For many years, this system worked well. It's beginning to break down now, largely because as ever-increasing numbers of BBSs silently close their doors the co-ordinator positions become vacant without warning.

It's too easy now to find systems like NC293 or NC299 that respond with "the number you have reached is out of service" despite being listed in the nodelists as active sites. Any routelist built from this info could well be attempting to route mail to BBSs that are long gone.

Any nodelist depending on updates from these missing NCs also breaks.

In the very early days of FidoBBS, there were two key Fidonet sites: TomJ's site Fido #1 in San Francisco (his local net 1:125 has long since folded) and the nodelist keepers' site Fido #51 in St. Louis (net 1:100).

Tom can be found on the Internet, but please don't bother calling the telephone number listed for 1:100/0 in this week's Fido nodelist.

It's someone's voice line. A wrong number.

Of ten systems listed for 1:100 St. Louis, at most one or two are still valid. A few answer voice but most of the numbers are now disconnected.

It was one and a half decades ago that the group of sysops in St. Louis had split Fido's growing nodelist into local net/node entries so that it could be more readily maintained and be kept accurate. Perhaps, before anyone creates yet another route list to try to route mail to yet another local net that no longer exists, the nodelist should be repaired.

The nodelist was the glue that holds Fido together. It's come apart now.

The number you have reached is not in service; please check the number and dial your call again. This is a recording.

What Happened To WWW.FIDONET.ORG?
By Lawrence Garvin

Over the past several weeks, participants of the FIDONEWS echo (and a few others) have observed problems reaching the website at http://WWW.FIDONET.ORG. There has been a lot of conversation, accusation, innuendo, and confusion about this situation. I'm going to attempt, in this article, to walk back through the whole situation in some sort of organized fashion and explain what the situation is and what it will take to fix it.

In the old days (this is prior to approx Feb 2000), Pennsylvania Online operated on the IP Network 198.69.90 -- a number I know well as I was an Fidonet/FTP client of PAOnline at that time. In February, 1988, the FIDONET.ORG domain was created. To the best of my knowledge it has always been hosted at Pennsylvania Online, though for our purposes that information is trivial. What is significant is what exists in recent years.

As of June, 1997, and perhaps earlier, though I cannot verify that information, there existed a computer system at Pennsylvania Online called http://FIDONET.FIDONET.ORG at IP Address 198.69.90.5. Among other things this machine was the FTP server for the FTPHub at Pennsylvania Online. It also hosted the website for WWW.FIDONET.ORG.

Sometime recently, and I'm speculating February, 2000, based on dates recorded in transactions in the Whois databases of Network Solutions, Inc., new IP Network Addresses at Pennsylvania Online were added. The new network(s) included 216.220.160.0.

As a result of this addition, and perhaps for other reasons I'm not aware of, the www.FIDONET.ORG systems were moved from the 198.69.90 network to the 216.220.160 network, apparently in February, 2001. Perhaps because the connection upstream from 216.220.160 was better than the one from 198.69.90. It really matters not why, just that they were. Under normal circumstances moving a computer system from one IP network to another is a trivial issue; especially when both networks are owned and operated by the same entity, as in this case.

The changes normally necessary to effect this switchover involve changing the IP Addresses listed in the DNS Servers for the affected domain, in this case FIDONET.ORG, and waiting a few hours. These changes were completed correctly. They can be verified by using a DNS utility called 'nslookup' and directly issuing a query to the Domain Name Server that is authoritative for the FIDONET.ORG domain to list the addresses registered. On my OS/2 system, the process goes like this:

[G:\temp]nslookup - dns1.paonline.com
Default Server:  dns1.paonline.com
IP Address:  216.220.160.7

> ls -t A fidonet.org.
[dns1.paonline.com]
 fidonet.org.       server = dns1.paonline.com
 fidonet.org.       server = dns2.paonline.com
 z2                 server = ns.bofh.it
 z2                 server = ns0.fido.net
 z2                 server = ns1.fido.net
 z2                 server = ns4.fido.net
 z2                 server = ns.datanova.se
 z2                 server = ns2.corbina.net
 z3                 server = verdi.tardis.net
 z3                 server = fidonet.fidonet.org
 z4                 server = dns1.paonline.com
 z4                 server = dns2.paonline.com
 z5                 server = dns1.paonline.com
 z5                 server = dns2.paonline.com
 z6                 server = ns.shim.org
 z6                 server = ns2.shim.org
 z6                 server = fidonet.fidonet.org
 gnfido             server = ns.gn.apc.org
 gnfido             server = ns1.igc.apc.org
 fidonet            216.220.174.11
 www                216.220.174.11
 ftp                216.220.174.11
 n340.z1            server = ns1.spydernet.com
 n340.z1            server = fidonet.fidonet.org
 www.z1             216.220.174.11
 ftp.z1             216.220.174.11

You can see from this list that the three FIDONET.ORG systems are listed and assigned to IP Address 216.220.174.11, and in most other circumstances this would end the conversion process.

However, a couple of unique conditions exist that are complicating the process for some people to access WWW.FIDONET.ORG, and, unfortunately, only George Peace can fix them.

The first condition is that although WWW.FIDONET.ORG points to the same IP Address as FIDONET.FIDONET.ORG, apparently WWW.FIDONET.ORG has been created as a Virtual Web Server on that machine and is configured to redirect all web service requests to FIDONET.FIDONET.ORG. Even this would not be a real issue since FIDONET.FIDONET.ORG is the same computer system (though I do have reservations about the efficiency of redirecting an address to the same machine). A more appropriate configuration would be to list WWW.FIDONET.ORG in the DNS as a CNAME entry pointing to FIDONET.FIDONET.ORG and removing the redirections.

A second, more critical, condition exists that is causing the interference with some people to access the Fidonet Web Site. When a web user enters http://www.fidonet.org into their web browser of choice, a query is sent to the Domain Name Service to retrieve the IP Address of WWW.FIDONET.ORG. In every case, the address returned is 216.220.174.11. This part of the DNS is working properly.

The browser then sents a request to 216.220.174.11 to retrieve the home page for WWW.FIDONET.ORG. But the redirection in place sends a message back to the browser that says "The stuff you want is actually at FIDONET.FIDONET.ORG, go get it from there". The web server is dumb as to the fact that it's the same machine. So, the browser repeats this process and sends a query to the Domain Name Service to retrieve the IP Address of FIDONET.FIDONET.ORG -- and here's where things start breaking down.

This gets very complex inside the operation of the Domain Name Service. I'll do my best to describe it in simple terms. If I fail, please feel free to send echomail (in FIDONEWS), netmail, or email and I'll be happy to try again. Another good source is the book "DNS And BIND" published by O'Reilly and Associates.

So, what happens at this point, apparently, is one of two things. Some computers, like mine, who have already identified an address in the FIDONET.ORG domain, retain information in their cache as to where they received that DNS information from. The next time a query needs to be made for an address in that domain, they retrieve the information they have on the "authoritative server" from the cache and send the query direct rather than going up the chain and back down. For those computers, they get back the real IP Address of FIDONET.FIDONET.ORG (216.220.174.11) and promptly view what purports to be the Fidonet.Org website.

But some other computers apparently are not so smart. They send out the query for FIDONET.FIDONET.ORG from scratch. The nature of the Domain Name Service is that queries always go from here, to the top, and back down. Hopefully, on the way up, a server will be found that knows the answer to the query. If not, they refer the query to the next higher server. When it gets to the top (the root servers) they refer the query to the "authoritative server". In this case, the "authoritative server" for FIDONET.ORG is DNS1.PAONLINE.COM. However, if any server along the way claims to know the answer to the query, it answers the query, and reports the answer as "non-authoritative". This is essentially what is happening. Incorrect information is being provided by a non-authoritative server (but only because that information should be correct, and it isn't).

In the particular situation that affects FIDONET.FIDONET.ORG, there is an additional piece of information registered in the Domain Name Service that is causing these second type of queries to be given incorrect answers.

I'm going to back up just a bit to catch up on some details. In order for the root servers to know where the authoritative servers actually are (that is, their IP Address), each Domain Name Server must be registered with the registering authority. There are several authorities these days, but for purposes of this article, we'll concentrate only on Network Solutions, Inc., as they affect this situation exclusively. To register one's Domain Name Server, you fill out a Host Registration, which includes the system name, your contact info, and the IP Address of the system, and that information is submitted to the Whois database at Network Solutions, Inc., along with the Domain Name Registration. Then the Host Registration information is also submitted to the Domain Name Service. These Host Registrations are then "hard-coded" into the root servers so that the IP Address of the authoritative server for any domain can be given to a query presented.

Having covered that, our fundamental problem with FIDONET.FIDONET.ORG is that there exists a Host Registration record for that system with the old IP Address of 198.69.90.5 and the only person that can change this information is George Peace. It's an arguable circumstance that the Host Registration record should have never existed in the first place, as I don't know whether or not that system was ever a Domain Name Server for FIDONET.ORG; what's certain is that it is not a Domain Name Server at this time and, therefore, does not need to be there at all.

The week before last I sent an email to George Peace asking him to look into this. I received no reply. Late last week I submitted a renegade request to delete the Host Registration record. An interesting feature of the Whois database system is that while only the authorized person(s) can actually implement a change to the data in the database, anybody can submit a request to make the change. What happens in this case is that a submission to delete the Host Registration record is flagged because the submitter is not authorized to make the change. Then, Network Solutions sends a notice to the authorized person(s), in this case George Peace, informing them that somebody attempted to make a change. The authorized person(s) then have an opportunity to approve the change, or prohibit the change. If they fails to respond, the request is automatically denied.

In any event, until George Peace authorizes a change, or Network Solutions determines the entry is invalid -- which would take a formal complaint, I imagine -- many persons are going to have challenges viewing this site. There are numerous ways to workaround the situation, but all of them involve George Peace, ultimately, to implement a permanent fix. George seems to be unresponsive to these requests.

All of the above has absolutely nothing to do with the parallel discussions concering the content of the site at WWW.FIDONET.ORG, which, although clean in presentation (IMHO), does contain some out of date information -- most notably broken links to non-existant echomail distribution hubs, as well as the pratically non-existant Zone 1 site. The links to Zone 2, Zone 3, and Zone 6 are functional, though no content exists at the Zone 3 site. Zone 4 and Zone 5 do not have a link configured.

As to the update of the content at the site, much has been said and written about who is, or is not, responsible for that content. That discussion is really beyond the scope of this article as it matters not what that content is, or is not, until the world can reliably navigate to the site.

I will also leave the suggestion to those most concerned that sometimes the telephone is the best way to conduct business such as this. I would imagine a polite telephone call during normal working hours to George at Pennsylvania Online with a polite request to look into the Host Registration issues with FIDONET.FIDONET.ORG and an explanation of how that is impacting access to the site by a significant number of persons would go a long way to resolving this issue. There are several fixes available, and most of them take merely seconds to implement. The ones that come immediately to mind, in order of preference are:

1. Remove the redirection from www.fidonet.org to fidonet.fidonet.org and let the system at 216.220.160.11 answer as www.fidonet.org, totally removing fidonet.fidonet.org from existence.
2. Edit the DNS to list www.fidonet.org as a CNAME to fidonet.fidonet.org (which should permit those clients having difficulty to get the correct IP address to fidonet.fidonet.org while attempting to resolve fidonet.org via the CNAME entry).
3. The ultimate, and correct, though of longest duration fix, is to remove the unnecessary Host Registration record for fidonet.fidonet.org from the Whois databases at http://www.networksolutions.com

Personally I think all three should be accomplished.

One thing is certain, though. Until these issues are resolved, any discussions or arguments about content are an exercise in futility.

Lawrence Garvin
1:106/6018