How does Name Resolution actually work in the latest version of macOS?

Question

Current version: macOS Sierra 10.12.3

I administer an OpenVPN server for my company. I have set the following:

# Send client instructions to use our internal DNS
push "dhcp-option DNS 172.31.5.39"
push "dhcp-option DNS 172.31.34.40"
push "dhcp-option DNS 172.31.33.23"

# Send client instructions to search these domains when doing short/non-FQDN name lookups
push "dhcp-option DOMAIN-SEARCH ies"
push "dhcp-option DOMAIN-SEARCH ec2"
push "dhcp-option DOMAIN-SEARCH elb"
push "dhcp-option DOMAIN-SEARCH us-west-2.compute.internal"

And on my machine everything works perfectly.

$ scutil --dns
DNS configuration

resolver #1
  search domain[0] : ies
  search domain[1] : ec2
  search domain[2] : elb
  search domain[3] : us-west-2.compute.internal
  nameserver[0] : 172.31.5.39
  nameserver[1] : 172.31.34.40
  nameserver[2] : 172.31.33.23
  flags    : Request A records
  reach    : Reachable

resolver #2
  domain   : local
  options  : mdns
  timeout  : 5
  flags    : Request A records
  reach    : Not Reachable
  order    : 300000

resolver #3
  domain   : 254.169.in-addr.arpa
  options  : mdns
  timeout  : 5
  flags    : Request A records
  reach    : Not Reachable
  order    : 300200

resolver #4
  domain   : 8.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  flags    : Request A records
  reach    : Not Reachable
  order    : 300400

resolver #5
  domain   : 9.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  flags    : Request A records
  reach    : Not Reachable
  order    : 300600

resolver #6
  domain   : a.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  flags    : Request A records
  reach    : Not Reachable
  order    : 300800

resolver #7
  domain   : b.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  flags    : Request A records
  reach    : Not Reachable
  order    : 301000

resolver #8
  domain   : ies
  nameserver[0] : 172.31.5.39
  nameserver[1] : 172.31.34.40
  nameserver[2] : 172.31.33.23
  flags    : Request A records
  reach    : Reachable

DNS configuration (for scoped queries)

resolver #1
  search domain[0] : ies
  search domain[1] : ec2
  search domain[2] : elb
  search domain[3] : us-west-2.compute.internal
  nameserver[0] : 172.31.5.39
  nameserver[1] : 172.31.34.40
  nameserver[2] : 172.31.33.23
  if_index : 4 (en0)
  flags    : Scoped, Request A records
  reach    : Reachable

$ dscacheutil -q host -a name svcmongouat1.ec2
name: svcmongouat1.ec2
ip_address: 172.31.16.60

$ dns-sd -Gv4v6 svcmongouat1.ec2
DATE: ---Fri 03 Mar 2017---
 1:03:47.635  ...STARTING...
Timestamp     A/R Flags if Hostname                               Address                                      TTL
 1:03:47.637  Add     2  0 svcmongouat1.ec2.                      0000:0000:0000:0000:0000:0000:0000:0000%<0>  60   No Such Record
 1:03:47.727  Add     2  0 svcmongouat1.ec2.                      172.31.16.60                                 39
^C

$ dns-sd -q svcmongouat1.ec2 255 255
DATE: ---Fri 03 Mar 2017---
 1:04:14.348  ...STARTING...
Timestamp     A/R Flags if Name                          Type  Class   Rdata
 1:04:14.349  Add     2  0 svcmongouat1.ec2.             Addr   IN     172.31.16.60
^C

But for every other user, they have the same results in the scutil, and are able to get correct lookups when the do dig, but not dscacheutil and of course most of their other applications fail also.

UPDATE:

Here is an example for a coworker experiencing the odd failure:

$ scutil --dns
DNS configuration

resolver #1
  search domain[0] : ies
  search domain[1] : ec2
  search domain[2] : elb
  search domain[3] : us-west-2.compute.internal
  nameserver[0] : 172.31.5.39
  nameserver[1] : 172.31.34.40
  nameserver[2] : 172.31.33.23
  flags    : Request A records
  reach    : Reachable

resolver #2
  domain   : local
  options  : mdns
  timeout  : 5
  flags    : Request A records
  reach    : Not Reachable
  order    : 300000

resolver #3
  domain   : 254.169.in-addr.arpa
  options  : mdns
  timeout  : 5
  flags    : Request A records
  reach    : Not Reachable
  order    : 300200

resolver #4
  domain   : 8.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  flags    : Request A records
  reach    : Not Reachable
  order    : 300400

resolver #5
  domain   : 9.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  flags    : Request A records
  reach    : Not Reachable
  order    : 300600

resolver #6
  domain   : a.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  flags    : Request A records
  reach    : Not Reachable
  order    : 300800

resolver #7
  domain   : b.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  flags    : Request A records
  reach    : Not Reachable
  order    : 301000

resolver #8
  domain   : ies
  nameserver[0] : 172.31.5.39
  nameserver[1] : 172.31.34.40
  nameserver[2] : 172.31.33.23
  flags    : Request A records
  reach    : Reachable

