Open billyzs opened 1 month ago
next thing to try on my end would be to maybe add a small delay in AGH's response so that it always takes at least a few hundred ms even for DNS rewrites, and see if macOS can work correctly with delay added. But I'm not familiar with AGH's code, so it would be great if someone from AGH can post a patch / point to where to add the delay.
Prerequisites
[X] I have checked the Wiki and Discussions and found no answer
[X] I have searched other issues and found no duplicates
[X] I want to report a bug and not ask a question or ask for help
[X] I have set up AdGuard Home correctly and configured clients to use it. (Use the Discussions for help with installing and configuring clients.)
Platform (OS and CPU architecture)
Darwin (aka macOS), AMD64 (aka x86_64)
Installation
Custom package (OpenWrt, HomeAssistant, etc; please mention in the description)
Setup
On a Server, DHCP is handled by AdGuard Home
AdGuard Home version
0.107.50
Action
Hello AdGuard team,
I have an AGH instance configured correctly on TrueNAS SCALE (using their official k3s/docker/helm charts app system which uses AGH's official docker images); clients are also configured correctly to use it. Normal browsing works fine. AGH is configured to do DHCP and also seem to work fine. However, for a few domains which I have configured a DNS rewrite in the web UI, as well as local hostnames that should be resolved via DHCP, lookups would fail using UDP but succeed using TCP.
In the examples below,
myhost.my-domain.net
is a record that I have a dns rewrite:myhost.my-domain.net
->192.168.0.20
; AGH server running on 192.168.0.20;lan
is my local DHCP domain name that AGH is configured to use (e.g.myhost.lan
).Using macOS
dig
:WORKED: Lookup of public domain over TCP
``` ❯ dig @192.168.0.20 google.com +all +keepopen +stats +retry=10 +time=10 +tcp took 61ms at 11:30:48 ; <<>> DiG 9.10.6 <<>> @192.168.0.20 google.com +all +keepopen +stats +retry=10 +time=10 +tcp ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35379 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;google.com. IN A ;; ANSWER SECTION: google.com. 10 IN A 172.217.168.78 ;; Query time: 80 msec ;; SERVER: 192.168.0.20#53(192.168.0.20) ;; WHEN: Thu May 30 11:31:17 CEST 2024 ;; MSG SIZE rcvd: 55 ```dig @192.168.0.20 google.com +all +keepopen +stats +retry=10 +time=10 +tcp
WORKED: Lookup of public domain over UDP
``` ❯ dig @192.168.0.20 google.com +all +keepopen +stats +retry=10 +time=10 +notcp ; <<>> DiG 9.10.6 <<>> @192.168.0.20 google.com +all +keepopen +stats +retry=10 +time=10 +notcp ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49823 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;google.com. IN A ;; ANSWER SECTION: google.com. 10 IN A 172.217.168.78 ;; Query time: 50 msec ;; SERVER: 192.168.0.20#53(192.168.0.20) ;; WHEN: Thu May 30 11:30:48 CEST 2024 ;; MSG SIZE rcvd: 55 ```dig @192.168.0.20 google.com +all +keepopen +stats +retry=10 +time=10 +notcp
WORKED: Lookup of DHCP domain over TCP
FAILED: Lookup of DHCP domain over UDP
WORKED: Lookup of DNS-rewrite domain over TCP
FAILED: Lookup of DNS-rewrite domain over UDP
Expected result
AGH responds to queries with domain names configured via DNS rewrite and internally by AGH DHCP server correctly over UDP
Actual result
AGH times out to queries with domain names configured via DNS rewrite and internally by AGH DHCP server over UDP
Additional information and/or screenshots
In AGH's query log, I can actually see the queries for
myhost.my-domain.net
, for both TCP and UDP queries which AGH responded with DNS rewrite and a very short response time (0.05ms v.s. several hundred ms for queries made to upstream DNS servers).To rule out any weird behavior with macos
dig
, I also tried with macOSnslookup
andkdig
(kdig (Knot DNS), version 3.3.5)
and obtained identical results as above.Just to be sure, I checked that port 53/udp is open on the AGH server
I made a post of macOS support forum in case there's something weird with how macOS handles DNS.
Tried another dns tool to bypass macOS DNS stack altogether, and still got some strange mixed results: If I enable the
VERBOSE
flag in the dns tool (which probably adds some delays) the query sometimes works over UDP, otherwise it would fail over UDP. I'm really not sure if it's something in AGH's UDP response, or the way macOS handles UDP/DNS. The latter seems unlikely, but then again, the same tool running on Linux works... I filed a bug report to Apple, but in the mean time please keep this issue open until we can definitely rule out AGH and say that it's a bug in macOS; also I'm referencing this issue in my bug report to Apple, so the information here needs to be accessible during this time.WORKED (sometimes): macOS, dnstool, UDP
FAILED: macOS, dnstool, UDP
WORKED: Linux, dnstool, UDP