LFCS Networking Practice Question
A Linux server uses systemd-resolved for DNS resolution. Users report that queries for internal hostnames such as 'db.corp.example.com' are failing, while external names resolve correctly. The administrator runs 'resolvectl status' and sees that the interface eth0 has DNS servers 10.0.0.53 and 'DNS Domain: corp.example.com'. Which command should be used to query the internal DNS server directly and verify that it responds to the name?
⚠ Common exam trap
The trap here is using resolvectl query, which goes through systemd-resolved and may reproduce the same failure, instead of querying the DNS server directly to isolate the issue.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
dig @10.0.0.53 db.corp.example.com
To verify that the internal DNS server at 10.0.0.53 can resolve the hostname, the administrator should query it directly with 'dig @10.0.0.53 db.corp.example.com'. This bypasses systemd-resolved and tests the server's response. If the server answers correctly, the problem lies in systemd-resolved's configuration, such as a missing routing domain or incorrect DNS server assignment for the interface.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
resolvectl query db.corp.example.com
Why it's wrong here
resolvectl query uses the systemd-resolved service to resolve the name, which may still fail if the routing domain or DNS server configuration is incorrect. It does not bypass systemd-resolved to query the internal server directly. To verify the server itself, you need a tool that sends the query straight to 10.0.0.53, such as dig or host.
- ✓
dig @10.0.0.53 db.corp.example.com
Why this is correct
This command sends a DNS query directly to the internal DNS server at 10.0.0.53, bypassing systemd-resolved. It verifies whether that specific server can resolve the hostname, isolating the problem to either the server or the local resolver configuration. If the server responds correctly, the issue is likely with systemd-resolved's routing or caching; if it fails, the DNS server itself is the problem.
- ✗
nslookup db.corp.example.com 10.0.0.53
Why it's wrong here
nslookup can query a specific server, but it is deprecated in many distributions and may not be installed by default. The question asks for a command to verify the server's response; while nslookup would work if available, dig is the modern standard and more likely to be present. However, nslookup is not the best answer because it is not guaranteed to be installed and provides less detailed output.
- ✗
systemd-resolve --status
Why it's wrong here
This command displays the current DNS configuration and status, including the servers and domains, but it does not perform a query. It shows what systemd-resolved knows, not whether the internal DNS server can resolve a specific name. To test resolution, you must send an actual query, such as with dig or resolvectl query.
Visual reference
Go deeper
Related to this question
About these practice questions
Courseiva writes every LFCS question from scratch — 406 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Linux Foundation exam blueprint
This LFCS practice question is part of Courseiva's free Linux Foundation certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the LFCS exam.