> On 9/11/2014 11:51 AM, Mark Elkins wrote: >> On Thu, 2014-09-11 at 11:27 -0400, Kevin Darcy wrote: >>> Mark, >>> Depending on implementation, a PTR RRset with multiple >>> records either >>> >>> -- only ever gets answered with the "first" record of the set (in >>> which case the second and subsequent records of the set are just a >>> waste of space), or >>> -- answers in a random, cyclic and/or round-robin fashion (in which >>> case, the results are non-deterministic from the standpoint of a >>> client, and this can cause problems and/or confusion) >> >> Last time I checked, ALL matching records are returned as a single >> Resource Record Set - (and in the case of DNSSEC - covered with a single >> signature). >> >> What the receiver does with it is up to that receiver... as you say - >> some of the information may be discarded. > If the invoker is using the classic gethostbyaddr() interface, then > it'll only see the RDATA from the "first" PTR RR, where "first" is > determined by the local nameserver implementation and/or the local > Operating System interface for name resolution. >> >>> So, although the standards allow multiple RRs, in practical terms, it >>> only makes sense for a PTR RRset to contain a *single* RR. >> I would still disagree. When there is forward<-->reverse checking, one >> may need the complete answer. I certainly have some processes that do an >> exhaustive check. > Certainly if one gets down to the resolver-library level and grovels > through all of the RRs in the Answer Section of the response packet, one > could certainly care more than the typical reverse-resolving > app/subsystem would. And any software that builds up certain heightened > expectations is likely to complain if those expectations are not met. > > - Kevin >>> On 9/11/2014 3:45 AM, Mark Elkins wrote: >>> >>>> On Wed, 2014-09-10 at 18:13 -0400, Kevin Darcy wrote: >>>>> No, what I'm saying is that if >>>>> >>>>> example.com owns an A record 203.0.113.48, and >>>>> www.example.com owns an A record 203.0.113.48, then >>>>> >>>>> where does 48.113.0.203.in-addr.arpa point? >>>>> >>>>> Some people will point it at example.com, some will point it at >>>>> www.example.com. What you get is a mish-mosh. No consistency. >>>> Although I prefer the use of a CNAME solution (CNAME www.example.com to >>>> example.com), in the case of separate A (and AAAA) records, one could >>>> point the reverse to both names. Nothing wrong with a PTR record having >>>> more than one answer. There is then no inconsistency, just choice. After >>>> all, pretty much every NS record has at least two Right-Hand-Sides >>>> (Answers).... >>>> >>>> >>>>> If, on the other hand, www.example.com is a CNAME to example.com, then >>>>> it's crystal clear where the reverse record will point -- example.com. >>>>> There is no ambiguity or option for inconsistency. >>>>> >>>>> - Kevin >>>>> >>>>> On 9/10/2014 5:48 PM, Eliezer Croitoru wrote: >>>>>> Hey Kevin, >>>>>> >>>>>> This is not an issue at all. >>>>>> A PTR is different then a "A" record and can be used by two reverse >>>>>> domain names and only the owner of the IP addresses space can define >>>>>> them. >>>>>> I am not sure if two PTR records for two domains will be applied to >>>>>> one IP but it is possible for two IP addresses to have the same PTR. >>>>>> >>>>>> Can we even use a CNAME as a PTR??? >>>>>> >>>>>> Eliezer >>>>>> >>>>>> On 09/11/2014 12:37 AM, Kevin Darcy wrote: >>>>>>> Also, have you considered the forward/reverse ambiguity that arises when >>>>>>> multiple owner names resolve to the same address? To which of those >>>>>>> names does the PTR point? >>>>>>> >>>>>>> - Kevin
Well, this is certainly getting far away from an answer to the original qustion! Originally our web server was only available as www.adi.com. Later I noticed that a lot of sites were available without the www. So I decided to allow our web server to be available as adi.com. But I still consider www.adi.com to be the real name of the server. And I certainly can not alias adi.com to www.adi.com! Tom Schulz Applied Dynamics Intl. sch...@adi.com _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users