Loading...

VONDS ©

Lab 132: Fix Slow Hostname Lookups (Reverse DNS)

Back to Lab Index

Diagnose slow SSH and sudo caused by hostname lookups that hit a timing-out DNS path. Collect before-and-after timing evidence with time and getent, then restore fast lookups by fixing resolver settings and reducing reverse-DNS impact.

networking troubleshooting dns ssh sudo core

Scenario

Users report that SSH logins and sudo prompts feel slow on a server that otherwise looks healthy. The symptom points to name resolution delays, usually caused by a resolver timeout or reverse DNS lookups on inbound connections.

Operator context

Treat this like a reliability issue. Capture timing evidence, remove the timeout path from the hot loop, and prove improvement by re-running the same measurements after each change.

Objective

  • Measure lookup latency using time and getent.
  • Identify the active resolver configuration and confirm the timeout path.
  • Update DNS settings to a working server and verify name service becomes fast.
  • Reduce SSH reverse-DNS impact by setting UseDNS no (policy permitting).
  • Re-test and capture before-and-after timings to document the fix.

Concepts

  • NSS resolution is what applications experience; use getent to test it.
  • Direct DNS queries isolate the server response using dig.
  • Resolver timeouts compound via retries and multiple name servers.
  • Reverse DNS is a common SSH delay when UseDNS is enabled.
  • Fix the dependency first (DNS reachability), then reduce optional lookups in hot paths.

Walkthrough

Step 1 : Measure NSS lookup latency.
Command 
time getent hosts portal.lab.local

This is your baseline. If name service is slow, you will see seconds of delay in the real time output. 

10.0.2.50   portal.lab.local

real    0m2.01s
user    0m0.00s
sys     0m0.00s
Step 2 : Identify the active DNS server.
Command 
resolvectl status

Find the DNS server in use for your active interface. In this lab, the configured resolver is incorrect and points to a server that does not respond. 

Link 2 (eth0)
     DNS Servers: 10.0.2.99
Current DNS Server: 10.0.2.99
Step 3 : Prove the resolver is timing out.
Command 
dig @10.0.2.99 portal.lab.local

This isolates the dependency. If the configured DNS server cannot answer, the resolver stack will retry and your interactive workflows will pay the delay. 

;; communications error to 10.0.2.99#53: timed out
;; communications error to 10.0.2.99#53: timed out
;; no servers could be reached
Step 4 : Set DNS to the correct server using NetworkManager.
Commands 
nmcli -t -f DEVICE,NAME con show --active | grep '^eth0:'
sudo nmcli con mod "<CONNECTION_NAME>" ipv4.dns "10.0.2.3"
sudo nmcli con up "<CONNECTION_NAME>"

This removes the timeout path by pointing name resolution at a working resolver. Re-apply the connection so the new DNS setting takes effect.

Step 5 : Confirm the active resolver is now 10.0.2.3.
Command 
resolvectl status
Link 2 (eth0)
     DNS Servers: 10.0.2.3
Current DNS Server: 10.0.2.3
Step 6 : Re-measure lookup time to prove improvement.
Command 
time getent hosts portal.lab.local

The lookup should return quickly now. If it does not, you still have a resolver/search/timeout issue to eliminate. 

10.0.2.50   portal.lab.local

real    0m0.01s
user    0m0.00s
sys     0m0.00s
Step 7 : Disable SSH reverse DNS lookups (policy permitting).
Safety note

Changing SSH server behavior is an operational decision. Validate the security and auditing impact for your environment before making this permanent.

Commands 
sudo grep -n '^[#[:space:]]*UseDNS' /etc/ssh/sshd_config
sudoedit /etc/ssh/sshd_config
sudo systemctl reload sshd

Ensure the configuration includes UseDNS no. This prevents sshd from doing reverse DNS lookups on connecting clients, which removes a common “SSH feels slow” failure mode when DNS is unreliable. 

# In /etc/ssh/sshd_config
UseDNS no
Step 8 : Validate the service path still works.
Command 
curl -I http://portal.lab.local

This confirms the hostname resolves and the application path is reachable after DNS changes. 

HTTP/1.1 200 OK

Common breakpoints

getent is fast, but SSH is still slow

The delay may be authentication (SSSD/LDAP), PAM modules, GSSAPI/Kerberos, or sshd settings unrelated to DNS. Check client/server logs and validate authentication paths independently of name resolution.

resolvectl is not available

The host may not be using systemd-resolved. Inspect /etc/resolv.conf and continue testing with dig against the configured name servers.

DNS looks correct but lookups are still slow

Check multiple unreachable name servers, search domain delays, or IPv6-related timeouts. Compare timings using direct queries (for example dig @SERVER NAME) and remove any server that cannot respond.

Cleanup checklist

This lab is non-destructive unless you changed resolver or SSH settings. If you need to restore the “broken” state for repeat testing, point DNS back to the bad server only in a lab environment.

Commands 
nmcli -t -f DEVICE,NAME con show --active | grep '^eth0:'
sudo nmcli con mod "<CONNECTION_NAME>" ipv4.dns "10.0.2.99"
sudo nmcli con up "<CONNECTION_NAME>"

Reference

  • time <command> : Measures elapsed time for a command.
  • getent hosts <name> : Resolves a hostname using the system NSS configuration.
  • resolvectl status : Shows active resolver configuration (systemd-resolved).
  • dig @<server> <name> : Queries a specific DNS server to test reachability and response.
    • @<server> : Sends the query to the specified DNS server.
  • nmcli con show --active : Lists active NetworkManager connections.
    • -t : Produces terse output (useful for scripting).
    • -f : Selects output fields (for example DEVICE,NAME ).
  • nmcli con mod "<con>" ipv4.dns "<server>" : Sets DNS for a connection profile.
    • ipv4.dns : Overrides DNS servers for the profile.
  • nmcli con up "<con>" : Re-applies a NetworkManager connection profile.
  • sudoedit <file> : Edits a file using your editor with elevated privileges.
    • /etc/ssh/sshd_config : OpenSSH server configuration file.
  • systemctl reload sshd : Reloads sshd configuration without dropping existing sessions.
  • curl -I <url> : Fetches HTTP response headers for quick connectivity checks.
    • -I : Requests headers only.