You are right. I'll look into it. Maybe there is something wrong with dae's new code.

Please send me a message if you need test or log information. Thanks again and have a nice day.

from dae.

I have disabled Adguardhome then changed dae dns and client dns to 223.5.5.5, it works now!

from dae.

1. You should use upstream adguardhome as your DNS like this:

dns {
  # upstream ...

  routing {
    request {
      fallback: adguardhome
    }
  }
}

2. You should set DNS server in DHCP setting as the IP of dae.

Notice that if your adguardhome is in the same machine of dae, please bind to WAN to make the adguardhome's https traffic to google go through proxy. In this case, pname(AdGuardHome) -> must_direct should be replaced with pname(AdGuardHome) && l4proto(udp) && port(53) -> must_direct

from dae.

1. You should use upstream adguardhome as your DNS like this:

dns {
  # upstream ...

  routing {
    request {
      fallback: adguardhome
    }
  }
}

2. You should set DNS server in DHCP setting as the IP of dae.

Notice that if your adguardhome is in the same machine of dae, please bind to WAN to make the adguardhome's https traffic to google go through proxy. In this case, pname(AdGuardHome) -> must_direct should be replaced with pname(AdGuardHome) && l4proto(udp) && port(53) -> must_direct

Thank you for your quick reply.
Yes, the adguardhome and dae are installed in the same system as transparent proxy.
I followed your instruction and added the DNS settings, but now all the websites can not open anymore. Browser shows dns error.
My settings are as follows

dns {
upstream {
adguardhomedns: 'tcp+udp://127.0.0.1:53'
}
routing {
request {
fallback: adguardhomedns
}
}
}

routing {
pname(AdGuardHome) && l4proto(udp) && dport(53) -> must_direct
pname(NetworkManager, systemd-resolved) -> direct
dip(224.0.0.0/3, 'ff00::/8') -> direct
dip(geoip:private) -> direct
dip(geoip:cn) -> direct
domain(geoisite:cn) -> direct
fallback: fast_group
}

