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@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@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@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@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@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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
