Traditional Unix Kerberos 5 implementations use the flat file /etc/krb5.conf file for hostname-to-Kerberos realm mapping, much like /etc/hosts can be used for name-to-IP mapping. The Kerberos configuration file contains two major pieces of information: the DNS domain name to Kerberos realm mappings, and a list of KDCs for each Kerberos realm. Obviously, this method does not scale, so just as DNS now serves the purpose of the old /etc/hosts file, DNS can also be used to provide Kerberos configuration.
Kerberos can use DNS as a service location protocol, by using the DNS SRV record as defined in RFC 2052. In addition, Kerberos can use a TXT record to locate the appropriate realm for a given host or domain name. These DNS entries are not required to run a Kerberos realm, but they do eliminate the need for manual configuration of clients. With these DNS records, Kerberos clients can find the appropriate KDCs without the use of a configuration file. Windows will establish the necessary SRV records automatically when an Active Directory domain is created. Those using Unix for their KDCs can create these DNS entries manually in their zone files as a convenience to clients.
Note that while Windows will use DNS to locate KDCs, it will not use DNS to locate any KDCs for any non-Windows Kerberos realms. Configuration information for non-Windows Kerberos realms must be entered manually using the ksetup tool. More information on this tool and enabling interoperability between Windows and other Kerberos implementations can be found in Chapter 8.
In order to use KDC discovery over DNS, the following records should be placed in the zone file corresponding to the Kerberos realm. In most cases, since the Kerberos realm name is simply an uppercase version of the DNS domain owned by the organization, these DNS entries are placed into the organization’s existing DNS zone file. However, if the Kerberos realm and DNS domain differ, then a new zone must be created with the name of the Kerberos realm.
This item represents the service that this SRV record
provides location information for. The service name for the
Kerberos KDC is always
_kerberos. Other Kerberos related
_kerberos-adm for the kadmin server,
_kpasswd for the Kerberos
5 password-changing service.
The protocol can either be _tcp or _udp. The latest Kerberos Clarifications document requires that all future KDCs accept both TCP and UDP connections from authentication clients.
This is the realm that the KDC is authoritative for. Since DNS is case-insensitive while realm names are case-sensitive, you cannot represent multiple realms with different cases in the same DNS zone. For example, since REALM.ORG and Realm.ORG differ only in case, they will both map to the same case-insensitive DNS zone. Therefore, KDC discovery through DNS is not possible when the names of two or more Kerberos realms differ only by capitalization.
The TTL field has the same meaning here as in any DNS record; it represents the amount of time that this record can be cached by DNS clients. Once the TTL time has expired, the cached information is invalidated and any further requests for this record have to be sent to the DNS server.
Just like MX records, several KDCs can be listed with differing priorities. Clients will try the listed KDCs in order, from lowest number to highest. If the KDC with the lowest-numbered priority is not available, it will try the next highest number until the client is able to successfully connect to a KDC.
The weight field implements simple load-balancing characteristics. For identical records with the same priority, clients will use a probabilistic algorithm to give more preference to hosts with a higher weight than those with a lower weight. To disable this load-balancing feature so that clients choose from equal priority records randomly, use a zero for this field.
This is the TCP or UDP port on which the service is listening.
This is the fully qualified DNS name of the machine providing the Kerberos service.
Here is an example of a set of SRV records for several Kerberos KDCs:
_kerberos._udp.WEDGIE.ORG. IN SRV 1 0 88 kerberos-1.wedgie.org. _kerberos._tcp.WEDGIE.ORG. IN SRV 1 0 88 kerberos-1.wedgie.org. _kerberos._udp.WEDGIE.ORG. IN SRV 10 0 88 kerberos-2.wedgie.org. _kerberos._tcp.WEDGIE.ORG. IN SRV 10 0 88 kerberos-2.wedgie.org. _kerberos-adm._tcp.WEDGIE.ORG. IN SRV 1 0 749 kerberos-1.wedgie.org. _kpasswd._udp.WEDGIE.ORG. IN SRV 1 0 464 kerberos-1.wedgie.org.
This example includes two Kerberos KDCs, kerberos-1 and kerberos-2. Both listen to the standard Kerberos 5 port, 88, on both UDP and TCP. Kerberos-1 is the master KDC, so it also handles all of the administration requests and password change requests. Since kerberos-1 has a lower priority than kerberos-2 (1 versus 10), clients will prefer using kerberos-1 for queries over kerberos-2.
Kerberos can also use DNS for domain name-to-realm mapping. This mapping, provided by the domain_realm stanza in MIT-style krb5.conf files, can also be provided through TXT records in DNS. The TXT record format for specifying domain name-to-realm mappings is similar to the SRV record format for locating Kerberos KDCs within a given Kerberos realm. It contains three major fields:
This field is always
This field is the DNS domain name or hostname.
This field is the Kerberos realm associated with the domain name in the previous field.
An example, mapping all hosts within the domain wedgie.org to the Kerberos realm WEDGIE.ORG is shown below:
_kerberos.wedgie.org. IN TXT "WEDGIE.ORG"
Note that the latest Kerberos Clarifications call for less dependence on the insecure DNS service to perform domain name-to-realm mapping for future implementations of Kerberos. This DNS-to-realm mapping is used by Windows’ Active Directory services to locate realm information, and was documented as part of an Internet Draft. However, the most recent Kerberos Clarifications drafts obsoletes the older Internet Draft and strongly recommends against using unsecured DNS services to provide this mapping.