Some log message
Mar 13 20:35:53 debian dae[500]: level=info msg="localhost:10649 <-> 127.0.0.1:53" dialer=direct mac="7c:2b:e1:13:18:e6" network="udp4(DNS)" outbound=direct pid=482 pname=AdGuardHome policy=fixed qname=qq.com. qtype=65
Mar 13 20:35:53 debian dae[500]: level=info msg="localhost:58437 <-> 127.0.0.1:53" dialer=direct mac="7c:2b:e1:13:18:e6" network="udp4(DNS)" outbound=direct pid=482 pname=AdGuardHome policy=fixed qname=qq.com. qtype=65
Mar 13 20:35:53 debian dae[500]: level=info msg="localhost:17601 <-> 127.0.0.1:53" dialer=direct mac="7c:2b:e1:13:18:e6" network="udp4(DNS)" outbound=direct pid=482 pname=AdGuardHome policy=fixed qname=qq.com. qtype=65
Mar 13 20:35:53 debian dae[500]: level=info msg="localhost:7013 <-> 127.0.0.1:53" dialer=direct mac="7c:2b:e1:13:18:e6" network="udp4(DNS)" outbound=direct pid=482 pname=AdGuardHome policy=fixed qname=qq.com. qtype=65
Mar 13 20:36:02 debian dae[500]: level=warning msg="handleConn: handleTCP relay error: read tcp 127.0.0.1:8708->127.0.0.1:10000: read: connection reset by peer"
Mar 13 20:36:02 debian dae[500]: level=warning msg="handleConn: handleTCP relay error: read tcp 127.0.0.1:8702->127.0.0.1:10000: read: connection reset by peer"
Mar 13 20:36:02 debian dae[500]: level=warning msg="handleConn: handleTCP relay error: read tcp 127.0.0.1:8716->127.0.0.1:10000: read: connection reset by peer"
Mar 13 20:36:02 debian dae[500]: level=warning msg="handleConn: handleTCP relay error: read tcp 127.0.0.1:8720->127.0.0.1:10000: read: connection reset by peer"
Mar 13 20:36:02 debian dae[500]: level=warning msg="handleConn: handleTCP relay error: read tcp 127.0.0.1:8736->127.0.0.1:10000: read: connection reset by peer"
Mar 13 20:36:03 debian dae[500]: level=warning msg="handleConn: handleTCP relay error: read tcp 127.0.0.1:8746->127.0.0.1:10000: read: connection reset by peer"
Mar 13 20:36:03 debian dae[500]: level=info msg="localhost:14382 <-> 1.0.0.1:443" dialMode=ip dialer="fast_node" domain= mac="7c:2b:e1:13:18:e6" network=tcp4 outbound="fast_group" pid=482 pname=AdGuardHome policy=fixed
Mar 13 20:36:03 debian dae[500]: level=info msg="localhost:45134 <-> 127.0.0.1:53" dialer=direct mac="7c:2b:e1:13:18:e6" network="udp4(DNS)" outbound=direct pid=482 pname=AdGuardHome policy=fixed qname=myserver.top. qtype=TypeA
Mar 13 20:36:13 debian dae[500]: level=warning msg="handleConn: handleTCP relay error: read tcp 127.0.0.1:13198->127.0.0.1:10000: read: connection reset by peer"
Mar 13 20:36:24 debian dae[500]: level=info msg="localhost:50070 <-> 127.0.0.1:53" dialer=direct mac="7c:2b:e1:13:18:e6" network="udp4(DNS)" outbound=direct pid=482 pname=AdGuardHome policy=fixed qname=qq.com. qtype=TypeA
Mar 13 20:36:24 debian dae[500]: level=info msg="localhost:52362 <-> 127.0.0.1:53" dialer=direct mac="7c:2b:e1:13:18:e6" network="udp4(DNS)" outbound=direct pid=482 pname=AdGuardHome policy=fixed qname=qq.com. qtype=65
Mar 13 20:36:24 debian dae[500]: level=info msg="192.168.1.6:61897 <-> 127.0.0.1:53" dialer=direct mac="04:92:26:bd:fc:60" network="udp4(DNS)" outbound=direct pid=0 pname= policy=fixed qname=qq.com. qtype=TypeA
Mar 13 20:36:24 debian dae[500]: level=info msg="192.168.1.6:61897 <-> 127.0.0.1:53" dialer=direct mac="04:92:26:bd:fc:60" network="udp4(DNS)" outbound=direct pid=0 pname= policy=fixed qname=qq.com. qtype=TypeA
Mar 13 20:36:25 debian dae[500]: level=info msg="192.168.1.6:61897 <-> 127.0.0.1:53" dialer=direct mac="04:92:26:bd:fc:60" network="udp4(DNS)" outbound=direct pid=0 pname= policy=fixed qname=qq.com. qtype=TypeA
Mar 13 20:36:27 debian dae[500]: level=info msg="192.168.1.6:61897 <-> 127.0.0.1:53" dialer=direct mac="04:92:26:bd:fc:60" network="udp4(DNS)" outbound=direct pid=0 pname= policy=fixed qname=qq.com. qtype=TypeA
Mar 13 20:36:31 debian dae[500]: level=info msg="192.168.1.6:61897 <-> 127.0.0.1:53" dialer=direct mac="04:92:26:bd:fc:60" network="udp4(DNS)" outbound=direct pid=0 pname= policy=fixed qname=qq.com. qtype=TypeA

from dae.

The log shows your AdGuardHome is requesting 127.0.0.1:53(itself, I guess). This should not happen.

from dae.

The log shows your AdGuardHome is requesting 127.0.0.1:53(itself, I guess). This should not happen.

Yes, dae seems to have intercepted the dns request, but local host and the PC that connected to the transparent gateway can't get the IP address.
The same configuration works fine on v2raya
Thank you for your great project.

A new error
Mar 13 21:26:32 debian dae[499]: level=warning msg="handlePkt: failed to read from: 127.0.0.1:53 (dialer: direct): read udp [::]:54994: i/o timeout"
Mar 13 21:26:32 debian dae[499]: level=warning msg="handlePkt: failed to read from: 127.0.0.1:53 (dialer: direct): read udp [::]:28874: i/o timeout"
Mar 13 21:26:32 debian dae[499]: level=warning msg="handleConn: handleTCP relay error: read tcp 127.0.0.1:17376->127.0.0.1:10000: read: connection reset by peer"

PS. the WAN port and the LAN port are both bound to enp1s0, is this the problem?

from dae.

You are right. I'll look into it. Maybe there is something wrong with dae's new code.

from dae.

It should be fixed in 207c343. Thank you so much for your issue! Please test it again.

PS. the WAN port and the LAN port are both bound to enp1s0, is this the problem?

It doesn't matter. dae supports this.

from dae.

Thank you for fast update. The good news is the local host works! But the PC connected to the transparent gateway still does not work. no error message appear.

from dae.

