A record of domain name must be name server ?

Kevin Darcy kcd at chrysler.com
Thu Sep 11 17:14:49 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 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
>>>>> _______________________________________________
>>>>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>>>>> unsubscribe from this list
>>>>>
>>>>> bind-users mailing list
>>>>> bind-users at lists.isc.org
>>>>> https://lists.isc.org/mailman/listinfo/bind-users
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>>>>
>>>> bind-users mailing list
>>>> bind-users at lists.isc.org
>>>> https://lists.isc.org/mailman/listinfo/bind-users
>>>
>>> _______________________________________________
>>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>>>
>>> bind-users mailing list
>>> bind-users at lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/bind-users
>> _______________________________________________
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>>
>> bind-users mailing list
>> bind-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20140911/eed0f725/attachment-0001.html>


More information about the bind-users mailing list