What are the issues with dns_lookup_realm ?

[Greg Hudson]

On Mon, 2010-10-11 at 10:22 -0400, Brian Candler wrote:
> - mod_auth_kerb tries to find realm for rails.api.example.com
>   (the virtual server hostname), via DNS lookups
> - mod_auth_kerb fails to find one
> - mod_auth_kerb looks for something duff like "HTTP/rails.api.example.com@"
>   in its keytab, and fails

I doubt it's actually failing.  It's probably falling back to
API.EXAMPLE.COM as the best available heuristic; that happens to be the
wrong answer.

> ''The misunderstanding here is that "the default realm" is not the default
> for host-to-realm mappings.  It's the default for parsing principal
> names which don't contain realms--for example, if you "kinit bcandler"
> instead of "kinit bcandler at EXAMPLE.COM".''

I'm actually a little surprised that mod_auth_kerb is doing a
host-to-realm lookup instead of just using the default realm for the
verification service principal.  I guess in some virtual host settings,
that's desirable.

> Maybe it would be cleaner if the client code failed immediately when asked
> to map a host to a realm but was unable to?  An error like "unable to find
> realm for host 192.0.2.1 (rails.api.example.com)" would have been easier for
> me to interpret.

The code could, I suppose, try to determine whether API.EXAMPLE.COM is
actually a Kerberos realm, and then fall back to the default realm.
That has its own pitfalls, though; if API.EXAMPLE.COM ever became a
realm (through SRV records, say), you'd get an unexpected behavior
change.

In any event, I've committed a change for 1.9 which would make the error
message from the keytab lookup more informative:

  No key table entry found for HTTP/rails.api.example.com at API.EXAMPLE.COM