Node scripts often encounter getaddrinfo EAI_AGAIN errors

[KaKi87]

Issue Details

• Version of AdGuard Home server: 0.107.2
• How did you install AdGuard Home: install.sh
• How did you setup DNS configuration: router
• If it's a router or IoT, please write device model: -
• CPU architecture: amd64
• Operating system and version: Ubuntu 20.04.3 LTS

Expected Behavior

Node scripts running on machines using AdGuard Home as DNS rarely encounter getaddrinfo EAI_AGAIN errors just like browsers rarely encounter DNS_PROBE_FINISHED_NXDOMAIN errors.

Actual Behavior

Node scripts running on machines using AdGuard Home as DNS often encounter getaddrinfo EAI_AGAIN errors.

Screenshots

Screenshot: router DNS configuration

Screenshot: `ifconfig`

Screenshot: setup guide

Screenshot: upstream DNS servers

Screenshot: bootstrap DNS servers

Screenshot: top clients

Additional Information

Additionally to solving this bug, I'm wondering if it would be possible for AdGuard Home to see all clients instead of only the router (cf. last screenshot).

---

Thanks

[EugeneOne1]

@KaKi87, hello. As far as I can tell from the screenshots, you've only specified the DNS server for the router itself so the connected devices are still sending requests to it. In this setup, the router is the source of all requests from the point of view of the AGH. It also increases the path that each request goes through making the whole system less efficient.

There are several ways to specify the DNS server's address for devices. Please let us know if that helped or not. Thanks.

[KaKi87]

You are absolutely right, but isn't the router setup the only way to force all devices to go through AdGuard Home ?
Like Alexa, Android TV, and other IoT devices that cannot be set up.
Thanks

[EugeneOne1]

@KaKi87, that's right. I'm not really familiar with Node's DNS pipeline, but a after a shallow research I can suppose the getaddrinfo EAI_AGAIN is related to DNS resolution timeout. Thus improving it's efficiency may help. Note that in case of propagating DNS servers' addresses via DHCP there is no need to set up each device separately.

AFAIK at least Android TV allows specifying DNS servers during of manual host configuration. However, you'll need a static IP address allocation for the device in this case. Fortunatelly routers usually provide such a feature. AGH's internal DHCP server may also be used for this purpose.

[KaKi87]

the getaddrinfo EAI_AGAIN is related to DNS resolution timeout

Oh, maybe I could find a way to increase that timeout, then.

in case of propagating DNS servers' addresses via DHCP there is no need to set up each device separately.

In my current configuration, the router uses 9.9.9.9 as secondary DNS server in case AdGuard Home or the server hosting it is down for some reason.
If I set up AdGuard Home as DHCP server, won't all devices fail to access the Internet if such issue happens ?

AFAIK at least Android TV allows specifying DNS servers during of manual host configuration. However, you'll need a static IP address allocation for the device in this case. Fortunatelly routers usually provide such a feature.

True, although I would like to avoid that.

Thanks

[EugeneOne1]

Well, AGH's DHCP also allows specifying DNS servers' addresses, so if it's configured to propagate another secondary server these issues should only affect the DHCP RELEASEs which are usually quite rare events.

Anyway, if the router allows specifying DNS addresses propagated by the DHCP lease, I'd recommend to use it instead of AGH's in such kind of unstable set-ups.

[KaKi87]

I understand. I'll try it and keep you posted

[KaKi87]

So, I tried AGH's DHCP : it works for apps and browsers, as much as router worked ; it displays individual clients, which is nicer for stats ; but it doesn't solve the Node issue.

Thanks

[EugeneOne1]

@KaKi87, sorry for a late response. There is a similar issue in the official Node's repository and there also a few possible ways to fix it. In general, you may try to specify different upstream servers for the Node's needs, or even inspect the query log for the topical queries.

I'm pretty sure the issue isn't a consequence of some bugs. However, could you please collect a verbose log catching the moment when the issue occurs. You may either send it here or to the devteam@adguard.com. Thanks.

