Hello! I figured I'd take a crack at #193 since I had the same observation.

Currently, doggo reads DNS configuration from /etc/resolv.conf on macOS, but this file doesn't reflect the actual DNS settings managed by the SystemConfiguration framework. Modern macOS systems use scutil --dns to expose the real configuration, which can include multiple resolvers for different domains - particularly important when connected to corporate VPNs or using MDM profiles.

I've added a new config_darwin.go that parses the output of scutil --dns instead. This gives doggo access to all the DNS servers configured on the system, including domain-specific resolvers that are common in enterprise environments. The implementation gracefully falls back to reading /etc/resolv.conf if scutil isn't available or fails for any reason.

While working on this, I realized it would be helpful to have a way to specifically query internal/corporate DNS servers. So I've also added a new --strategy=internal option that automatically filters for RFC 1918 private IP addresses (10.x.x.x, 172.16-31.x.x, 192.168.x.x) and RFC 4193 IPv6 ULA addresses (fd00::/8). This makes it much easier to investigate name resolution issues when you're connected to a VPN or have corporate DNS profiles installed.

The macOS-specific code lives in config_darwin.go and follows the same pattern as the existing Windows implementation. I updated the Unix config build tag to exclude darwin, so Linux and BSD systems continue using the existing /etc/resolv.conf approach. The internal strategy logic integrates cleanly with the existing strategy system and respects the IPv4/IPv6 filtering flags.

One thing worth noting: the implementation aggregates nameservers from all non-mDNS resolvers, not just resolver #1. This means the --strategy=internal option can discover corporate DNS servers even when they're configured as domain-specific resolvers (e.g. resolver #8 for *.corp.example.com).

This is a purely additive change. The existing strategies (all, random, first) work exactly as before, and explicit nameserver specifications with -n continue to work. The default behavior on macOS now uses scutil instead of /etc/resolv.conf, but returns the same nameservers in practice (resolver #1). Other platforms are completely unaffected.

I've tested this with various network configurations on macOS: standard public DNS, connected to a corporate VPN with internal DNS servers, and with domain-specific resolver profiles. The internal strategy correctly identifies and uses private IP nameservers, and successfully resolves internal corporate domains. The fallback to /etc/resolv.conf works as expected when scutil isn't available.