Kerberos behavior in the presence of multiple PTR records

[Nico Williams]

On Thu, Mar 14, 2013 at 6:19 PM, Yury Sulsky <yury.sulsky at gmail.com> wrote:
> On Thu, Mar 14, 2013 at 4:20 PM, Nico Williams <nico at cryptonector.com>
> wrote:
>> To my knowledge no RFC says that only one PTR RR may exist in any
>> given PTR RRSet.  In practice all implementations of getnameinfo(),
>> gethostbyaddr(), and the like, use only the first PTR RR in the PTR
>> RRSet for obvious semantic reasons: such code is looking for a
>> canonical name for an IP address, and more than one name means there's
>> no canonical name, thus either failure or "pick one" are the only
>> options.
>
> Does that mean it's just always a mistake for there to exist more than one
> PTR record for a given IP address? I just assumed it's a set operation, just
> like you might have multiple A records pointing to the same IP address, you
> might have multiple PTR records pointing back at those names.

In practice yes, it's a mistake.

As for what the RFCs say... it's a bit confusing.  RFC2181 says:

10.2. PTR records

   Confusion about canonical names has lead to a belief that a PTR
   record should have exactly one RR in its RRSet.  This is incorrect,
   the relevant section of RFC1034 (section 3.6.2) indicates that the
   value of a PTR record should be a canonical name.  That is, it should
   not be an alias.  There is no implication in that section that only
   one PTR record is permitted for a name.  No such restriction should
   be inferred.

But "canonical name" in practice, that is, the way APIs are
formulated, means "the one true name", not "the one or more true
names", because a "true name" implies "only one".  Indeed, the
definition of CNAME in RFC1034 is identifies the canonical name of an
alias", which very much says "there's only one canonical name".
Meanwhile what RFC1035 says is:

   Domain names in RRs which point at another name should always point at
   the primary name and not the alias.  This avoids extra indirections in
   accessing information.

So... there should be just one canonical name (see definition of
CNAME) and PTRs (pointers) should point to the primary (canonical)
name of the thing.  So why does RFC2181 say that this does not imply
that there should only be one PTR RR in any PTR RRSet?!  I don't know.
 It seems wrong to me.

In any case, if you were looking for a way to find all of a host's
_aliases_, PTR RRs are not what you're looking for, and indeed,
there's no RR type in DNS for that operation.  Even if there was, it
could only tell you about aliases known / desired-to-be-listed by the
owner of the RRSet name.

>> In any case, you should never want to use PTR RR lookups for principal
>> name canonicalization.  (Not unless you are using DNSSEC, which you're
>> almost certainly not.)
>
> I think this code only uses the reverse lookup as a sanity check, which
> fails in an inconsistent manner if there is more than a single PTR record
> (depending on which one is returned first).

There's no defined order for RRs in an RRSet (they are unordered
sets), therefore having multiple PTR RRs technically results in
non-deterministic behavior by code that picks the first PTR in the
RRset.

Nico
--