{"id":4263,"date":"2018-08-21T01:55:34","date_gmt":"2018-08-20T21:55:34","guid":{"rendered":"https:\/\/rakhesh.com\/?p=4263"},"modified":"2022-04-26T07:09:08","modified_gmt":"2022-04-26T06:09:08","slug":"macos-vpn-doesnt-use-the-vpn-dns","status":"publish","type":"post","link":"https:\/\/rakhesh.com\/infrastructure\/macos-vpn-doesnt-use-the-vpn-dns\/","title":{"rendered":"MacOS VPN doesn’t use the VPN DNS"},"content":{"rendered":"

Continuing with my previous post<\/a> … as part of configuring it I went to “Advanced” > “DNS” in the VPN connection and put in my remote end DNS server and domain name to search. On Windows 10 I didn’t even have to do this – remote DNS and domains were automatically configured as part of connecting. Anyways, once I put these in though I thought it should just work out of the box but it didn’t.<\/p>\n

So turns out many others have noticed and complained about this. I couldn’t find a solution as such to this but learnt about scutil --dns<\/code> in the process. Even though the Mac OS has a \/etc\/resolv.conf<\/code> file it does not seem to be used; rather, the OS has its own way of DNS resolution and scutil --dns<\/code> lets you see what is configured. (I am very very sketchy on the details and to be honest I didn’t make much of an effort to figure out the details either). In my case the output of this command showed that the VPN provided resolver for my custom domain was being seen by scutil<\/code> and yet it wasn’t being used – no idea why.<\/p>\n

I would like to point out this post<\/a> though that shows how one can use scutil to override the DHCP or VPN assigned DNS servers with another. Good to know the kind of things scutil<\/code> can do.<\/p>\n

And while on this confusing topic it is worth pointing out that tools like nslookup<\/code> and dig<\/code> use the resolver provided in \/etc\/resolv.conf<\/code> so these are not good tools if you want to test what an average Mac OS program might be resolving a particular name to. Best to just ping<\/code> and see what IP a name resolves to.<\/p>\n

Anyways, I didn’t want to go down a scripting route like in that nice blog post so I tried to find an alternative.<\/p>\n

Oh, almost forgot! Scoped queries. If you check out this SuperUser post<\/a> you can see the output of scutil --dns<\/code> and come across the concept of scoped queries. The idea (I think) is that you can say domain xyz.com should be resolved using a particular name server, domain abc.com should be resolved via another, and so on. From that post I also got the impression you can scope it per interface … so the idea would be that you can scope the name server for my VPN interface to be one, while the name server for my other interfaces to be another. But this wasn’t working in my case (or I had configured something wrong – I dunno. I am a new Mac OS user). Here was my output btw so you can see my Azure hosted domain rakhesh.net has its own name server, while my home domain rakhesh.local has its own (and don’t ask me where the name server for general Internet queries is picked up from … I have no idea!).<\/p>\n

DNS configuration\r\n\r\nresolver #1\r\n  search domain[0] : rakhesh.local\r\n  nameserver[0] : 2001:8f8:002d:20eb::1\r\n  nameserver[1] : 192.168.1.1\r\n  if_index : 6 (en0)\r\n  flags    : Request A records, Request AAAA records\r\n  reach    : 0x00020002 (Reachable,Directly Reachable Address)\r\n\r\nresolver #2\r\n  domain   : local\r\n  options  : mdns\r\n  timeout  : 5\r\n  flags    : Request A records, Request AAAA records\r\n  reach    : 0x00000000 (Not Reachable)\r\n  order    : 300000\r\n\r\n<snip>\r\n\r\nresolver #7\r\n  domain   : b.e.f.ip6.arpa\r\n  options  : mdns\r\n  timeout  : 5\r\n  flags    : Request A records, Request AAAA records\r\n  reach    : 0x00000000 (Not Reachable)\r\n  order    : 301000\r\n\r\nDNS configuration (for scoped queries)\r\n\r\nresolver #1\r\n  search domain[0] : rakhesh.local\r\n  nameserver[0] : 2001:8f8:002d:20eb::1\r\n  nameserver[1] : 192.168.1.1\r\n  if_index : 6 (en0)\r\n  flags    : Scoped, Request A records, Request AAAA records\r\n  reach    : 0x00020002 (Reachable,Directly Reachable Address)\r\n\r\nresolver #2\r\n  search domain[0] : rakhesh.net\r\n  nameserver[0] : 10.0.0.4\r\n  if_index : 12 (ipsec0)\r\n  flags    : Scoped, Request A records\r\n  reach    : 0x00000002 (Reachable)\r\n<\/pre>\n
Anyways, here’s a link to scutil<\/code><\/a> for my future reference. And story 1<\/a> and story 2<\/a> on mDNSResponder, which seems to be the DNS resolver in Mac OS. And while on mDNSResponder, if you want to flush you local DNS cache you can do the following (thanks to this help page<\/a>):<\/p>\n
sudo killall -HUP mDNSResponder;sudo killall mDNSResponderHelper;sudo dscacheutil -flushcache<\/pre>\n
What a mouthful! :)<\/p>\n
Also, not related to all this, but something I had to Google on as I didn’t know how to view the routing table in Mac OS. If you want to do the same then netstat -nr<\/code> is your friend.<\/p>\n
Ok, so going back to my problem. I was reading the resolver(5)<\/code> man page and came across the following:<\/p>\n
Mac OS X supports a DNS search strategy that may involve multiple DNS resolver clients.<\/p>\n
Each DNS client is configured using the contents of a single configuration file of the format described below, or from a property list supplied from some other system configuration database. Note that the \/etc\/resolv.conf<\/code> file, which contains configuration for the default (or “primary”) DNS resolver client, is maintained automatically by Mac OS X and should not be edited manually. Changes to the DNS configuration should be made by using the Network Preferences panel.<\/p>\n
Mac OS X uses a DNS search strategy that supports multiple DNS client configurations. Each DNS client has its own set of nameserver addresses and its own set of operational parameters.<\/em> Each client can perform DNS queries and searches independent of other clients. Each client has a symbolic name which is of the same format as a domain name, e.g. “apple.com”<\/em>. A special meta-client, known as the “Super” DNS client acts as a router for DNS queries. The Super client chooses among all available clients by finding a best match<\/em> between the domain name given in a query and the names of all known clients.<\/p>\n
Queries for qualified names are sent using a client configuration that best matches the domain name given in the query. For example, if there is a client named “apple.com”, a search for “www.apple.com” would use the resolver configuration specified for that client. The matching algorithm chooses the client with the maximum number of matching domain components. For example, if there are clients named “a.b.c”, and “b.c”, a search for “x.a.b.c” would use the “a.b.c” resolver configuration, while a search for “x.y.b.c” would use the “b.c” client. If there are no matches, the configuration settings in the default client, generally corresponding to the \/etc\/resolv.conf<\/code> file or to the “primary” DNS configuration on the system are used for the query.<\/p>\n
If multiple clients are available for the same domain name, the clients ordered according to a search_order<\/code> value (see above). Queries are sent to these resolvers in sequence by ascending value of search_order<\/code>.<\/p>\n
The configuration for a particular client may be read from a file having the format described in this man page. These are at present located by the system in the \/etc\/resolv.conf<\/code> file and in the files found in the \/etc\/resolver<\/code> directory. However, client configurations are not limited to file storage. The implementation of the DNS multi-client search strategy may also locate client configurations in other data sources, such as the System Configuration Database. Users of the DNS system should make no assumptions about the source of the configuration data.<\/p><\/blockquote>\n
If I understand this correctly, what it is saying is that:<\/p>\n
    \n
  1. The settings defined in \/etc\/resolv.conf<\/code> is kind of like the fall-back\/ default?<\/li>\n
  2. Each domain (confusingly referred to as “client”) in the man-page can have its own settings. You define these as files in \/etc\/resolver\/<\/code>. So I could have a file called \/etc\/resolver\/google.com<\/code> that defines how I want the “google.com” domain to be resolved – what name servers to use etc. (these are the typical options one finds in \/etc\/resolv.conf<\/code>).<\/li>\n
  3. The system combines all these individual definitions, along with dynamically created definitions such as when a VPN is established (or any DHCP provided definitions I’d say, including wired and wireless) into a configuration database. This is what scutil<\/code> can query and manipulate.<\/li>\n<\/ol>\n
    What this means for me though is that I can create a file called \/etc\/resolver\/rakhesh.net<\/code> (my Azure domain is rakhesh.net) with something like these:<\/p>\n
    nameserver 10.0.0.4<\/pre>\n
    Thus any requests for rakhesh.net will go via this name server. When I am not connected to VPN these requests will fail as the DNS server is not reachable, but when connected it will work fine.<\/p>\n
    What if I want to take this one step further though? As in I want DNS requests for rakhesh.net to go to its proper external DNS server when I am not on VPN but go via the internal DNS server when I am on VPN? That too is possible. All I have to do is have multiple files – since I can’t call all of them \/etc\/resolver\/rakhesh.net<\/code> – and within each specify the domain name via the domain<\/code> parameter and also define the preference via a search_order<\/code> parameter. The one with the lower number gets tried first.<\/p>\n
    So I now have two files. For internal queries I have \/etc\/resolver\/rakhesh.net.azure<\/code> (the name doesn’t matter):<\/p>\n
    domain rakhesh.net\r\nnameserver 10.0.0.4\r\nsearch_order 1\r\ntimeout 5<\/pre>\n
    For external queries I have \/etc\/resolver\/rakhesh.net.inet<\/code>:<\/p>\n
    domain rakhesh.net\r\nnameserver 162.159.24.178\r\nnameserver 162.159.25.191\r\nsearch_order 2<\/pre>\n
    The internal file has higher priority. I also added a timeout of 5 seconds so it doens’t spend too much time trying to contact the name server if the VPN is not connected. Easy peasy. This way my queries work via the internal DNS servers if I am connected to VPN, and via external DNS servers if I am not on VPN.<\/p>\n
    If I now look at the output of scutil --dns<\/code> I see all this info captured:<\/p>\n
    <snip>\r\n\r\nresolver #8\r\ndomain : rakhesh.net\r\nnameserver[0] : 10.0.0.4\r\nflags : Request A records, Request AAAA records\r\nreach : 0x00000002 (Reachable)\r\norder : 1\r\n\r\nresolver #9\r\ndomain : rakhesh.net\r\nnameserver[0] : 162.159.24.178\r\nnameserver[1] : 162.159.25.191\r\nflags : Request A records, Request AAAA records\r\nreach : 0x00000002 (Reachable)\r\norder : 2<\/pre>\n
    So that’s it. Hope this helps someone!<\/p>\n
    Update (26th April 2022)<\/strong>: I was mistakently referring to \/etc\/resolver\/xxx<\/code> as \/etc\/resolvers<\/strong>\/xxx<\/code> in many places. Thanks to Seth Kingsley for pointing this out. Fixed this. \ud83d\udc4d\ud83c\udffc<\/p>\n","protected":false},"excerpt":{"rendered":"
    Continuing with my previous post … as part of configuring it I went to “Advanced” > “DNS” in the VPN connection and put in my remote end DNS server and domain name to search. On Windows 10 I didn’t even have to do this – remote DNS and domains were automatically configured as part of … Continue reading MacOS VPN doesn’t use the VPN DNS<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","enabled":false}}},"categories":[333,853],"tags":[383,47,850,851,852,99],"jetpack_publicize_connections":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/posts\/4263"}],"collection":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/comments?post=4263"}],"version-history":[{"count":0,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/posts\/4263\/revisions"}],"wp:attachment":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/media?parent=4263"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/categories?post=4263"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/tags?post=4263"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}