rdns, past and future

[Greg Hudson]

On 5/26/20 5:09 PM, Ken Dreyer wrote:
> In public cloud environments or Kubernetes environments, PTR records
> are difficult or impossible for administrators to set. We increasingly
> have to tell users to set "rdns = fallback" or "rdns = false".

Note that dns_canonicalize_hostname and rdns are separate settings.
dns_canonicalize_hostname supports "fallback", but rdns only supports
true or false (and only takes effect when DNS canonicalization happens).

If a PTR record is not set at all, the library should by default use the
forward canonicalization result.  The problem happens when there is a
PTR record, but it has a non-useful value.

> I'm wondering what the original purpose of Kerberos' rdns feature was.
> Why would a client want or need to do hostname canonicalization?

Forward DNS canonicalization was a convenience for cnames and
non-qualified hostnames.  We now have a qualify_shortname feature to
address single-label names by adding a domain suffix, but it only
appeared in 1.18.

The additional reverse canonicalization step was, to the best of my hazy
understanding, aimed specifically at a historical element of the Athena
computing environment at MIT, most likely a pool of dialups which
load-balanced via A record.

We know that the rdns=true default is an inconvenience for many
environments.

> I'm also wondering if we will ever be able to default MIT Kerberos'
> rdns setting to "fallback" or "false" in a future version. IMHO this
> would make it easier to deploy Kerberos applications in modern hosting
> environments.

I floated the idea of changing the rdns default to false some years ago,
and got the sense that it would be traumatic to a number of existing
deployments.  Client library upgrades are generally not intentional, so
warning people via release notes doesn't really help.

Changing the default for dns_canonicalize_hostname to "fallback" would
be less likely to be traumatic.  Fedora is starting to put
dns_canonicalize_hostname=fallback in their shipped default krb5.conf.
(They have put rdns=false in this file since 2013.)  If there isn't much
fallout, we might change the library default in 1.19.  That change
wouldn't help when the forward-but-not-reverse-canonicalization result
is best, but it does help if the originally entered name or its
shortname-qualified version is correct.

We had a design floating around for a protocol extension where the KDC
could set a "please don't canonicalize" ticket flag.  Unfortunately no
progress has been made on this idea.