Your DNS should be configured so that gethostbyname() and gethostbyaddr()(or
your operating system equivalent) returns the fully qualified domain name
for a host.

Now, this is technically NOT true. The "real" answer is that you can do it
either way, as long as you're consistent. When MIT Kerberos figures out
service principal names, it calls:

gethostbyaddr(gethostbyname(host))

So if you have your name service configured to return "short" names, then as
long as you use the short name in the instance of the service principal,
then everything will be fine.

That being said .... YOU DO NOT WANT TO DO THIS!

First and foremost, it will break people who are not in your domain who try
to use your Kerberized services. It will also undo the very wise change from
the way instances were handled in Kerberos 4.

Trust me when I say that configuring your name service the "right" way will
be better in the long run.

Unfortunately, things are less clear when multi-homed hosts are involved.

The issue of multi-homed hosts is a large one; very few things deal with
multi-homed hosts well, and there are a number of schools of thought on how
multi-homed hosts should be treated.

This FAQ does not claim to address the issue of multi-homed hosts. It does,
however, try to explain the issues involved with multi-homed hosts and
Kerberos, and the FAQ author does make a "recommendation" as to the way you
should configure your DNS. Take it with the appropriate grain of salt :-)

I have seen two basic schools of thought when it comes to dealing with
multi-homed hosts:

  1. Treat the host as a bunch of different single-homed machines, all of
     which happen to magically share the same hardware (the "one name per
     interface" scheme).
  2. Treat the host as a single machine, with a bunch of network interface
     cards (the "multiple address records per machine" scheme).

Both of these approaches have their advantages and disadvantages. I
personally recommends the second approach ("multiple address records per
machine"), as I feel it is closer to reality. Also, the Host Requirements
RFC (RFC 1123) says:

     2.3 Applications on Multihomed hosts

     When the remote host is multihomed, the name-to-address
     translation will return a list of alternative IP addresses. As
     specified in Section 6.1.3.4, this list should be in order of
     decreasing preference. Application protocol implementations SHOULD
     be prepared to try multiple addresses from the list until success
     is obtained. More specific requirements for SMTP are given in
     Section 5.3.4.

However, RFC 1122 does admit:

     Multihoming introduces considerable confusion and complexity into
     the protocol suite, and it is an area in which the Internet
     architecture falls seriously short of solving all problems.

Regardless of the way you configure your host name resolution, it's critical
to understand the issues involved.

When connecting to a Kerberized host, the service instance used is derived
from the fully qualified host name. If there is one host key but multiple
canonical names per host, connections to the interfaces who's names do not
match the name of the host used in the Kerberos instance will fail.

If that was too confusing, here's an example:

We have a host called foo.bar.org, that's in the BAR.ORG realm. It has one
host key, host/foo.bar.org@BAR.ORG, and three interfaces:

foo.bar.org             IN      A       1.2.3.4
foo-fddi.bar.org        IN      A       1.2.4.4
foo-en.bar.org          IN      A       1.2.5.4

If I say "telnet foo.bar.org" (using my Kerberized telnet), everything works
fine. But if I try connecting to foo-en.bar.org, then this will fail,
because there is no such principal called host/foo-en.bar.org@BAR.ORG.

You can create multiple keys per host, but that won't solve all of your
problems either. Some Kerberized application servers will only accept
principals for services who's instance is the FQDN of the local hostname.
ftpd is an example of one such application server (in the above example, for
our host called "foo", this means that ftpd would only accept principals
with the instance of foo.bar.org).

There is considerable debate about whether or not application servers should
accept any valid service key, or only ones that match their canonical name.
However, in the case of ftpd, RFC 2228 is quite clear that ftpd is doing the
right thing according to the FTP Security Specification.

Another issue with multihomed hosts is the issue of credential forwarding.
When credentials are forwarded to a remote machine, the IP address(es) of
the remote machine are placed in the ticket. When you go to use this ticket,
the KDC verifies the addresses in the ticket against the source address of
the request.

There is currently no way for Kerberos to know all of a machine's interfaces
when using the "one name per interface" scheme. So when you forward
credentials to a multihomed machine using this configuration, you must make
sure that the address you place in the ticket is the IP address that the
remote machine will use to talk to the KDC (and if you're using cross-realm,
you have to make sure it's the same interface to all KDCs).

Both of these issues go away when using the "multiple address records per
host" scheme. However, you can use this setup and have the ability to refer
to different interfaces. Here's an example DNS setup:

my.host.name.   A       1.2.3.4
                A       1.2.4.4
                A       1.2.5.4

my-en0.host.name.       A       1.2.3.4
my-en1.host.name.       A       1.2.4.4
my-en2.host.name.       A       1.2.5.4

4.3.2.1         PTR     my.host.name.
4.4.2.1         PTR     my.host.name.
4.5.2.1         PTR     my.host.name.

In summary, you can make both ways work. The FAQ author recommends using
"multiple address records per host", but you can do things the other way if
you're careful.

One final note: if you're using NIS instead of DNS for hostname resolution,
you will find that you cannot use the "multiple address records per host"
setup, because of the way NIS works (it's a key-value map, and silently
strips out all but one address record). This holds true even if you're using
DNS to hold your zone information and you've configured NIS to fall back to
DNS!