address-to-names

[Kevin Darcy]

Hongbo Shi wrote:

> Thanks a lot.
> I read the sections in the [RFC2181].
> Are the following considerations correct?
> 1) CNAME is used to define an alias.

Correct.

> 2) PTR must not point to an alias.

Correct. As part of a general rule applying to *all* record types which point
to names. But this is not a very strict rule. RFC 1034, for example, says that,
by the "robustness principle", implementations should still follow
"illegal" CNAME chains.

> 3) PTR could point to a set of different canonical names correspoinding the
>    same IP address.

Correct. If would add that it is not mandatory for PTR's to point to A records
with any particular address. It's not mandatory for them to point to A records
at all. In fact, it's not mandatory that they point to anything that actually
exists. Just think of each PTR as a connector between 2 different names,
syntactically identical to a CNAME, but without the special processing
associated with aliases. By far, the most common use of PTR's is for reverse
lookups, but technically they are not limited to this.

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

Correct. And BIND even treats PTRs specially so that the normal sorting
preferences (e.g. cyclic/random) don't apply; "fixed" order is always used. So
a client that is querying a BIND server and doesn't look beyond the first
PTR RR doesn't ever see any of the others in the RRset, no matter how many
times it queries the name. This differs from, say, an A RRset, where the first
record in the RRset might differ from query to query.


- Kevin

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