The server IP responds to ping but the hostname or application does not work: how should DNS be investigated?
Check client DNS, suffix search, A and AAAA records, caches, hosts overrides, VPN DNS routing, and whether the application uses a short name or FQDN.
Check client DNS, suffix search, A and AAAA records, caches, hosts overrides, VPN DNS routing, and whether the application uses a short name or FQDN. For this case, first verify client DNS configuration and DNS suffix search list, then use correctness of A/AAAA records to decide whether remediation is needed.
Define the failure boundary first
For this network and security-boundary case, establish the failure boundary with DNS and DNS, then continue to correctness of A/AAAA records. Capture the current state, incident time and one known-good comparison before changing production configuration.
Work through the dependency chain
| Check | Why it matters | Recommended action |
|---|---|---|
| 01 · client DNS configuration | Verify client DNS configuration on the affected path using logs, counters or state information rather than relying only on the configured rule. | Record the current value, evidence source and timestamp for client DNS configuration. If adjustment is required, change one condition only and retain the original setting for rollback. |
| 02 · DNS suffix search list | Verify DNS suffix search list on the affected path using logs, counters or state information rather than relying only on the configured rule. | Check DNS suffix search list read-only and save the result. If it differs from the baseline, correlate it with the incident time and recent changes before remediation. |
| 03 · correctness of A/AAAA records | Verify correctness of A/AAAA records on the affected path using logs, counters or state information rather than relying only on the configured rule. | Compare correctness of A/AAAA records with a known-good peer, the log timeline and the real application path; confirm whether it is causal before changing production. |
| 04 · local hosts file and resolver cache | Review the current state, related logs and recent changes for local hosts file and resolver cache, then align them with the incident timeline before deciding whether a change is required. | Record the current value, evidence source and timestamp for local hosts file and resolver cache. If adjustment is required, change one condition only and retain the original setting for rollback. |
| 05 · VPN/multi-NIC DNS priority | Review the current state, related logs and recent changes for VPN/multi-NIC DNS priority, then align them with the incident timeline before deciding whether a change is required. | Check VPN/multi-NIC DNS priority read-only and save the result. If it differs from the baseline, correlate it with the incident time and recent changes before remediation. |
| 06 · short-name versus FQDN behavior | Review the current state, related logs and recent changes for short-name versus FQDN behavior, then align them with the incident timeline before deciding whether a change is required. | Compare short-name versus FQDN behavior with a known-good peer, the log timeline and the real application path; confirm whether it is causal before changing production. |
ipconfig /all
nslookup server.corp.example
ipconfig /displaydnsChange only after the evidence is clear
- Start with read-only evidence. Check client DNS configuration and DNS suffix search list before changing configuration.
- If the first checks are normal, continue with correctness of A/AAAA records and local hosts file and resolver cache, keeping evidence tied to the incident time.
- Change configuration only when the evidence explains the symptom. For VPN/multi-NIC DNS priority, preserve the original value and define the rollback trigger before adjustment.
- Validate short-name versus FQDN behavior in a controlled scope before expanding to production users or traffic.
Validation and rollback
- Validate the complete user or application workflow; do not stop at the single status of client DNS configuration.
- Recheck VPN/multi-NIC DNS priority and short-name versus FQDN behavior after the change and confirm that no new bypass, permission expansion or secondary error has appeared.
- Archive evidence from client DNS configuration through short-name versus FQDN behavior, together with before/after configuration, business validation and the rollback point.
Common wrong turns
- Changing DNS and DNS at the same time, which makes the original cause impossible to prove.
- Treating a normal result for correctness of A/AAAA records as proof that hosts and the rest of the business path are healthy.
- Leaving a temporary exception related to VPN/multi-NIC DNS priority or FQDN in production without an owner, expiry time and rollback note.
Related questions
Where should I start with “The server IP responds to ping but the hostname or application does not work: how should DNS be investigated?”?
Start with client DNS configuration and DNS suffix search list; they establish the first useful troubleshooting boundary without changing production state.
What should be checked after the first layer looks normal?
Continue with correctness of A/AAAA records and local hosts file and resolver cache, then correlate the result with the incident time and the actual user or application path.
What should be retained after the change?
Keep evidence for VPN/multi-NIC DNS priority and short-name versus FQDN behavior, plus the original configuration, validation result, observation notes and rollback point.