On 07/04/18 14:47, Fred Douglas wrote:
> Thanks for the explanation of REFUSED's meaning! I bet it's that the UDP 
> sends are outright failing; I suspect that something is going wrong with the 
> bind at program start. I'll take a look at the logs and report back on Monday.

When using port-randomisation, dnsmasq has to create and bind sockets
for each upstream interaction. Once you nail the port number using
query-port, it doesn't need to do that and will create and  bind a
single socket at startup which it uses thereafter. A failure of that
process should cause a fatal error and abort at start-up.

> For now, though, I can pretty confidently say I'm not accidentally blocking 
> the packets. All of my iptables rules are either for TCP, not for the 
> interface that goes to the internet (eth0), or are matching UDP ports that 
> these experiments aren't using.
> I used query-port=0, observed the unchanging source port of the (successful) 
> resolutions, restarted dnsmasq with query-port=that_port - and got the error. 
> Even if I was getting unlucky, and that attempt and my other attempts in the 
> ephemeral range were failing because the port happened to be in use when 
> dnsmasq tried to bind it, that shouldn't be the case for the lower numbered 
> ports I was trying. (I'm not making any other changes in between these 
> experiments, either, just changing query-port in dnsmasq.conf to commented, 
> 0, or non-0, and then `service dnsmasq restart`.)

running dnsmasq under strace (run dnsmasq with the -d option) would be
useful, to see exactly what system calls it's making.

You have used --log-queries to make sure this REFUSED return code isn't
coming from usptream, haven't you?



>> Just tried a simple test, and didn't see the same behaviour.
>> Use log-queries to check that the process is really failing in dnsmasq,
>> ie the problem is not REFUSED answers from upstream. A REFUSED answer
>> from dnsmasq only occurs if either there are no possible upstream server
>> to forward to, or if attempts to send UDP packets to all upstream
>> servers fail immediately, at kernel level. You're not accidentally
>> blocking packets from you special port, are you?
>> Cheers,
>> Simon.
>>On 06/04/18 21:08, Fred Douglas wrote:
>>>/I would like dnsmasq to stick to a single source port for its requests, 
>>>/>>/so that I can differentiate them from other DNS requests going out the 
>>>/>>/same interface. />>//>>/The query-port option works as advertised when 
>>>set to 0 (i.e. picks a />>/single random port and sticks to it). Any other 
>>>value, however - below />>/1024, a little above 1024, way up in the 50000s - 
>>>causes dnsmasq to />>/respond to all queries with a "REFUSED" (DNS error 
>>>code 5). />>//>>/My dnsmasq.conf is empty other than query-port, and I 
>>>haven't made any />>/other weird changes to the system that should be 
>>>relevant. This is />>/Debian's current [2.76+whatever security patches] 
>>>version of dnsmasq. />>//>>/Does anyone else get this behavior? />>//>>/Fred 
>>>/>>/Dnsmasq-discuss mailing list />>/Dnsmasq-discuss at 
> <http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss> 
> />>/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

Dnsmasq-discuss mailing list

Reply via email to