DNS Swap

AnotherUser

Limp Gawd
Joined
Oct 7, 2011
Messages
137
We currently have sub shops that use a combination of Cisco routers & ASA's to VPN back to our main location. These devices do DHCP & DNS with DNS primary being our main DNS server (inside 10.x.x.x) and the secondary being an outside DNS (ISP, Google etc).

The problem we run into is if the VPN drops, Windows cannot talk to the primary DNS so it swaps to the secondary. Once the VPN is back up, computers still cannot communicate to our 10.x.x.x network since Windows is just happy as a fat cat with cheese to use the secondary DNS.

Question is, how can we tell windows to swap back to the primary without a reboot or adapter disable/enable? Anyone know any batch file commands that would do this?
 
i'd be figuring out why your VPN is going down so much.... no real reason to have VPN go down and internet DNS servers still work....

also, are you sure it's DNS? you say it can't communicate with your 10.x.x.x subnet... is that only by name?
 
i'd be figuring out why your VPN is going down so much.... no real reason to have VPN go down and internet DNS servers still work....

also, are you sure it's DNS? you say it can't communicate with your 10.x.x.x subnet... is that only by name?

VPN does not go down a lot but there are times when the internet connection has issues and the VPN will be up and down until the ISP corrects the issues so it would be nice not to have to reboot.

When I say it cant communicate to 10.x.x.x I mean it can't do DNS queries, ping etc, the tunnel is down.
 
VPN does not go down a lot but there are times when the internet connection has issues and the VPN will be up and down until the ISP corrects the issues so it would be nice not to have to reboot.

When I say it cant communicate to 10.x.x.x I mean it can't do DNS queries, ping etc, the tunnel is down.

this is what i was getting at.... if the internet being down is the only thing that causes the issues, then just remove the secondary DNS entry to outside DNS... force your own or none at all... if the only time your VPN is down is when your internet is down, shouldn't be a problem....
 
this is what i was getting at.... if the internet being down is the only thing that causes the issues, then just remove the secondary DNS entry to outside DNS... force your own or none at all... if the only time your VPN is down is when your internet is down, shouldn't be a problem....

If something happens at our main location that would prevent them from connecting, we like to have the outside DNS there so they can still browse at least.
 
How many clients at each sub shop?

This is where it is nice to have a DC at each location doing DNS/DHCP at least. It also can prevent GPO issues if you are doing Active Directory.

Main cost is licensing these days. The hardware for a single DC is extremely cheap.
 
Tell me, is everything at 10.x.x.x under a single domain?

Each location has it's own subnet.

How many clients at each sub shop?

Grentz said:
This is where it is nice to have a DC at each location doing DNS/DHCP at least. It also can prevent GPO issues if you are doing Active Directory.

Main cost is licensing these days. The hardware for a single DC is extremely cheap.

From 1 upto ~20. Windows Server machines are slowly headed out to each location but they are not and will not be DC's.
 
From 1 upto ~20. Windows Server machines are slowly headed out to each location but they are not and will not be DC's.

Why not? Hyper-V a domain controller running DHCP and DNS at each shop if they can't afford the hardware for multiple servers, they will hardly use any resources.
 
If you're going to put a server at each site anyway, then I'd agree that you should put DNS on that server. a DC would be great too, even a RODC would be an improvement over having nothing.... If you're sending servers out to the sites, it is going to be more important going forward for clients to be able to authenticate to access those local server resources when the WAN/VPN link is down.....

But if you really don't want to put DCs on-site, at least setup DNS to be a secondary to your AD controllers. Then let those local servers handle external DNS (either natively, or via setting up forwarders). But, if you do setup secondary DNS at those sites, make sure to setup the clients to use them as secondary on the clients or you'll impact dynamic DNS updates from the clients (unless you don't care about that, but it's still not recommended).
 
RODC might be an option one day, but it could be 12-24 months or never before some of these shops see servers.

I'm still hoping for an alternate solution though.
 
If something happens at our main location that would prevent them from connecting, we like to have the outside DNS there so they can still browse at least.

i understand, just don't think it's worth the obvious trouble it's causing... if your internet is up and your equipment isn't responsive, you should fix it on your end, in my opinion....
 
i understand, just don't think it's worth the obvious trouble it's causing... if your internet is up and your equipment isn't responsive, you should fix it on your end, in my opinion....

There are a few times (over many shops it happens more than you think) when an ISP will drop to the point of a VPN disconnect, suddenly all the windows machines DNS switches to the secondary and say 25 seconds later it's back online. Now everyone has to reboot to correct this. Say the ISP has 3 down/up's over a 30 minute time period, only 90 seconds downtime total, reboots take a good chunk of time out of the work flow.

For the next 12-24 months or for some locations, never, while waiting for a server and or us to implement an alternate solution, I'm seeking ideas on how to quickly repair the situation.
 
Let's try a different approach. OP, what kind of managability do you have over the windows machines? You might try setting up a scheduled job every x minutes ( maximum window of failure ). This job would simply restart the DNS Client service in windows.

If I'm right ( I haven't tested this, so I may in fact be quite wrong ), when the DNS Client service restarts it will redo the DNS election process. If everything is fine, then the clients won't notice anything. If you are currently in a failover condition and the vpn is up, the clients will fail back to the primary.
 
Another approach is to expose your corporate secondary DNS server to the internet, filtering for the public IPs of your remote sites. Or, if you have a single ( or very few ) domains, you could setup a bind server to act as a secondary for these domains and expose that to the internet with the same restrictions.

Then just change your secondary DNS IP on the clients to this exposed DNS server.
 
Last edited:
Another approach is to expose your corporate secondary DNS server to the internet, filtering for the public IPs of your remote sites. Or, if you have a single ( or very few ) domains, you could setup a bind server to act as a secondary for these domains and expose that to the internet with the same restrictions.

Then just change your secondary DNS IP on the clients to this exposed DNS server.

Exposing your DNS server to the outside world violates some ISP terms of service. Most do not want people running rouge DNS servers.

I would just do what is already suggested. Remove the public DNS server. If the day ever comes that the VPN will be down for an extended period of time just remote in and change the DNS entries on the local side.
 
Exposing your DNS server to the outside world violates some ISP terms of service. Most do not want people running rouge DNS servers.
I get the impression OP might be utilizing a more business friendly ISP. This is actually the option I would choose, as it satisfies the OP's constraints and is the easiest to implement.

Anyway, even most consumer grade ISPs don't care what you run on your line ( short of file sharing, apparently ).
 
I get the impression OP might be utilizing a more business friendly ISP. This is actually the option I would choose, as it satisfies the OP's constraints and is the easiest to implement.

This is also an incredibly dangerous thing to do if you don't know how to properly harden a server for direct internet exposure. Hackers treat things like these as a playground.
 
This is also an incredibly dangerous thing to do if you don't know how to properly harden a server for direct internet exposure.
Not really. Especially if you only allow your known IPs ( ie: your remote sites ).
 
Back
Top