Subject: bug#58520: Persistent failure to DNS-lookup hostname

From: Visuwesh <[email-masked]>
Date: Sat, 04 Nov 2023 00:16:52 +0530

[வெள்ளி நவம்பர் 03, 2023] Stefan Monnier wrote:

>> FWIW, I experience this sometimes when I change from an Ethernet
>> connection to a WiFi connection (I cannot remember if the inverse is
>> true too).  This change to another connection once I wake my laptop from
>> hibernation.  During this change, /etc/resolv.conf definitely changes
>> because I use resolvconf to set connection-specific and
>> interface-specific DNS nameserver setting.  [ I need to set the DNS
>> server manually for the Ethernet connection but I can use dhcp for the
>> Wifi one.  ]
>
> Sounds like the exact same problem, indeed.
> If you ever come up with some further hints about what it needs to
> reproduce it (or even better: an actual recipe), I'd be happy to hear them.

Unfortunately, I only experience this intermittently.  This is the first
time I see this issue in months (but could also be because I haven't
been bringing my laptop as often to the WiFi-only building).

> Currently it seems that hibernate/suspend might be related, tho
> I suspect it's a red herring.

You may be right about that but I cannot exactly prove it because
walking while carrying my laptop with its lid open for 2 km is not going
to be fun.  :-)
I don't want to turn off suspend-on-lid-close and potentially overheat
my laptop either.

>> The other super weird part is that eww _can_ open debbugs.gnu.org just
>> fine, but if I use Gnus to fetch the bug report it doesn't...
>
> Hmm... any chance that you're using some package which makes `eww` use
> some external tool instead of `url.el`?

No, I don't use any nor do I know of such a package.  Actually, an even
stranger thing happened with eww that I neglected to mention: some
requests to search.brave.com clearly failed with the lookup failure but
eww made enough requests to render the webpage from Brave search just
fine.  This is what I see in the *Messages* buffer

     1 Contacting host: www.doi2bib.org:443
     2 Error: (error www.doi2bib.org/443 Temporary failure in name resolution)
     3 Contacting host: search.brave.com:443
     4 search.brave.com/0 Temporary failure in name resolution
     5 cdn.search.brave.com/0 Temporary failure in name resolution
     6 cdn.search.brave.com/0 Temporary failure in name resolution
     7 Contacting host: www.doi2bib.org:443
     8 Error: (error www.doi2bib.org/443 Temporary failure in name resolution)
     9 Contacting host: www.doi2bib.org:443
    10 open-network-stream: www.doi2bib.org/443 Temporary failure in name resolution
    11 Contacting host: search.brave.com:443
    12 cdn.search.brave.com/0 Temporary failure in name resolution
    13 Contacting host: www.doi2bib.org:443
    14 open-network-stream: www.doi2bib.org/443 Temporary failure in name resolution
    15 Contacting host: doi2bib.org:80

Line nos. 1 and 2 are from url.el requests.  3--6 and 11--12 is from
connection to search.brave.com from eww for an internet search.
I cannot say with confidence but 15 should be when I opened doi2bib.org
in eww once it became obvious that url.el will keep on failing...

>> I am not sure how long this failing Emacs instance will fail but if it
>> helps, I can try to do some debugging on my end as well.
>
> AFAICT once it happens it doesn't fix itself: the DNS server used by
> your Emacs process is "stuck" and doesn't pay attention to
> /etc/resolv.conf, so it "gets fixed" if you happen to be connected on
> a network where the DNS server that Emacs tries to contact is available.

Your analysis seems to be correct.  Now that I'm back on the Ethernet
connection, Emacs can happily make all the network requests its heart
desires.  

But I seem to recall a similar failure back when you initially spoke of
this issue (even before opening this bug report) and I think I solved it
by opening the failing webpage in eww, which is why I tried this again
today for doi2bib.org.  It seemed to have worked once i.e., eww opened
the website but failed again when I tried a second time.
So for all I know, it could have been sheer luck.

>> I tried to use tcpdump but the manpage seems to suggest that there is
>> no way to filter network requests made by a particular process, and
>> I see too many junk requests to isolate the traffic that matters.
>
> I used a filter which only kept packets sent to a DNS port (port 53) and
> that was sufficient to see requests to the "wrong" DNS server (e.g. the
> one you use when your machine is connected via Ethernet, even though
> the machine is currently connected via wifi) and to confirm that those
> requests are correlated with the operation I perform in Emacs.

That sounds a bit too involved for me currently.  If I get more time
(this might not happen until January) and if the bug shows its face
itself again, I will try to look into this in greater detail to help
squash this bug.