PVE Domain Controller Promotion Failure Caused by iStoreOS IPv6 DNS

While promoting a second Windows Server domain controller in PVE, DC2 had its IPv4 DNS statically pointed at DC1, yet the AD DS wizard still could not contact the domain. Direct queries to DC1 returned the expected SRV records.

The router was advertising its own global IPv6 address as DNS through DHCPv6 and RA/RDNSS. Windows queried that server first; the router knew nothing about the private AD zone and returned a valid NXDOMAIN response.

All addresses, domain names, and device identifiers below are generalized.

The decisive comparison

ISP IPv6-PD
      ↓
iStoreOS / OpenWrt (DHCPv4, DHCPv6, RA/RDNSS)
      ↓
PVE
 ├─ DC1: existing domain controller and AD DNS
 └─ DC2: server being promoted

The default query used the router's IPv6 DNS:

nslookup ad.example.internal

Server:  UnKnown
Address: 2001:db8:100::1

*** UnKnown can't find ad.example.internal: Non-existent domain

Querying DC1 explicitly worked:

Resolve-DnsName _ldap._tcp.dc._msdcs.ad.example.internal \
  -Type SRV -Server 192.168.100.11

That proves the AD zone and Netlogon records are healthy. The failure is DNS-server selection on DC2.

Trace the IPv6 DNS advertisement

Inspect both address families on Windows:

Get-DnsClientServerAddress -InterfaceAlias "Ethernet"
ipconfig /all

Then inspect the LAN interface and DHCP configuration on the router:

ip -6 addr show dev br-lan
uci show dhcp.lan

With RA and DHCPv6 server mode enabled and no explicit DNS override, odhcpd may advertise the LAN interface's own IPv6 address. Public upstream DNS cannot resolve a private AD zone, so NXDOMAIN is expected.

NXDOMAIN is a valid negative answer, not a timeout. It should not be treated as “this resolver is down.” Server: UnKnown only indicates the absence of a PTR record and is not the root cause.

Why a Windows-only change did not hold

Set-DnsClientServerAddress \
  -InterfaceAlias "Ethernet" \
  -ServerAddresses @("192.168.100.11")

This does not stop future RA/RDNSS advertisements. Removing the dynamic IPv6 address on each client treats the symptom; the router continues to publish it.

Minimal router change

Every client in this lab retained IPv4 and could query AAAA records through IPv4 DNS. The chosen fix stopped advertising the router as IPv6 DNS while retaining IPv6 addressing, SLAAC, DHCPv6, RA, and the default route.

cp /etc/config/dhcp /tmp/dhcp.before-ipv6-dns-change
uci changes dhcp
/etc/init.d/odhcpd status
uci export dhcp >/dev/null || exit 10

uci set dhcp.lan.dns_service='0'
uci set dhcp.lan.ra_dns='0'
uci changes dhcp
uci export dhcp >/dev/null || exit 10
uci commit dhcp
/etc/init.d/odhcpd restart

Some compact iStoreOS builds do not implement uci validate; uci export ... >/dev/null provides a basic parse check.

Validate that IPv6 remained healthy:

/etc/init.d/odhcpd status
ip -6 addr show dev br-lan
ip -6 route show default
nslookup -type=AAAA ipv6.google.com 127.0.0.1
logread -e odhcpd | tail -30

Refresh Windows and verify AD discovery

DC2 was not yet serving production, so a reboot cleared the DHCPv6 lease and RDNSS lifetime:

Restart-Computer

After reboot:

Get-DnsClientServerAddress -InterfaceAlias "Ethernet"
Resolve-DnsName _ldap._tcp.dc._msdcs.ad.example.internal -Type SRV
nltest /dsgetdc:ad.example.internal

Avoid rebooting the only existing domain controller merely to clear DNS state. Try a lease renewal and cache clear first, then schedule maintenance after DC2 promotion and replication validation.

ipconfig /release6 "Ethernet"
ipconfig /renew6 "Ethernet"
Clear-DnsClientCache

IPv4 DNS can still return IPv6 destinations

Stopping an IPv6 DNS advertisement does not disable IPv6. A client can send a DNS query over IPv4, receive an AAAA record, and connect to the destination over IPv6.

The exception is a truly IPv6-only client that cannot reach any IPv4 resolver; such a network needs a separate design.

Rollback and long-term design

uci -q delete dhcp.lan.dns_service
uci -q delete dhcp.lan.ra_dns
uci commit dhcp
/etc/init.d/odhcpd restart

A cleaner long-term design gives both DCs stable ULA addresses and advertises those addresses as DNS to an AD VLAN. Domain members should use only AD DNS; public lookups should go through AD DNS forwarders rather than a public resolver configured as a backup.

Summary

The problem was not an AD/IPv6 incompatibility. It was an incorrect resolver advertised in a dual-stack network:

Router advertises itself as IPv6 DNS
            ↓
Windows asks it for the private AD zone
            ↓
Router returns NXDOMAIN
            ↓
DC2 cannot discover a domain controller

When static IPv4 DNS looks correct, inspect IPv6 DNS and trace RA/RDNSS to the device that actually supplied it.