[KaKi87]

The issue you linked is related to Node on Docker, which I am not using, and the tutorial link returns 404. Thanks

[EugeneOne1]

@KaKi87, sorry about the link, I've fixed it.

There are some common recommendations about the EAI_AGAIN error in the linked issue. For example, you may add the Node's resources appearing with SERVFAIL response code in query log to the /etc/hosts file.

[KaKi87]

So, turns out verbose mode was already enabled. However, absolutely no log entry is created while the issue occurs.

add the Node's resources appearing with SERVFAIL response code in query log to the /etc/hosts file

I don't understand 😅

[EugeneOne1]

Well, do you know exactly, what's requested by the Node script you're using? Firstly, it'd be helpful to determine these domains, then searching the query log for those. This will at least give an exact reason of why aren't they fulfilled.

[KaKi87]

do you know exactly, what's requested by the Node script you're using?

No, the script is a Discord bot powered by eris.

determine these domains

discord.com

then searching the query log for those

2022/01/19 19:20:30.146526 933#299665 [debug] DNSFwd: Checking record A (162.159.135.232) for discord.com.
2022/01/19 19:20:30.146693 933#299665 [debug] DNSFwd: Checking record A (162.159.136.232) for discord.com.
2022/01/19 19:20:30.146809 933#299665 [debug] DNSFwd: Checking record A (162.159.138.232) for discord.com.
2022/01/19 19:20:30.146917 933#299665 [debug] DNSFwd: Checking record A (162.159.137.232) for discord.com.
2022/01/19 19:20:30.147025 933#299665 [debug] DNSFwd: Checking record A (162.159.128.233) for discord.com.
;discord.com.	IN	 A
discord.com.	254	IN	A	162.159.135.232
discord.com.	254	IN	A	162.159.136.232
discord.com.	254	IN	A	162.159.138.232
discord.com.	254	IN	A	162.159.137.232
discord.com.	254	IN	A	162.159.128.233
;discord.com.	IN	 A
2022/01/19 19:28:52.066720 933#300148 [debug] tls://dns.quad9.net:853: sending request A discord.com.
2022/01/19 19:28:52.075954 933#300148 [debug] github.com/AdguardTeam/dnsproxy/proxy.exchangeWithUpstream(): upstream tls://dns.quad9.net:853 successfully finished exchange of ;discord.com.	IN	 A. Elapsed 9.373916ms.

Is that it ?

Thanks

[EugeneOne1]

Don't be confused between "log" and "query log". The first one is the one you've just send. The second is the AGH's feature, you may find it in top of web interface.

As for the log, it provides some useful info:
Could you also try to add this rule to the custom rules list:

||discord.com$dnsrewrite=NOERROR;A;162.159.135.232,162.159.136.232,162.159.138.232,162.159.137.232,162.159.128.233

[KaKi87]

So, I went looking : I found query log entries coming from the Node script's host, and I found query log entries related to Discord, but I did not found any log entry matching both criteria.

I think there's something important I forgot to tell you, and I'm sorry if it is, because I didn't realized it could be : the Node script's host, and AdGuard Home's host, are the same.

add this rule to the custom rules list

I did, but it didn't changed anything.

Thanks

[EugeneOne1]

I think it'd be reasonable to set the loopback address (127.0.0.1) of DNS server for that host to avoid redundant routing. However, I'd like to take a look at the full log (not query log) since it may contain more useful data. Could you please send it here or to devteam@adguard.com?

[KaKi87]

I think it'd be reasonable to set the loopback address (127.0.0.1) of DNS server for that host

Actually, that's what I already did, and that's actually where the issue is from : AdGuard Home is not listening on 127.0.0.1 but on the host's local network IP address.

Switching the DNS server to that adress seem to have solved my issue.

I'd like to take a look at the full log (not query log)

Isn't that what I put in a code block earlier ?

Thanks, and sorry for the disturbance.