Can a Home Router Resolve Split DNS for Both IPv4 and IPv6?

Eva Wong is the Technical Writer and resident tinkerer at ZimaSpace. A lifelong geek with a passion for homelabs and open-source software, she specializes in translating complex technical concepts into accessible, hands-on guides. Eva believes that self-hosting should be fun, not intimidating. Through her tutorials, she empowers the community to demystify hardware setups, from building their first NAS to mastering Docker containers.

Yes if the router or delegated resolver serves the intended A and AAAA answers to the correct client networks and clients actually use that resolver for both families.

This becomes a real compatibility question when internal hostnames must resolve to private IPv4 and IPv6 addresses while public clients receive public answers. Start with a disposable path or account, keep the previous working state available, and judge the design by the original workload rather than by a one-time connection test.

Separate the Supported Architecture From the Risky One

The supported branch is client-specific A and AAAA answers from one authoritative policy. The competing branch is IPv6 clients bypassing the local resolver or receiving an unreachable global or ULA address. Record versions, identities, addresses, mount paths, permissions, and the current observable state before changing either branch.

The relevant split DNS views defines the first compatibility boundary. Use it to constrain the claim, then verify the same behavior on this exact home server instead of treating a documented feature as proof that the full design works.

Write the decision rule before testing: success must produce each network receives the intended address family and reaches the same certificate-bearing service without public hairpinning; failure includes AAAA leaks a public or stale address, clients use encrypted external DNS, or IPv6 routing and firewall policy do not match the answer. This prevents a partial connection or clean command exit from being misread as end-to-end compatibility.

Reproduce the Exact Storage and Network Path

Use one controlled discriminator: query A and AAAA from each VLAN, inspect the resolver actually used, then connect over both families with public fallback disabled during the test. Hold the client, workload, file set, account, and timing constant so the changed component is the only plausible explanation.

Use dnsmasq address rules to choose the second observation that matters for this path. Capture both sides of the transaction: resolver or route, negotiated protocol, process identity, exit status, latency, transferred bytes, and any recovery event.

Repeat the test after the lifecycle event named in the title—recreation, reconnect, remount, restart, failover, or client change. A design that works only while old sockets, caches, or credentials remain warm has not passed.

dig A app.home @router
dig AAAA app.home @router
curl -4 https://app.home
curl -6 https://app.home

Interpret Durability, Timeout, and Recovery Results

PASS: each network receives the intended address family and reaches the same certificate-bearing service without public hairpinning. Save the exact versions and topology that produced this state, because the conclusion applies to those conditions rather than every implementation of the protocol.

FAIL: AAAA leaks a public or stale address, clients use encrypted external DNS, or IPv6 routing and firewall policy do not match the answer. Check shared dependencies such as DNS, MTU, identity, firewall state, storage latency, and cached sessions before declaring either primary branch responsible.

EXCEPTION: remove the incorrect AAAA override, restore a reachable answer set, and fix resolver advertisement plus IPv6 routing before re-enabling it. Do not widen privileges, delete source data, weaken transport security, or replace working storage until a repeatable observation identifies which boundary failed.

-15% OFF
Single board computer zimaboard2

Keep the Design Only After a Restore-Grade Check

Apply only the action matched to the observed branch, then rerun the original workload. Keep the design only when each network receives the intended address family and reaches the same certificate-bearing service without public hairpinning across two relevant lifecycle cycles and under the expected concurrent load.

Use the split-horizon DNS to verify the closest dependent workflow. Its access, timing, and recovery behavior must remain unchanged while the new design is active.

Stop and return to the saved state if AAAA leaks a public or stale address, clients use encrypted external DNS, or IPv6 routing and firewall policy do not match the answer. Escalate with timestamps, exact versions, route or mount evidence, and the smallest reproduction rather than adding another workaround.

Cross-check the result against the IPv6 firewall rules so risk is not merely moved into another network, identity, backup, or storage layer.

For dual-stack split DNS, the qualified answer is therefore the opening judgment—not an unconditional yes. The observable pass state is the acceptance line; the fail state is the rollback line.

FAQ

Can an A record work while AAAA breaks the app?

Yes. Many clients prefer IPv6, so a bad AAAA path can fail before IPv4 is tried.

Will browser secure DNS ignore the router?

It can. Confirm the client's effective resolver and define policy for encrypted DNS on managed devices.

Should internal IPv6 use ULA or global addresses?

Either can work when routing, DNS, firewall, and certificate names are consistent; test the actual client path.

Support & Tips

More to Read

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.