[Dnsmasq-discuss] force --local/--server protocol

Simon Kelley simon at thekelleys.org.uk
Mon Jan 7 10:10:18 GMT 2013


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 at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 




More information about the Dnsmasq-discuss mailing list