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? Cheers, Simon. > >> 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 >>>lists.thekelleys.org.uk > <http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss> > />>/http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss />> > > > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasqfirstname.lastname@example.org > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > _______________________________________________ Dnsmasq-discuss mailing list Dnsmasqemail@example.com http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss