[24.0 backport] libnetwork: just forward the external DNS response

[thaJeztah]

• backport of libnetwork: just forward the external DNS response #45565
• Fixes In K8s + dind, DNS forwards SERVFAIL instead of NXDOMAIN #45553
• Fixes Something is wrong with networking, perhaps DNS in 24.0, unexplained delays #45555

Changes to the DNS resolver in #44664 fixed some bugs, including load-bearing bugs which masked other bugs. One bug not fixed by the aforementioned PR is that the resolver handles non-authoritative NXDOMAIN responses by failing over to the next external DNS server in the list. That behaviour does not make sense as authoritative responses only come from the authoritative name servers for a domain, and most of the time none of the servers in the list will be authoritative. What would make sense for handling a non-authoritative NXDOMAIN is to recursively resolve up to the authoritative name servers to get an authoritative answer to cache. But our DNS resolver is a stub resolver, not a recursive resolver, so there is no good reason for it to treat any NXDOMAIN response differently from a NOERROR response. (If you depended on this fail-over behaviour to successfully resolve domains because the first external DNS server in your list returns NXDOMAIN for the public internet, that DNS server is broken and needs to be fixed. If we can make a split-horizon DNS resolver which resolves public domain names by forwarding, so can you.)

Commit 9cf8c4f fixed a bug in the fail-over behaviour by replying SERVFAIL if none of the external name servers provided a successful response instead of falling through to forward the last non-successful response received. Unfortunately that was a load-bearing bug which masked the aforementioned NXDOMAIN issue.

- What I did
Our resolver is just a forwarder for external DNS—a stub resolver—so it should act like it. Unless it's a server failure or refusal, take the response at face value and forward it along to the client. RFC 8020 is only applicable to caching recursive name servers and our resolver is neither caching nor recursive.

- How I did it
Deleted code which had no business existing in a DNS stub resolver.

- How to verify it

$ docker network create mybridge
$ docker run --rm -t --network mybridge --dns 8.8.8.8 alpine sh -c 'apk add -qU bind-tools && dig nxdomain.test'

v24.0.0:

; <<>> DiG 9.18.14 <<>> nxdomain.test
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 45178
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;nxdomain.test.			IN	A

;; Query time: 4 msec
;; SERVER: 127.0.0.11#53(127.0.0.11) (UDP)
;; WHEN: Thu May 18 14:12:18 UTC 2023
;; MSG SIZE  rcvd: 31

This PR:

; <<>> DiG 9.18.14 <<>> nxdomain.test
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 34098
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;nxdomain.test.			IN	A

;; AUTHORITY SECTION:
.			86398	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. 2023050900 1800 900 604800 86400

;; Query time: 6 msec
;; SERVER: 127.0.0.11#53(127.0.0.11) (UDP)
;; WHEN: Thu May 18 14:15:05 UTC 2023
;; MSG SIZE  rcvd: 117

- Description for the changelog

• Fixed an issue where DNS query NXDOMAIN replies from external servers were forwarded to the client as SERVFAIL

- A picture of a cute animal (not mandatory but encouraged)