<div dir="ltr"><div class="gmail_default" style="font-family:times new roman,serif">Indeed, that's the commit that did it.</div><div class="gmail_default" style="font-family:times new roman,serif"><br></div><div class="gmail_default" style="font-family:times new roman,serif">I'm not sure why that change has any effect for DNAMEs, though (which are not being generated internally to dnsmasq)...</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 29, 2020 at 12:07 PM Geert Stappers <<a href="mailto:stappers@stappers.nl">stappers@stappers.nl</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Jul 29, 2020 at 11:23:17AM -0700, James Brown wrote:<br>
> I'm upgrading some test nodes in my employer's cluster from 2.78 to 2.82<br>
> and handling of DNAMEs in the new version seems different (and wrong).<br>
> <br>
> The setup:<br>
> <br>
> <a href="http://local.mycompany.net" rel="noreferrer" target="_blank">local.mycompany.net</a> is a DNAME to local-<dcname>.<a href="http://mycompany.net" rel="noreferrer" target="_blank">mycompany.net</a>, with<br>
> authoritative resolvers in each datacenter serving a different DNAME record<br>
> <a href="http://prod.mycompany.net" rel="noreferrer" target="_blank">prod.mycompany.net</a> is an unrelated domain<br>
> <br>
> /etc/resolv.conf contains the line<br>
> <br>
> search <a href="http://local.mycompany.net" rel="noreferrer" target="_blank">local.mycompany.net</a> <a href="http://prod.mycompany.net" rel="noreferrer" target="_blank">prod.mycompany.net</a><br>
> <br>
> Imagine searching for the bare-word "foo", which is defined in<br>
> <a href="http://prod.mycompany.net" rel="noreferrer" target="_blank">prod.mycompany.net</a> but nowhere else.<br>
> <br>
> Under dnsmasq 2.78, querying for the bare name "foo" using the system<br>
> resolver will correctly first attempt to query for "<a href="http://foo.local.mycompany.net" rel="noreferrer" target="_blank">foo.local.mycompany.net</a>",<br>
> get back a DNAME to <a href="http://foo.local-dcname.mycompany.net" rel="noreferrer" target="_blank">foo.local-dcname.mycompany.net</a>, then get an empty<br>
> response with the NXDOMAIN code; that will fail, and glibc will then query "<br>
> <a href="http://foo.prod.mycompany.net" rel="noreferrer" target="_blank">foo.prod.mycompany.net</a>", which is the correct record.<br>
> <br>
> Under dnsmasq 2.82, querying for the bare name "foo" using the system<br>
> resolver will correctly first attempt to query for "<a href="http://foo.local.mycompany.net" rel="noreferrer" target="_blank">foo.local.mycompany.net</a>",<br>
> get back a DNAME to <a href="http://foo.local-dcname.mycompany.net" rel="noreferrer" target="_blank">foo.local-dcname.mycompany.net</a>, gets back an empty<br>
> response with the NOERROR code. This causes the system resolver to stop<br>
> trying new search domains. This behavior seems to be dependent on caching;<br>
> the first request correctly returns NXDOMAIN but subsequent requests return<br>
> NOERROR. There's actually something more confusing to it than this; if the<br>
> first request is for A, then subsequent AAAA requests return NOERROR but<br>
> subsequent A requests return NXDOMAIN. Some kind of weird cache poisoning<br>
> between record types?<br>
> <br>
> I bisected this in git and this behavioral change was introduced in<br>
> commit b6f926fbefcd2471699599e44f32b8d25b87b471.<br>
<br>
$ git log b6f926fbe...b6f926fbe^1<br>
commit b6f926fbefcd2471699599e44f32b8d25b87b471<br>
Author: Simon Kelley <<a href="mailto:simon@thekelleys.org.uk" target="_blank">simon@thekelleys.org.uk</a>><br>
Date: Tue Aug 21 17:46:52 2018 +0100<br>
<br>
Don't return NXDOMAIN to empty non-terminals.<br>
<br>
When a record is defined locally, eg an A record for one.two.example then<br>
we already know that if we forward, eg an AAAA query for one.two.example,<br>
and get back NXDOMAIN, then we need to alter that to NODATA. This is handled<br>
by check_for_local_domain(). But, if we forward two.example, because<br>
one.two.example exists, then the answer to two.example should also be<br>
a NODATA.<br>
<br>
For most local records this is easy, just to substring matching.<br>
for A, AAAA and CNAME records that are in the cache, it's more difficult.<br>
The cache has no efficient way to find such records. The fix is to<br>
insert empty (none of F_IPV4, F_IPV6 F_CNAME set) records for each<br>
non-terminal.<br>
<br>
The same considerations apply in auth mode, and the same basic mechanism<br>
is used there too.<br>
<br>
<br>
Regards<br>
Geert Stappers<br>
-- <br>
Silence is hard to parse<br>
<br>
_______________________________________________<br>
Dnsmasq-discuss mailing list<br>
<a href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk" target="_blank">Dnsmasq-discuss@lists.thekelleys.org.uk</a><br>
<a href="http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss" rel="noreferrer" target="_blank">http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><span style="font-family:"times new roman",serif">James Brown</span><div><span style="font-family:"times new roman",serif">Engineer</span></div></div></div></div></div>