Learn Kerberos - DNS & Time Synchronization Prerequisites

#Introduction

In episode 3 you saw the full Kerberos authentication flow — and two things stood out as the foundation of all those flows: the timestamp that feeds the authenticator, and the name resolution that lets a client find the KDC. Episode 3 closed with a warning that time synchronization is part of Kerberos's security mechanism itself. Now it's time to prove it.

This episode dissects the two infrastructure prerequisites that most often break real-world Kerberos implementations: time synchronization and DNS. You'll set up NTP with chrony, understand the 5-minute clock tolerance and how to adjust it, create SRV records for KDC discovery, prepare a /etc/hosts fallback, and learn to solve the legendary Clock skew too great error. Let's start with the most critical: time.

#Why Time Synchronization Is So Critical

Recall the mechanism from episode 3: the authenticator contains a timestamp encrypted with the session key, and the server stores that timestamp in a replay cache. Both only make sense if all parties share the same understanding of time.

#Timestamp and Replay Protection

The timestamp has two functions:

1. Keeping freshness — if the timestamp is too old, the request is considered stale and rejected.
2. Keeping uniqueness — if the timestamp has been seen before (stored in the replay cache), the request is considered a replay and rejected.

Without clock synchronization, these functions collapse. A slow client clock makes timestamps always "in the past," so valid requests get rejected. A client clock that's too fast makes timestamps "from the future," which is also suspected. Both conditions surface as the same error message.

#Default Tolerance: 5 Minutes

Kerberos has a built-in tolerance of 300 seconds (5 minutes) — the default clockskew value. That means the clock difference between client, KDC, and service can be up to 5 minutes. This is loose enough to accommodate normal clock drift, but tight enough to prevent replay attacks with an unreasonable window.

#The Clock Skew Too Great Error

When the clock difference exceeds the tolerance, the KDC or service responds with a classic error:

kinit: Preauthentication failed while getting initial credentials

Clock skew too great (37 seconds)

The number in parentheses hints at the size of the difference. Note that the error can surface as Preauthentication failed — meaning debugging needs a deeper trace. The fastest way to find out: run KRB5_TRACE=1 kinit in your lab.

#Setting Up Time Synchronization with chrony

We'll use chrony — a modern NTP implementation available on Ubuntu Server. Install it on all three VMs (the KDC and both clients):

Install chrony on all VMs

sudo apt update
sudo apt install chrony -y

In a lab environment, all VMs can point to the same time source — for example, a public NTP server or a VM acting as the time server. The default configuration in /etc/chrony/chrony.conf already points to the public NTP pool:

# Use public servers from the pool.ntp.org project.
pool 2.ubuntu.pool.ntp.org iburst

For an isolated lab, you can add an internal time server. Enable and verify:

sudo systemctl enable --now chrony
chronyc tracking
timedatectl

The chronyc tracking output shows the synchronization status: the System time field shows the difference between the system clock and the time source. If all VMs are synchronized to the same source, the difference between VMs will be tiny — far below the 5-minute tolerance.

#Configuring clockskew in krb5.conf

The 5-minute tolerance is the default, but it can be changed through the /etc/krb5.conf file. In the [libdefaults] section, add the clockskew value in seconds:

[libdefaults]
    default_realm = EXAMPLE.COM
    clockskew = 300
    ticket_lifetime = 24h
    renew_lifetime = 7d
    forwardable = true

The value 300 equals the default, but writing it explicitly makes your configuration clear and easy to adjust. In practice, careful admins sometimes increase this value in environments where the clock is hard to maintain — but be careful: the larger the tolerance, the wider the replay attack window you allow.

#DNS for Kerberos

DNS is how a client finds the KDC. Without correct DNS, the client will never find the server it needs to talk to — even if the time is perfect.

#Forward and Reverse Lookup

Kerberos depends heavily on names:

• Forward lookup — hostname to IP address.
• Reverse lookup — IP address to hostname.

Service principals use hostnames like host/kdc.example.com@EXAMPLE.COM, and the service needs to validate that the client is contacting the correct name. Inconsistent DNS — a hostname that differs from the DNS record, or a mismatched reverse lookup — is a source of Server not found in Kerberos database errors.

#SRV Records: KDC Discovery

To find the KDC, clients read SRV records in the realm's DNS zone. The three main records that must exist:

Example in a BIND zone (db.example.com):

$ORIGIN example.com.
_kerberos._udp        SRV 0 0 88 kdc.example.com.
_kerberos._tcp        SRV 0 0 88 kdc.example.com.
_kerberos-master._tcp SRV 0 0 88 kdc.example.com.
_kpasswd._udp         SRV 0 0 464 kdc.example.com.

#TXT Record: Realm Information

One more TXT record helps clients learn which realm matches a domain:

$ORIGIN example.com.
_kerberos.example.com. TXT "EXAMPLE.COM"

#Testing with dig

After creating the records, verify with dig:

dig +short _kerberos._udp.example.com SRV
dig +short -x 192.168.10.10
dig +short _kerberos.example.com TXT

If dig +short _kerberos._udp.example.com SRV returns 0 0 88 kdc.example.com., clients will find the KDC correctly. You can also test client resolution directly with getent hosts kdc.example.com.

#Fallback: /etc/hosts

For small labs or environments without full DNS, Kerberos can use /etc/hosts as a fallback. On every VM, add the following lines:

192.168.10.10   kdc.example.com     kdc
192.168.10.21   client1.example.com client1
192.168.10.22   client2.example.com client2

#Troubleshooting Time Skew

When the error appears, use the following check sequence:

date --set="2026-08-03 10:00:00"

If a large difference is found, fix the system clock — in a lab it's often enough to rewrite the clock with date --set, then let chrony maintain consistency afterward. In production, fix the NTP source and let synchronization work automatically.

#Conclusion

This episode handled the two infrastructure prerequisites that most often destroy Kerberos: time synchronization and DNS. You set up chrony on all VMs, understood the 5-minute clockskew tolerance and how to change it in krb5.conf, created the _kerberos, _kerberos-master, and _kpasswd SRV records along with the realm TXT record, used /etc/hosts as a lab fallback, and learned the troubleshooting sequence for the Clock skew too great error.

Key points to take with you:

• Timestamps are part of Kerberos's security mechanism — time must be synchronized.
• Default tolerance is 300 seconds; tighten it for strict security, widen it only when necessary.
• SRV records are how clients find the KDC; TXT records connect domains to realms.
• dig is the fastest DNS verification tool; /etc/hosts is the small-lab lifesaver.
• The Clock skew too great error usually hides behind Preauthentication failed — dig it out with KRB5_TRACE=1.

In the next episode, episode 5, we'll assemble everything: installing the MIT Kerberos KDC — from package installation, realm configuration in krb5.conf and kdc.conf, creating the database with kdb5_util, creating the first principal, to verifying with kinit and klist. This is the episode where your lab truly comes alive. See you there!