DoH is working even if deactivated
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)
Linux, AMD64 (aka x86_64)
Installation
Custom package (OpenWrt, HomeAssistant, etc; please mention in the description)
Setup
On one machine
AdGuard Home version
0.107.48
Action
even when tls: enabled: false, the AGH server reply to DoH requests:
q example.com MX @https://adguard.example.com
example.com. 21h57m8s MX 0 .
full TLS config section:
tls:
enabled: false
server_name: adguard.example.com
force_https: false
port_https: 13120
port_dns_over_tls: 853
port_dns_over_quic: 784
port_dnscrypt: 0
dnscrypt_config_file: ""
allow_unencrypted_doh: true
certificate_chain: ""
private_key: ""
certificate_path: /etc/yunohost/certs/adguard.example.com/crt.pem
private_key_path: /etc/yunohost/certs/adguard.example.com/key.pem
strict_sni_check: false
Expected result
if tls: enabled: false, AGH should refuse any DoH requests, as stated in the interface:
Actual result
Instead of refusing the DoH request, AGH reply with the right answer
The setting is working properly for DoT and DoQ
Additional information and/or screenshots
The installation is using the YunoHost package I'm one of its maintainers, btw
Thanks for the report. This seems to be an unintended consequence of allow_unencrypted_doh: true. DoH on port 443 doesn't work, but on port 80 does.
just in case: the nginx config for the /dns-query path:
location /dns-query {
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
proxy_bind 127.0.0.1;
proxy_pass http://127.0.0.1:3002/dns-query;
}
On a second thought, I'm not sure whether this is an issue. Enabling the DoH server over plain HTTP is precisely what the setting is supposed to do. @OniriCorpe, what's the expected behavior here from your point of view? As in, why wasn't the connection between allow_unencrypted_doh and serving DNS over plain HTTP isn't obvious?
Hi @OniriCorpe are you able to answer the query? Thanks!