[38739] in Kerberos

home help back first fref pref prev next nref lref last post

Re: rdns, past and future

daemon@ATHENA.MIT.EDU (Greg Hudson)
Tue May 26 17:59:47 2020

To: Ken Dreyer <ktdreyer@ktdreyer.com>, <kerberos@mit.edu>
From: Greg Hudson <ghudson@mit.edu>
Message-ID: <e995ee2d-d6f1-e896-fef4-16c80ff35b1e@mit.edu>
Date: Tue, 26 May 2020 17:56:44 -0400
MIME-Version: 1.0
In-Reply-To: <CAD3FbMWbxiS=2Qx_6igCX-RWsO4L5qOtX8p74Wx0AL+in+Uqaw@mail.gmail.com>
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu

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.
________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

home help back first fref pref prev next nref lref last post