<div dir="ltr"><div class="gmail_default" style="font-family:times new roman,serif">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).</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">The setup:</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"><a href="http://local.mycompany.net">local.mycompany.net</a> is a DNAME to local-<dcname>.<a href="http://mycompany.net">mycompany.net</a>, with authoritative resolvers in each datacenter serving a different DNAME record</div><div class="gmail_default" style="font-family:times new roman,serif"><a href="http://prod.mycompany.net">prod.mycompany.net</a> is an unrelated domain</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">/etc/resolv.conf contains the line</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">search <a href="http://local.mycompany.net">local.mycompany.net</a> <a href="http://prod.mycompany.net">prod.mycompany.net</a></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">Imagine searching for the bare-word "foo", which is defined in <a href="http://prod.mycompany.net">prod.mycompany.net</a> but nowhere else.</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">Under dnsmasq 2.78, querying for the bare name "foo" using the system resolver will correctly first attempt to query for "<a href="http://foo.local.mycompany.net">foo.local.mycompany.net</a>", get back a DNAME to <a href="http://foo.local-dcname.mycompany.net">foo.local-dcname.mycompany.net</a>, then get an empty response with the NXDOMAIN code; that will fail, and glibc will then query "<a href="http://foo.prod.mycompany.net">foo.prod.mycompany.net</a>", which is the correct record.</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">Under dnsmasq 2.82, querying for the bare name "foo" using the system resolver will correctly first attempt to query for "<a href="http://foo.local.mycompany.net">foo.local.mycompany.net</a>", get back a DNAME to <a href="http://foo.local-dcname.mycompany.net">foo.local-dcname.mycompany.net</a>, 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?</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 bisected this in git and this behavioral change was introduced in commit b6f926fbefcd2471699599e44f32b8d25b87b471.</div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="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></div>