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

[Fred Douglas]

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> 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/mailman/listinfo/dnsmasq-discuss> />>/
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss />>
> >
> >
> >
> > _______________________________________________
> > Dnsmasq-discuss mailing list
> > 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
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20180409/bea51ec4/attachment.html>