AD Domain lookup is not working without VPN from SITE office

VPNs allow remote offices to connect in a secure way. A VPN creates an encrypted data tunnel inside which data exchange between remote offices is performed, given the correct routing info (i.e. route traffic to remote office network through the VPN interface.
So yes, if the above is  your case and the VPN goes down there won't be no connectivity between VPN connected offices.

So is your question: Why are the Read Only Domain controllers on each branch site (including DFS & DNS services ) isn't providing these services?

Assuming I've interpreted your query correctly, it's a big question with a variety of possible solutions.

Without further info I recommend starting with some basics as below:

Check DNS servers on your clients. If they are not using the local DNS servers for DNS lookups it wont work.
Perform NSLOOKUP <domainname> (in  CMD window) to see what Domain controllers are listed as available.
Try typing one of the branch servers into 'run' to see what is shown. if netlogon/sysvol aren't there they are not functioning Domain Controllers.
Recheck your assignment of subnets to Active Directory Sites. branch subnets may be incorrectly looking for a domain controller in the wrong site.

when you said VPN is disconnected means?
If you have site to site VPN tunnel created , it should not be turned off intermittently, its one time task and may get down when internet goes down or your VPN device goes down.
If on client PC, it should get seamless connectivity and even don't need to know that he is connected through VPN tunnel

OR

may be you are talking with point to site VPN connectivity and you are offsite location from internet you are connecting to network over VPN and in that case you can access AD and network resources, if you close point to site VPN connection but obvious you will get disconnected

Can you recheck what exactly your issue and question please?

Sounds like either your clients are using the main office DNS servers as their primaries or your RODC either did not enroll properly in the ForestDNSZones or DomainDNSZones partitions or perhaps, you have a forwarder set in your RODC DNS server.

I think Jeff is on the spot, I misunderstood the question as I thought the OP was pinging a remote DC. Just one thing, a forwarder won't break DNS functionality od the domain as the forwarder will be used for DNS resolution when the DNS server has no knowledge of the name requested. Windows DNS server uses root hints by default.

@OP

Can you comment please

Everybody is puzzled

Hi everyone,
Thanks for the reply

As Jeff said I think the problem is with DNS server. I will add some more information below about DNS to help you understand about current setup

•      At site office all devises are using RODC as primary DNS and main office DC as secondary DNS.
•      Primary DNS of RODC is loopback IP (127.0.0.1) and secondary DNS is main office DC.
•       In RODC (also DNS server) all forwarders are public DNS (8.8.8.8 etc.)
•      When I do NSLOOKUP (nslookup dubai.XXXX.local) I am getting three IP address, all of them are IP addresses of main office DC.
•      We have only one domain which is dubai.XXXX.local, sites offices doesn’t have separate child domain

So,
Your issue is when vpn is down, u r not able to access local resources?

Is that correct?

People here finding hard times to correlate question description and issue as you don't write exact issue

Can you check one thing?
When vpn is down, can your users are able to logon domain?
May be you can logoff and logon again?

If you failed to logon quickly or logged on after much time (cached logon), it means you have not added users to allowed password replication policy, in that case users won't be able to login when vpn is down
By default rodc don't authenticate users on its own and forward requests to r/w dc unless you add users to password replication policy

- Primary DNS of RODC is loopback IP (127.0.0.1) and secondary DNS is main office DC.-
Uh, not a good idea. the DNS settings in a Servers NIC control 2 things. Where the server registers its IP address and What the server itself uses as a DNS server. If it is looking at itself first, (the loopback. Never a good idea in my experience) it will try to register its IP there but.... an RODC is read only. And since it finds the zone there, it will not register itself. Make the Main office the primary, the RODC secondary and the reregister the NICS (IPconfig /registerdns). Wait for replication and see if the issue persists. For forwarders, others may disagree but I never setup Forwarders. At least have not since 2003. The way it works with Microsoft DNS can be a little wonky. If you have root hints and a local DNS, it should work fine. But, as I said, this is my way of doing things. Others may have different experiences, just a valid.
  To explain what is happening, your clients are looking at your RODC for DNS. It sees the domain and gets the NS records which probably as of now, point to the main office. So, if the VPN is up, no problem. However, with the VPN down, they cannot connect to the main office so having a local copy, without NS records and the matching A records for the local server (do not know which is missing without seeing your zone file, it cannot resolve any hosts in that domain.
  Secondary DNS addresses in your workstations only work when your primary servers DNS service is down. If the client gets a response from the service at all, even if it is just a non-answer, it will not try anymore.

To clarify on forwarders, I do use them in certain situations with DNS resolver only servers (no hosted zones) and I do use conditional forwarders in many places.

Secondary DNS addresses in your workstations only work when your primary servers DNS service is down.

Sorry @Jeff but that's not true. it's well know that Windows will use both DNS servers in a fairly random way. they are not primary/secondary.

@John
please run (in a CMD window):  nslookup - <RODC's IP> and post the response.
this will confirm if the RODC is serving DNS at all or not, which is the first step.

If it fails then the RODC's DNS isnt working. checking event viewer to identify why would be my recommended next step.

if it works, try typing the hostname of the RODC to see if it resolves to the right IP. also try typing the domain to see if that resolves correctly or not.

This should give us enough info to move forward.

Sorry @Jeff but that's not true. it's well know that Windows will use both DNS servers in a fairly random way. they are not primary/secondary.

This is true only if alternate DNS server is public DNS server

If both server are internal DNS, client won't send query to alternate DNS server unless primary is down, this is by design
For example, check sites where only single DNs onsite and they point to 2nd DNS to another HO site DC server, purpose is if primary server goes down, client should resolve queries through 2nd DNS server, queries don't get directly to alternate DNS server, in that case it will defeat purpose of alternate DNS server

Steve, I stand behind my statement. It comes from 18+ years of dealing with Windows DNS. I am applying it only to Johns stated setup and if you have seen Windows use Random lookups with internal DNS servers, you have seen something I have never seen. It will always use the primary unless it cannot contact that machine, then will use Secondary servers.
  There are a lot of things you can do to modify behavior of a DNS server such as forcing iterative or recursive lookups and using conditional forwarders but in my experience, if you set a primary DNS server and it can contact it, it will not use the secondary server.
  My answer to him was more to point out that if the A record for the RODC was not registered or an NS record did not exist, it would cause his issue.

try to register its IP there but.... an RODC is read only

It simply forwards it to a writable DC

Secondary DNS addresses in your workstations only work when your primary servers DNS service is down.

Correct. Easy to prove

This is true only if alternate DNS server is public DNS server

No, the local endpoint has no concept of public/internal

Sorry @Jeff but that's not true. it's well know that Windows will use both DNS servers in a fairly random way. they are not primary/secondary.

No, it is not. Easy to prove. Please provide references