rdns, past and future

[Jeffrey Altman]

On 5/26/2020 5:09 PM, Ken Dreyer wrote:
> Hi folks,
> 
> 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".

As described in RFC4120 Section 1.3

  https://tools.ietf.org/html/rfc4120#section-1.3

Kerberos implementations "MUST NOT use insecure DNS queries to
canonicalize the hostname components of the service principal names."

That said MIT and Heimdal have canonicalized hostnames using insecure
DNS since the beginning of time and changing the defaults will be sure
to break authentication for some unknown number of sites.

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

There are two reasons that scream at me:

 1. Before the introduction of Kerberos Referrals by Microsoft
    (and later standardized and adopted by MIT, Heimdal, ...),
    the clients required the PTR name in order to determine the
    true "domain" for host domain to realm mapping.  With Kerberos
    referrals it is best if the Kerberos client sends the initial
    service ticket request to a KDC in the client principal's
    realm and allow the KDC to refer the client to the first
    cross-realm hop if required.

    There are still too many systems that have client-side
    domain_realm mapping data that would break if "rdns" was turned
    off.

 2. Before the existence of DNS SRV records, CNAME records were the
    only method of offering a service on multiple hosts.  However,
    its a poor idea to share the same key across all of the hosts.
    In order to identify the name of the host that was contacted
    the DNS PTR record is used.  Even with the existence of SRV
    records, too few application protocols use them.

    Even for services that are hosted on a system system, CNAME
    records are convenient to permit migration of services from an
    old machine to a new one.

    Again, disabling "rdns" by default will break an unknown number
    of application clients.

> 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'm unaware of any OS distribution that ships with Kerberos that doesn't
provide some default equivalent of "/etc/krb5.conf".  Those
distributions can of course add whatever default settings it wants with
appropriate documentation.  If a distribution ships default krb5.conf
with "rdns = false", then an end user that replaces the default
krb5.conf with their organization's krb5.conf will not be broken.  If
the hard coded default is changed, then installing the organization's
krb5.conf might not work as intended.

Jeffrey Altman


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4080 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/kerberos/attachments/20200526/325b06b8/attachment-0001.bin