[Dnsmasq-discuss] Temporary failure in name resolution when IPv6 is enabled

[Simon Kelley]

On 09/02/2021 04:08, Amit wrote:
> On Wed, Feb 3, 2021 at 12:16 PM Geert Stappers <stappers at stappers.nl> wrote:
>>
> 
> [snip]
> 
>>
>> My guess:
>>
>> } } Where is the `ping www.google.com` done?
>> } The ping is done at the end of the chain
>> } } Where and how is IPv6 disabled?
>> } Same machine,  magic from Network Manager
>> }
>> } Although disabling IPv6 is probably not the solution this was just an
>> } observation that disabling seems to allow queries to function again
>>
>> The dnsmasq machine has no or a broken IPv6 configuration.
>> Breaking IPv6 on the client at the end of the chain
>> results in a fallback (failback?) to IPv4.
>>
>>
>> The install of version 2.82  probably has some side effects,
>> side effects that cover or undo problems.
>>
>>
>>> If there are more details required, I can provide them.
>>
>> Feedback on the guess is  appriciated.
> 
> Following up. So about 20-30 devices in our fleet were affected, so a
> rollback to 2.82 was performed. One of our
> devs did an analysis which points to a different theory on why the
> issue is happening:
> 
> ```
> tcpdump shows dnsmasq send the query out both Ethernet and Wi-Fi, but
> only shows the reply coming back on Ethernet. ip link (output below)
> shows my Wi-Fi interface, wlp2s0, is DORMANT, which could be the
> reason we don't get the reply on Wi-Fi?
> 
> When building from git://thekelleys.org.uk/dnsmasq.git
> cfcafdd27c74dc187fe96a9cfa88b1aef53540a0 with HAVE_DBUS enabled
> in config.h (to make it work under NetworkManager), dnsmasq sees the
> reply in reply_query, but doesn't get as far as process_reply.
> 
> It seems reply_query is returning early here [1] when lookup_frec
> returns NULL? Perhaps the recently-introduced de-duplication isn't
> storing all the correct query hashes? And/or it assumes we will
> eventually get a reply on all configured interfaces?
> 
> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=src/forward.c;h=8fb03273e1744fb2c2a7606213eee7249ab02278;hb=cfcafdd27c74dc187fe96a9cfa88b1aef53540a0#l849
> 
> $ ip l
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
> mode DEFAULT group default qlen 1000
>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> 2: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc
> pfifo_fast state DOWN mode DEFAULT group default qlen 1000
>     link/ether 8c:16:45:ac:fe:88 brd ff:ff:ff:ff:ff:ff
> 3: enx70886b8e26e0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
> pfifo_fast state UP mode DEFAULT group default qlen 1000
>     link/ether 70:88:6b:8e:26:e0 brd ff:ff:ff:ff:ff:ff
> 4: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
> state UP mode DORMANT group default qlen 1000
>     link/ether 7c:2a:31:0c:53:55 brd ff:ff:ff:ff:ff:ff
> ```
> 
> Hope this gives you further clue.
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 


Thanks for your work on this. I just pushed a commit at

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=141a26f979b4bc959d8e866a295e24f8cf456920

Would it be possible to test that, and see if it sorts the problem.

mailing list thread at

http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q1/014697.html

provides some explanation.


Cheers,

Simon.