DNS Architecture • AdGuard Home • Resilience • Proxmox

Split DNS Architecture and DNS Resilience Redesign

I redesigned DNS in my homelab after repeated failures exposed a dependency problem: systems needed stable name resolution to recover, but parts of the environment were too dependent on the same internal DNS layer that was failing. I responded by separating DNS policy by device role and moving AdGuard Home onto its own Proxmox node to reduce shared-service risk and improve resilience.

AdGuard Home Split DNS Resilience Proxmox Dependency Mapping

Environment

Proxmox-hosted homelab

The environment runs on Proxmox with services separated by role, allowing infrastructure decisions to be tied to function and trust level rather than convenience alone.

AdGuard Home

AdGuard Home provides internal DNS and local rewrites for internal service access, making it an important dependency for normal day-to-day operation.

Separate Management, Services, and Client Roles

DNS behavior is assigned by role: management uses public DNS, services use AdGuard Home with public fallback, and other devices use AdGuard Home only.

DNS had previously been colocated with other services

DNS was moved multiple times after failures exposed architectural weaknesses. It was eventually placed on its own node instead of being bundled with unrelated services.

Problem

My DNS design changed multiple times because failures in the environment kept exposing weak spots. I initially tried to improve resilience, but some of those changes added complexity without truly reducing dependency risk. DNS was also sharing space with other services, which increased the chance that one problem could affect multiple functions at once. The core issue was that recovery paths were not independent enough from the DNS service they depended on.

Why This Matters

  • If core infrastructure depends on broken internal DNS, recovery becomes slower and more confusing.
  • DNS should support recovery, not block it.
  • Infrastructure devices need a more independent resolution path than normal clients.

Approach

I split DNS behavior by role instead of using one policy for everything. Management systems were assigned public DNS so they would keep an independent recovery path. Service systems were configured to use AdGuard Home with public DNS backup so they could still use internal resolution while retaining a fallback option. Other systems used AdGuard only, keeping client behavior centralized and consistent. I then moved DNS onto its own Proxmox node so it was no longer bundled with unrelated services.

Implementation

  • Defined DNS policy by device role instead of using one resolver pattern for everything.
  • Assigned management systems to public DNS so recovery would not depend on the internal resolver layer.
  • Configured service systems to use AdGuard Home with public DNS backup.
  • Kept clients and other non-core systems on AdGuard Home only for centralized filtering and internal resolution.
  • Moved DNS onto its own dedicated Proxmox node after repeated failures showed that colocating it with unrelated services increased risk.

Validation

  • Verified management systems could still resolve names without relying entirely on AdGuard.
  • Verified service-side resolution still worked with internal DNS and had fallback protection.
  • Verified clients continued using AdGuard as intended.
  • Tested after migration to ensure DNS worked cleanly from its new dedicated node.

Outcome

The final design gave the environment a cleaner separation of responsibilities and reduced the risk of circular dependency during failures. DNS became easier to reason about, troubleshooting became more direct, and the service was placed in a role better aligned with how critical it is to the rest of the environment.

Key Lesson

  • Trying to add resilience without first mapping dependencies can make systems more fragile.
  • Isolating core services can be more valuable than layering on more complexity.

What I'd Improve Next

  • Add documented failover testing.
  • Maintain a DNS dependency map.
  • Add a secondary internal resolver for true redundancy.
  • Document exact client and infrastructure DNS policy as a source of truth.
← Back to Projects