A record of domain name must be name server ?

Thomas Schulz schulz at adi.com
Thu Sep 11 18:20:37 UTC 2014

> 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, and
>>>>> www.example.com owns an A record, then
>>>>> where does 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

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.
schulz at adi.com

More information about the bind-users mailing list