[Dnsmasq-discuss] query-port option causes DNS error code 5(REFUSED)

Tue Apr 10 21:49:40 BST 2018

I still can't reproduce this, but tracing through the code, I found two
different problems which might have a bearing. I just pushed the fixes
to these to git, and tagged 2.80test1

The fixes (top two at
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=summary) should apply
to 2.76, if that's the easiest way to test, otherwise build from the
2.80test1 tarball.

I'd be very interested to know if they help.

Cheers,

Simon.

On 09/04/18 17:01, Fred Douglas wrote:
> Ok, got the output of log-queries=extra. It is indeed the bind at
> program start:
> 
> reading /run/dnsmasq/resolv.conf
> ignoring nameserver 8.8.8.8 - cannot make/bind socket: Address already
> in use
> ignoring nameserver 8.8.4.4 - cannot make/bind socket: Address already
> in use
> 
> That's query-port!=0. With =0 or unset, you get
> reading /run/dnsmasq/resolv.conf
> using nameserver 8.8.8.8#53
> using nameserver 8.8.4.4#53
> 
> "ignoring nameserver - cannot make/bind" is printed when the
> allocate_sfd function fails to allocate a socket set. allocate_sfd
> returns null early when !daemon->osport, which I guess is why
> query-port=0 sees the same good behavior as query-port unset. So, I
> would guess the problem is in allocate_sfd.
> 
> dnsmasq does not exit after that error happens, and I assume sees itself
> as not having access to any resolvers, causing the REFUSEDs.
> 
> On Sat, Apr 7, 2018 at 6:45 PM Simon Kelley <simon at thekelleys.org.uk
> <mailto:simon at thekelleys.org.uk>> wrote:
> 
>     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>
>     > <http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss>
>     />>/http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss />>
>     >
>     >
>     >
>     > _______________________________________________
>     > Dnsmasq-discuss mailing list
>     > Dnsmasq-discuss at lists.thekelleys.org.uk
>     <mailto:Dnsmasq-discuss at lists.thekelleys.org.uk>
>     > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>     >
> 
> 
>     _______________________________________________
>     Dnsmasq-discuss mailing list
>     Dnsmasq-discuss at lists.thekelleys.org.uk
>     <mailto:Dnsmasq-discuss at lists.thekelleys.org.uk>
>     http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 