LPIC-2 202-450: DNS, Web, File and Network Services

An infrastructure service can respond correctly to a local test and still fail its users. A DNS daemon may answer one query but not authorize a zone transfer appropriately; a web server may serve a default site but not the intended virtual host; and an NFS export may be reachable from an unintended network. These are configuration problems across service and trust boundaries, not necessarily faults in the underlying Linux kernel. LPIC-2 Exam 202 focuses on running the network-facing infrastructure that depends on those boundaries.

202-450 is the second LPIC-2 exam, covered by Linux Professional Institute's published version 4.5 objectives. Topics include Domain Name Server (207), HTTP Services (208), File Sharing (209), Network Client Management (210), E-Mail Services (211) and System Security (212). Passing both 201-450 and 202-450 is required for LPIC-2, and the holder must have an active LPIC-1 certification to receive the advanced credential. Exam 202 is service administration, not a retelling of Exam 201's kernel and storage topics.

Build DNS services that answer the right questions

DNS involves different roles: a recursive resolver obtains answers on behalf of clients, an authoritative server publishes answers for zones it serves, and a caching resolver can retain responses to reduce repeated lookups. A server may perform multiple functions, but mixing them without access controls can create operational and security problems. The BIND configuration used for an authoritative zone should reflect who can query, recurse, update records or request transfers. A successful answer to one local query says little about whether the service's access model is appropriate.

Zone data includes names, addresses, aliases and records for services, mail delivery and zone administration. TTL values affect how long caches may retain answers; changing a record at an authoritative server does not force every client to forget cached data immediately. A serial number in a traditional zone-transfer workflow helps secondaries recognize updates. Basic knowledge of DNSSEC adds the distinction between origin authentication of DNS data and confidentiality of queries: signing records does not automatically encrypt the client's request path.

When a domain appears unavailable, begin with evidence. Check which nameservers are authoritative, which resolver the client consulted, whether the requested record exists, whether the response is cached and whether the daemon has loaded its latest configuration. A syntax check can catch malformed zone data, but it cannot prove that delegation at a parent zone is correct. DNS and IP address-management fundamentals are directly useful when distinguishing an incorrect host record from an address-allocation failure.

Practise a small lab with an isolated authoritative zone and a separate client resolver. Change a record, verify the serial and observe cached responses before the TTL expires. Then intentionally misconfigure a record and use query tools and logs to identify the failing layer. Such a lab teaches delegation, caching and authoritative roles without exposing an open recursive resolver to the public internet.

Operate web servers with clear virtual-host and TLS boundaries

HTTP service configuration combines listener addresses, request routing, content roots, access rules and application integration. Apache and Nginx express these responsibilities with different configuration structures, but they face similar questions: which virtual host receives an incoming request, what process serves it, and who can read the underlying files? A request for the wrong hostname may be served by a default virtual host even when the desired site is configured correctly. The client-visible page alone may not identify the misconfiguration.

Access restrictions need to reflect application requirements and the origin of the request. Filesystem permissions can prevent the web-service user from reading content; HTTP access rules can deny clients independently; an upstream reverse proxy may terminate TLS and pass traffic internally. A fix at one layer does not necessarily resolve an error at another. When a site returns 403, 404 or 502, the candidate should decide whether the response comes from the web server, application or proxy before editing configuration.

TLS adds certificate identity, key protection and protocol-policy concerns. A certificate must match the hostname the client intends to reach, and the server must have a correctly configured certificate chain and private key. Enabling HTTPS without testing the actual virtual host may leave a default certificate served to some clients. A private key copied casually into a world-readable directory defeats much of the intended security. Review configuration with syntax tools and restart or reload only after verifying what the running daemon will accept.

Performance diagnosis also matters. Slow responses may come from a saturated process pool, connection backlog, slow upstream application or network path rather than missing CPU capacity. Watch error logs, request timing and process limits as a coherent set. An administrator should know when a successful service restart merely hides a resource leak that will recur under the next busy period.

Share files through Samba and NFS without losing ownership control

File sharing connects Linux permissions with network authentication and protocol-specific access rules. NFS commonly exports directories to eligible clients and maps identities according to server and client configuration. Samba offers SMB/CIFS interoperability used in mixed Windows and Linux environments. Neither system is simply a switch that makes a path universally readable. A writable network share needs a clear model of which users can create files, how ownership is represented and whether any guest access is permitted.

For NFS, the export path, allowed client networks, mount options and server-side permissions must agree. A client successfully mounting a share does not imply it can write the intended files. Root-squashing and identity mapping affect access, and differences between NFS versions influence authentication and firewall requirements. Where NFS is used for application storage, administrators must also understand how the workload handles interrupted connections and concurrent writes.

