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

[James Brown]

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?

On Wed, Jul 29, 2020 at 12:16 PM James Brown <jbrown at easypost.com> wrote:

> Indeed, that's the commit that did it.
>
> I'm not sure why that change has any effect for DNAMEs, though (which are
> not being generated internally to dnsmasq)...
>
> On Wed, Jul 29, 2020 at 12:07 PM Geert Stappers <stappers at stappers.nl>
> wrote:
>
>> On Wed, Jul 29, 2020 at 11:23:17AM -0700, James Brown wrote:
>> > 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.
>>
>> $ git log b6f926fbe...b6f926fbe^1
>> commit b6f926fbefcd2471699599e44f32b8d25b87b471
>> Author: Simon Kelley <simon at thekelleys.org.uk>
>> Date:   Tue Aug 21 17:46:52 2018 +0100
>>
>>     Don't return NXDOMAIN to empty non-terminals.
>>
>>     When a record is defined locally, eg an A record for one.two.example
>> then
>>     we already know that if we forward, eg an AAAA query for
>> one.two.example,
>>     and get back NXDOMAIN, then we need to alter that to NODATA. This is
>> handled
>>     by  check_for_local_domain(). But, if we forward two.example, because
>>     one.two.example exists, then the answer to two.example should also be
>>     a NODATA.
>>
>>     For most local records this is easy, just to substring matching.
>>     for A, AAAA and CNAME records that are in the cache, it's more
>> difficult.
>>     The cache has no efficient way to find such records. The fix is to
>>     insert empty (none of F_IPV4, F_IPV6 F_CNAME set) records for each
>>     non-terminal.
>>
>>     The same considerations apply in auth mode, and the same basic
>> mechanism
>>     is used there too.
>>
>>
>> Regards
>> Geert Stappers
>> --
>> Silence is hard to parse
>>
>> _______________________________________________
>> Dnsmasq-discuss mailing list
>> Dnsmasq-discuss at lists.thekelleys.org.uk
>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>
>
>
> --
> James Brown
> Engineer
>


-- 
James Brown
Engineer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20200911/56656d46/attachment.html>