Allow users to specify name-servers in input regardless of nameservers/local addresses supplied with flags

[phillip-stephens]

Closes #436

You can't connect to a non-loopback nameserver with a loopback local address, and vice-versa. Prior to this change, lots of validation/unit tests were added to ensure that if loopback/non-loopback addresses (local addresses, name servers) were mixed in the ResolverConfig, an error would be thrown. The thinking was that after validation, we could be sure we could reach any nameserver we tried with the localAddress stored.

However, this approach doesn't work for the reasonable example:
echo "google.com,1.1.1.1" | ./zdns A when /etc/resolv.conf contains only loopback addresses

Since in the absence of user-supplied --name-servers, we use /etc/resolv.conf to fill them in, the above would fail since the Resolver would have a loopback local address, but then we'd attempt to query an internet-routable IP.

The solution I settled on was to stop checking for this loopback mismatch and just get local addresses/sockets on-demand. Users are free to mix and match as they like. For example, the following works:

$ echo "google.com,1.1.1.1" | ./zdns A --name-servers="127.0.0.53" --verbosity=5
INFO[0000] using local addresses: []
INFO[0000] for non-iterative lookups, using external nameservers: 127.0.0.53:53
INFO[0000] for iterative lookups, using nameservers: 127.0.0.53:53
...
INFO[0000] none of the user-supplied local addresses could connect to name server 1.1.1.1:53, using local address 171.67.71.209
...
{"name":"google.com","results":{"A":{"data":{"additionals":[{"flags":"","type":"EDNS0","udpsize":1232,"version":0}],"answers":[{"answer":"142.250.189.238","class":"IN","name":"google.com","ttl":268,"type":"A"}],"protocol":"udp","resolver":"1.1.1.1:53"},"duration":0.004254892,"status":"NOERROR","timestamp":"2024-09-05T19:42:58Z"}}}

And you can even mix and match loopback and non-loopback too

$ echo "google.com\nyahoo.com" | ./zdns A --name-servers="127.0.0.53,1.1.1.1"

{"name":"yahoo.com","results":{"A":{"data":{"additionals":[{"flags":"","type":"EDNS0","udpsize":65494,"version":0}],"answers":[{"answer":"98.137.11.163","class":"IN","name":"yahoo.com","ttl":1228,"type":"A"},{"answer":"74.6.231.20","class":"IN","name":"yahoo.com","ttl":1228,"type":"A"},{"answer":"74.6.143.25","class":"IN","name":"yahoo.com","ttl":1228,"type":"A"},{"answer":"74.6.231.21","class":"IN","name":"yahoo.com","ttl":1228,"type":"A"},{"answer":"74.6.143.26","class":"IN","name":"yahoo.com","ttl":1228,"type":"A"},{"answer":"98.137.11.164","class":"IN","name":"yahoo.com","ttl":1228,"type":"A"}],"protocol":"udp","resolver":"127.0.0.53:53"},"duration":0.000919296,"status":"NOERROR","timestamp":"2024-09-05T19:30:43Z"}}}
{"name":"google.com","results":{"A":{"data":{"additionals":[{"flags":"","type":"EDNS0","udpsize":1232,"version":0}],"answers":[{"answer":"142.251.32.46","class":"IN","name":"google.com","ttl":171,"type":"A"}],"protocol":"udp","resolver":"1.1.1.1:53"},"duration":0.003497767,"status":"NOERROR","timestamp":"2024-09-05T19:30:43Z"}}}

Notice we're able to use both a loopback and non-loopback nameservers just fine. This is accomplished by creating connectionInfo objects on-demand rather than at Resolver initiation. If a user never needs a loopback UDP socket, one is not created. But once it's created, it will be saved so we don't have to re-open the socket.

Reprecussions

One outcome/downside of this approach is we no longer validate if a name-server is reachable at Resolver startup` from the current local addresses. We just try it and see if it works. So the following don't error until the lookup is attempted.

In the below example, this host lacks IPv6 connectivity. We don't error at Resolver init, but in the query itself.

~/zdns on  phillip/436-name-server-loopback-bug! ⌚ 19:30:43
$ echo "google.com,2606:4700:4700::1111" | ./zdns A
{"name":"google.com","results":{"A":{"data":{"protocol":"","resolver":""},"duration":0.001083508,"error":"could not get a connection info to query nameserver [2606:4700:4700::1111]:53: unable to find default IP address to open socket: dial udp [2606:4700:4700::1111]:53: connect: network is unreachable","status":"ERROR","timestamp":"2024-09-05T19:33:30Z"}}}


~/zdns on  phillip/436-name-server-loopback-bug! ⌚ 19:33:51
$ echo "google.com" | ./zdns A --name-servers=2606:4700:4700::1111
{"name":"google.com","results":{"A":{"data":{"protocol":"","resolver":""},"duration":0.000414397,"error":"could not get a connection info to query nameserver [2606:4700:4700::1111]:53: unable to find default IP address to open socket: dial udp [2606:4700:4700::1111]:53: connect: network is unreachable","status":"ERROR","timestamp":"2024-09-05T19:33:56Z"}}}

Testing

I've run the test suite on GH, on a host without IPv6 connectivity and with, and with loopback NS's in /etc/resolv.conf and without.

Spot-checked a couple modules while varying --4/--6, --iterative, /etc/resolv.conf with + without loopback.

Performance

One area of concern is around the creation of sockets on-demand. If it's working as I intended it shouldn't matter, each resolver creates a socket of whatever type just once. Testing shows no noticeable regression compared to main.
When running make benchmark
main - 36.15 s.
branch - 31.93 s.

Note to Reviewers

Check out getConnectionInfo here, it has the "on-demand" socket creation