[Dnsmasq-discuss] Dnsmasq does not cache a authoritative response from upstream ?

[Akash]

Hi,

Been fiddling with all the settings and still wondering why doesn't dnsmasq
cache a authoritative response from a server supplied with -S. I wish to
use dnsmasq as a caching proxy for my master DNS server in a way that
dnsmasq queries our master server for DNS records and serves them to the
net, while caching them in memory. In case the master is down, dnsmaq
should continue serving the cached records.

Pdnsd is able to do this but is outdated and doesn't support SPF records.
Any way to achieve the same with dnsmasq?

At present when I point dnsmasq to our master DNS server, it just forwards
queries as they come with no caching. If I point dnsmasq to something like
8.8.8.8, it does cache the response BUT its reply to the internet is also
non-authoritative (as returned by 8.8.8.8) which isn't what its supposed to
be. Being a proxy for our DNS server, its responses should be authoritative.

-Thanks
Akash

[Simon Kelley]

So, you're saying that an AA bit in an answer stops dnsmasq from
caching that answer? It's no-trivial for me to test that just now, but
I'm not aware of any reason why dnsmasq should behave in that way, and
A quick grep of the code shows no obvious use of the AA flag to do
_anything_ to do with caching.

Cheers,

Simon.

Post by Akash
Hi,
Been fiddling with all the settings and still wondering why doesn't
dnsmasq cache a authoritative response from a server supplied with
-S. I wish to use dnsmasq as a caching proxy for my master DNS
server in a way that dnsmasq queries our master server for DNS
records and serves them to the net, while caching them in memory.
In case the master is down, dnsmaq should continue serving the
cached records.
Pdnsd is able to do this but is outdated and doesn't support SPF
records. Any way to achieve the same with dnsmasq?
At present when I point dnsmasq to our master DNS server, it just
forwards queries as they come with no caching. If I point dnsmasq
to something like 8.8.8.8, it does cache the response BUT its reply
to the internet is also non-authoritative (as returned by 8.8.8.8)
which isn't what its supposed to be. Being a proxy for our DNS
server, its responses should be authoritative.
-Thanks Akash
_______________________________________________ Dnsmasq-discuss
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Akash]

Post by Simon Kelley
So, you're saying that an AA bit in an answer stops dnsmasq from
caching that answer? It's no-trivial for me to test that just now, but
I'm not aware of any reason why dnsmasq should behave in that way, and
A quick grep of the code shows no obvious use of the AA flag to do
_anything_ to do with caching.

Yes that is what I meant. Its easy to test. When you run this command:

***@noname:~# dnsmasq -h -R -d -q -S 8.8.8.8

and query the server running above command for yahoo.com, you see the
following output. As 8.8.8.8 is not authoritative for yahoo.com, dnsmasq
is caching the results:

dnsmasq: started, version 2.62 cachesize 150
dnsmasq: compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6
no-Lua TFTP conntrack
dnsmasq: using nameserver 8.8.8.8#53
dnsmasq: cleared cache
dnsmasq: query[A] yahoo.com from 67.222.132.211
dnsmasq: forwarded yahoo.com to 8.8.8.8
dnsmasq: reply yahoo.com is 206.190.36.45
dnsmasq: reply yahoo.com is 98.138.253.109
dnsmasq: reply yahoo.com is 98.139.183.24
dnsmasq: query[A] yahoo.com from 67.222.132.211
dnsmasq: cached yahoo.com is 98.139.183.24
dnsmasq: cached yahoo.com is 98.138.253.109
dnsmasq: cached yahoo.com is 206.190.36.45
dnsmasq: query[A] yahoo.com from 67.222.132.211
dnsmasq: cached yahoo.com is 206.190.36.45
dnsmasq: cached yahoo.com is 98.139.183.24
dnsmasq: cached yahoo.com is 98.138.253.109

Running same command but instead of 8.8.8.8 using 119.160.247.124 now
which is authoritative for yahoo.com:

***@noname:~# dnsmasq -h -R -d -q -S 119.160.247.124

when queries are sent again for yahoo.com, they are always forwarded and
not cached:

