kameshpatil55

New Member
Joined
Jun 13, 2025
Messages
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...
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
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.
 

Back
Top