During setup the engineer configures a single DNS server — the site's primary domain controller. Weeks later that DC goes offline for patching and the appliance can no longer resolve names for mail or time services. Which basic name-service hygiene was skipped?

Basic name-service configuration is redundancy and completeness: a primary resolver, a secondary resolver that does not share the primary's failure domain, and the site's search domain so short names resolve consistently across the estate. An infrastructure device that depends on names for mail relay lookup, time servers, and updates inherits every single point of failure left in the DNS path — a planned DC maintenance window taking the sole resolver down is exactly the foreseeable scenario. Aggressive caching fails by mechanism: cached entries expire and must eventually be refreshed from an authoritative server, so a sole-server design fails on the same day the server does, a few lookup lifetimes later. Public resolvers as primary invert the security model — internal names for internal infrastructure exist only in internal zones, and internet resolvers cannot see a mail relay's private records, let alone be trusted for them. Replacing all names with numeric addresses is an anti-pattern disguised as a workaround: certificates, logs, and application configs assume stable names, and the review process flagged by the deployment depends on resolution working rather than being deleted. Exam caveat: verify the secondary genuinely answers by testing with the primary disabled in a maintenance window. Operational check: configure both resolvers and the search domain, perform a test lookup, and record which servers the appliance points at in the deployment record.