LPIC-2 202-450: DNS, Network Services, and Security

The 202-450 exam is the second required LPIC-2 examination from Linux Professional Institute, version 4.5. It assesses administration of network-facing services: DNS, web servers, file sharing, client management, mail systems and security. A candidate must also pass LPIC-2's 201-450 exam and hold an active LPIC-1 credential to receive the LPIC-2 certification. The published examination has 60 multiple-choice and fill-in-the-blank questions over 90 minutes. Its practical emphasis is a mixed Linux enterprise network where services depend on names, identities, storage permissions, routing and safe access. A competent administrator can distinguish a service outage from a misconfigured dependency and repair it without exposing users or data.

Run DNS services with appropriate authority

DNS translates names into resource records, but authoritative servers and recursive resolvers play different roles. An authoritative server answers for zones it controls; a recursive resolver follows or caches answers for clients. Some deployments combine functions, but the security and operational boundaries remain important. A public authoritative server should not automatically become an unrestricted recursive resolver. Learn how a BIND configuration defines zones, listens on interfaces and controls queries, transfers and logging. Review tools such as named-checkconf, named-checkzone, rndc, dig and host in the context of the official objectives.

A zone change can be syntactically valid but operationally wrong. An incorrect serial, missing delegation, stale caching interval or bad reverse mapping can cause different answers at different clients. Investigate the authoritative response first, then resolver behavior and the application's actual lookup. In a production incident, compare answers from the relevant name servers rather than flushing every cache without evidence. A BIND DNS server troubleshooting explanation deepens these distinctions. DNS administration is about consistency, security and change control, not just editing A records until a website appears to work.

Publish web services securely and predictably

Web server administration involves listening addresses, virtual hosts, routing to applications, TLS configuration, logs and resource limits. Apache HTTP Server and NGINX differ in configuration and operational behavior, but both require a clear mapping from hostname and request path to the intended content or upstream application. A reverse proxy can hide application details and centralize TLS termination, yet may also introduce a new availability or security dependency. Understand why an HTTPS certificate mismatch, an absent backend connection and a wrong virtual host can all produce user complaints of “website down” while requiring different fixes.

For a failed deployment, identify which layer still works. Confirm DNS resolution, TCP connectivity, TLS handshake and application response separately. A request reaching the web server but returning a gateway error often indicates upstream availability or configuration rather than DNS. Review log access restrictions and avoid writing sensitive request parameters into publicly readable files. Changes to virtual host ordering or default site behavior can unintentionally expose internal applications. A service is not securely deployed simply because it returns an HTTP 200 to one test request.

Manage file sharing across mixed operating systems

NFS and Samba provide ways to share files with different client populations. NFS deployments depend on export rules, identity mapping, filesystem permissions and protocol settings. Samba supports SMB interoperability with Windows environments and requires careful alignment among accounts, share definitions and underlying Unix permissions. A user allowed by a share-level setting may still be denied by filesystem ownership; changing the network share rule alone does not necessarily resolve the conflict. Understand why matching identities across systems matters to both access and auditability.

Suppose a finance share becomes writable by more staff after a directory integration change. Diagnose the effective SMB or NFS authorization along with group membership and filesystem ACLs. The proper remedy is to restore the intended least-privilege behavior, not to set world-writable permissions. Network access should also be limited to authorized client segments. File-sharing performance and reliability depend on storage health and permissions beyond the protocol service itself, linking LPIC-2 service administration to the infrastructure coverage of 201-450.

Design DHCP and centralized authentication thoughtfully

DHCP supplies client addressing and related options, while relay agents help clients reach servers across routed boundaries. An address pool with insufficient capacity or the wrong network parameters can make users appear disconnected even though their physical links are healthy. Investigate lease state, server scope, relay paths and option delivery before changing switch ports. IPv6 introduces its own address-configuration and router-advertisement considerations; do not assume every IPv4 mechanism has an identical counterpart.

Pluggable Authentication Modules (PAM) and services such as SSSD can integrate centralized identity into Linux authentication workflows. A configuration change that blocks logins may have wide operational impact, especially on systems without alternate recovery access. Differentiate authentication (verifying identity) from authorization (deciding permitted actions) and account lifecycle management. Test changes in a controlled session while maintaining an authorized recovery path. A system relying on directory services should have a documented policy for temporary directory outages that does not silently grant excessive privileges.

