You run a simple update, and suddenly your terminal hangs for thirty seconds while dnf insists on checking every remote repository for header updates. It is a massive annoyance, especially when you are on a metered connection or just trying to quickly install a package. The defaults are set for a server that never sleeps, not for a workstation that spends half its life suspended.

Why dnf thinks it needs to be so needy

Most sysadmins think dnf is just slow. It isn’t. It is just overly aggressive about cache invalidation. By default, dnf checks the metadata timestamps against the remote servers constantly. If it decides your local repo information is even a few hours old, it triggers a refresh. This behavior is baked into the configuration files in /etc/dnf/dnf.conf and keeps you from seeing the speed you actually paid for.

echo 'metadata_expire=86400' | sudo tee -a /etc/dnf/dnf.conf

• Set metadata_expire to 86400 seconds to force a 24-hour cache window
• Use dnf makecache –timer only when you absolutely need the latest state
• Avoid using -y until you have verified the cached versions are what you expect

The trade-off you need to own

Increasing the metadata expiry does have a risk. If a repository pushes an urgent security patch, your system will not see it until the cache expires or you manually trigger an update. That is a trade-off I am happy to make for the performance gain. Keep in mind that dnf clean all is your escape hatch if things get weird, but do not make it a daily habit.

Next time you feel the urge to blame the network for a slow update, look at your cache settings first. A few seconds of editing a config file saves minutes of waiting every single day.