If there is information about where to find the KDC or kadmind for a realm in the krb5.conf for a realm, that information will be preferred, and DNS will not be queried.
Heimdal will try to use DNS to find the KDCs for a realm. First it
will try to find a
SRV resource record (RR) for the realm. If no
SRV RRs are found, it will fall back to looking for an
A RR for
a machine named kerberos.REALM, and then kerberos-1.REALM, etc
Adding this information to DNS minimises the client configuration (in the common case, resulting in no configuration needed) and allows the system administrator to change the number of KDCs and on what machines they are running without caring about clients.
The downside of using DNS is that the client might be fooled to use the wrong server if someone fakes DNS replies/data, but storing the IP addresses of the KDC on all the clients makes it very hard to change the infrastructure.
An example of the configuration for the realm
$ORIGIN example.com. _kerberos._tcp SRV 10 1 88 kerberos.example.com. _kerberos._udp SRV 10 1 88 kerberos.example.com. _kerberos._tcp SRV 10 1 88 kerberos-1.example.com. _kerberos._udp SRV 10 1 88 kerberos-1.example.com. _kpasswd._udp SRV 10 1 464 kerberos.example.com. _kerberos-adm._tcp SRV 10 1 749 kerberos.example.com.
More information about DNS SRV resource records can be found in RFC-2782 (A DNS RR for specifying the location of services (DNS SRV)).
Heimdal also supports a way to lookup a realm from a hostname. This to minimise configuration needed on clients. Using this has the drawback that clients can be redirected by an attacker to realms within the same cross realm trust and made to believe they are talking to the right server (since Kerberos authentication will succeed).
An example configuration that informs clients that for the realms it.example.com and srv.example.com, they should use the realm EXAMPLE.COM:
$ORIGIN example.com. _kerberos.it TXT "EXAMPLE.COM" _kerberos.srv TXT "EXAMPLE.COM"