<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 9/11/2014 11:51 AM, Mark Elkins
wrote:<br>
</div>
<blockquote cite="mid:1410450712.883.459.camel@mje.posix.co.za"
type="cite">
<pre wrap="">On Thu, 2014-09-11 at 11:27 -0400, Kevin Darcy wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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)
</pre>
</blockquote>
<pre wrap="">
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.</pre>
</blockquote>
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.<br>
<blockquote cite="mid:1410450712.883.459.camel@mje.posix.co.za"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">So, although the standards allow multiple RRs, in practical terms, it
only makes sense for a PTR RRset to contain a *single* RR.
</pre>
</blockquote>
<pre wrap="">
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.</pre>
</blockquote>
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.<br>
<br>
- Kevin
<blockquote cite="mid:1410450712.883.459.camel@mje.posix.co.za"
type="cite">
<blockquote type="cite">
<pre wrap="">
On 9/11/2014 3:45 AM, Mark Elkins wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Wed, 2014-09-10 at 18:13 -0400, Kevin Darcy wrote:
</pre>
<blockquote type="cite">
<pre wrap="">No, what I'm saying is that if
example.com owns an A record 203.0.113.48, and
<a class="moz-txt-link-abbreviated" href="http://www.example.com">www.example.com</a> 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
<a class="moz-txt-link-abbreviated" href="http://www.example.com">www.example.com</a>. What you get is a mish-mosh. No consistency.
</pre>
</blockquote>
<pre wrap="">Although I prefer the use of a CNAME solution (CNAME <a class="moz-txt-link-abbreviated" href="http://www.example.com">www.example.com</a> 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)....
</pre>
<blockquote type="cite">
<pre wrap="">If, on the other hand, <a class="moz-txt-link-abbreviated" href="http://www.example.com">www.example.com</a> 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:
</pre>
<blockquote type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">_______________________________________________
Please visit <a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a> to
unsubscribe from this list
bind-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a>
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a>
</pre>
</blockquote>
<pre wrap="">_______________________________________________
Please visit <a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list
bind-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a>
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a>
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
Please visit <a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list
bind-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a>
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a>
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
Please visit <a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list
bind-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a>
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Please visit <a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list
bind-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a>
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a></pre>
</blockquote>
<br>
</body>
</html>