From the way your question is worded, it seems your expectation is that when Windows needs to resolve a name, it will ask the primary DNS server. And if the primary DNS server doesn't know the answer, it will then ask the secondary.
I hope the above isn't what you were expecting, but if it is, then let me show you why that's a mistake.
DNS doesn't work that way. The only time a resolver will failover to the secondary DNS server is when the primary does not respond at all. An example will clarify:
Suppose you have a primary DNS server at 1.1.1.1 and a secondary at 2.2.2.2. Your client is configured with them in this order. 2.2.2.2 hosts a a private zone foocompany.local; 1.1.1.1 hosts no zones of its own, and does root lookups for internet hosts.
If your client tries to lookup someserver.foocompany.local, 1.1.1.1 will return NXDOMAIN (eg "I queried the root servers and they say that domain does not exist"). Your resolver will not then ask 2.2.2.2 what it knows, unless 1.1.1.1 fails to reply within the timeout period (usually 2 seconds). It'll just quit looking. Further, your client will cache the NXDOMAIN result, as per RFC2308. Even if you change NIC settings such that 2.2.2.2 is the primary server, you'll still get NXDOMAIN results until that local NXDOMAIN cache is expired. You can verify this by issuing ipconfig /displaydns at the command prompt.
IIRC, Windows' DNS resolver caches NXDOMAIN for a short time - 5 minutes. But still this can be annoying.
Anyhow. I realize this is a little bit tangential to your problem, but clarifying this point may bring about an epiphany for your planned design. EG: you may want the VPN's DNS server first to resolve after all. Although it is a tad slower, it knows more, since it can resolve both the domains private to the VPN and public internet domains; whereas the local LAN DNS resolver knows nothing of those domains private to the VPN.
Cheers!
Disclaimer: I'd never even heard of Teredo or ISATAP until I read your post.
That said, I'll take a swing at them:
My guess it that 8-11 are the 'other ends' of 12-16. Or maybe the bridge ends of 1-5 into the virtual network and NAT that is being set up.
v6 interfaces need to be separately addressable from v4 interfaces, so that's 5 more (given you've got 5 physical interfaces - you didn't actually specify). Add another couple to serve as bridges and NAT bottlenecks and those numbers seem reasonable.
Assuming a v4 environment is still a reasonable default.
One Teredo per physical interface perhaps? Just because you (likely) have them bonded or something doesn't mean they have to be.
Best Answer
I'm not familiar with the way Shrew itself works, but is absolutally possible to create a connection that shows up in
ipconfigand is fully functional without it having a driver installed or showing up in the network connections (6to4 connections are made this way).You do it by using the
netshcommands. You may be able to share it that way, but I haven't done any real research into it.