address-to-names

[Hongbo Shi]

Thanks a lot. 
I read the sections in the [RFC2181].
Are the following considerations correct? 
1) CNAME is used to define an alias. 
2) PTR must not point to an alias.
3) PTR could point to a set of different canonical names correspoinding the 
   same IP address. 
4) Though PTR could point to a set of different canonical names, practically
   no client software looks beyond the first PTR in a PTR RRset. Waste of 
   time and effort.

Best Regards.

Hongbo Shi

From: Kevin Darcy <kcd at daimlerchrysler.com>
Subject: Re: address-to-names
Date: Fri, 13 Oct 2000 21:26:45 -0400

> 
> Hongbo Shi wrote:
> 
> > Dear all,
> >
> >  I have thought about the PTR RR for long time.
> >  I still not quite sure why PTR RR is based on the "one IP one domain"
> >  consideration in [RFC1034].
> >  I hope somebody can answer this question for me.
> 
> I'm not sure what you mean by "one IP one domain". If you mean the
> misconception that a PTR record should have only 1 RR, then this is
> specifically debunked in RFC 2181, section 10.2 ("PTR records").
> 
> > [RFC1034]
> > cname & aliases:
> >  "Most of these systems have a notion that one of the equivalent set of
> >   names is the canonical or primary name and all others are aliases."
> >
> > PTR:
> >  "Domain names in RRs which point at another name should always point a=
> t
> >  the primary name and not the alias.  This avoids extra indirections in
> >  accessing information."
> >
> >  Furthermore a lot of persons regard the domain name used in the A reco=
> rd
> > as a cname. Is it correct? Is it misunderstanding? Is there some new RF=
> Cs
> > already permitted the consideration?
> 
> There is some confusion about CNAMEs and "canonical names". This too is
> addressed in RFC 2181. See section 10.1.1 ("CNAME terminology").
> 
> >  And then based on the cosideration above, if the following A records e=
> xist,
> >
> >  A.ISI.EDU    IN   A    10.0.0.52
> >  B.ISI.EDU    IN   A    10.0.0.52
> >  C.ISI.EDU    IN   A    10.0.0.52
> >
> >  of course "address-to-names" should exist.
> >
> >  52.0.0.10.IN-ADDR.ARPA  IN      PTR     A.ISI.EDU
> >  52.0.0.10.IN-ADDR.ARPA  IN      PTR     B.ISI.EDU
> >  52.0.0.10.IN-ADDR.ARPA  IN      PTR     C.ISI.EDU
> 
> There is no formal requirement that all 3 of these PTR RR's exist.
> Administrators may choose to create any or none of them, or different PTR=
> 's
> entirely.
> 
> In practice, no client software (as far as I know) looks beyond the first
> PTR in a PTR RRset. So it's a waste to create the others. If you want to =
> see
> how wasteful this can become, trying doing a reverse lookup of 209.164.15=
> .191
> on the Internet sometime (credit goes to Peter H=E5kanson for discovering=
>  this
> abomination).
> 
> 
> - Kevin
> 
> 
> 
> 
>