Re: Classes other then IN

Hi,

--On Dienstag, Oktober 06, 2009 11:15:36 -0500 David Nicol 
<[email protected]> wrote:

> On Mon, Oct 5, 2009 at 6:07 PM, Richard J. Sexton <[email protected]>
> wrote:
>>
>> Classes might be an elegant solution
>
> If your definition of "elegant" is equivalent to "peg-whittling."
>
> the CLASS field was included back in the dim times before IPv4 had
> become entirely ubiquitous, and there were competing networking
> protocols with competing addressing notations, and it made perfect
> sense to imagine serving the network address of a networked resource
> under the same name in DecNet, IPX, Appletalk, etc formats. Thus the
> lack of differentiating.

For *exactly* this reason it was never really used.
Consider a couple of VAXes sitting on DECNet.
If they like to lookup DECNet Phase IV addresses (actually an ISO-IP 
protocol) they will do the lookup via DECNet. Thus one has to bind the DNS 
Server on DECNet (of course).

However, DNS is essentially a NAME RESOLUTION protocol. It maps one name to 
another one (lets say string); except for A and AAA adresses.
Thus, in todays use, under a COMMON namespace you have different resources.
By invention of the CLASS attribute you have entirely DIFFERENT namespaces.

Ther is really no good reason, why you should put them on the very same 
server.


> After background pondering this for a couple hours, it seems like a
> reasonable modern use, given the unchallenged sovereignty of the IN
> addressing scheme, for an additional class, might be geo-coordinates.
> A LL class might request latitude/longitude coordinates of a named
> resource.  Physical coordinates are in wide use and are deeply
> separate from IN addresses in the ways that might justify assigning
> them a CLASS designator.

I pretty much doubt this. You could use TXT Records to store coordinates; 
and assign to clients coordintes even in a dynamic DNS and mobile IP 
environments.

Check for SSH Fingerprint RRs.

regards.
--eh.



Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de/