dnsmasq: started, version 2.62 cachesize 150
dnsmasq: compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6
no-Lua TFTP conntrack
dnsmasq: using nameserver 119.160.247.124#53
dnsmasq: cleared cache
dnsmasq: query[NS] yahoo.com from 67.222.132.211
dnsmasq: forwarded yahoo.com to 119.160.247.124
dnsmasq: query[A] yahoo.com from 67.222.132.211
dnsmasq: forwarded yahoo.com to 119.160.247.124
dnsmasq: reply yahoo.com is 98.139.183.24
dnsmasq: reply yahoo.com is 98.138.253.109
dnsmasq: reply yahoo.com is 206.190.36.45
dnsmasq: query[A] yahoo.com from 67.222.132.211
dnsmasq: forwarded yahoo.com to 119.160.247.124
dnsmasq: reply yahoo.com is 98.138.253.109
dnsmasq: reply yahoo.com is 206.190.36.45
dnsmasq: reply yahoo.com is 98.139.183.24
dnsmasq: query[A] yahoo.com from 67.222.132.211
dnsmasq: forwarded yahoo.com to 119.160.247.124
dnsmasq: reply yahoo.com is 98.138.253.109
dnsmasq: reply yahoo.com is 206.190.36.45
dnsmasq: reply yahoo.com is 98.139.183.24

-Akash

[Simon Kelley]

Tracing this through the code, it turns out that what's inhibiting
caching is not that the upstream server is authoritative. Rather, the
problem is that it's NOT recursive.

There's even a relevant comment in the code that explains why.

/*
Don't cache replies from non-recursive nameservers, since we may get a
reply containing a CNAME but not its target, even though the target
does exist. */


I guess that it would be possible to finnesse that to only inhibit
caching when the answer does include a CNAME.


Cheers,

Simon.

Post by Akash

Post by Simon Kelley
So, you're saying that an AA bit in an answer stops dnsmasq from
caching that answer? It's no-trivial for me to test that just
now, but I'm not aware of any reason why dnsmasq should behave in
that way, and A quick grep of the code shows no obvious use of
the AA flag to do _anything_ to do with caching.

Yes that is what I meant. Its easy to test. When you run this
and query the server running above command for yahoo.com, you see
the following output. As 8.8.8.8 is not authoritative for
dnsmasq: started, version 2.62 cachesize 150 dnsmasq: compile time
options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP
conntrack dnsmasq: using nameserver 8.8.8.8#53 dnsmasq: cleared
forwarded yahoo.com to 8.8.8.8 dnsmasq: reply yahoo.com is
reply yahoo.com is 98.139.183.24 dnsmasq: query[A] yahoo.com from
cached yahoo.com is 98.138.253.109 dnsmasq: cached yahoo.com is
206.190.36.45 dnsmasq: query[A] yahoo.com from 67.222.132.211
dnsmasq: cached yahoo.com is 206.190.36.45 dnsmasq: cached
yahoo.com is 98.139.183.24 dnsmasq: cached yahoo.com is
98.138.253.109
Running same command but instead of 8.8.8.8 using 119.160.247.124
when queries are sent again for yahoo.com, they are always
dnsmasq: started, version 2.62 cachesize 150 dnsmasq: compile time
options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP
cleared cache dnsmasq: query[NS] yahoo.com from 67.222.132.211
dnsmasq: forwarded yahoo.com to 119.160.247.124 dnsmasq: query[A]
yahoo.com from 67.222.132.211 dnsmasq: forwarded yahoo.com to
reply yahoo.com is 98.138.253.109 dnsmasq: reply yahoo.com is
206.190.36.45 dnsmasq: query[A] yahoo.com from 67.222.132.211
dnsmasq: forwarded yahoo.com to 119.160.247.124 dnsmasq: reply
yahoo.com is 98.138.253.109 dnsmasq: reply yahoo.com is
query[A] yahoo.com from 67.222.132.211 dnsmasq: forwarded yahoo.com
to 119.160.247.124 dnsmasq: reply yahoo.com is 98.138.253.109
dnsmasq: reply yahoo.com is 206.190.36.45 dnsmasq: reply yahoo.com
is 98.139.183.24
-Akash

[Carlos Carvalho]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Tracing this through the code, it turns out that what's inhibiting
caching is not that the upstream server is authoritative. Rather, the
problem is that it's NOT recursive.
There's even a relevant comment in the code that explains why.
/*
Don't cache replies from non-recursive nameservers, since we may get a
reply containing a CNAME but not its target, even though the target
does exist. */
I guess that it would be possible to finnesse that to only inhibit
caching when the answer does include a CNAME.

A non-recursive upstream is of little use. I suggest putting a warning in the
logs and leaving it as is.

[Simon Kelley]

Post by Carlos Carvalho
A non-recursive upstream is of little use. I suggest putting a
warning in the logs and leaving it as is.

There is already a warning if any upstream server is not recursive.

Simon.

Post by Carlos Carvalho
_______________________________________________ Dnsmasq-discuss
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss