[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RRE: The InterNIC: a case study in bad database management
I've dropped a note to Jonathan Kamens pointing out that
InterNIC is a monopoly, and therefore has no real reason to
keep up any databases that don't directly generate money.
-Allen
From: IN%"[email protected]" 14-DEC-1996 02:53:56.61
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
This message was forwarded through the Red Rock Eater News Service (RRE).
Send any replies to the original author, listed in the From: field below.
You are welcome to send the message along to others but please do not use
the "redirect" command. For information on RRE, including instructions
for (un)subscribing, send an empty message to [email protected]
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Date: Fri, 13 Dec 1996 16:44:21 -0800 (PST)
From: [email protected]
Subject: RISKS DIGEST 18.67
RISKS-LIST: Risks-Forum Digest Friday 13 December 1996 Volume 18 : Issue 67
----------------------------------------------------------------------
Date: Thu, 12 Dec 1996 17:07:04 -0500
From: "Jonathan I. Kamens" <[email protected]>
Subject: The InterNIC: a case study in bad database management
(This message was also sent to comp.protocols.dns.ops .)
The InterNIC (http://www.internic.net) is responsible for Internet domain
name service for all top-level domains, as well as for second-level domains
underneath all the old ARPA domains except MIL (EDU, GOV, NET, ORG, COM).
Until a few years ago, domain registration services were provided by the
InterNIC for free. That changed when they convinced the NSF that its grant
money wasn't enough to cover their costs, so (amid much hubbub on the Net)
they started charging $50 per year for any second-level domain registration,
with the first two years (i.e., $100) payable in advance.
According to <http://rs.internic.net/nic-support/nicnews/stats.html>, the
InterNIC registered 638,788 new domains between August 1993 and September
1996. If I'm doing my math right, at $100 per domain, that's almost $64
million, or over $20 million per year. I would think that with that much
money, they'd be able to provide competent service to their customers.
Unfortunately, my experience has been that they're simply not doing an
acceptable job. Some examples:
*****
* Their automated systems do not function properly.
They've introduced a PGP-based system for authentication of domain
contacts. In other words, they allow domain contacts to register
their PGP public keys in the InterNIC public-key database, and then
requests which come from those contacts will only be accepted as
authentic if they are signed with the corresponding provide key.
Unfortunately, this system does not always work. Recently, I
submitted a series of twelve database modification requests to the
InterNIC in a single day. All of them were correctly signed with my
PGP key. Of the twelve requests, three were returned to me in
messages beginning, "We are not able to verify the PGP signed message
that you sent us."
To make matters worse, for one of those three failed requests, I received
a message claiming the the modifications I'd requested had been completed,
two days *before* I received the message informing me that they were unable
to verify my PGP signature.
I have asked the InterNIC multiple times why their system randomly fails
to verify valid PGP signatures. They have not responded to my inquiries.
Interestingly enough, another poster to comp.protocols.dns.ops claimed
that when he asked an InterNIC on the telephone about their PGP
authentication system, he was told that it is not currently working. That
would seem to indicate that the InterNIC is aware that there are problems
with it, and yet they continue to advertise it on their Web site without any
indication that it might not work for any given request.
* There are some data in the database which are impossible to update using
the templates they provide.
One of the types of data stored in the InterNIC database is hosts; in
particular, hosts which act as domain-name servers for domains registered
with the InterNIC have records in the database.
Host records include an organization name and address associated with the
host. And yet, the template for updating host records (available at
<ftp://rs.internic.net/templates/host-template.txt>) does not have fields in
it for updating that information! I believe that there are a couple of
other record types in the database which have this same problem.
This organization/address data has been described to me by an InterNIC
employee as an "old hold-over;" it seems that new host records do not have
organization and address data, but old ones do. Nevertheless, one would
think that when switching to a new format for host records, the InterNIC
would have either removed the obsolete data from the old records or
established a procedure for updating it.
Instead, the only way to update this information electronically is to send
a plain-text message to [email protected] explaining what you're
trying to do, and then hope that whoever reads your message will be
competent enough to understand what you're asking for and do the update by
hand. Which brings me to my next point...
* When asked how to do something that is not handled automatically by their
templates, their staff give incorrect answers (or simply ignore the query)
more often than they give correct answers.
Of the twelve requests mentioned above, six of them were handled
improperly by the InterNIC staff members who processed them. Iwn several
cases, I received a response instructing me to use a particular template to
make the changes I had requested, when in fact those changes had nothing
whatsoever to do with the template they told me to use.
I finally had to escalate my requests by sending "out-of-band" E-mail to
an InterNIC employee who has resolved problems of this sort for me in the
past, and she was able to "bounce" my requests to a high enough level that
they actually got processed.
Incidentally, the InterNIC introduced one or more typographical errors
into the data I sent them when processing six of my twelve requests (i.e.,
when they were done processing my requests, six of the twelve records I
asked them to modify had one or more typographical errors in them).
I suppose that sending incorrect answers is better than how things were a
few months ago -- then, if you sent a request that the person who read your
message did not know how to answer, he/she simply ignored it and sent no
response whatsoever.
* There are some data in their database which are impossible to update using
their current procedures.
Imagine this scenario... Joe Admin at Foo, Inc. is responsible for system
administration, including DNS administration. He therefore has a contact
record in the InterNIC database indicating that he works for Foo, Inc., and
he is listed as a contact for various domain, network, and host records, in
the InterNIC database.
Now, he leaves the company and takes a new job, with no further contact
with Foo, Inc. He doesn't bother to update his contact record in the
InterNIC database before he leaves.
Foo, Inc. would rather not let records remain in the InterNIC database
claiming that Joe works for them when in fact he does not. Therefore, they
want to contact the InterNIC and tell them, "Look, the information in Joe
Admin's contact record which says that he for us is incorrect. You can
confirm this by attempting to send E-mail to the address in the record, or
by calling the phone number in the record and asking to speak to him. The
person who answers will confirm that he no longer works there. Please
either delete the contact record completely or remove the information in it
which associates Joe Admin with Foo, Inc."
Sounds reasonable, right? Well, unfortunately, the InterNIC has *no
procedures whatsoever* for allowing a company to remove contact information
which incorrectly lists them.
I attempted to do just what I described, i.e., to get the InterNIC to
remove the contact record for a former employee of OpenVision who no longer
works here, and who I cannot contact to ask him to update his own record
(and considering that it's not hurting him in any way, I don't see that he'd
have any incentive to update it even if I could ask him to).
After several rounds of E-mail with the InterNIC, they called me on the
telephone to discuss what I was trying to do. Once on the phone with them,
I was "bounced up" through several layers of InterNIC staff, until I was
finally able to speak to a woman who was perfectly willing to admit that
yes, the scenario I described was a somewhat common one, and yes, it was
perfectly reasonable for a company not to want the InterNIC database to
associate non-employees with the company, but no, there's no way for anyone
but the owner of a contact handle to update it. "Perhaps we need to
establish a procedure for that, and I'll be glad to discuss that for you
with our customer service manager, but we don't have one right now," she
said, and she did not offer to make an exception and handle my particular
request manually without the blessing of a "procedure".
Presumably, this means that I could edit my own contact handle to
indicate that I work for any company that I want, and that company
would have no way to get the InterNIC to remove the fraudulent
information.
Similarly, presumably, that means that (to be a little morbid for a
moment), if someone listed in the InterNIC database dies, there's no way for
anyone else to get the InterNIC to remove the deceased's record from the
database.
When I pressed the woman about this, she said to me, "If you're a network
administrator at this company, you presumably have control over the mail
server" (an assumption which is not always true, and indeed isn't true in
this case; although I can ask the people who administer the mail server to
make changes and hope that they'll listen, I don't have the ability to make
the changes directly). "Well," she continued," if you send us a mail
message which claims to be from the former employee, asking for his record
to be deleted, we'll process it."
"Let me get this straight," I responded. "You're telling me that I should
forge E-mail to your system in order to delete this record." She confirmed
that interpretation. I said, "Surely you see the absurdity of that."
She responded, "Well, obviously, ideally we wouldn't want anyone forging
requests to our system, but in this case, that's the only way for you to
delete the record."
"What if the former employee had associated a PGP key with his contact
record before he left the company."
"Well, in that case, you'd need his private PGP key in order to delete the
record."
"But surely you know that's impossible -- the whole point of PGP is that
only the owner a private key has access to it. Even if I had access to the
file in which it was stored, I wouldn't know the correct password to unlock
it."
"Well, in that case, there would be no way for you to delete the record."
*****
There are a number of countries with strict laws about the collection of
private information in computerized databases. Database maintainers are
required to seek permission from all individuals who have data about them
stored in the database, to guarantee the security of the database, and to
establish working procedures for keeping the data in the databases
up-to-date.
The United States has few such laws (there are laws about specific types of
databases, such as credit and medical records, but no laws about databases
in general). Until I started dealing with the InterNIC, I didn't see much
point to them. Well, I've changed my mind. the InterNIC proves rather
clearly that left to their own devices, companies will not maintain
databases in a responsible manner.
Incidentally, nowhere on the InterNIC's WWW site can I find the address or
telephone number of the governmental office which oversees their grant and
handles complaints about their services. Several months ago, I sent them
E-mail asking for them so that I could file a complaint, to be considered
the next time their grant comes up for renewal. Like many of my other
messages to them, that request was ignored.
Jonathan Kamens | OpenVision Technologies, Inc. | [email protected]
------------------------------
End of RISKS-FORUM Digest 18.67
************************