For krb5.conf, there are six different stanzas used:

[libdefaults]
     Various configuration parameters used by the Kerberos library. The
     krb5.conf man page lists all of the available parameters. Ones you
     should take special note of are:

     default_realm
          The default Kerberos realm. THIS IS REQUIRED!

     default_keytab_name
          The default keytab used by application servers. In pre-1.0
          releases of Kerberos 5, the default was /etc/v5srvtab, but
          starting with 1.0 it is now /etc/krb5.keytab. This field could be
          used to ease the transition from a pre-1.0 installation to an
          up-to-date version of Kerberos 5.

     ccache_type
          This sets the credential cache type used by Kerberos. The default
          credential cache type is 3.

          Credential cache type 1 is also understood by DCE 1.0.3a systems,
          and credential cache type 2 is also understood by DCE 1.1 systems.
          If you wish to have interoperability with DCE, you may want to set
          this value.

          If you wish to use the kdc_timesync feature, you will need to set
          this value to 4, as this is the credential cache type that
          supports header tags, which are used by the clock skew correction
          code.

     kdc_timesync
          Setting this variable to 1 enables Kerberos clients to
          automatically correct for a difference between the local clock and
          the clock used by the KDC. Note that you will need to set
          ccache_type to a value of 4 to use this feature.
[login]
     This configures the behavior of login.krb5. The man page for login.krb5
     explains these in more detail.

[realms]
     This section lists all of the Kerberos realms known to this client. If
     a realm is not listed in this section, than it cannot be accessed by
     the client that is using this configuration file.

     Configuration variables of note used in this section are:

     default_domain
          This lists the default domain used to convert V4 instances (which
          were not fully qualified host names) to V5 instances (which are
          fully qualified).

          When converting a principal name from Kerberos 4 to Kerberos 5,
          the default_domain is appended to the instance. When converting
          from Kerberos 5 to Kerberos 4, it is removed.

     v4_instance_convert
          This is used to configure exceptions to the default_domain mapping
          rule. In this subsection is a list of V4 instance names and their
          V5 equivalents.

     Note that neither of these two variables are required if you're not
     planning on using the Kerberos 4 compatibility of Kerberos 5. Question
     2.8 explains the use of these two variables in more detail.

[domain_realm]
     This section defines the mapping from hostnames to Kerberos realms.

     When using host-based services, a Kerberos client needs to know the
     Kerberos realm that the service lives in so it can contact the proper
     KDC (and optionally request cross-realm tickets if necessary). This is
     determined by the rules found in the domain_realm section.

     If you're only using one Kerberos realm, and your realm is the
     uppercase version of your domain name, then you don't need a
     domain_realm section.

     One point about the [domain_realm] stanza that confuses a lot of people
     is whether or not to use a leading period when referring to domains
     (most people put both just to be safe). For example:

     [domain_realm]
             foo.bar.org = FOO.BAR.ORG
             .foo.bar.org = FOO.BAR.ORG

     The rules are very simple. Anything with a leading period matches all
     hosts in that domain. So the entry for .foo.bar.org matches all hosts
     in the foo.bar.org domain. Entries without a leading period only match
     that specific host. So in this case, the entry for foo.bar.org only
     matches the host foo.bar.org.

     An important side note is that domain wildcard entries do not match a
     host who's name is the name of your domain. In other words, the entry
     for .foo.bar.org doesn't match a host called foo.bar.org.

     If this is too confusing, remember these simple rules:

       1. You almost always need an entry for your domain with a leading
          period.
       2. You only need an entry without a leading period if you have a host
          named the same as your domain name (in other words, your domain is
          foo.bar.org, and you have a host called foo.bar.org).

[logging]
     This section describes the way different Kerberos programs perform
     logging. Currently this is only used by the KDC and the admin servers,
     so this section is only required on on your master and slave Kerberos
     servers.
[capaths]
     This section defines a set of valid authentication paths when doing
     transitive cross-realm authentication. The use of this section is
     explained further in Question 2.15.

A bare minimum krb5.conf will need to contain a default_realm entry and a
[realms] section describing your default realm. For example:

[libdefaults]
        default_realm = FOO.BAR

[realms]
        FOO.BAR = {
                kdc = kdc1.foo.bar
                kdc = kdc2.foo.bar
                admin_server = kdc1.foo.bar
        }

If your realm name is different than your domain name, then you'll need an
appropriate mapping entry under [domain_realm].

[libdefaults]
        default_realm = TEST.BAR

[realms]
        TEST.BAR = {
                kdc = kdc1.foo.bar
                kdc = kdc2.foo.bar
                admin_server = kdc1.foo.bar
        }

[domain_realm]
        .foo.bar = TEST.BAR

The kdc.conf uses the same format. The man page describes all of the
sections and variables used. The critical ones are:

max_life
     This is the maximum lifetime for all tickets issued from this KDC. The
     default is 10 hours. If you wish to increase the ticket lifetime, you
     will need to increase this variable (in addition to increasing the
     lifetime of the principals in the database).

supported_keytypes
     This lists all of the key/salt combinations that will be created for
     new principals or principals that change their password. This is
     important if you wish to support Kerberos 4 or AFS clients.

     Since it is impossible to change a key from one salt type to another, I
     always advise people to configure in support for V4 salted keys when
     they first set up their realm, since it may require users to change
     their passwords if you find out you need V4 compatibility at a later
     date (depending on what sort of V4 compatibility you need). Question
     2.8 has more information on the subject of configuring V4
     compatibility.

A minimal kdc.conf would be:

[realms]
    FOO.BAR = {
        supported_keytypes = des:normal
    }

If you wanted to support V4 and AFS salted keys, you might have:

[realms]
    FOO.BAR = {
        supported_keytypes = des:normal des-cbc-crc:v4 des-cbc-crc:afs3
    }