This might be a bit long winded, but I'll try to address most of your issues in one go. Wish me luck!
You can have your upstream service providers advertise a default route (0.0.0.0) through BGP to your routers. When you configure OSPF on your BGP routers, you can use the command "default-information originate." As long as you're getting the default route from your ISP (which only happens when you have connectivity to that ISP), you'll advertise the default route into OSPF. As soon as you lose that default route from your ISP, you'll lose the OSPF default route.
You'll need to establish BGP peering between all of your internet routers (the ones connected to your ISPs). This is an internal BGP or iBGP relationship and needs to be a full mesh. Per your diagram, you only have two internet routers, so a full mesh is simple. There are no tricky steps to peer on iBGP versus eBGP; just a simple neighbor statement. When BGP sees that your neighbor has the same AS number, it forms an iBGP relationship instead of an eBGP one.
Preferring one route over another is a bit tricky, particularly where BGP is concerned. Load balancing is done using route maps and traditionally with as-path prepending. There are a few ways to do this. I'd like to add a caveat that if you aren't filtering outgoing route advertisements, you'll end up advertising ISP A's routes to ISP B and C and so forth which will turn you into a transit AS and you'll end up piping some A <-> B, A <-> C, and B <-> C traffic through your network which is probably not what you want.
Here's one go at your load balancing:
! Set an IP access list that matches your BGP-advertised network
ip access-list standard 1 permit a.b.c.d mask a.b.c.d
! Set an IP as-path access list to only allow advertising of YOUR network
ip as-path access-list 1 permit ^$
! Make a route-map for ISP C, match the as-path and access-list above, then make it look
! less appealing than going through ISP A/B
route-map ISP_C 10
match ip address 1
match as-path 1
set as-path prepend <Your AS> <Your AS> <Your AS>
! The more times you prepend your AS to a route, the less desirable it looks, so traffic
! will be more likely to come in via ISP A/B than C. The last step is to add it to your
! ISP C neighbor statement in BGP
router bgp <Your AS>
neighbor <ISP C> route-map ISP_C out
If you have more than one subnet, you can even things out a little more and use router B for site B and router A for site A by selectively prepending your AS path to individual subnets. Here's an example:
Router A:
ip access-list standard 1
permit <site B subnets>
ip as-path 1 permit ^$
route-map ISP_AB 10
match ip address 1
match as-path 1
set as-path prepend <Your AS> <Your AS>
route-map ISP AB 20
match as-path 1
router bgp <Your AS>
neighbor <ISP A> route-map ISP_AB out
neighbor <ISP B> route-map ISP_AB out
Router B:
ip access-list standard 1
permit <site A subnets>
ip as-path 1 permit ^$
route-map ISP_C 10
match ip address 1
match as-path 1
set as-path prepend <Your AS> <Your AS>
route-map ISP C 20
match as-path 1
router bgp <Your AS>
neighbor <ISP C> route-map ISP_C out
What you've effectively done is make site B's subnets look less appealing coming from Router A than they do from ISP C and make site A's subnets look less appealing coming from Router B than they do from ISP A/B. You might have to play around with your AS path prepending some to get the right amount of prepending in.
I hope this helps! BGP is a bit of a monster, but once you understand the parts, it's fun to play with. I highly recommend the CBT Nuggets series on BGP if you feel a bit shaky on the subject and I always use GNS3 as a testbed to verify big network changes before I implement them.
Experiment
There is a lot of conflicting information about what actually happens on a Windows client when using split-dns. So much that I decided to gather some evidence and see where it points. I set up a simultaneous packet capture on both the VPN-connected Windows client and the ASA to which that client is connected. Here is a diagram of the test setup:
With the packet captures running, I initiated DNS resolution on the client. To do so, I pressed enter on srv1.internal.example.com in Google Chrome. Here are the resulting packet captures adjusted to sync their clocks and merged together.
Packets with IDs starting with "C" are from the Windows [C]lient.
Packets starting with "A" are from the [A]SA.
Analysis
In orange, we can see four separate DNS queries that are trying to be made by Windows/Chrome: The destinations of the four DNS queries are as follows:
- 8.8.8.8 - the DNS Server associated with the Wifi Adapter (packet
C69)
- 10.10.10.3 - the first DNS Server associated with the VPN Adapter (packet
C70)
- 8.8.8.8 - the DNS Server associated with the Wifi Adapter (packet
C78)
- 10.10.10.4 - the second DNS Server associated with the VPN Adapter (packet
C81)
What is most revealing is that the two DNS queries apparently sent to 8.8.8.8 appear at the ASA in packets A95 and A105 with source and destination IPs translated from external addresses to internal addresses. The responses from the DNS server for those translated queries are in A97 and A106 which are themselves then translated to external addresses again in packets C74 and C84, respectively. These DNS queries ultimately succeed.
Answers to the original questions
If Windows opts to send DNS queries for internal domains to adapters other than the VPN adapter, how can the VPN client ensure all DNS queries for internal domains are tunneled to the internal DNS servers?
Based on the above evidence, the VPN client seems to intercept DNS queries that match the domain configured using the split-dns value command on non-VPN adapters.
Am I missing something here? Is there something fancy going on that somehow allows the VPN client to intercept DNS queries that Windows sends to the wrong adapter?
The fancy part that was missing is that the VPN client performs a sort of network address translation to make it appear to Windows that DNS queries for the internal domain are being serviced by the public DNS server to which Windows sent its request. In fact those requests are serviced by the internal DNS server.
I'm not sure exactly how this is accomplished, and there doesn't seem to be any documentation from Cisco that speaks to this. I accept that there is some amount of sorcery that the VPN client performs on the Windows end to achieve a functioning split DNS.
Notes on Adapter Binding Order
I tinkered with the oft-cited adapter binding order. Here is what I found. The adapter order seems to have no impact on the efficacy of the VPN Client's ability to intercept and translate DNS queries for internal domains.
Putting the VPN adapter highest in the binding order seems to result in Windows sending DNS requests only to the DNS servers on the VPN adapter initially. Those requests seem to be dropped entirely by the VPN Client (presumably because they don't match the internal domain). This then results in a Windows timeout (or a series of them) until, eventually, Windows attempts DNS resolution using the non-VPN adapter. This creates a noticeable and irritating delay when browsing.
Based on this, it seems that in split DNS configurations the VPN adapter should not be the highest priority.
Best Answer
The best way to accompalish this task to create another internal DNS server and ensure both primary and secondary dns servers are in synchronised .
And configure both primary and secondary DNS server ip address in network adapter properties in client workstation s
If primary DNS servers goes down secondary DNS server will take workload . Client work station will send recursive querry on secondary ip address configured on workstation.