I think you can configure your DHCP to use a public DNS (such as 8.8.8.8 and 223.5.5.5 but whatever it is); the requests will be intercepted by dae and forwarded to adguardhome. Because if you configure it as adguardhome_ip:53, the DNS traffic will be sent to adguardhome directly and not forwareded by dae.

from dae.

I think you can configure your DHCP to use a public DNS (such as 8.8.8.8 and 223.5.5.5 but whatever it is); the requests will be intercepted by dae and forwarded to adguardhome. Because if you configure it as adguardhome_ip:53, the DNS traffic will be sent to adguardhome directly and not forwareded by dae.

Still not work, should I need change resolv.conf in local host? The current settings is 127.0.0.1 (adguardhome)

The public DNS configure in adguardhome is DoH https://1.1.1.1/dns-query

from dae.

No. It should be OK. I committed a new patch ea568eb. Hope it can resolve it.

After this patch. I noticed that it is also feasible to set the IP of dae machine as DNS server in DHCP settings even if the port 53 is listened on by another program.

from dae.

Sorry, I have recompiled the latest version but no luck. No matter if I set DNS to adguardhome ip or public dns it doesn't work

Can you share your full configuration file?

the error message appears when I set the client DNS to 8.8.8.8
Mar 13 23:09:51 debian bash[461]: [0313/230951.860578:ERROR:ssl_client_socket_impl.cc(985)] handshake failed; returned -1, SSL error code 1, net_error -100
Mar 13 23:09:51 debian dae[482]: level=info msg="localhost:40588 <-> the server ip:443" dialMode=domain dialer="fast_node" domain=my.server.top mac="7c:2b:e1:13:18:e6" network=tcp4 outbound="fast_group" pid=461 pname=naive policy=fixed
Mar 13 23:09:51 debian dae[482]: level=warning msg="handleConn: handleTCP relay error: read tcp 127.0.0.1:30526->127.0.0.1:10000: read: connection reset by peer"
Mar 13 23:09:51 debian bash[461]: [0313/230951.876978:ERROR:ssl_client_socket_impl.cc(985)] handshake failed; returned -1, SSL error code 1, net_error -100

from dae.

OK.. But what is the naive process? I notice that the naive proxy is in the log. Are logs generated quickly now?

from dae.

I don't think it's a problem with naiveproxy. On the local host, the proxy works fine. But the client still can't get the IP address.

root@debian:~# wget qq.com
--2023-03-13 23:37:31-- http://qq.com/
Resolving qq.com (qq.com)... 123.151.137.18, 61.129.7.47, 183.3.226.35
Connecting to qq.com (qq.com)|123.151.137.18|:80... connected.
HTTP request sent, awaiting response... 302 Moved Temporarily
Location: https://www.qq.com/ [following]
--2023-03-13 23:37:31-- https://www.qq.com/
Resolving www.qq.com (www.qq.com)... 121.14.77.221, 121.14.77.201
Connecting to www.qq.com (www.qq.com)|121.14.77.221|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘index.html.10’

index.html.10 [ <=> ] 26.67K --.-KB/s in 0.02s

2023-03-13 23:37:31 (1.30 MB/s) - ‘index.html.10’ saved [27307]

root@debian:~# wget google.com
--2023-03-13 23:37:37-- http://google.com/
Resolving google.com (google.com)... 142.250.176.14
Connecting to google.com (google.com)|142.250.176.14|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://www.google.com/ [following]
--2023-03-13 23:37:37-- http://www.google.com/
Resolving www.google.com (www.google.com)... 142.250.188.228
Connecting to www.google.com (www.google.com)|142.250.188.228|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘index.html.11’

index.html.11 [ <=> ] 15.73K --.-KB/s in 0.02s

2023-03-13 23:37:38 (772 KB/s) - ‘index.html.11’ saved [16103]

from dae.

OK. Do you have a linux machine? You can set log_level to trace in the dae configuration file, then:

1. Use dig to test whether the dns is fine.
2. Use curl 1.1.1.1 to test whether the request will be successful without dns.

I'm not sure whether you can do this on Windows with similar tools.

from dae.

OK. Do you have a linux machine? You can set log_level to trace in the dae configuration file, then:

1. Use dig to test whether the dns is fine.
2. Use curl 1.1.1.1 to test whether the request will be successful without dns.

I'm not sure whether you can do this on Windows with similar tools.

I will creat a VM to test tomorrow.
It's time to rest. Stay healthy :-)
Thank you for your hard work.

from dae.

Thanks for your help. Good night.

from dae.

dig and curl output
root@test:~# dig qq.com

