resolver: ask again over TCP when a reply offers recursion (closes #300)

dnswatcher never asks for recursion, so a reply marked recursion
available comes from a resolver on the network answering in the
server's place, as on a network that sends all DNS to one resolver.
Such a resolver answers only from its cache, or with SERVFAIL or
REFUSED, which made make check fail there.

A reply over UDP marked so is now asked again over TCP, which many such
networks leave alone, and the TCP reply is used. A reply from a root
server's address still marked so is not used, and when every root
server refuses or gives one, the error is the existing "this network
intercepts DNS queries".

Model: opus-5-5

README.md

@@ -561,6 +561,17 @@ This approach ensures:
 - Ability to detect split-horizon or inconsistent responses across authoritative
   servers.
 
+dnswatcher never asks a server for recursion, so a reply marked "recursion
+available" did not come from the server it was sent to. It came from a recursive
+resolver on the network answering in that server's place, as on a network where
+a router rule, a VPN or a DNS filter sends all DNS to one resolver. Such a query
+is sent again over TCP, which many of those networks leave alone, and the reply
+over TCP is used; when that retry fails, the reply over UDP is kept. A root
+server never offers recursion, so a reply from a root server's address that is
+still marked so after that is passed over. When every root server refuses a
+query or gives such a reply, the lookup fails with the error "this network
+intercepts DNS queries".
+
 A watched name's records are stored as its nameservers return them, CNAME
 included. When they return a CNAME and no address, the chain of every CNAME
 target they gave is followed (with a depth limit to prevent loops) to the A and