Operate mail and security services without becoming an open relay

Mail transport introduces DNS dependencies, message submission, queuing, filtering and delivery failure analysis. A server that accepts mail from a trusted application should not become an unrestricted relay for the internet. Understand SMTP routing roles, local aliases, logs and common causes of deferred or rejected messages. A healthy process can still have a growing queue if destination DNS, remote policy or TLS authentication fails. Inspect queue and rejection reasons before widening relay permissions, which can expose the host to abuse and reputation damage.

Security objectives include SSH, firewalls, VPNs, access restrictions and intrusion awareness appropriate to Linux server administration. Restrict management interfaces, keep services patched and review default configurations. A file server, web proxy and mail host have different exposure profiles and should not all inherit identical permissive firewall rules. Logging and time synchronization help correlate attacks, but logs may include personal or confidential information that requires controlled access. Security is an operational property maintained through review and monitoring, not a final checklist completed once at installation.

Troubleshoot a company-wide name-resolution failure

After a scheduled maintenance window, users cannot reach internal file shares or a customer portal, while direct IP connections to some servers still work. Start by determining whether the DNS authoritative data is wrong, the recursive resolver is unavailable or the clients are receiving an incorrect resolver through DHCP. Test a known record against the authoritative server and a client resolver separately. Check zone serials, service logs and firewall rules. If DNS was migrated, verify that delegation and resolver forwarding reflect the intended architecture and that caches will converge within expected TTL behavior.

The file share symptom may involve name resolution alone, while the portal might additionally have a reverse-proxy configuration error. Resolve those as separate causes instead of assuming one change repaired every problem. Capture before-and-after responses and record which clients were affected. If DHCP options must change, confirm that renewed leases distribute the right servers and consider how long existing clients may continue using old settings. This exercise integrates DNS, DHCP, web, file sharing and operational evidence—the real value of LPIC-2 service expertise.

Validate a secure DNS and web change across trust boundaries

Suppose a department migrates an internal documentation service to a new server. The new web instance passes a local health check, but some employees receive certificate warnings and others reach an old site. The deployment crosses at least three trust boundaries: authoritative DNS data, resolver caching and the HTTPS identity presented to clients. Investigate each separately. First query the relevant authoritative servers for the actual record and time-to-live values. Then compare a known internal recursive resolver and a client lookup. A stale or inconsistent answer can persist until caches expire, even after zone content is corrected.

Next inspect the requested hostname, server name indication and certificate subject names. A TLS failure may arise because a default virtual host receives the connection, a reverse proxy serves the wrong certificate, or a certificate chain is incomplete. Do not disable certificate validation to hide a configuration mistake. If the front end terminates TLS and forwards to another service, confirm how client identity, scheme and host information are passed and which headers the backend trusts. The system should never treat an arbitrary client-supplied header as an authoritative security assertion.

A migration can also change file-sharing paths, service accounts or access permissions. If document attachments reside on NFS or SMB, verify the underlying mount and ownership before relaxing web-server privileges. The application should access only the files it needs, and exposure of a public web endpoint must not create a bridge to every private share. Review logs for requested hosts and error patterns, while avoiding collection of confidential content beyond legitimate operational needs.

End with a measured cutover. Confirm name resolution and certificate behavior from representative clients, monitor old and new endpoints, and document the rollback if a critical dependent service fails. Check that expired records and certificates are retired safely, not left accessible indefinitely. This scenario joins DNS, web services, authentication, file sharing and service validation into an auditable LPIC-2 operation and illustrates why individual commands cannot replace systems-level reasoning.

Prepare by operating a small mixed network

Create a lab with a Linux DNS server, web server, SMB or NFS share, DHCP service and at least two clients. Introduce a broken zone, wrong share permission, exhausted DHCP pool and rejected outbound mail as independent faults. Use service logs and client evidence to distinguish them. Compare this service-focused exam with LPIC-2 201-450, which covers the kernel, storage and recovery dependencies behind these applications. Review the official LPI 4.5 blueprint before scheduling; a strong candidate can explain why each service works, how it fails and what verification proves a safe recovery.