[Dnsmasq-discuss] Incorrect response for DNAME'd records in dnsmasq 2.80+

James Brown jbrown at easypost.com
Wed Jul 29 19:23:17 BST 2020


I'm upgrading some test nodes in my employer's cluster from 2.78 to 2.82
and handling of DNAMEs in the new version seems different (and wrong).

The setup:

local.mycompany.net is a DNAME to local-<dcname>.mycompany.net, with
authoritative resolvers in each datacenter serving a different DNAME record
prod.mycompany.net is an unrelated domain

/etc/resolv.conf contains the line

search local.mycompany.net prod.mycompany.net

Imagine searching for the bare-word "foo", which is defined in
prod.mycompany.net but nowhere else.

Under dnsmasq 2.78, querying for the bare name "foo" using the system
resolver will correctly first attempt to query for "foo.local.mycompany.net",
get back a DNAME to foo.local-dcname.mycompany.net, then get an empty
response with the NXDOMAIN code; that will fail, and glibc will then query "
foo.prod.mycompany.net", which is the correct record.

Under dnsmasq 2.82, querying for the bare name "foo" using the system
resolver will correctly first attempt to query for "foo.local.mycompany.net",
get back a DNAME to foo.local-dcname.mycompany.net, gets back an empty
response with the NOERROR code. This causes the system resolver to stop
trying new search domains. This behavior seems to be dependent on caching;
the first request correctly returns NXDOMAIN but subsequent requests return
NOERROR. There's actually something more confusing to it than this; if the
first request is for A, then subsequent AAAA requests return NOERROR but
subsequent A requests return NXDOMAIN. Some kind of weird cache poisoning
between record types?

I bisected this in git and this behavioral change was introduced in
commit b6f926fbefcd2471699599e44f32b8d25b87b471.
-- 
James Brown
Engineer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20200729/bd94aec3/attachment.html>


More information about the Dnsmasq-discuss mailing list