domain name resolution is not as clear-cut a problem as one might think

[David Vinayak Wallace <GUMBY@mc.lcs.mit.edu>]

    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
    user.

    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
    search tree.

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.