bug: krb5_get_host_realm() no longer uses DNS

[Greg Hudson]

On Wed, 2010-05-19 at 18:29 -0400, Richard Silverman wrote:
> in my system, DNS TXT records *are* "explicit local configuration."

They're explicit configuration, but not local to the host machine.
(They're local to your organization, but that's not the sense in which I
was using the term.)

> Perhaps dns_lookup_realm could have more values: "no,"
> "on_referral_failure," and "always."  I would set "yes" to mean "always"
> for backward compatibility, but you might want it to be
> "on_referral_failure."

I think this is more complexity than you need.  You don't actually need
DNS records to take priority over referrals; you just want them to apply
to acceptors--or, more generally, for acceptors to work without local
configuration of the server realm.

I could see us making either of the following changes to use cases like
yours:

1. Bringing the krb5_get_fallback_host_realm() logic back into the
acceptor case somehow, effectively restoring the 1.5 behavior for
acceptors.  The most obvious way to do this would, unfortunately, be a
pretty clear layering violation--krb5_kt_get_entry should not be
invoking host-to-realm logic--so this would probably be done within the
krb5 GSS mechanism code.

2. Making the referral realm match any realm within keytabs.  With this
behavior, your servers wouldn't need to consult DNS TXT records to
determine their own realms (though you'd presumably still need the
records for the sake of initiators), eliminating a denial of service
spoofing attack.  Sam did not like this option back in 1996, although I
don't fully understand his objection:
        
        One option would be to match any realm if you get a null realm
        principal in the keytab code.  I dislike this option a lot even
        though I think Doug would like it.  The problem is that you get
        behavior that might encourage some people to remove domain_realm
        mappings.