[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
domain name resolution is not as clear-cut a problem as one might think
Date: Tue, 15 Dec 87 18:31 PST
From: Jerry Bakin <Jerry at MARLOWE.inference.dialnet.symbolics.com>
A domain resolver takes the
request from a user concerning an address and formats it according to
spec, and ships it off to the name server to be answered. The name
server determines the answer (it may determine someone else to ask) and
sends that information back to the resolver who sends it back to the
Unfortunately, the RFCs were misunderstood (an easy thing to do) and
while all of the functionality seems to have been implemented, the
functionality was incorrectly split between the resolver and the name
server. Essentially, a Symbolics domain resolver is expected to walk a
tree of all possible queries and the Symbolics name server is supposed
to simply answer each query, yes or no. According to the RFC, the
resolver should only start the tree at the top node and the name server
should keep expanding the tree until an answer is found. The net effect
(pun intended) is that if an ARPAnet domain resolver happens on the
exact question to ask the Symbolics name server all is well. But, if it
doesn't ask the exact question, but asks instead any correct question,
the Symbolics name server will not take the initiative and follow the
It's unusual for me to defend the Giant Amoeba, but in this case
Symbolics isn't necessarily wrong (and I don't believe the person
resonsible is on this list). Your statement is not completely
correct. It's true that "the RFCs were misunderstood," but it's not
clear whether by the authors or the implementors. There are
implementation issues (such as why should a central nameserver take
all its cycles recursively servicing requests for resolvers which may
be doing nothing but waiting for a reply anyway?) and semantic issues
(if you're only allowed to use authoritative data and data the
nameserver itself doesn't have locally can't be authoritative than how
can a recursive request be used?). If you're really interested in
this get on namedroppers. But the question of how this is all to work
is still up in the air.
G. It doesn't seem like it should take more than six months (from NSLUG
to now) to fix this. To implement the basic functionality from what
they have should only take a few weeks...
H. They are very tight lipped about it all. The code was at first
restricted and now it is supposedly optional. Well terrific, I have
to buy the source so I can fix the problem.
So I think the implication is that anything they do will be "wrong"
(and in fact will be pessimal for certain customers). But they should
make the sources BASIC and allow people to customise them to their own
vision of how they want their namespace system to work.
And on another issue,
just what is customer-reports for? Several have told me on occasion
that they are not allowed to fix code or issue patches.
I. I have offered to take the code, fix the problem, return the code
and all for free. I have never heard a response to that.
Customer-reports, like most companies' support departments, consists
of people who know how to read manuals. Technical people go crazy in
such a job. Therefore I generally use it for complaints rather than
for things which I want fixed in the near term. What works is just to
send them your code; that way they can send the code to the
responsible person, and maybe then it'll be "fixed in the next release."
All is not lost however, we have recently made use of a very cheap
product ($50 gets you executable and SOURCE to PMDF) to hook VMS up with
a domain mailer (not store and forward) which lets you use normal VMS
mail to send/receive mail over a phone line from VMS systems with PMDF
or UNIX systems with MMDF.
I don't LIKE mmdf/pmdf, but I don't TRUST the pos Symbolics mailer,
whose probability of delivery is even worse than sendmail's.