Examkin

Question

Difficulty: Very hardUtilizing Command-Line Network Troubleshooting Utilities

A network engineer is troubleshooting why internal workstations cannot access a newly deployed secure internal portal at `vault.corp.local`. The engineer executes `dig vault.corp.local` on a client workstation and captures the following terminal output:

;; QUESTION SECTION:
;vault.corp.local. IN A

;; ANSWER SECTION:
vault.corp.local. 300 IN CNAME sec-srv01.corp.local.

;; ADDITIONAL SECTION:
sec-srv01.corp.local. 300 IN A 10.200.5.25

Next, the engineer remotely accesses the destination server (`10.200.5.25`) and runs `netstat -tuln`, which displays:

Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 10.200.5.25:8443 0.0.0.0:* LISTEN
udp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN

When end users attempt to navigate to `https://vault.corp.local` using standard browser defaults, the request immediately fails with a "Connection Refused" error. Based on the command outputs provided, which root cause explains why clients are unable to connect?

  1. The web application daemon is listening on TCP port 8443 rather than standard HTTPS port 443, causing default client web requests to be rejected by the host.Answer
  2. B
    The DNS lookup failed because the ANSWER section returned a CNAME canonical alias rather than an authoritative direct A record for vault.corp.local.
  3. C
    The DNS server misconfiguration forced the host to resolve an MX mail exchanger record instead of an AAAA IPv6 host address.
  4. D
    The web service is bound to UDP port 53, which is incompatible with TCP-based web browser sessions.

Answer

The web application daemon is listening on non-standard TCP port 8443 rather than standard HTTPS port 443, causing default client web requests to be rejected by the host.
The `dig` output demonstrates successful name resolution, resolving `vault.corp.local` via alias to IP address `10.200.5.25`. However, the `netstat -tuln` output shows the web daemon listening on custom TCP port 8443 (`10.200.5.25:8443`) rather than the standard HTTPS port 443. When users attempt to connect via standard HTTPS (`https://vault.corp.local`), their browser sends traffic to port 443. Because no service is bound to TCP port 443 on the target host, the server's OS rejects the connection attempt.

Step-by-Step Solution

1
Analyze the `dig` command output snippet to evaluate DNS resolution.
The `dig` query for `vault.corp.local` returns a CNAME pointing to `sec-srv01.corp.local.`, and the ADDITIONAL section successfully resolves `sec-srv01.corp.local.` to IP address `10.200.5.25`.
DNS resolution is functioning correctly; the client successfully resolves the target domain name to IPv4 address `10.200.5.25`.
2
Analyze the `netstat -tuln` command output snippet from target host `10.200.5.25`.
The output indicates an active TCP listening socket on `10.200.5.25:8443` (`tcp 0 0 10.200.5.25:8443 ... LISTEN`). Port 443 is not listed.
Web browsers attempting an HTTPS connection to `https://vault.corp.local` automatically target TCP port 443 by default unless an explicit port is appended to the URL.
3
Synthesize the DNS resolution result and socket binding state to determine why connections are refused.
Because no process is listening on TCP port 443 on host `10.200.5.25`, TCP SYN packets sent to port 443 trigger a TCP RST (Reset) packet from the operating system, resulting in a 'Connection Refused' error in the client browser.
Connecting requires matching both IP address resolution and target port listening states.

Key Concept

Correlating DNS query output with host netstat socket bindings during protocol troubleshooting
Rate this question

Topics

Utilizing Command-Line Network Troubleshooting Utilities

More questions from this topic