; <<>> DiG 9.16.37-Debian <<>> qq.com
;; global options: +cmd
;; connection timed out; no servers could be reached

root@test:~# dig google.com

; <<>> DiG 9.16.37-Debian <<>> google.com
;; global options: +cmd
;; connection timed out; no servers could be reached

root@test:~# curl -f qq.com
curl: (6) Could not resolve host: qq.com

DAE Log
Mar 14 09:50:22 debian dae[463]: level=trace msg="Request to DNS upstream" question=[{qq.com. TypeA ClassINET}] upstream="tcp+udp://127.0.0.1:53"
Mar 14 09:50:22 debian dae[463]: level=trace msg="Choose DNS path" ipversions=[4] l4protos=[udp tcp] upstream="tcp+udp://127.0.0.1:53"
Mar 14 09:50:22 debian dae[463]: level=trace msg="Update DNS record cache" addition=".(TypeOPT): dnsmessage.OPTResource{Options: []dnsmessage.Option{}}" ans="qq.com.(TypeA): 123.151.137.18; qq.com.(TypeA): 61.129.7.47; qq.com.(TypeA): 183.3.226.35" auth= qname=qq.com. rcode=RCodeSuccess
Mar 14 09:50:22 debian dae[463]: level=trace msg=Accept question=[{qq.com. TypeA ClassINET}] upstream="tcp+udp://127.0.0.1:53"
Mar 14 09:50:22 debian dae[463]: level=info msg="192.168.1.12:43311 <-> 127.0.0.1:53" dialer=direct mac="26:0e:1b:34:f6:6d" network="udp4(DNS)" outbound=direct pid=0 pname= policy=fixed qname=qq.com. qtype=TypeA
Mar 14 09:50:27 debian dae[463]: level=trace msg="UDP(DNS) 192.168.1.12:43311 <-> Cache: qq.com. TypeA"
Mar 14 09:50:32 debian dae[463]: level=trace msg="UDP(DNS) 192.168.1.12:43311 <-> Cache: qq.com. TypeA"
Mar 14 09:51:27 debian dae[463]: level=trace msg="Request to DNS upstream" question=[{google.com. TypeA ClassINET}] upstream="tcp+udp://127.0.0.1:53"
Mar 14 09:51:27 debian dae[463]: level=trace msg="Choose DNS path" ipversions=[4] l4protos=[udp tcp] upstream="tcp+udp://127.0.0.1:53"
Mar 14 09:51:27 debian dae[463]: level=info msg="localhost:46598 <-> 1.0.0.1:443" dialMode=ip dialer="fast_node" domain= mac="7c:2b:e1:13:18:e6" network=tcp4 outbound="fast_group" pid=445 pname=AdGuardHome policy=fixed
Mar 14 09:51:28 debian dae[463]: level=trace msg="Update DNS record cache" addition=".(TypeOPT): dnsmessage.OPTResource{Options: []dnsmessage.Option{}}" ans="google.com.(TypeA): 172.217.14.78" auth= qname=google.com. rcode=RCodeSuccess
Mar 14 09:51:28 debian dae[463]: level=trace msg=Accept question=[{google.com. TypeA ClassINET}] upstream="tcp+udp://127.0.0.1:53"
Mar 14 09:51:28 debian dae[463]: level=info msg="192.168.1.12:44100 <-> 127.0.0.1:53" dialer=direct mac="26:0e:1b:34:f6:6d" network="udp4(DNS)" outbound=direct pid=0 pname= policy=fixed qname=google.com. qtype=TypeA
Mar 14 09:51:32 debian dae[463]: level=trace msg="UDP(DNS) 192.168.1.12:44100 <-> Cache: google.com. TypeA"
Mar 14 09:51:37 debian dae[463]: level=trace msg="UDP(DNS) 192.168.1.12:44100 <-> Cache: google.com. TypeA"

from dae.

what about curl 1.1.1.1

from dae.

I think it may be a NIC problem. Try to listen AdGuardHome on a non-53 port.

Don't fotget to modify corresponding upstream settings in dae config.

from dae.

what about curl 1.1.1.1

root@test:~# curl 1.1.1.1

301 Moved Permanently

from dae.

I think it may be a NIC problem. Try to listen AdGuardHome on a non-53 port.

Don't fotget to modify corresponding upstream settings in dae config.

Modified the adguardhome port but still the same result

