On 06/01/13 15:00, Mr Dash Four wrote: > >> It's certainly true of the code as-distributed. Making modifications to >> turn UDP-from-the-client intp TCP-to-the-server would be possible, but a >> non-trivial bit of coding. >> > OK, suppose I have the following scenario: > > My resolv.conf.dnsmasq (the file which dnsmasq uses to make dns queries) > contains 2 "real" DNS servers: 10.1.1.1 and, say, 8.8.8.8. Lets assume > that a client makes a request to dnsmasq using port udp:53. dnsmasq then > queries the 1'st server - 10.1.1.1 (I have "strict-order" active, so the > servers are tried in turn for every request) on 10.1.1.1:53 using udp. > 10.1.1.1 then responds with "response truncated" message (that is done > on purpose so that dnsmasq, hopefully, tries 10.1.1.1:53 tcp instead). > What would happen next: > > a) dnsmasq tries the next dns server in turn - 8.8.8.8 in this case; > b) dnsmasq returns an error to the client; > c) dnsmasq tries again on 10.1.1.1:53 tcp and then responds with the > answer to the client (note that the original request from the client to > dnsmasq was done using udp); > d) dnsmasq returns the answer with the "truncated response" bit set to the client, which then retries over TCP, and dnsmasq makes a TCP connection to 10.1.1.1
The net effect of d) is much the same as c), provided that client behaves in the conventional way, so It may be a winner :-) Cheers, Smion. > If the answer is not c), is there any way I could force dnsmasq to > follow the path in c) above? > > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss