address-to-names

Hongbo Shi shi at goto.info.waseda.ac.jp
Sat Oct 14 03:40:18 UTC 2000


I really appreciate your comments. 
I think this time my question was completely resolved. :)

P.S. In the future, maybe I will have some new questions on 
     the section 4), sorting preferences. Hope I can get the
     answer again.

Best Regards.

Hongbo Shi

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

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




More information about the bind-users mailing list