0

DNS is being served up by a Windows 2016 server and has no issues that I'm aware of except when trying to resolve the server's IP, using macOS, from inside the network.

Dig's output is confusing to me because it seems to be able to resolve name name to IP (unless I use +trace +recurse) and resolve IP to name. And yes the tld is a proper tld, it's not .local or anything weird like that. Ping doesn't seem to know who the host is even after pulling this IP with dig.

Any insight would be appreciated. I'm running this from Sonoma 14.1.2 on an M1 Max. As far as I know this doesn't happen from Windows 10/11 clients. The issue disappears if I'm working remotely over an OpenVPN tunnel.

username@Proteus % dig -t a some.domain.tld

; <<>> DiG 9.10.6 <<>> -t a some.domain.tld
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11941
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1


;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;some.domain.tld.                  IN      A


;; ANSWER SECTION:
some.domain.tld.           3600    IN      A       192.168.110.10


;; Query time: 64 msec
;; SERVER: 192.168.110.14#53(192.168.110.14)
;; WHEN: Fri Dec 08 15:43:54 PST 2023
;; MSG SIZE  rcvd: 57


username@Proteus % dig +trace +recurse some.domain.tld


; <<>> DiG 9.10.6 <<>> +trace +recurse some.domain.tld
;; global options: +cmd
;; Received 28 bytes from 192.168.110.14#53(192.168.110.14) in 68 ms


username@Proteus % dig -x 192.168.110.10


; <<>> DiG 9.10.6 <<>> -x 192.168.110.10
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3430
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1


;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;10.110.168.192.in-addr.arpa.   IN      PTR


;; ANSWER SECTION:
10.110.168.192.in-addr.arpa. 3600 IN    PTR     some.domain.tld.


;; Query time: 77 msec
;; SERVER: 192.168.110.14#53(192.168.110.14)
;; WHEN: Fri Dec 08 15:52:29 PST 2023
;; MSG SIZE  rcvd: 82


username@Proteus % ping some.domain.tld
ping: cannot resolve some.domain.tld: Unknown host
Harv
  • 6,520
  • This is essentially a dupe of: https://apple.stackexchange.com/questions/24018/dns-lookups-fail-with-e-g-ping-but-work-with-host?rq=1. The point is that dig(1), like host(1), doesn't use the system resolver, but ping(1) does. However, the solutions proposed in that old thread won't necessarily work now. Check the network settings to make sure the DNS server is listed first. – Linc D. Dec 09 '23 at 02:18
  • The DNS server is listed first, yes. I did see that question, restarting mDNSResolver didn't help me. In the case of that question, I thought the fact that he was trying to resolve a .local address was important; in my case, I'm not. It's just a normal hostname with a regular tld on the internal network being resolved by an internal DNS server that oddly works fine from Windows or over VPN but not if I'm on the local network via WiFi or Ethernet. – Harv Dec 09 '23 at 09:11
  • You say the WIndows clients on the local network can resolve the name, as far as you know. Are you sure about that? Are there any other Macs on the network, and if so, are they resolving? Does anyone in the office have an iPhone, and if so, does it resolve? – Linc D. Dec 09 '23 at 20:23
  • Yes I'm sure. Other Macs on the network don't resolve the server in question, luckily I'm the only one who ever needs to use it. I'll double-check with my iPhone next time I'm in the office. – Harv Dec 09 '23 at 23:46
  • Confirmed, iOS also does not resolve the hostname. – Harv Dec 14 '23 at 02:10
  • If iCloud Private Relay is enabled, please disable it and test. In the Wi-Fi settings, if "Limit IP address tracking" is enabled, disable that and test. – Linc D. Dec 14 '23 at 05:42

0 Answers0