For Samba, share definitions, account databases and effective Unix permissions interact. A user can authenticate successfully but still be denied a file because the underlying filesystem blocks access. Conversely, broad filesystem permissions combined with permissive share settings can reveal more data than the administrator intended. Testing must include an allowed account, a denied account and both read and write operations. That provides stronger evidence than browsing the share from an administrator workstation and seeing its name.

File-sharing design should include backups, corruption recovery and auditing appropriate to the data. RAID or mirrored storage does not protect against deletion from an authenticated network client. A good lab creates two users with different group memberships and a small shared project directory, then demonstrates the precise results from Linux-local and network-client perspectives.

Provide dependable DHCP and directory-backed services

DHCP automates address configuration through leases and options. An administrator may assign dynamic pools, reservations and network-specific settings such as router and DNS information. A client that receives an IP address but the wrong DNS resolver will appear to have partial connectivity. The server's available address range, subnet boundaries and relay configuration also affect which clients can obtain valid leases. IPv6 networks introduce additional mechanisms, including Router Advertisements and DHCPv6, that should not be collapsed into the IPv4 model.

Relays forward selected client requests between network segments, while the DHCP service determines eligibility and options. A missing or misconfigured relay may prevent clients on one VLAN from receiving a lease even though clients on the server's local network work correctly. A candidate should capture the client's address, gateway and DNS values rather than assuming a successful lease proves every field is appropriate. DHCP behavior in enterprise networks provides supporting context for interpreting this failure.

Central directory technologies such as LDAP store structured identity and organization information that other services can query. Entries, attributes, distinguished names and directory access controls are different from local /etc/passwd accounts, although integration tools can connect them. An authenticated query should see only what its permissions permit. Directory transport security, replication and backup requirements matter when the service becomes part of an organization's login infrastructure.

In practice, directory-backed authentication and network addressing share a systems principle: a configuration change is not complete until representative clients can use it. Test both a typical and an intentionally unauthorized query or login, confirm results in logs, and record the expected failure mode. Security controls are credible when they reject the wrong action as reliably as they permit the right one.

Understand mail delivery and mailbox access as separate services

Email infrastructure divides message submission, transport, final delivery and retrieval. An MTA such as Postfix can accept or relay messages according to its configuration, while an IMAP/POP service such as Dovecot lets users retrieve or access stored mail. These roles are not interchangeable. A successful SMTP acceptance response may mean only that the next hop has queued the message, not that an end user has opened it or even that final delivery succeeded.

DNS MX records identify receiving mail exchangers for a domain, but correct MX records alone do not ensure safe transport. Server identity, TLS settings, relay rules, spam controls, queue health and mailbox storage constraints all influence delivery. An open relay is a serious misconfiguration because outsiders may abuse the server to send mail without authorization. An overly restrictive server, however, may reject legitimate internal applications that need to submit notifications. Rules should be tested with explicit client identities and domains.

Mailbox access has its own authentication and privacy concerns. Dovecot's configuration controls protocols, login methods and storage access; TLS protects transport where correctly configured. Users seeing an empty mailbox may be connecting to a different account or storage path even if the mail transport is working. Logs should be interpreted by component: the MTA knows about queueing and routing, while the retrieval service knows about authenticated mailbox sessions.

A useful diagnostic exercise sends one message through an isolated local system, records its queue identifier, watches transport events and then verifies mailbox access. Compare this with a deliberately invalid recipient and a rejected relay attempt. The goal is to demonstrate the boundaries at which evidence exists rather than equating “command returned zero” with successful end-to-end delivery.

Secure the services and connect them to a recovery plan

Service security includes SSH configuration, authentication controls, packet filtering, VPN awareness and the operational protection of credentials. SSH key files illustrate why protecting a private credential is different from enabling encrypted network transport. Opening a firewall port does not make the underlying daemon safe; a secure daemon can still be unreachable because of a mistaken route or filtering rule. Audit the listening interfaces with ss, test firewall decisions, and review which accounts can administer the service. Remote changes should preserve an out-of-band recovery method to prevent accidental lockout.

Linux host security also relies on update management, logging and correct separation of duties. Public-facing web applications, internal DNS and file-sharing services have different exposure models and should not inherit identical access rules for convenience. Backups must cover configuration, data and relevant secrets while keeping restore credentials protected. A restore test must show that DNS zones, shared directories or mail queues are recoverable to an acceptable state, not merely that a compressed archive exists somewhere.

The strongest Exam 202 exercise follows a client transaction across several systems: a workstation receives DHCP options, resolves a DNS name, opens a TLS web connection and authenticates to a file or mail service. If it fails, the administrator must determine which layer owns the problem rather than rebuilding the whole host. The LPIC-2 201-450 exam tests the kernel, storage and local network foundations on which these services run; 202-450 tests whether the same operator can deliver and protect actual multi-host services. Together they define advanced, distribution-neutral Linux administration.