Reduce DNS timeout to prevent HTTP timeout of Deezer connect ( and probably other slowness problems)

[scred47]

The Deezer connect fails to initiate if AAAA lookup times out .

by default DNS Timeout is 5 seconds.

https://manpages.org/resolvconf/5

timeout:n
Sets the amount of time the resolver will wait for a response from a remote name server before retrying the query via a different name server. Measured in seconds, the default is RES_TIMEOUT (currently 5, see <resolv.h>). The value for this option is silently capped to 30.

The problem is that the DNS query sends both A and AAAA lookups and even when it receives the A record , it still waits for the AAAA record.

This behavior I described here.

raspberrypi/bookworm-feedback#362

The problem is that it causes the deezer connect client to fail as it goes above the Timeouts allowed by the Deezer API of 5 seconds.

Reported here.

roderickvd/pleezer#52

So there are 2 workarounds I tested

1. is to set a shorter DNS timeout then the 2 seconds HTTP read timeout that deezer connect uses by adding the following to /etc/resolv.conf

options timeout:1

When this is done when 1 second is met we don' t wait for the AAAA record anymore when timeout is reached and just use the received A record to connect.

2. add the option no-aaaa to resolv.conf to prevent completely AAAA lookup.

To make this change persistent I installed resolvconf and added one of the options to /etc/resolvconf/resolv.conf.d/head

[moodeaudio]

Reading through the links it seems that quad-a lookup is legit since ipv6 is generally enabled in virtually all OS's, and the slow DNS lookups in your scenario may be due to a particular network or Pi config.

In any case it's not too much trouble to add an option to the Deezer Config screen that can be used to patch /etc/resolv.conf during moode startup. This can work providing resolv.conf is queried dynamically every time a DNS query is made. If its some sort of static, one-time config during early boot then this approach won't work.

Example screen shots

[scred47]

Hi,

thank you for checking this.

I like the idea of putting that in the Deezer connect configuration page to make that a user educated decision to make.

That said a timeout of 2 seconds would be already too long because that currently is the HTTP timeout of Pleezer.

My workaround was 1 second.

[moodeaudio]

Ok, I'll make that change.

[moodeaudio]

Does resolv.conf get read each time a DNS query is made?

If it only gets read once for example during Linux boot or when first DNS query is made then my approach of patching resolv.conf during moode startup won't work.

[scred47]

Hi,

the moment you save a change to resolv.conf it's effective without having to reload anything. The changes are cleared at reboot so I guess this would work if pleezer starts after the resolv.conf is "reset" during boot.

You may want to hold off any changes because by tweeking timeouts it seems the last development version of pleezer I just tested isn't affected anymore.

I need to test it for the raspberry zero 2w where I initially saw this problem occur to see if it os fixed there as well in case there's an environment factor that doesn't affect the device I tested on.

I will confirm here shortly.

[roderickvd]

Reading through the links it seems that quad-a lookup is legit since ipv6 is generally enabled in virtually all OS's, and the slow DNS lookups in your scenario may be due to a particular network or Pi config.

Yes, something wonky must be going on with @scred47's upstream DNS. Obviously there's many other users who are using pleezer successfully so never ran into this issue.

But, if we can work around it easily, then I'm all for robustness.

That said a timeout of 2 seconds would be already too long because that currently is the HTTP timeout of Pleezer.

In main the timeout is set to 10s.

You may want to hold off any changes because by tweeking timeouts it seems the last development version of pleezer I just tested isn't affected anymore.

I need to test it for the raspberry zero 2w where I initially saw this problem occur to see if it os fixed there as well in case there's an environment factor that doesn't affect the device I tested on.

Yeah... I guess if we can keep @moodeaudio from adding that rather technical option with the renderer config, then that'd be good.

I will confirm here shortly.

👍

[moodeaudio]

I like that :-)

[scred47]

Hi ,

Unfortunately the behavior is the same on the RPI zero 2W.

Reading through the links it seems that quad-a lookup is legit since ipv6 is generally enabled in virtually all OS's, and the slow DNS lookups in your scenario may be due to a particular network or Pi config.

I can agree for the slow response or no response, but not for the fact the OS doesn't just go on with initiating connection once it received A record and also resends the A lookup for some reason. That part seems broken to me client side not network side. BUT

I tested a bit further this time with a raspberry Pi 2B ( instead of zero 2W where I noticed this problem ) using :
-the bultin ethernet
-on the same subnet,
-with the same DNS server
-same DHCP server
-and on the same OS ( Debian 12 based Raspberry OS)

and to my surprise it behaves differently. The AAAA lookup still happens , the AAAA response is never received BUT pleezer or ping do not wait for the DNS to timeout they just initiate TCP or ping as soon as they receive the response of A record. So it is all working as expected on the RPI 2B

So to isolate further the scope of what I see it seems to only happen when using the bulitin wifi of the raspberry pi zero 2W.

Due to that I don't have hardware to test I cannot :

--confirm if and external USB ethernet would also change the behavior on the RPI zero 2W
--confirm confirm if another model with builtin wifi is also affected the same way

Yes, something wonky must be going on with @scred47's upstream DNS.

I've also tested with google DNS , with cloudflare DNS and even with KPN DNS. The issue is the same.

Obviously there's many other users who are using pleezer successfully so never ran into this issue.

Users can also stop using that feature silently if affected without reporting or trying to diagnose anything.