Loading...

VONDS ©

Lab 131: Fix Wrong Hostname Resolution (hosts override)

Back to Lab Index

Fix an application misrouting issue caused by a bad /etc/hosts override that forces portal.lab.local to resolve to 127.0.0.1 instead of DNS. Confirm the resolution path, remove the override safely, verify DNS resolution to 10.0.2.50, then validate the HTTP endpoint.

networking troubleshooting dns nss core

Scenario

Users report the internal app at portal.lab.local is loading the wrong environment. The ticket notes: “It looks like this host resolves portal.lab.local to 127.0.0.1.” You must confirm the resolution path, remove any bad /etc/hosts override, verify DNS is used, and confirm the service is reachable.

Expected result

portal.lab.local should resolve to 10.0.2.50. Verification target: http://portal.lab.local.

Objective

  • Confirm what IP portal.lab.local resolves to on this host.
  • Locate any /etc/hosts override that forces a bad mapping.
  • Remove the override safely and re-check resolution.
  • Verify the active DNS server configuration as a sanity check.
  • Confirm the portal responds over HTTP after resolution is corrected.

Concepts

Hostname resolution on Linux typically follows the system NSS configuration (often /etc/nsswitch.conf), and /etc/hosts frequently takes precedence over DNS.

  • NSS path: what applications use (hosts file + DNS based on system configuration).
  • Direct DNS query: what dig shows (ignores /etc/hosts).
  • Mismatch signal: if getent and dig disagree, you likely have a local override.
Operational habit

Use getent hosts to confirm what applications actually see. Use dig to confirm what DNS says. When they differ, trust getent for user impact.

Walkthrough

Step 1: Check what IP portal.lab.local resolves to (NSS vs DNS).
Commands 
getent hosts portal.lab.local
getent ahosts portal.lab.local
dig +short portal.lab.local

getent tests the system’s real resolution path (NSS), which can include /etc/hosts before DNS. dig queries DNS directly and will not show /etc/hosts overrides. 

# Example mismatch:
127.0.0.1   portal.lab.local
# DNS:
10.0.2.50
Step 2: Find the /etc/hosts override.
Command 
grep -n 'portal.lab.local' /etc/hosts

Any mapping for portal.lab.local here will typically win over DNS for normal system tools. 

# Example:
6:127.0.0.1 portal.lab.local portal
Step 3: Remove the offending line safely.
Commands 
sudoedit /etc/hosts
# OR
sudo vim /etc/hosts
# OR
sudo vi /etc/hosts
# OR
sudo nano /etc/hosts

Remove only the bad mapping and keep legitimate entries intact. sudoedit is a safe default because it edits a temp file and then writes back with the correct permissions. 

# Remove:
127.0.0.1 portal.lab.local portal
Step 4: Re-check resolution and confirm 10.0.2.50.
Commands 
getent hosts portal.lab.local
dig +short portal.lab.local

After removing the override, NSS should fall back to DNS and return the ticketed IP. 

10.0.2.50   portal.lab.local
Step 5: Sanity check the resolver configuration.
Commands 
resolvectl status
cat /etc/resolv.conf

Confirm the host is pointed at the expected DNS server (in this environment, typically 10.0.2.3).

Step 6: Verify the portal responds over HTTP.
Commands 
curl -I http://portal.lab.local
curl -sS http://portal.lab.local | head

This confirms correct resolution plus service reachability. If DNS looks correct but HTTP fails, pivot to service health on 10.0.2.50, firewalling, routing, or application issues. 

HTTP/1.1 200 OK

Breakpoints

getent and dig both show 10.0.2.50 but users still see the wrong app

The issue may be caching (browser, proxy, CDN), a load balancer routing problem, or an application-side environment mapping issue. Prove which backend you reached with curl -v or app headers.

dig fails or returns no records

DNS may be down or the zone is missing records. Confirm the configured DNS server is reachable and validate resolution against the DNS server directly.

You edited /etc/hosts but resolution still returns 127.0.0.1

Check for additional aliases in /etc/hosts (another line), or an application/container using its own hosts file or custom resolver.

HTTP fails after resolution is corrected

Test reachability to the IP directly (curl -I http://10.0.2.50) and confirm the service is listening and allowed through firewall policy.

Cleanup checklist

If you need to restore the previous lab state, you can re-add the bad mapping. Do this only in a lab environment.

Commands 
sudoedit /etc/hosts
# Add back (lab-only):
# 127.0.0.1 portal.lab.local portal

getent hosts portal.lab.local
dig +short portal.lab.local

Reference

  • getent hosts <name>: resolve a hostname through the system NSS stack.
  • getent ahosts <name>: show resolved address records as seen by NSS.
  • dig +short <name>: query DNS directly (ignores /etc/hosts).
  • /etc/hosts: local hostname-to-IP override file (often takes precedence over DNS).
  • grep -n <pattern> /etc/hosts: find matching entries with line numbers.
  • sudoedit /etc/hosts: safely edit a root-owned file via a temp copy.
  • resolvectl status: show active resolver configuration (systemd-resolved).
  • /etc/resolv.conf: resolver config file (often generated by NetworkManager/systemd-resolved).
  • curl -I <url>: fetch HTTP headers to confirm reachability and response.