SparkLabs Forum.

Community Help.


Not using OpenVPN DNS server first

I have been experiencing the same problems for quite some time running OSX 10.12.x. The problem I have seen much like the output of "scutil --dns" is that the domain for the VPN is being added to the unscoped resovler #1 (and then also added as unscoped resolver #2).

I currently run Viscosity v1.7.11(1463) which does not have the setting described above. Instead there is now DNS settings on each connection of which one is labeled mode. It has automatic, full DNS, split DNS and disabled. The automatic setting seems to be more or less the split DNS setting. To me it seems that the split DNS setting is what would be the proper setting, but that does not work because the VPN DNS domain is added to the unscoped resolver #1 which is the primary resolver that was setup under DHCP (which is correct for the normal net connection). Full DNS setting is a partial fix in that it will push resolver #1 up to resolver #2 and then create the VPN DNS information as resolver #1. That basically works, but not truly correctly in that the VPN resolvers are now handling nearly all the DNS resolution. But when another VPN is brought up, half my resolutions do not get directed as expected. BTW all my VPN DNS are private zones that are not resolvable other than by the DNS server on the other end of the VPN connection and they are all unique (i.e. one VPN DNS server can not resolve for another VPN connection).

Any thoughts on now to fix this (and not by going into the network connection each time to reorder the resolvers) would be appreciated.

Thanks.
Hi hickey,

I've spit your post off from the very old topic it was posted on, which is no longer relevant to how DNS is processed in Viscosity.

Please read up on the different DNS modes Viscosity supports:
https://www.sparklabs.com/support/kb/ar ... #dns-modes

In short, if you want your VPN connection's DNS servers to be used for all lookups, use Full DNS mode. If you only want to use your VPN connection's DNS servers for certain domains, then use Split DNS.

It sounds like you may be confusing scutil's two different sections in its output. There is the first section titled "DNS configuration", and the second section titled "DNS configuration (for scoped queries)". When looking at what DNS server/s will be used to lookup a particular domain, the second section should be looked at (the ordering in the first section is irrelevant).

If you are using Split DNS with no DNS domains set, then you'll like see this warning in the connection log:
https://www.sparklabs.com/support/kb/ar ... e-present/

Cheers,
James
Yes, but the split DNS setting does not work correctly. This is what the original posting was talking about and what I tried to explain in my last posting. So here I will try again......

After bringing up a VPN connection that pushes DNS resolvers to the client Viscosity structures the resolvers as follows. A few of the domain names have been changed to protect the innocent :-)

Code: Select all

0:1 ᐅ scutil --dns 
DNS configuration

resolver #1
  search domain[0] : stage.foobar.com
  search domain[1] : hsd1.wa.comcast.net
  search domain[2] : wa.comcast.net
  nameserver[0] : 208.67.222.222
  nameserver[1] : 8.8.8.8
  if_index : 5 (en0)
  flags    : Request A records
  reach    : Reachable

resolver #2
  domain   : stage.foobar.com
  nameserver[0] : 10.67.43.8
  nameserver[1] : 10.67.44.72
  flags    : Supplemental, Request A records
  reach    : Reachable
  order    : 101000

[ Removed misc. resolvers ]

DNS configuration (for scoped queries)

resolver #1
  search domain[0] : hsd1.wa.comcast.net
  search domain[1] : wa.comcast.net
  nameserver[0] : 208.67.222.222
  nameserver[1] : 8.8.8.8
  if_index : 5 (en0)
  flags    : Scoped, Request A records
  reach    : Reachable

resolver #2
  search domain[0] : stage.foobar.com
  nameserver[0] : 10.67.43.8
  nameserver[1] : 10.67.44.72
  if_index : 13 (utun10)
  flags    : Scoped, Request A records
  reach    : Reachable
 


Now the problem is that the domain name (stage.foobar.com) for the VPN connection is getting setup on the first unscoped resolver. Because stage.foobar.com is not a publicly available zone (it can only be resolved by the private resolvers 10.67.43.8 and 10.67.44.72) the way that Viscosity has added the DNS information (this connection is using Split DNS) causes any lookups in the stage.foobar.com domain to be routed to the Comcast resolvers which have no access to the stage.foobar.com zone.

Here is some proof.....

Code: Select all

0:0 ᐅ dig apiserver.stage.foobar.com                                                                                                                     [10:12]

; <<>> DiG 9.8.3-P1 <<>> apiserver.stage.foobar.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 20095
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;apiserver.stage.foobar.com. IN A

;; AUTHORITY SECTION:
foobar.com.      86   IN   SOA   pdns100.ultradns.com. snoc.foobar.com. 1483769333 86400 7200 604800 300

;; Query time: 51 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Wed Oct 31 10:28:29 2018
;; MSG SIZE  rcvd: 115


If DNS was setup correctly by the Split DNS setting, then this request would have been routed to one of the private DNS resolvers and actually succeeded.

Now if there was a way to force all DNS lookups to be routed through the scoped resolvers instead, that would be great (since the scoped query section is setup correctly), but I don't know if that is possible. Actually I don't quite understand how a query is determined to be scoped or unscoped.

Please let me know if this is still not making sense or is unclear. Thanks.
That setup all looks fine. The DNS servers 10.67.43.8 and 10.67.44.72 will be used to resolve stage.foobar.com subdomains.

Please see the following regarding the use of "dig":
https://www.sparklabs.com/support/kb/ar ... unix-users

Cheers,
James
4 posts Page 1 of 1

Copyright © 2016 SparkLabs Pty Ltd. All Rights Reserved. Privacy Policy