Kerberos behavior in the presence of multiple PTR records
Yury Sulsky
yury.sulsky at gmail.com
Thu Mar 14 11:25:34 EDT 2013
Hi guys,
This may be just me misunderstanding PTR records, but it looks like the
Kerberos library doesn't support multiple records when checking that a
hostname maps to an ip address that maps back to the same hostname (I think
this check only takes place if the "rdns" option is set).
My (uninformed) expectation is that the check would make sure that
hostname is a member of one of the sets returned by:
(reverse(ip) for all ips in forward(hostname))
This may be the relevant piece of code (in src/lib/krb5/os/sn2princ.c):
/*
* Do a reverse resolution to get the full name, just in
* case there's some funny business going on. If there
* isn't an in-addr record, give up.
*/
/* XXX: This is *so* bogus. There are several cases where
this won't get us the canonical name of the host, but
this is what we've trained people to expect. We'll
probably fix it at some point, but let's try to
preserve the current behavior and only shake things up
once when it comes time to fix this lossage. */
err = getnameinfo(ai->ai_addr, ai->ai_addrlen,
hnamebuf, sizeof(hnamebuf), 0, 0,
NI_NAMEREQD);
freeaddrinfo(ai);
if (err == 0) {
free(remote_host);
remote_host = strdup(hnamebuf);
if (!remote_host)
return ENOMEM;
}
The effect of this is that if the DNS server returns the "wrong" PTR record
first, the check fails. Additionally, there is a call to [getaddrinfo]
above which only examines the first address returned.
Is there a reason it's not secure to consider all forward and reverse
records, or does the "XXX: This is *so* bogus" comment refer to this
behavior? If so, wouldn't changing that behavior only increase the number
of times this check passes? (i.e. how would it break people's expectations?)
Thanks,
Yury
More information about the Kerberos
mailing list