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