DNS configuration (for scoped queries)

resolver #1
  search domain[0] : ies
  search domain[1] : ec2
  search domain[2] : elb
  search domain[3] : us-west-2.compute.internal
  nameserver[0] : 172.31.5.39
  nameserver[1] : 172.31.34.40
  nameserver[2] : 172.31.33.23
  if_index : 4 (en0)
  flags    : Scoped, Request A records
  reach    : Reachable
$ 
$ 
$ dscacheutil -q host -a name svcmongouat1.ec2
$ dscacheutil -q host -a name svcmongouat1.ec2
$ 
$ 
$ dns-sd -Gv4v6 svcmongouat1.ec2
DATE: ---Thu 09 Mar 2017---
11:07:18.693  ...STARTING...
Timestamp     A/R Flags if Hostname                               Address                                      TTL
11:07:18.694  Add     3  0 svcmongouat1.ec2.                      0000:0000:0000:0000:0000:0000:0000:0000%<0>  60   No Such Record
11:07:18.695  Add     2  0 svcmongouat1.ec2.                      0.0.0.0                                      108002   No Such Record
^C
$ 
$ 
$ dns-sd -q svcmongouat1.ec2 255 255
DATE: ---Thu 09 Mar 2017---
11:07:43.522  ...STARTING...
Timestamp     A/R Flags if Name                          Type  Class   Rdata
11:07:43.523  Add     3  0 svcmongouat1.ec2.             Addr   IN     0.0.0.0    No Such Record
11:07:43.524  Add     2  0 svcmongouat1.ec2.             AAAA   IN     0.0.0.0    No Such Record
^C
$
$
$ dig svcmongouat1.ec2

; <<>> DiG 9.8.3-P1 <<>> svcmongouat1.ec2
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42225
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 0

;; QUESTION SECTION:
;svcmongouat1.ec2.        IN    A

;; ANSWER SECTION:
svcmongouat1.ec2.    30    IN    A    172.31.16.60

;; AUTHORITY SECTION:
.            6413    IN    NS    i.root-servers.net.
.            6413    IN    NS    k.root-servers.net.
.            6413    IN    NS    l.root-servers.net.
.            6413    IN    NS    d.root-servers.net.
.            6413    IN    NS    j.root-servers.net.
.            6413    IN    NS    c.root-servers.net.
.            6413    IN    NS    b.root-servers.net.
.            6413    IN    NS    f.root-servers.net.
.            6413    IN    NS    a.root-servers.net.
.            6413    IN    NS    e.root-servers.net.
.            6413    IN    NS    h.root-servers.net.
.            6413    IN    NS    g.root-servers.net.
.            6413    IN    NS    m.root-servers.net.

;; Query time: 103 msec
;; SERVER: 172.31.5.39#53(172.31.5.39)
;; WHEN: Thu Mar  9 10:58:27 2017
;; MSG SIZE  rcvd: 261

$

I've searched Google and it seems to be a mystery to everyone and has also changed many time in different version of OS X.

So, again, the question is:

How does Name Resolution actually work in the latest version of macOS?
What applications use what tools and why?
How do I determine ^^#2^^?
How can someone debug?

I think the most infuriating part of this is that on the day I posted this, only my machine could resolve names while all others failed. Then the next day during lunch I ask my team to leave their machines unlock so I can work on it. And of course every one of them worked flawlessly. And now the cycle is repeating. — Bruno Bronosky, Commented Mar 2, 2017 at 16:13
I'd like to see the full output of scutil --dns. It doesn't make sense to me that you'd only have scoped resolvers. It would be nice to see the full output both when the VPN connection is up and when it is down. — Spiff, Commented Mar 3, 2017 at 5:06
Also note that dig doesn't use the scoped query mechanism. If you don't specify a DNS server to dig, it will check /etc/resolv.conf to find a DNS server to use, but that file is autogenerated and only contains the default servers for unscoped queries. To query DNS like the system does, use dns-sd -Gv4v6 example.com, and dns-sd -q example.com 255 255 (you have to Ctrl-C out of dns-sd). — Spiff, Commented Mar 3, 2017 at 5:10
@Spiff, I have added your requests. I thought I was doing the reader a favor by keeping the scutil --dns output terse. My bad. Thanks for looking. — Bruno Bronosky, Commented Mar 3, 2017 at 6:13
Thanks for the full scutil --dns output. Does this show the working case or the failing case? Was this machine's VPN tunnel up or down when this was taken? — Spiff, Commented Mar 6, 2017 at 21:17

Stack Exchange Network

How does Name Resolution actually work in the latest version of macOS?

0

You must log in to answer this question.

Browse other questions tagged
macos
dns
openvpn
macos-sierra
.

Hot Network Questions

How does Name Resolution actually work in the latest version of macOS?

0

You must log in to answer this question.

Browse other questions tagged macosdnsopenvpnmacos-sierra.

Related

Hot Network Questions

Browse other questions tagged
macos
dns
openvpn
macos-sierra
.