PTR Records & Kerberos

If your Kerberos authentication is failing intermittently and the logs point to hostname verification, the culprit is often a misconfigured PTR record. This post walks through why multiple PTR records for a single address break reverse DNS lookups and how that cascades into Kerberos ticket failures.

A valid PTR record is one that resolves to a name which then resolves back to the original address. For this reason, PTR records should not use names that resolve back to multiple addresses.

It is worth noting that no RFC explicitly requires a PTR record for every A record, though it is clearly listed as a design goal. The RFCs also never explicitly forbid multiple PTR records for a given address. Unfortunately, doing so creates problems with name resolution. The root cause lies in how records are reported by servers and consumed by clients.

What Happens With Multiple PTR Records

Suppose you have multiple PTR records for a given address. Here is the sequence of events:

1. A request is made for PTR records for the address, typically by something trying to verify one of the hostnames.
2. The server treats the set of PTR records in round-robin, “load sharing” the results. In effect, it reorders the records in an essentially random permutation and reports them all by design. Name services generally randomize the ordering of records that share the same canonical name, even when true balancing is not enabled. This is configurable, but it remains an expected behavior.
3. The requester sees a stack of records but only reads the first one. The remaining records are assumed to be supporting records (NS records, etc.). The result is a randomly chosen record from the set of PTR records presented by the name service. In general, clients that request name information by design will only process and use the first result returned.
4. There is little chance that the resulting name returned by the name service and later interpreted by the client will match the name that was originally being verified.

Impact on Kerberos

Applying this concept to Kerberos as a client, a similar problem occurs if the name given in the PTR record resolves back to multiple addresses. This would happen, for example, when Kerberos is trying to verify a hostname prior to issuing tickets or tokens. Kerberos may attempt to break through fake PTR records by verifying that the name it obtains resolves back to the original address. However, due to the way name services and clients generally work, it may randomly obtain a non-validating result from the name service, causing the verification to fail.

• Networking
• Security

• Dns
• Kerberos
• Troubleshooting