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

[Amit]

On Wed, Feb 17, 2021 at 5:30 PM Amit <amit.uttam at gmail.com> wrote:
>
> On Wed, Feb 17, 2021 at 4:36 PM Simon Kelley <simon at thekelleys.org.uk> wrote:
> >
> > 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.
> > >
> > > _______________________________________________
> >
> > 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.
>
> Thanks for the patch. Tried it but unfortunately the same issue
> persists when an IPV6 DNS server is present and configured.
>
> Let me know if you need more logs or other tests I can run.

The latest patch:
https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=305cb79c5754d5554729b18a2c06fe7ce699687a
seems to have resolved the issue for me.

I'll recommend we try out the fix to our fleet.

Thank you.