AdguardTeam / AdGuardHome

Network-wide ads & trackers blocking DNS server
https://adguard.com/adguard-home/overview.html
GNU General Public License v3.0
25.68k stars 1.84k forks source link

DNS resolution speed issue with local hosts files #6165

Open MiKing233 opened 1 year ago

MiKing233 commented 1 year ago

Prerequisites

Platform (OS and CPU architecture)

Linux, ARM64

Installation

Custom package (OpenWrt, HomeAssistant, etc; please mention in the description)

Setup

On one machine

AdGuard Home version

v0.107.36

Action

In my DNS resolution log, I noticed that the resolution speed of rewritten items from the hosts file is not normal, and they appear too slow

I correspond the device names in my domain to the IP addresses through the hosts file of this Gateway

In my /etc/hosts, there are approximately over 30 records, and file size is 1.5KB

Expected result

I think the DNS resolution speed of hosts files should be like this, or even faster than them

image

Actual result

But the actual parsing speed is very slow, with an average of over 100ms or even higher (毫秒=ms)

image

Additional information and/or screenshots

This issue has a lower priority as the impact is not actually felt

ainar-g commented 1 year ago

Could you try the latest Beta release? We have replaced the /etc/hosts mechanism there, and the new one should be faster and more correct.

MiKing233 commented 1 year ago

Could you try the latest Beta release? We have replaced the /etc/hosts mechanism there, and the new one should be faster and more correct.

Hi, after a period of testing, I have obtained some of the following results

On v0.108.0-b.44 may seem faster, but I still don't think it should be this speed image

But I noticed some details: For these high latency PTR queries, they all come from the device running ADGH itself (127.0.0.1), while devices from br-lan, such as me using my LAPTOP to execute command

nslookup 10.128.20.102

The following results were obtained:

PS C:\Users\MiKing233> nslookup 10.128.20.102
服务器:  NanoPiR4S-Gateway
Address:  10.128.20.2

名称:    MiKing233-iPhone12Pro
Address:  10.128.20.102

In the DNS query log of ADGH, the latency is as follows image Request from my LAPTOP(10.128.20.101), delay is normal

If the entry in/etc/hosts is called through ping, there is no problem with latency, This will be a Class A DNS query image

At present, there is only so much information I can know. In short, the problem of high DNS request latency lies in PTR requests

MiKing233 commented 1 year ago

Supplementary explanations to the above

On v0.108.0-b.44 this issue does not seem to occur frequently, But I am certain that this issue has been occurring continuously at v0.107.36 image

But besides this issue, I also discovered a new one, Also only exists in PTR queries The results in the query log will be returned x3 image

EugeneOne1 commented 1 year ago

@MiKing233, doesn't the /etc/hosts file contain this entry three times? Or perhaps this hostname mentioned in three records?

MiKing233 commented 1 year ago

@MiKing233, doesn't the /etc/hosts file contain this entry three times? Or perhaps this hostname mentioned in three records?

No, there is only one record corresponding to this IP address and host name in the/etc/hosts file

for the same /etc/hosts file On v0.107.36 I confirm the query logs in ADGH like this:

响应细节

状态: 重写项
耗时: 0.09 毫秒
响应代码: NOERROR

规则:
10.128.20.1 Mi-BE10GbE-Router
系统主机文件

响应:
PTR: Mi-BE10GbE-Router. (ttl=10)
codac commented 1 year ago

I'm not quite sure but I might have the same Issue in a similar manner. I need to restart the docker frequently (at least once a day) as the reolving times go up to several hundret ms per request. After restarting the docker the times go down to under 100ms.

The low entries are after the restart, the high values are before the restart. So it seems that this behaviour builds up hour by hour until the requests are getting so slow that surfing the net is nearly impossible anymore.

192.168.0.1 is the router 192.168.0.21 is the device running AGH on it

Unbenannt

EugeneOne1 commented 1 year ago

@MiKing233, unfortunately, we can't reproduce this slowdown. Could you please collect verbose log for us? There are few actions we'd like to see captured:

You may send it to devteam@adguard.com.

MiKing233 commented 1 year ago

