As someone to sits on the boundary, I want to add a few clarifications
to the discussion going on between Dan and Ned and others...
(1) To say that the central administrations of e.g., BITNIC and the DDN
NIC should do more is to make a statement that ultimately translates
into a requirement for dollars. We are in the interesting situation
that, when offered the "opportunity" to put more dollars into the pot to
pay for improved services like this, institutions on both the BITNET
side and the Internet side have been less than enthusiastic. Although
the long-awaited NSFNet NIC RFP may help to reverse the situation, it is
interesting to observe that, for many years the Internet community has
survived on a mostly-free-ride on US Department of Defense funds and
activities. One should, unfortunately, moderate one's expectations in
circumstances like this.
(2) The beginnings of this discussion have identified a problem within
BITNET that some of us who are supposed to worry about technical
concerns in that area were not aware of, or not clearly focused on. We
are now, and have started a discussion on how to handle it. Give us a
few days, ok? :-)
(3) It is clear that, however a BITNET site construes DOMAIN NAMES,
accuracy of that table wrt national-level domains requires that someone,
somehow, tell Hank (or someone else) when a new country-level domain has
been added. If the logic people want to apply with BITNET should apply,
symmetrically, to, e.g., uucp and FidoNet environments, then we really
need to develop a general procedure for notifying relevant maintainers
(or everyone) when a new root-level domain is added. We don't have such
a mechanism at present. For BITNET, at least, I've wanted to clarify
what we want to be doing before asking DDN-NIC and IANA to establish
such a procedure.
(4) IMHO, there is a flaw in the "local tables and then bounce"
model which moves it well away from optimality. The flaw is that such
local tables cannot contain all of the DNS. If I send something to
foo.bar.XX and it bounces locally because XX isn't a country, fine. But
if I send something to foo.XX.PE, and there is no "xx.pe" subdomain, it
is going to the (BITNET->Internet) gateway, which will have to do
something. If the PE domain is represented by a single wildcard (common
for many country domains), then foo.XX.PE is going to need to go to the
Mail eXchanger to to the country itself (off SMTP/IP-Internet) before a
"no host" determination can be made and returned to the originator.
These cases may not look very different to the user, and we are
optimizing only the cases in which the last few characters are wrong.
(5) Even Ned's "just put all of the country codes in" won't help very
much in the current situation. While it would have helped with Peru, it
is my understanding that there is a large and growing queue at the NIC
of registration requests from emerging countries of the former Soviet
Union. That queue is on hold because the country-entities don't have
3166 codes. The process of getting new codes in and official is very
slow. When the codes are officially designated, I'd guess that the NIC
will know, and start registering, before Ned has a chance to produce new
tables and a new release. There will always be coordination and
sequencing problems until BITNET hosts (and uucp, and Fidonet, and
various internal company networks) all have direct access to the DNS.
I'm not holding my breath.
(6)
Believe it or not, a lot of them have actually been advised not to use DNS by
various so-called experts!
Some are even MILNET sites that have command orders to not use DNS.
:-(
(7)
The tables I have are dated Feburary 1992 (no day is given). They usually
come out at the beginning of the month. You might try to argue for a
middle-of-the-month update or something.
We have enough problems getting sites to update once-monthly tables.
There are lots of reasons for things like the DNS that can be updated
every few minutes if necessary. Unfortunately, the store-and-forward,
no end-to-end virtual circuit, networks can't have such a thing without
phenominal overhead.
Again, the problem is motivation and resources. There are non-DNS
IP/Internet sites that manage host table updates about every six months,
creating a similar situation.
--john