Re: Domain name, domain name, what shalt thou be, domain name?


Philip Prindeville [CC] (philipp@Larry.McRCIM.McGill.EDU)
Mon, 11 Apr 88 22:54:26 EDT


(I will be happy to move this discussion to a more appropriate list, if you
wish to continue this "in public".)

        A typical site needs a simple way to generate an INADDR-ARPA database
        from its name->address database. A many-many map from SOA zones to
        networks makes it hard to automate this generation.

IN-ADDR.ARPA records are undeniable a kludge and an afterthought. It seemed
that the inverse query was implausible computationally for doing address to
name mappings. There is no clean solution. A mapping that is optimized in
one direction can be very hard to compute inversely (such as hashing).

        I think it very undesirable to have lots of hosts with one authority
        for their name->address translation and a different one for
        address->name translation. In some cases it's necessary, I suppose,
        but the number of such hosts should be minimized so as to maximize the
        modularity of the database. A much cleaner scheme is to have a host's
        real domain name directly depend upon its network number, and instead
        have a pointer record in the other domain allowing an alias. The
        domain system as presently defined is sufficiently general to allow
        both schemes; which one gets used becomes a question of taste and
        pragmatics.

If JPL is willing to give him a subnet number, then handling address to
name translation as well shouldn't be putting them out. What is "desirable"
and "clean" is not always convergent with what is necessary. Creating "fake"
names to facilitate solutions is hardly a "clean" approach.

Having a host's name depend on its address is an intolerable restriction.
It completely negates the distributed capability of the domain name system.

In the example, you should be able to have:

$ORIGIN s.49.128.in-addr.arpa.
1 IN PTR (some name for 1)
2 IN PTR (some other name for 2)
... IN PTR (...)
h IN NS Some-Server.Sun.Com.
... IN PTR (...)

in JPL's nameserver for s.49.128.in-addr.arpa and have it point to one
of Sun's nameservers and make it authorative for that particular host.
This would allow the "proper" administration of the name. But as I said,
you could just as easily have JPL administer the mapping locally.

-Philip



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:41:55 GMT