@MiKing233, unfortunately, we can't reproduce this slowdown. Could you please collect verbose log for us? There are few actions we'd like to see captured:

  • Update the hosts file to make AdGuardHome reload it;
  • An A DNS request for some host specified in hosts;
  • A PTR request for some IP address specified in hosts;

You may send it to devteam@adguard.com.

對於PTR請求高延遲的問題, 我還需要補充一些: 對於我在DNS Server或是在局域網客戶端上手動發起的PTR請求, 通過ADGH查詢是不存在高延遲問題的 image image

然而在我看到的有關PTR請求存在高延遲問題的DNS請求, 都不是我手動進行查詢的, 這似乎是來自於這臺設備的系統本身 image

我的設備運行OpenWrt作爲局域網内Gateway之用途, 同時運行ADGH提供DNS查詢 Openwrt-18.06-Linux5.4.203 在我觀察到, 每當OpenWrt運行一段時間, 它會對hosts中的條目進行一次完整的PTR查詢, 而這個動作則會讓ADGH查詢的延遲變得不正常的高, 我注意到ADGH在1秒内處理了近30條查詢, 可能是我設備效能的問題, 又或者是I/O效能的問題? 晚些時候我會排查這個問題, 不過我的/etc/hosts條目只存在47行, 大小為1.5K, 我不太懷疑是設備本身的效能導致的.

EugeneOne1 commented 1 year ago

@MiKing233,我可以肯定地说,在大量请求导致的高负载时间内,这些请求的平均处理速度会比正常情况下慢。 这与机器资源的平均分配有关。 您能否尝试将配置文件中的 max_goroutines 设置设为 0,看看情况是否有所改善,处理时间是否变得更均匀?

MiKing233 commented 1 year ago

@MiKing233,我可以肯定地说,在大量请求导致的高负载时间内,这些请求的平均处理速度会比正常情况下慢。 这与机器资源的平均分配有关。 您能否尝试将配置文件中的 max_goroutines 设置设为 0,看看情况是否有所改善,处理时间是否变得更均匀?

Hi @EugeneOne1 ,抱歉讓您久等了, 我使用dnsperf工具對迸發解析速度進行了測試, 發現DNS解析速度過慢的問題的確是由於短時間内需要處理大量的DNS請求造成的, 并且這個問題不是僅存在於PTR請求, 但我對此仍有疑問:

我使用了

dnsperf -d testfile.lan -s 10.128.20.2 -p 53

來對ADGH進行測試, 在testfile.lan文件中, 完整包含/etc/hosts中的41個條目, 就像這樣"Mi-BE10GbE-Router A", 解析速度如下圖 image 但我并不認爲這是設備性能導致的問題 image 此設備的CPU信息如下"AArch64 / Rockchip RK3399 / Dual-core Cortex-A72 up to 2.2GHz and Quad-core Cortex-A53 up to 1.8GHz", 在41條DNS迸發請求下設備的loading並不高

另外, 此時我的ADGH使用的上游伺服器為10.128.20.2:54, 是OpenWrt自帶的Dnsmasq, 所以這是否意味著可能是Dnsmasq對高迸發請求的回應速度過慢, 而不是ADGH的問題呢

# root @ OpenWrt in ~ [22:15:58]
$ netstat -ntulp | grep 54
tcp        0      0 127.0.0.1:54            0.0.0.0:*               LISTEN      14476/dnsmasq
tcp        0      0 10.128.20.2:54          0.0.0.0:*               LISTEN      14476/dnsmasq

此外例如對Mi-BE10GbE-Router的A類請求, 實際是來自上游Dnsmasq的回應, 爲此我更改了上游DNS伺服器為8.8.8.8, 希望借此來測試ADGH的性能, 但發現此時ADGH根本無法回應來自/etc/hosts的條目, image 這直接導致ADGH回應了一個NXDOMAIN...

我覺得現在有些混亂, 在繼續測試下去前, 我覺得還是應該向您確認一下, ADGH是否支援解析來自/etc/hosts的A類記錄?, 目前我只發現PTR記錄是由ADGH進行rewrite的, 但是對與A類請求, 在我目前測試下, ADGH作爲DNS伺服器似乎對於域名不會先檢查/etc/hosts文件而直接將DNS的A類請求丟給上游DNS伺服器