Holger Schletz wrote:
Hi,
I get occasional REFUSED responses from dnsmasq on a specific network, though
the query is actually successful. I am able to reproduce the error with
dnsmasq 2.22 on Debian "Sarge" and 2.23 on Debian "Etch" in this network.
However, i could not reproduce it with 2.23 on a different network. My Etch
home box is also OK.
The problem occurs
- with the first query after dnsmasq starts up (this would not be a serious
problem). Subsequent queries are successful.
- with queries issued by nightly cron jobs (which fail completely in
consequence - very bad!)
The network uses a dial-on-demand DSL connection, which gets triggered by the
query from the cronjobs. However, the dialup is perfomed on an external
router and should be completely transparent to the network (except for a
short delay). BIND9 never had this problem.
Moreover, in the first case the error can be reproduced even if the DSL link
is already up.
This is how i tested it:
1. restart dnsmasq
2. run "host <some.domain.name>"
3. host responds: "Host <some.domain.name> not found: 5(REFUSED)"
4. But the query log shows:
Nov 17 11:54:48 zfg15 dnsmasq[8039]: query[A] <some.domain.name> from
127.0.0.1
Nov 17 11:54:48 zfg15 dnsmasq[8039]: forwarded <some.domain.name> to
<first.dns.server>
Nov 17 11:54:48 zfg15 dnsmasq[8039]: forwarded <some.domain.name> to
<second.dns.server>
Nov 17 11:54:48 zfg15 dnsmasq[8039]: reply <some.domain.name> is
<some.ip.address>
What's going on here? What is so special about my network? And most important:
how do I fix it? :-)
Thanks,
Holger
Dnsmasq only generates REFUSED return codes itself if there are no
suitable upstream DNS servers to forward a query to, or all the attempts
to forward fail at transmission time (typically, with "No route to
host") That's clearly not what is happening here, so the REFUSED return
code must be coming from one of the upstream servers.
What is happening if this:
* This is the first query to dnsmasq, so it doesn't know which of the
upstream servers are working. In this situation, it sends the query to
all the servers, (two, in this case.) That's the first three lines of
the log.
* One of the upstream servers returns REFUSED, which gets sent back to
the original requestor, that's your problem. This is not logged by dnsmasq.
* The other upstream server returns a good anwer, which is also sent to
the orignal requestor, but too late. That's the last line in the log.
The upstream server which returns a good answer is marked as "good" and
any subsequent request are sent there, so the problem doesn't recur.
The reason why it happens like this is partly just history and inertia,
partly because I didn't want to risk the original requestor getting no
response at all, (and suffering a long timeout) when upstream servers
are returning error codes. However, this isn't the first time this has
been reported as a bug (see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=330422), and from the
next release the behaviuor will change. Now, if a query gets send to n
servers, the first n-1 error replies will be dropped, and only the last
one returned to the original requestor. That means that if some upstream
servers are erroring, but some are working, then the query will still
suceed.
I plan to release version 2.24, which has this change, fairly soon and
I'm happy to make the current development snapshot available to anyone
who wants to try it.
Holger, to fix your problem I suggest either weeding out the broken
nameserver (though experience shows that by now, it's probably working
again!), or risking the 2.24 beta.
Cheers,
Simon.
