LPI 102-500 Practice Test 59
Question 580
While verifying a Linux change request, an engineer finds: A domain returns NXDOMAIN from a corporate resolver while an engineer claims that using `host` against a public resolver proves the local client is correctly configured. Which TWO complementary steps provide the best corrective action and its most direct diagnostic verification? Select TWO answers.
- Compare `dig name`, `dig @server name`, `host name`, `getent ahosts name` and the resolver settings.
- Use dig or host to test chosen DNS servers explicitly and separately verify normal resolver lookup through getent and local client settings.
- Inspect `ip route` and selected `ip route get`, then set or repair the appropriate default route in the active manager or with `ip route` for a controlled temporary change.
- Inspect `hostnamectl status`, /etc/hostname, /etc/hosts and `getent hosts` output before and after reboot.
- Assume success from `dig @8.8.8.8` guarantees every local application uses that same server and returns the same answer.
Explanation
Correct Answers
A:Most direct verification evidence: Compare `dig name`, `dig @server name`, `host name`, `getent ahosts name` and the resolver settings. Linux principle: A direct DNS query to a named server tests that server, while application resolution follows local NSS, caching and resolver configuration.
B:Recommended administrative action: Use dig or host to test chosen DNS servers explicitly and separately verify normal resolver lookup through getent and local client settings. Linux principle: A direct DNS query to a named server tests that server, while application resolution follows local NSS, caching and resolver configuration.
Incorrect Answers
C:This alternative addresses Linux routing tables and default gateway selection, not the specific issue of DNS query tools and authoritative versus recursive answers: Inspect `ip route` and selected `ip route get`, then set or repair the appropriate default route in the active manager or with `ip route` for a controlled temporary change. Linux principle: A direct DNS query to a named server tests that server, while application resolution follows local NSS, caching and resolver configuration. Appropriate response: Use dig or host to test chosen DNS servers explicitly and separately verify normal resolver lookup through getent and local client settings. Root-cause evidence: Compare `dig name`, `dig @server name`, `host name`, `getent ahosts name` and the resolver settings. Independent acceptance: The application's normal lookup resolves the intended name from the approved resolver with no split-horizon mismatch.
D:This alternative addresses Hostnamectl and durable host identification, not the specific issue of DNS query tools and authoritative versus recursive answers: Inspect `hostnamectl status`, /etc/hostname, /etc/hosts and `getent hosts` output before and after reboot. Linux principle: A direct DNS query to a named server tests that server, while application resolution follows local NSS, caching and resolver configuration.
E:This shortcut is unsafe for the present Linux issue: Assume success from `dig @8.8.8.8` guarantees every local application uses that same server and returns the same answer. A direct DNS query to a named server tests that server, while application resolution follows local NSS, caching and resolver configuration.
Question 581
A Linux administrator investigates the following system incident: A service name is expanded with an unintended search domain and maps to the wrong environment even though the absolute FQDN is correct. Which administrative step is the MOST appropriate way to resolve this issue? Select ONE best answer.
- Review NSS ordering, DNS search domains and active systemd-resolved or NetworkManager resolver integration before changing client resolution.
- Use `nmcli connection` to edit the correct NetworkManager profile's IPv4 method, addresses, gateway and activation settings, then reapply deliberately.
- Assume /etc/resolv.conf is always a manually maintained static file and that a short hostname cannot be affected by DNS search suffixes.
- Choose TCP when reliable ordered byte streams are needed, UDP for connectionless datagrams with application-level reliability as required, and ICMP for appropriate network control and diagnostics.
Explanation
Correct Answer
A:Recommended administrative action: Review NSS ordering, DNS search domains and active systemd-resolved or NetworkManager resolver integration before changing client resolution. A resolver's search suffixes, per-link DNS choices and stub or split-DNS behavior can alter queries independently of the authoritative zone contents.
Incorrect Answers
B:That option would use `nmcli connection` to edit the correct NetworkManager profile's IPv4 method, addresses, gateway and activation settings, then reapply deliberately, but it addresses a different concern. A resolver's search suffixes, per-link DNS choices and stub or split-DNS behavior can alter queries independently of the authoritative zone contents.
C:That option would assume /etc/resolv.conf is always a manually maintained static file and that a short hostname cannot be affected by DNS search suffixes, but it addresses a different concern. A resolver's search suffixes, per-link DNS choices and stub or split-DNS behavior can alter queries independently of the authoritative zone contents.
D:This alternative addresses TCP versus UDP versus ICMP diagnostics, not the specific issue of Resolver precedence, search domains and systemd-resolved: Choose TCP when reliable ordered byte streams are needed, UDP for connectionless datagrams with application-level reliability as required, and ICMP for appropriate network control and diagnostics. Linux principle: A resolver's search suffixes, per-link DNS choices and stub or split-DNS behavior can alter queries independently of the authoritative zone contents. Appropriate response: Review NSS ordering, DNS search domains and active systemd-resolved or NetworkManager resolver integration before changing client resolution. Root-cause evidence: Inspect `resolvectl status` if used, /etc/resolv.conf target, search directives and queries for short names versus fully qualified names. Independent acceptance: Approved short and absolute names resolve to intended addresses on the correct link without breaking VPN split DNS.
Question 582
On a production Linux workstation or server, a technician observes: A service name is expanded with an unintended search domain and maps to the wrong environment even though the absolute FQDN is correct. Which Linux behavior or technical principle BEST explains why the issue occurs? Select ONE best answer.
- A resolver's search suffixes, per-link DNS choices and stub or split-DNS behavior can alter queries independently of the authoritative zone contents.
- RFC1918 private IPv4 ranges are 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16; not every 172.x or 192.x address is private.
- Different Linux networking managers apply persistent interface settings through their own configurations; conflicting ownership can cause changes to be ignored or overwritten.
- Assume /etc/resolv.conf is always a manually maintained static file and that a short hostname cannot be affected by DNS search suffixes.
Explanation
Correct Answer
A:Relevant Linux operating principle: A resolver's search suffixes, per-link DNS choices and stub or split-DNS behavior can alter queries independently of the authoritative zone contents.
Incorrect Answers
B:This alternative addresses RFC1918 private addressing and internet routing, not the specific issue of Resolver precedence, search domains and systemd-resolved: RFC1918 private IPv4 ranges are 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16; not every 172.x or 192.x address is private. Linux principle: A resolver's search suffixes, per-link DNS choices and stub or split-DNS behavior can alter queries independently of the authoritative zone contents. Appropriate response: Review NSS ordering, DNS search domains and active systemd-resolved or NetworkManager resolver integration before changing client resolution. Root-cause evidence: Inspect `resolvectl status` if used, /etc/resolv.conf target, search directives and queries for short names versus fully qualified names. Independent acceptance: Approved short and absolute names resolve to intended addresses on the correct link without breaking VPN split DNS.
C:This alternative addresses NetworkManager and systemd-networkd configuration ownership, not the specific issue of Resolver precedence, search domains and systemd-resolved: Different Linux networking managers apply persistent interface settings through their own configurations; conflicting ownership can cause changes to be ignored or overwritten. Linux principle: A resolver's search suffixes, per-link DNS choices and stub or split-DNS behavior can alter queries independently of the authoritative zone contents. Appropriate response: Review NSS ordering, DNS search domains and active systemd-resolved or NetworkManager resolver integration before changing client resolution. Root-cause evidence: Inspect `resolvectl status` if used, /etc/resolv.conf target, search directives and queries for short names versus fully qualified names. Independent acceptance: Approved short and absolute names resolve to intended addresses on the correct link without breaking VPN split DNS.
D:That option would assume /etc/resolv.conf is always a manually maintained static file and that a short hostname cannot be affected by DNS search suffixes, but it addresses a different concern. Independent acceptance: Approved short and absolute names resolve to intended addresses on the correct link without breaking VPN split DNS.
Question 583
During an LPIC-1 practice lab, the operator encounters this condition: A service name is expanded with an unintended search domain and maps to the wrong environment even though the absolute FQDN is correct. Which evidence or command result MOST directly tests the suspected root cause? Select ONE best answer.
- Inspect `resolvectl status` if used, /etc/resolv.conf target, search directives and queries for short names versus fully qualified names.
- Inspect `ip -6 addr`, `ip -6 route`, router advertisements and a scoped ping6 to the link-local destination.
- Assume /etc/resolv.conf is always a manually maintained static file and that a short hostname cannot be affected by DNS search suffixes.
- Inspect interface addresses and routing, compare to the exact RFC1918 CIDR ranges, and test external source visibility where permitted.
Explanation
Correct Answer
A:Most direct verification evidence: Inspect `resolvectl status` if used, /etc/resolv.conf target, search directives and queries for short names versus fully qualified names. A resolver's search suffixes, per-link DNS choices and stub or split-DNS behavior can alter queries independently of the authoritative zone contents.
Incorrect Answers
B:That option would inspect `ip -6 addr`, `ip -6 route`, router advertisements and a scoped ping6 to the link-local destination, but it addresses a different concern. A resolver's search suffixes, per-link DNS choices and stub or split-DNS behavior can alter queries independently of the authoritative zone contents.
C:This shortcut is unsafe for the present Linux issue: Assume /etc/resolv.conf is always a manually maintained static file and that a short hostname cannot be affected by DNS search suffixes. A resolver's search suffixes, per-link DNS choices and stub or split-DNS behavior can alter queries independently of the authoritative zone contents.
D:That option would inspect interface addresses and routing, compare to the exact RFC1918 CIDR ranges, and test external source visibility where permitted, but it addresses a different concern. A resolver's search suffixes, per-link DNS choices and stub or split-DNS behavior can alter queries independently of the authoritative zone contents.
Question 584
A helpdesk escalation describes this Linux behavior: A service name is expanded with an unintended search domain and maps to the wrong environment even though the absolute FQDN is correct. Which observed outcome BEST confirms a successful and properly scoped correction? Select ONE best answer.
- Remote traffic takes the intended next hop while on-link paths remain correct and route behavior persists as configured.
- Assume /etc/resolv.conf is always a manually maintained static file and that a short hostname cannot be affected by DNS search suffixes.
- Host resolution follows the documented local and DNS precedence without stale overrides for the service name.
- Approved short and absolute names resolve to intended addresses on the correct link without breaking VPN split DNS.
Explanation
Correct Answer
D:Observable acceptance criterion: Approved short and absolute names resolve to intended addresses on the correct link without breaking VPN split DNS. A resolver's search suffixes, per-link DNS choices and stub or split-DNS behavior can alter queries independently of the authoritative zone contents.
Incorrect Answers
A:This alternative addresses Linux routing tables and default gateway selection, not the specific issue of Resolver precedence, search domains and systemd-resolved: Remote traffic takes the intended next hop while on-link paths remain correct and route behavior persists as configured. Linux principle: A resolver's search suffixes, per-link DNS choices and stub or split-DNS behavior can alter queries independently of the authoritative zone contents. Appropriate response: Review NSS ordering, DNS search domains and active systemd-resolved or NetworkManager resolver integration before changing client resolution. Root-cause evidence: Inspect `resolvectl status` if used, /etc/resolv.conf target, search directives and queries for short names versus fully qualified names. Independent acceptance: Approved short and absolute names resolve to intended addresses on the correct link without breaking VPN split DNS.
B:This shortcut is unsafe for the present Linux issue: Assume /etc/resolv.conf is always a manually maintained static file and that a short hostname cannot be affected by DNS search suffixes. A resolver's search suffixes, per-link DNS choices and stub or split-DNS behavior can alter queries independently of the authoritative zone contents.
C:This alternative addresses Local hosts resolution versus DNS settings, not the specific issue of Resolver precedence, search domains and systemd-resolved: Host resolution follows the documented local and DNS precedence without stale overrides for the service name. Linux principle: A resolver's search suffixes, per-link DNS choices and stub or split-DNS behavior can alter queries independently of the authoritative zone contents. Appropriate response: Review NSS ordering, DNS search domains and active systemd-resolved or NetworkManager resolver integration before changing client resolution. Root-cause evidence: Inspect `resolvectl status` if used, /etc/resolv.conf target, search directives and queries for short names versus fully qualified names. Independent acceptance: Approved short and absolute names resolve to intended addresses on the correct link without breaking VPN split DNS.
Question 585
An operations handoff identifies this problem: A service name is expanded with an unintended search domain and maps to the wrong environment even though the absolute FQDN is correct. Which misleading assumption MOST directly contributes to this failure and should be rejected? Select ONE best answer.
- Assume /26 means the first 26 hosts belong to one network and that all addresses with the same first three dotted-quad octets are local.
- Assume /etc/resolv.conf is always a manually maintained static file and that a short hostname cannot be affected by DNS search suffixes.
- Assume the command `hostname newname` persistently changes every host identification file and DNS record automatically.
- Attempt DNS repairs for an interface that is administratively DOWN and assume temporary `ip` state cannot be overwritten by NetworkManager.
Explanation
Correct Answer
B:Reject this specific misconception: Assume /etc/resolv.conf is always a manually maintained static file and that a short hostname cannot be affected by DNS search suffixes. It incorrectly assumes behavior that conflicts with the observed Linux conditions.
Incorrect Answers
A:That option would assume /26 means the first 26 hosts belong to one network and that all addresses with the same first three dotted-quad octets are local, but it addresses a different concern. A resolver's search suffixes, per-link DNS choices and stub or split-DNS behavior can alter queries independently of the authoritative zone contents.
C:This alternative addresses Hostnamectl and durable host identification, not the specific issue of Resolver precedence, search domains and systemd-resolved: Assume the command `hostname newname` persistently changes every host identification file and DNS record automatically.
D:This alternative addresses Ip command address and link troubleshooting, not the specific issue of Resolver precedence, search domains and systemd-resolved: Attempt DNS repairs for an interface that is administratively DOWN and assume temporary `ip` state cannot be overwritten by NetworkManager. Linux principle: A resolver's search suffixes, per-link DNS choices and stub or split-DNS behavior can alter queries independently of the authoritative zone contents. Appropriate response: Review NSS ordering, DNS search domains and active systemd-resolved or NetworkManager resolver integration before changing client resolution. Root-cause evidence: Inspect `resolvectl status` if used, /etc/resolv.conf target, search directives and queries for short names versus fully qualified names. Independent acceptance: Approved short and absolute names resolve to intended addresses on the correct link without breaking VPN split DNS.
Question 586
A team maintaining a Linux host reports: A laptop's resolv.conf file points to a local stub resolver, but support replaces the stub with a hardcoded address without checking systemd-resolved. Which administrative step is the MOST appropriate way to resolve this issue? Select ONE best answer.
- Assume /etc/resolv.conf is always a manually maintained static file and that a short hostname cannot be affected by DNS search suffixes.
- Review hosts lookup precedence in nsswitch.conf and maintain the correct /etc/hosts and resolver settings for each source.
- Use `nmcli connection` to edit the correct NetworkManager profile's IPv4 method, addresses, gateway and activation settings, then reapply deliberately.
- Review NSS ordering, DNS search domains and active systemd-resolved or NetworkManager resolver integration before changing client resolution.
Explanation
Correct Answer
D:Recommended administrative action: Review NSS ordering, DNS search domains and active systemd-resolved or NetworkManager resolver integration before changing client resolution. Scenario: A laptop's resolv.conf file points to a local stub resolver, but support replaces the stub with a hardcoded address without checking systemd-resolved.
Incorrect Answers
A:This shortcut is unsafe for the present Linux issue: Assume /etc/resolv.conf is always a manually maintained static file and that a short hostname cannot be affected by DNS search suffixes. It cannot establish a safe correction. Scenario: A laptop's resolv.conf file points to a local stub resolver, but support replaces the stub with a hardcoded address without checking systemd-resolved.
B:That option would review hosts lookup precedence in nsswitch.conf and maintain the correct /etc/hosts and resolver settings for each source, but it addresses a different concern. A resolver's search suffixes, per-link DNS choices and stub or split-DNS behavior can alter queries independently of the authoritative zone contents.
C:This alternative addresses NetworkManager persistent wired connection profiles, not the specific issue of Resolver precedence, search domains and systemd-resolved: Use `nmcli connection` to edit the correct NetworkManager profile's IPv4 method, addresses, gateway and activation settings, then reapply deliberately. Scenario: A laptop's resolv.conf file points to a local stub resolver, but support replaces the stub with a hardcoded address without checking systemd-resolved.
Question 587
While verifying a Linux change request, an engineer finds: A laptop's resolv.conf file points to a local stub resolver, but support replaces the stub with a hardcoded address without checking systemd-resolved. Which Linux behavior or technical principle BEST explains why the issue occurs? Select ONE best answer.
- The iproute2 command changes and reports kernel interface state, while durable settings are managed by the host's networking service.
- A resolver's search suffixes, per-link DNS choices and stub or split-DNS behavior can alter queries independently of the authoritative zone contents.
- Assume /etc/resolv.conf is always a manually maintained static file and that a short hostname cannot be affected by DNS search suffixes.
- IPv6 commonly uses 128-bit addresses and prefix notation; fe80::/10 link-local addresses are limited to one link and typically need an interface zone for selection.
Explanation
Correct Answer
B:Relevant Linux operating principle: A resolver's search suffixes, per-link DNS choices and stub or split-DNS behavior can alter queries independently of the authoritative zone contents. Scenario: A laptop's resolv.conf file points to a local stub resolver, but support replaces the stub with a hardcoded address without checking systemd-resolved.
Incorrect Answers
A:This alternative addresses Ip command address and link troubleshooting, not the specific issue of Resolver precedence, search domains and systemd-resolved: The iproute2 command changes and reports kernel interface state, while durable settings are managed by the host's networking service. Scenario: A laptop's resolv.conf file points to a local stub resolver, but support replaces the stub with a hardcoded address without checking systemd-resolved. Linux principle: A resolver's search suffixes, per-link DNS choices and stub or split-DNS behavior can alter queries independently of the authoritative zone contents. Appropriate response: Review NSS ordering, DNS search domains and active systemd-resolved or NetworkManager resolver integration before changing client resolution. Root-cause evidence: Inspect `resolvectl status` if used, /etc/resolv.conf target, search directives and queries for short names versus fully qualified names. Independent acceptance: Approved short and absolute names resolve to intended addresses on the correct link without breaking VPN split DNS.
C:This shortcut is unsafe for the present Linux issue: Assume /etc/resolv.conf is always a manually maintained static file and that a short hostname cannot be affected by DNS search suffixes. It cannot establish a safe correction. Scenario: A laptop's resolv.conf file points to a local stub resolver, but support replaces the stub with a hardcoded address without checking systemd-resolved. Linux principle: A resolver's search suffixes, per-link DNS choices and stub or split-DNS behavior can alter queries independently of the authoritative zone contents.
D:This alternative addresses IPv6 addressing link-local scope and prefix rules, not the specific issue of Resolver precedence, search domains and systemd-resolved: IPv6 commonly uses 128-bit addresses and prefix notation; fe80::/10 link-local addresses are limited to one link and typically need an interface zone for selection. Scenario: A laptop's resolv.conf file points to a local stub resolver, but support replaces the stub with a hardcoded address without checking systemd-resolved. Linux principle: A resolver's search suffixes, per-link DNS choices and stub or split-DNS behavior can alter queries independently of the authoritative zone contents. Appropriate response: Review NSS ordering, DNS search domains and active systemd-resolved or NetworkManager resolver integration before changing client resolution. Root-cause evidence: Inspect `resolvectl status` if used, /etc/resolv.conf target, search directives and queries for short names versus fully qualified names. Independent acceptance: Approved short and absolute names resolve to intended addresses on the correct link without breaking VPN split DNS.
Question 588
A Linux administrator investigates the following system incident: A laptop's resolv.conf file points to a local stub resolver, but support replaces the stub with a hardcoded address without checking systemd-resolved. Which evidence or command result MOST directly tests the suspected root cause? Select ONE best answer.
- Inspect interface addresses and routing, compare to the exact RFC1918 CIDR ranges, and test external source visibility where permitted.
- Inspect protocol-specific packet traces and socket details, run both ICMP and application-layer reachability tests, and check filtering rules.
- Inspect `resolvectl status` if used, /etc/resolv.conf target, search directives and queries for short names versus fully qualified names.
- Assume /etc/resolv.conf is always a manually maintained static file and that a short hostname cannot be affected by DNS search suffixes.
Explanation
Correct Answer
C:Most direct verification evidence: Inspect `resolvectl status` if used, /etc/resolv.conf target, search directives and queries for short names versus fully qualified names. Scenario: A laptop's resolv.conf file points to a local stub resolver, but support replaces the stub with a hardcoded address without checking systemd-resolved.
Incorrect Answers
A:This alternative addresses RFC1918 private addressing and internet routing, not the specific issue of Resolver precedence, search domains and systemd-resolved: Inspect interface addresses and routing, compare to the exact RFC1918 CIDR ranges, and test external source visibility where permitted. Scenario: A laptop's resolv.conf file points to a local stub resolver, but support replaces the stub with a hardcoded address without checking systemd-resolved.
B:That option would inspect protocol-specific packet traces and socket details, run both ICMP and application-layer reachability tests, and check filtering rules, but it addresses a different concern. A resolver's search suffixes, per-link DNS choices and stub or split-DNS behavior can alter queries independently of the authoritative zone contents.
D:This shortcut is unsafe for the present Linux issue: Assume /etc/resolv.conf is always a manually maintained static file and that a short hostname cannot be affected by DNS search suffixes. It cannot establish a safe correction. Scenario: A laptop's resolv.conf file points to a local stub resolver, but support replaces the stub with a hardcoded address without checking systemd-resolved. Linux principle: A resolver's search suffixes, per-link DNS choices and stub or split-DNS behavior can alter queries independently of the authoritative zone contents. Appropriate response: Review NSS ordering, DNS search domains and active systemd-resolved or NetworkManager resolver integration before changing client resolution. Root-cause evidence: Inspect `resolvectl status` if used, /etc/resolv.conf target, search directives and queries for short names versus fully qualified names. Independent acceptance: Approved short and absolute names resolve to intended addresses on the correct link without breaking VPN split DNS.
Question 589
On a production Linux workstation or server, a technician observes: A laptop's resolv.conf file points to a local stub resolver, but support replaces the stub with a hardcoded address without checking systemd-resolved. Which observed outcome BEST confirms a successful and properly scoped correction? Select ONE best answer.
- The host reports the approved name consistently and local resolution returns the correct intended addresses.
- Local IPv6 neighbors communicate on the correct interface and routed destinations use a valid global or otherwise routed address with appropriate route.
- Approved short and absolute names resolve to intended addresses on the correct link without breaking VPN split DNS.
- Assume /etc/resolv.conf is always a manually maintained static file and that a short hostname cannot be affected by DNS search suffixes.
Explanation
Correct Answer
C:Observable acceptance criterion: Approved short and absolute names resolve to intended addresses on the correct link without breaking VPN split DNS. Scenario: A laptop's resolv.conf file points to a local stub resolver, but support replaces the stub with a hardcoded address without checking systemd-resolved.
Incorrect Answers
A:This alternative addresses Hostnamectl and durable host identification, not the specific issue of Resolver precedence, search domains and systemd-resolved: The host reports the approved name consistently and local resolution returns the correct intended addresses.
B:This alternative addresses IPv6 addressing link-local scope and prefix rules, not the specific issue of Resolver precedence, search domains and systemd-resolved: Local IPv6 neighbors communicate on the correct interface and routed destinations use a valid global or otherwise routed address with appropriate route. Scenario: A laptop's resolv.conf file points to a local stub resolver, but support replaces the stub with a hardcoded address without checking systemd-resolved. Linux principle: A resolver's search suffixes, per-link DNS choices and stub or split-DNS behavior can alter queries independently of the authoritative zone contents. Appropriate response: Review NSS ordering, DNS search domains and active systemd-resolved or NetworkManager resolver integration before changing client resolution. Root-cause evidence: Inspect `resolvectl status` if used, /etc/resolv.conf target, search directives and queries for short names versus fully qualified names. Independent acceptance: Approved short and absolute names resolve to intended addresses on the correct link without breaking VPN split DNS.
D:This shortcut is unsafe for the present Linux issue: Assume /etc/resolv.conf is always a manually maintained static file and that a short hostname cannot be affected by DNS search suffixes. A resolver's search suffixes, per-link DNS choices and stub or split-DNS behavior can alter queries independently of the authoritative zone contents.
Question 590
During an LPIC-1 practice lab, the operator encounters this condition: A laptop's resolv.conf file points to a local stub resolver, but support replaces the stub with a hardcoded address without checking systemd-resolved. Which TWO complementary steps provide the best corrective action and its most direct diagnostic verification? Select TWO answers.
- Inspect `resolvectl status` if used, /etc/resolv.conf target, search directives and queries for short names versus fully qualified names.
- Inspect `systemctl` service state, NetworkManager device management, /etc/systemd/network and active connection profiles alongside `ip` state.
- Inspect `ip route` and selected `ip route get`, then set or repair the appropriate default route in the active manager or with `ip route` for a controlled temporary change.
- Assume /etc/resolv.conf is always a manually maintained static file and that a short hostname cannot be affected by DNS search suffixes.
- Review NSS ordering, DNS search domains and active systemd-resolved or NetworkManager resolver integration before changing client resolution.
Explanation
Correct Answers
A:Most direct verification evidence: Inspect `resolvectl status` if used, /etc/resolv.conf target, search directives and queries for short names versus fully qualified names. Scenario: A laptop's resolv.conf file points to a local stub resolver, but support replaces the stub with a hardcoded address without checking systemd-resolved. Linux principle: A resolver's search suffixes, per-link DNS choices and stub or split-DNS behavior can alter queries independently of the authoritative zone contents.
E:Recommended administrative action: Review NSS ordering, DNS search domains and active systemd-resolved or NetworkManager resolver integration before changing client resolution. Scenario: A laptop's resolv.conf file points to a local stub resolver, but support replaces the stub with a hardcoded address without checking systemd-resolved. Linux principle: A resolver's search suffixes, per-link DNS choices and stub or split-DNS behavior can alter queries independently of the authoritative zone contents.
Incorrect Answers
B:This alternative addresses NetworkManager and systemd-networkd configuration ownership, not the specific issue of Resolver precedence, search domains and systemd-resolved: Inspect `systemctl` service state, NetworkManager device management, /etc/systemd/network and active connection profiles alongside `ip` state.
C:This alternative addresses Linux routing tables and default gateway selection, not the specific issue of Resolver precedence, search domains and systemd-resolved: Inspect `ip route` and selected `ip route get`, then set or repair the appropriate default route in the active manager or with `ip route` for a controlled temporary change. Scenario: A laptop's resolv.conf file points to a local stub resolver, but support replaces the stub with a hardcoded address without checking systemd-resolved. Linux principle: A resolver's search suffixes, per-link DNS choices and stub or split-DNS behavior can alter queries independently of the authoritative zone contents. Appropriate response: Review NSS ordering, DNS search domains and active systemd-resolved or NetworkManager resolver integration before changing client resolution. Root-cause evidence: Inspect `resolvectl status` if used, /etc/resolv.conf target, search directives and queries for short names versus fully qualified names. Independent acceptance: Approved short and absolute names resolve to intended addresses on the correct link without breaking VPN split DNS.
D:This shortcut is unsafe for the present Linux issue: Assume /etc/resolv.conf is always a manually maintained static file and that a short hostname cannot be affected by DNS search suffixes. Scenario: A laptop's resolv.conf file points to a local stub resolver, but support replaces the stub with a hardcoded address without checking systemd-resolved. A resolver's search suffixes, per-link DNS choices and stub or split-DNS behavior can alter queries independently of the authoritative zone contents.
