Discussion:
[Dnsmasq-discuss] trying the next DNS server if answer is "refused"?
Richard Hansen
2015-12-02 05:44:40 UTC
Permalink
Hi all,

Is it possible to configure dnsmasq to try the next server in
/etc/resolv.conf if it gets a "refused" answer?

I have an unusual setup where some of the servers in /etc/resolv.conf
are non-recursive servers that only answer queries for a particular
subdomain (for which they are authoritative). If dnsmasq forwards a
query to one of these servers, and the query is for a name outside the
subdomain, the server will reply with "refused" (with the "recursion
available" flag cleared). dnsmasq forwards this reply to the original
client without trying any of the other servers in /etc/resolv.conf.

The system's resolver's behavior is to try the next server in
/etc/resolv.conf if it gets a "refused" answer. I would like dnsmasq to
do the same.

I would use the --server option to avoid this problem by filtering the
queries sent to the non-recursive servers, except:

* I can't figure out how to tell dnsmasq to use DNS server
203.0.113.52 for queries to *.foo.example.com and 198.51.100.22 for
everything else. The man page says an empty domain ("//") means
unqualified queries, not the root domain.

* dnsmasq is started by libvirt, and as far as I can tell libvirt
doesn't provide a way to override dnsmasq's command-line arguments
and/or config file. :(

Thanks,
Richard
Richard Hansen
2015-12-02 06:02:12 UTC
Permalink
Post by Richard Hansen
Is it possible to configure dnsmasq to try the next server in
/etc/resolv.conf if it gets a "refused" answer?
I just noticed these bits from CHANGELOG.archive:

version 2.21
Improve handling of SERVFAIL and REFUSED errors. Receiving
these now initiates search for a new good server, and a
server which returns them is not a candidate as a good
server.

version 2.24
Tweak behaviour on receipt of REFUSED or SERVFAIL rcodes,
now the query gets retried on all servers before returning
the error to the source of the query.

This is the exact behavior I want, except for the part where REFUSED
causes the server to be "not a candidate as a good server." (Just
because the server is a bad choice for that particular query doesn't
mean it's bad for all queries.)

I'm using dnsmasq version 2.68, so I'll run some more tests to see if I
can figure out why things aren't behaving as expected. (tcpdump shows
it giving up immediately when it gets a REFUSED.) Could the behavior
I'm seeing be caused by --strict-order?

Thanks,
Richard
Eric Hiller
2015-12-06 00:15:44 UTC
Permalink
Richard,

I believe I have the exact same requirements if I am reading this
correctly, and I have not found a solution either. If you do please let me
know!

This was my post a while back
//// start ////

I have a setup currently where I have a VPN that is transient, but when it
is connected, I need to query the on-net DNS server for `domain.tld` to hit
`secure(s).domain.tld` but when the VPN is disconnected I need to continue
to query the public DNS servers for the normal `public.domain.tld` records
as per normal.

I've tried just leaving, hoping that after timeouts to the more specific
server=/domain.tld/q.w.e.r
dnsmasq would fall back to the more generally defined
server=a.b.c.d
But that wasn't the case

I also tried using
strict-order

But that did not do it either;

I realize I could set:
strict-order
server=/domain.tld/q.w.e.r
server=/domain.tld/a.b.c.d

But was just wondering if there was a more elegant way?

//// end ////

And I actually ended up trying the strict route ordering, and that did not
work either, If the domain.tld servers fail the entire domain.tld becomes
unresolvable; that is the default nameserver is not tried.

Wondering if you or anyone else has a solution here?

In the meantime what I did was add a static host entry for the
vpn.domain.tld on my vpn endpoint so that at least it could resolve that
host. Not ideal, but ok for now in my situation.

-Eric
Post by Richard Hansen
Post by Richard Hansen
Is it possible to configure dnsmasq to try the next server in
/etc/resolv.conf if it gets a "refused" answer?
version 2.21
Improve handling of SERVFAIL and REFUSED errors. Receiving
these now initiates search for a new good server, and a
server which returns them is not a candidate as a good
server.
version 2.24
Tweak behaviour on receipt of REFUSED or SERVFAIL rcodes,
now the query gets retried on all servers before returning
the error to the source of the query.
This is the exact behavior I want, except for the part where REFUSED
causes the server to be "not a candidate as a good server." (Just
because the server is a bad choice for that particular query doesn't
mean it's bad for all queries.)
I'm using dnsmasq version 2.68, so I'll run some more tests to see if I
can figure out why things aren't behaving as expected. (tcpdump shows
it giving up immediately when it gets a REFUSED.) Could the behavior
I'm seeing be caused by --strict-order?
Thanks,
Richard
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Continue reading on narkive:
Loading...