dns {
upstream {
adguardhomedns: 'tcp+udp://127.0.0.1:54'
}
routing {
request {
fallback: adguardhomedns
}
}
}
routing {
pname(AdGuardHome) && l4proto(udp) && dport(54) -> must_direct
pname(NetworkManager, systemd-resolved) -> direct

from dae.

So weird. I have the same configuration but cannot reproduce.

from dae.

What if you do not use adguardhome? Will it perform fine?

from dae.

Will adguardhome work (test it on port 53) when dae is stopped?

from dae.

What if you do not use adguardhome? Will it perform fine?

I have changed dns settings in dae and client to 1.1.1.1, same result. If remove the dns section in ade, it works.

dns {
upstream {
adguardhomedns: 'udp://1.1.1.1:53'
}
routing {
request {
fallback: adguardhomedns
}
}
}

nameserver 1.1.1.1

from dae.

Will adguardhome work (test it on port 53) when dae is stopped?

Yes, adguardhome works fine. The problem only occurs after added dns section to dae

from dae.

Ok... Good change... So if you change fallback:adgaurdhome to fallback:asis, will it remain failure?

from dae.

Ok... Good change... So if you change fallback:adgaurdhome to fallback:asis, will it remain failure?

changed dns to 1.1.1.1 and fallback to asis, I got these errors

Mar 14 11:50:23 debian dae[481]: level=trace msg="Request to DNS upstream" question=[{qq.com. TypeA ClassINET}] upstream=asis
Mar 14 11:50:23 debian dae[481]: level=trace msg="Choose DNS path" ipversions=[4] l4protos=[udp] upstream="udp://1.1.1.1:53"
Mar 14 11:50:23 debian dae[481]: level=trace msg="Request to DNS upstream" question=[{qq.com. TypeAAAA ClassINET}] upstream=asis
Mar 14 11:50:23 debian dae[481]: level=trace msg="Choose DNS path" ipversions=[4] l4protos=[udp] upstream="udp://1.1.1.1:53"
Mar 14 11:50:23 debian dae[481]: level=warning msg="handlePkt: failed to dial '1.1.1.1:53': proxy: SOCKS5 proxy at 127.0.0.1:10000 failed to connect: command not supported by socks5 server: UDPAssociate"
Mar 14 11:50:23 debian dae[481]: level=warning msg="handlePkt: failed to dial '1.1.1.1:53': proxy: SOCKS5 proxy at 127.0.0.1:10000 failed to connect: command not supported by socks5 server: UDPAssociate"
Mar 14 11:50:28 debian dae[481]: level=trace msg="Request to DNS upstream" question=[{qq.com. TypeA ClassINET}] upstream=asis
Mar 14 11:50:28 debian dae[481]: level=trace msg="Choose DNS path" ipversions=[4] l4protos=[udp] upstream="udp://1.1.1.1:53"
Mar 14 11:50:28 debian dae[481]: level=trace msg="Request to DNS upstream" question=[{qq.com. TypeAAAA ClassINET}] upstream=asis
Mar 14 11:50:28 debian dae[481]: level=trace msg="Choose DNS path" ipversions=[4] l4protos=[udp] upstream="udp://1.1.1.1:53"
Mar 14 11:50:28 debian dae[481]: level=warning msg="handlePkt: failed to dial '1.1.1.1:53': proxy: SOCKS5 proxy at 127.0.0.1:10000 failed to connect: command not supported by socks5 server: UDPAssociate"
Mar 14 11:50:28 debian dae[481]: level=warning msg="handlePkt: failed to dial '1.1.1.1:53': proxy: SOCKS5 proxy at 127.0.0.1:10000 failed to connect: command not supported by socks5 server: UDPAssociate"

from dae.

Please change your dns to 223.5.5.5 and try again.

from dae.

Please change your dns to 223.5.5.5 and try again.

Changed dns on both client and dae but no luck.

Mar 14 11:58:26 debian dae[483]: level=trace msg="Request to DNS upstream" question=[{qq.com. TypeA ClassINET}] upstream=asis
Mar 14 11:58:26 debian dae[483]: level=trace msg="Choose DNS path" ipversions=[4] l4protos=[udp] upstream="udp://223.5.5.5:53"
Mar 14 11:58:26 debian dae[483]: level=trace msg="Request to DNS upstream" question=[{qq.com. TypeAAAA ClassINET}] upstream=asis
Mar 14 11:58:26 debian dae[483]: level=trace msg="Choose DNS path" ipversions=[4] l4protos=[udp] upstream="udp://223.5.5.5:53"
Mar 14 11:58:26 debian dae[483]: level=trace msg="Update DNS record cache" addition=".(TypeOPT): dnsmessage.OPTResource{Options: []dnsmessage.Option{}}" ans="qq.com.(TypeA): 61.129.7.47; qq.com.(TypeA): 183.3.226.35; qq.com.(TypeA): 123.151.137.18" auth= qname=qq.com. rcode=RCodeSuccess
Mar 14 11:58:26 debian dae[483]: level=trace msg=Accept question=[{qq.com. TypeA ClassINET}] upstream=asis
Mar 14 11:58:26 debian dae[483]: level=info msg="192.168.1.12:58889 <-> 223.5.5.5:53" dialer=direct mac="26:0e:1b:34:f6:6d" network="udp4(DNS)" outbound=direct pid=0 pname= policy=fixed qname=qq.com. qtype=TypeA
Mar 14 11:58:26 debian dae[483]: level=trace msg=Accept question=[{qq.com. TypeAAAA ClassINET}] upstream=asis
Mar 14 11:58:26 debian dae[483]: level=info msg="192.168.1.12:58889 <-> 223.5.5.5:53" dialer=direct mac="26:0e:1b:34:f6:6d" network="udp4(DNS)" outbound=direct pid=0 pname= policy=fixed qname=qq.com. qtype=TypeAAAA
Mar 14 11:58:31 debian dae[483]: level=trace msg="UDP(DNS) 192.168.1.12:58889 <-> Cache: qq.com. TypeA"
Mar 14 11:58:31 debian dae[483]: level=trace msg="Request to DNS upstream" question=[{qq.com. TypeAAAA ClassINET}] upstream=asis
Mar 14 11:58:31 debian dae[483]: level=trace msg="Choose DNS path" ipversions=[4] l4protos=[udp] upstream="udp://223.5.5.5:53"
Mar 14 11:58:32 debian dae[483]: level=trace msg=Accept question=[{qq.com. TypeAAAA ClassINET}] upstream=asis
Mar 14 11:58:32 debian dae[483]: level=info msg="192.168.1.12:58889 <-> 223.5.5.5:53" dialer=direct mac="26:0e:1b:34:f6:6d" network="udp4(DNS)" outbound=direct pid=0 pname= policy=fixed qname=qq.com. qtype=TypeAAAA

here is the full config file
config.dae.txt

from dae.

There is a weird point. If your proxy does not support UDP, why after removing DNS section it can forward traffic to 1.1.1.1:53 successfully?

from dae.

I see. You mean that DNS server uses adguardhome in this case.

from dae.

I think dae should act like a normal dns server when port 53 is not in use. Can you reach me on telegram? @mzz2017

from dae.

I think dae should act like a normal dns server when port 53 is not in use. Can you reach me on telegram? @mzz2017

Sorry, my telegram account is currently unavailable

If the dns setting is added to dae, does that mean dae will listening on port 53? Maybe I should stop the adguradhome service and try again

from dae.

Dae will not actually listen on port 53. It uses a magic method to simulate. Use sudo netstat -ulpen or sudo lsof -i:53 to make sure 53 is not be listened on.

from dae.

Generally, it works fine regardless of whether other programs listen on 53. However, it will fail when you have some other program listen on port 53 and your NIC does not support to disable checksum verification in the production environment.

If you encounter this problem, the solution is to not occupy port 53. You should change your adguardhome listening port.

from dae.

Disable NIC checksum verification, do you mean this command？
ethtool --offload tx off

from dae.

Disable NIC checksum verification, do you mean this command？ ethtool --offload tx off

No, it has nothing with offload. Do not disable it.

from dae.

Maybe I should give up using adguardhome if dae also supports the dns caching feature

from dae.

Maybe I should give up using adguardhome if dae also supports the dns caching feature

Yes. You can do this. Now dae only supports tcp/udp. DoH, DoT, DoQ are in TODO list. And if you still want to use adguardhome, I think trying changing the listening port is a good method.

Anyway, thanks for help with debugging.

from dae.

Can I using Doh in dae like this 1111dns: 'https://1.0.0.1/dns-query:443'

from dae.

Not yet. dae does not support DoH yet.

from dae.

Of course, this feature is important, and I think it should be supported in the first half of this year.

from dae.

Of course, this feature is important, and I think it should be supported in the first half of this year.

I will continue testing in the evening. Thank you very much for your patience!
dae is indeed faster than v2raya, hope it support Doh soon. good job!

from dae.

Thank you! Have a good day!

from dae.

I'll close this issue as completed. If you have other problems. Please open another issue.

from dae.