Examkin

Question

Difficulty: MediumTroubleshooting DNS and Name Resolution Services

A network technician is troubleshooting name resolution issues on a Linux client system. The client can successfully reach internal resources by IP address, but system applications fail to resolve the hostname `app.lab.internal`.

The technician executes a targeted query using `dig` and receives the following output:

$ dig @172.16.0.10 app.lab.internal A

; <<>> DiG 9.16.1-Ubuntu <<>> @172.16.0.10 app.lab.internal A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41258
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;app.lab.internal. IN A

;; ANSWER SECTION:
app.lab.internal. 3600 IN A 172.16.50.25

Despite the direct query returning a valid record from `172.16.0.10`, standard system tools and web browsers on the workstation still fail to resolve `app.lab.internal`. Which of the following potential root causes could explain this behavior? (Select TWO.)

  1. The local system resolver configuration file (`/etc/resolv.conf`) is pointing to a different DNS server instead of `172.16.0.10`.Answer
  2. An incorrect static entry for `app.lab.internal` exists in the client's local `/etc/hosts` file.Answer
  3. C
    The DNS server at `172.16.0.10` lacks an authoritative A record for `app.lab.internal`.
  4. D
    UDP port 53 traffic is blocked by a network firewall between the workstation and `172.16.0.10`.

Answer

The two valid causes are that the workstation's `/etc/resolv.conf` file specifies a different DNS server than `172.16.0.10`, and that an erroneous static entry exists in the local `/etc/hosts` file.
The `dig` tool with the `@server` parameter directly queries the targeted DNS server (`172.16.0.10`) while ignoring local OS resolution mechanisms. Because the `dig` command succeeded with `NOERROR` and returned an A record, `172.16.0.10` is reachable and functional. System applications fail either because `/etc/resolv.conf` is pointing the system to a different, failing DNS server, or because an entry in `/etc/hosts` takes precedence over DNS queries and contains a bad mapping.

Step-by-Step Solution

1
Analyze the output of the `dig @172.16.0.10 app.lab.internal A` command.
The response status is `NOERROR` with an answer section providing IP `172.16.50.25`. This confirms the DNS server at `172.16.0.10` has a valid record and is reachable over port 53 UDP.
Direct DNS server queries test the server's record availability and network reachability independently of the host's operating system resolver settings.
2
Identify how operating system name resolution differs from direct utility queries like `dig`.
Standard system calls check the local host configuration (e.g., `/etc/hosts`) first, followed by the default DNS servers listed in `/etc/resolv.conf`.
Utilities such as `dig` bypass local OS resolution order and `/etc/hosts` files to query target IP addresses directly.
3
Deduce potential local misconfigurations causing system-wide resolution failure.
If `/etc/resolv.conf` does not list `172.16.0.10` or if `/etc/hosts` contains a conflicting/stale mapping, system applications will fail while `dig @172.16.0.10` succeeds.
Discrepancies between host-level configuration files and explicit server queries pinpoint client-side configuration issues.

Key Concept

Discrepancies between direct DNS queries (dig/nslookup specifying a server) and operating system name resolution mechanisms (resolver configuration and host files).
Rate this question

Topics

Troubleshooting DNS and Name Resolution Services

More questions from this topic