📎 AI Summary:
The original poster describes managing multiple DNS zones, with internal and secondary zones for internal and secure FQDNs, respectively. While internal users can resolve primary zone FQDNs reliably, they experience intermittent issues with the secondary zone FQDNs, which resolve consistently when accessing via SSL VPN. The overall concern centers on resolving DNS inconsistencies within the internal network for secure, secondary zone FQDNs.

kameshpatil55

New Member
Joined
Jun 13, 2025
Messages
1
Thread Author #1
We have configured multiple DNS zones in our environment. The primary DNS zone contains all internal server and hostname records. Additionally, we have created a secondary DNS zone to manage secure application FQDNs, which are mapped to internal server IPs. For public access, corresponding secure FQDN records are also maintained in our GoDaddy DNS panel; however, public access is currently restricted for roaming users.

At present, internal network users can successfully resolve FQDNs defined in the primary zone. However, FQDNs from the secondary DNS zone, despite pointing to the same internal IPs, intermittently fail to load within the internal network. Interestingly, when users connect via SSL VPN from roaming or local network, the secure FQDNs load consistently without issues.

internal fqdn :- vm01.in.example.com (under primary default zone)
secured fqdn :- https://webportal.apps-example.com (new zone:-apps-example.com)
 

Last edited:
Solution
Ha! You’ve pretty much summed up the timeless corporate IT struggle in one sentence. DNS issues do have that mischievous habit of acting up just enough to cause mass finger-pointing—and VPN always seems to play the role of the “it works for me” get-out-of-jail card.
If your secondary DNS zone is acting shy, maybe it just needs some encouragement (or, you know, a properly configured zone transfer and firewall adjustment). Next step: a gentle reminder to the team that endless restarts are not a recognized troubleshooting method—though admittedly, it’s IT’s universal placebo.
If you’re seeing this issue persist only off-VPN, it’s time to check if your internal DNS servers are reachable, forwarding correctly, and the right records are...

WindowsForum AI

AI
Staff member
Robot
Joined
Mar 14, 2023
Messages
114,240
Ha! You’ve pretty much summed up the timeless corporate IT struggle in one sentence. DNS issues do have that mischievous habit of acting up just enough to cause mass finger-pointing—and VPN always seems to play the role of the “it works for me” get-out-of-jail card.
If your secondary DNS zone is acting shy, maybe it just needs some encouragement (or, you know, a properly configured zone transfer and firewall adjustment). Next step: a gentle reminder to the team that endless restarts are not a recognized troubleshooting method—though admittedly, it’s IT’s universal placebo.
If you’re seeing this issue persist only off-VPN, it’s time to check if your internal DNS servers are reachable, forwarding correctly, and the right records are replicated to both primary and secondary. And—just in case—verify your split-brain DNS setup (if you have one), conditional forwarders, and that those GPOs aren't sabotaging anyone behind the scenes.
If you’ve got logs, errors, or want a more technical diagnosis, toss those details here and we’ll dig in like IT detectives on a snack break.
 

Solution

anyname

Member
Joined
Nov 8, 2025
Messages
4
We have configured multiple DNS zones in our environment. The primary DNS zone contains all internal server and hostname records. Additionally, we have created a secondary DNS zone to manage secure application FQDNs, which are mapped to internal server IPs. For public access, corresponding secure FQDN records are also maintained in our GoDaddy DNS panel; however, public access is currently restricted for roaming users.

At present, internal network users can successfully resolve FQDNs defined in the primary zone. However, FQDNs from the secondary DNS zone, despite pointing to the same internal IPs, intermittently fail to load within the internal network. Interestingly, when users connect via SSL VPN from roaming or local network, the secure FQDNs load consistently without issues.

internal fqdn :- vm01.in.example.com (under primary default zone)
secured fqdn :- https://webportal.apps-example.com (new zone:-apps-example.com)
The issue is likely due to split DNS and zone configuration. Internal users intermittently fail to resolve apps-example.com because the secondary zone may not be properly delegated or replicated across internal DNS servers. VPN users work because the VPN DNS handles the secondary zone correctly. Check zone replication, forwarders, and DNS suffix settings for the secondary zone internally.