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 [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
