<div dir="ltr"><div class="gmail_default" style="font-family:times new roman,serif">That is fantastic, Dominick!</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 testing now, but in preliminary testing, this patch appears to fix the DNAME issue for me.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Sep 13, 2020 at 10:03 PM Dominick C. Pastore <<a href="mailto:dominickpastore@dcpx.org">dominickpastore@dcpx.org</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">This caught my eye because it's similar to a bug I noticed in 2.80. See (and ignore the first half of the message about CNAMEs; that was an unrelated issue):<br>
<a href="http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2019q4/013483.html" rel="noreferrer" target="_blank">http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2019q4/013483.html</a><br>
<br>
It sounds like that was essentially the same issue, but without DNAMEs. It turned out it had already been fixed but the fix hadn't been released yet at the time:<br>
<a href="http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=162e5e0062ce923c494cc64282f293f0ed64fc10" rel="noreferrer" target="_blank">http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=162e5e0062ce923c494cc64282f293f0ed64fc10</a><br>
<br>
That fix was eventually in 2.81, but it looks like it misses the cases where the NXDOMAIN reply contains a CNAME or DNAME.<br>
<br>
I've attached a patch that hopefully fixes this, but word of warning: I've only been able to verify that it fixes the CNAME case, not the DNAME case. I don't think it breaks the intended functionality from b6f926f, but I will admit, I don't feel familiar enough with the inner workings of Dnsmasq to verify that myself.<br>
<br>
Regards,<br>
Dominick<br>
<br>
On Fri, Sep 11, 2020, at 7:53 PM, James Brown wrote:<br>
> Just wanted to bump this thread since this is still kind of a show-stopper for anyone that uses DNAMEs heavily. Any thoughts on how to fix?<br>
> <br>
> On Wed, Jul 29, 2020 at 12:16 PM James Brown <<a href="mailto:jbrown@easypost.com" target="_blank">jbrown@easypost.com</a>> wrote:<br>
>> Indeed, that's the commit that did it.<br>
>> <br>
>> I'm not sure why that change has any effect for DNAMEs, though (which are not being generated internally to dnsmasq)...<br>
>> <br>
>> On Wed, Jul 29, 2020 at 12:07 PM Geert Stappers <<a href="mailto:stappers@stappers.nl" target="_blank">stappers@stappers.nl</a>> wrote:<br>
>>> 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>
>> <br>
>> <br>
>> -- <br>
>> James Brown<br>
>> Engineer<br>
> <br>
> <br>
> -- <br>
> James Brown<br>
> Engineer<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>
> _______________________________________________<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>