debugging
debugging
debugging
debugging
use default route interface IP for OS resolver queries
remove retries
fix resolv.conf clobbering on MacOS, set custom local addr for os resolver queries
remove the client info discovery logic on network change, this was overkill just for the IP, and was causing service failure after switching networks many times rapidly
handle ipv6 local addresses
guard ciTable from nil pointer
debugging failure count
fix test
use upstreamIS var
init map, fix watcher flag
attempt to detect network changes
attempt to detect network changes
cancel and rerun reinitializeOSResolver
cancel and rerun reinitializeOSResolver
cancel and rerun reinitializeOSResolver
ignore invalid inferaces
ignore invalid inferaces
allow OS resolver upstream to fail
dont wait for dnsWait group on reinit, check for active interfaces to trigger reinit
fix unused var
simpler active iface check, debug logs
dont spam network service name patching on Mac
dont wait for os resolver nameserver testing
remove test for osresovlers for now
async nameserver testing
remove unused test
The current flow involves marking OS resolver as down, which is not
right at all, since ctrld depends on it for leaking queries.
This commits implements new flow, which ctrld will restore DNS settings
once leaking marked, allowing queries go to OS resolver until the
internet connection is established.
So it would work in more general case than just captive portal network,
which ctrld have supported recently.
Uses who may want no leaking behavior can use a config to turn off this
feature.
So it can be run regardless of ctrld current status. This prevents a
racy behavior when reset DNS task restores DNS settings of the system,
but current running ctrld process may revert it immediately.
So changes to DNS after ctrld stopped won't be reverted by the goroutine
itself. The problem happens rarely on darwin, because networksetup
command won't propagate config to /etc/resolv.conf if there is no
changes between multiple running.
Currently, ctrld watches changes to /etc/resolv.conf file, then
reverting to the expected settings. However, if /etc/resolv.conf is a
symlink, changes made to the target file maynot be seen if it's not
under /etc directory.
To fix this, just evaluate the /etc/resolv.conf file before watching it.
