pfSense split-DNS overrides and TLS certificate validation limits

pfSense DNS Resolver and Forwarder support host overrides that answer local queries before upstream resolution. When an override maps a public hostname to a private address, TLS clients still validate the certificate against the requested hostname. This creates a boundary between DNS identity and certificate trust: a public certificate may fail with a name mismatch if the override points to a different or deeper label, while a private certificate may fail if the client does not trust the issuing CA. DNSSEC validation in DNS Resolver can return SERVFAIL for broken zones, preventing the TLS handshake from starting.

The unresolved decision is whether to preserve split-horizon DNS and align certificates with overridden names, or to adjust per-service trust stores so local clients accept the presented chain. No single documented pfSense capability automatically reconciles DNS overrides with certificate validation across all services, and the consumer of a certificate—whether the web GUI, a package, or an external client—determines which trust anchors apply.

Because resolver mode, DNSSEC settings, and certificate assignments vary by pfSense version, what is the most reliable way to determine whether a TLS failure originates from split-DNS interception, DNSSEC resolution failure, or a genuine certificate name or chain mismatch? Should administrators prioritize matching certificate SAN entries to overridden hostnames, or is adjusting per-service trust more maintainable when DNS overrides are required?