Kerberos behavior in the presence of multiple PTR records

[Nico Williams]

On Fri, Mar 15, 2013 at 9:04 AM, Yury Sulsky <yury.sulsky at gmail.com> wrote:
> On Thu, Mar 14, 2013 at 8:55 PM, Nico Williams <nico at cryptonector.com>
> wrote:
>>
>> 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.
>
>
> Nico, thanks for the pointer ( :-) ) to that RFC. This part clears it up for
> me:
>
> 10. Naming issues
>
>    It has sometimes been inferred from some sections of the DNS
>    specification [RFC1034, RFC1035] that a host, or perhaps an interface
>    of a host, is permitted exactly one authoritative, or official, name,
>    called the canonical name.  There is no such requirement in the DNS.
>
> It seems that an IP address may belong to multiple canonical names (i.e.
> there may be multiple A and PTR records referring to a single IP), but an
> alias may only point to one of these names (i.e. there can only be one CNAME
> record for a given alias).

Yes, but it doesn't follow that in one case "canonical" means "one"
and in the other it means "many".  And the APIs have resolved this
problem anyways.  This is a case where what the RFCs say is irrelevant
because what got deployed wins.

> On Thu, Mar 14, 2013 at 9:39 PM, Greg Hudson <ghudson at mit.edu> wrote:
>>
>> There is no check to see if that result is the same as the forward lookup.
>> Take a  look at what happens to the remote_host variable after the
>> getnameinfo call.
>
>
> Right, thanks. I should have read more carefully. Still, wouldn't it make
> sense to iterate through all PTR records and search for one that matches the
> canonical name returned from the forward lookup? If a record like that does
> exist, returning that one would allow the user to specify a host that has
> other canonical names (and multiple PTR records).

The code here isn't seeing the PTR records.  Instead MIT Kerberos is
calling system library functions (getnameinfo(3)) that do that, and
those functions, as I've explained, only look at one PTR RR.

Nico
--