# \[BUG\] Encrypted DNS (DoH) not working on MT6000 Flint 2 - Firmware 4.8.4 **URL:** \ **Category:** VPN, DNS, Leaks\ **Created:** [March 27, 2026, 11:30am UTC](https://forum.gl-inet.com/t/bug-encrypted-dns-doh-not-working-on-mt6000-flint-2-firmware-4-8-4/67827 "2026-03-27T11:30:13Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![MsX](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/m/4af34b/32.png) [@MsX](https://forum.gl-inet.com/u/MsX)\ **Post date:** [March 27, 2026, 11:30am UTC](https://forum.gl-inet.com/t/bug-encrypted-dns-doh-not-working-on-mt6000-flint-2-firmware-4-8-4/67827/1 "2026-03-27T11:30:13Z")
Hi everyone, after updating my GL-MT6000 Flint 2 from 4.8.3 → 4.8.4 (Firmware Type: release, compiled 2026-03-12), Encrypted DNS / DoH stopped working completely. ⚠ **Important: this update arrived as a standard stable release — no beta label, no warning, no indication of gray release status. There was no way to know this was experimental.** **What happens** Every time I select any DoH preset from Network → DNS → Encrypted DNS (Quad9, Cloudflare, etc.), all clients immediately lose internet. Wi-Fi stays connected but DNS fails completely. Ping to 8.8.8.8 still works — confirming it's a DNS-only issue. This worked perfectly on 4.8.3. **Steps to reproduce** 1. Go to Network → DNS 2. Set Mode → Encrypted DNS 3. Select any preset (e.g. quad9-doh-ip4-port443-filter-pri) 4. Tap Submit 5. All clients lose internet immediately. **Root cause** The preset list uses hostnames ([dns.quad9.net](http://dns.quad9.net), [dns.cloudflare.com](http://dns.cloudflare.com) etc.). The https-dns-proxy service on port 5453 needs to resolve those hostnames before it can start — but DNS isn't up yet at that point. Bootstrap deadlock. In 4.8.4 the firewall rule lan\_drop\_leaked\_dns is now enabled and blocks any DNS fallback, making the failure total. **Workaround** Use DoH with direct IP instead of hostname — these work fine on 4.8.4: [https://9.9.9.9/dns-query](https://9.9.9.9/dns-query) (Quad9, same filtering as filter-pri preset) [https://1.1.1.1/dns-query](https://1.1.1.1/dns-query) (Cloudflare) [https://8.8.8.8/dns-query](https://8.8.8.8/dns-query) (Google) Note: the app has no field to type a custom DoH URL — the workaround above requires SSH. Please add a custom input field in the Encrypted DNS UI. Device info Model: GL-MT6000 Flint 2 Firmware: 4.8.4 — Type: release Compiled: 2026-03-12 17:56:15 Previous firmware: 4.8.3 (working) AdGuard Home: disabled IPv6: disabled Update received: automatically via router panel, shown as standard stable release Thanks ---
**Author:** ![Aashish.007](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/a/ea5d25/32.png) [@Aashish.007](https://forum.gl-inet.com/u/Aashish.007)\ **Post date:** [March 27, 2026, 11:44am UTC](https://forum.gl-inet.com/t/bug-encrypted-dns-doh-not-working-on-mt6000-flint-2-firmware-4-8-4/67827/2 "2026-03-27T11:44:01Z")
Is there no pre defined bootstrap dns here in the application? ---
**Author:** ![MsX](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/m/4af34b/32.png) [@MsX](https://forum.gl-inet.com/u/MsX)\ **Post date:** [March 27, 2026, 11:56am UTC](https://forum.gl-inet.com/t/bug-encrypted-dns-doh-not-working-on-mt6000-flint-2-firmware-4-8-4/67827/3 "2026-03-27T11:56:06Z")
Good point. In a correct https-dns-proxy setup, a plain DNS bootstrap (e.g. 8.8.8.8) should be configured so the service can resolve the DoH hostname on startup before DNS is fully operational. Looking at my config (debug\_info.log), dnsmasq is configured with: server=127.0.0.1#5453 (only upstream) noresolv=1 (no fallback resolv.conf) This means dnsmasq has zero fallback if the service on port 5453 doesn't respond. There is no visible bootstrap plain DNS configured for https-dns-proxy in 4.8.4. On 4.8.3 this worked fine, so either: The bootstrap DNS was present in 4.8.3 and got removed/broken in 4.8.4 The bootstrap mechanism changed behavior between the two versions The workaround of using [https://9.9.9.9/dns-query](https://9.9.9.9/dns-query) (direct IP) confirms the issue: with an IP-based URL there is no hostname to resolve at bootstrap, so the service starts correctly. Could a GL.iNet dev confirm whether the bootstrap DNS config for https-dns-proxy changed between 4.8.3 and 4.8.4? ---
**Author:** ![59jg1p](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/5/8dc957/32.png) [@59jg1p](https://forum.gl-inet.com/u/59jg1p)\ **Post date:** [March 27, 2026, 1:34pm UTC](https://forum.gl-inet.com/t/bug-encrypted-dns-doh-not-working-on-mt6000-flint-2-firmware-4-8-4/67827/4 "2026-03-27T13:34:25Z")
I can confirm a related issue on the same firmware, in a slightly different scenario. **Device:** GL-MT6000 (Flint 2) **Firmware:** 4.8.4 (updated from 4.8.3, settings kept) In my setup, DoH works fine with AdGuard Home enabled. The moment I disable AdGuard Home, DNS stops working completely for all clients and for the router itself. This matches your finding exactly. Via SSH I confirmed that dnsmasq is hardcoded to forward all DNS requests to 127.0.0.1#5453, even when AdGuard Home is disabled and nothing is listening on that port: ```plaintext /etc/config/dhcp: list server '127.0.0.1#5453' /etc/config/dhcp: option noresolv '1' ``` With noresolv=1 and no service on port 5453, there is zero fallback — complete DNS outage. **Workaround:** Keep AdGuard Home enabled (DoH works correctly through it). Switching to Plain DNS also restores connectivity, but sacrifices encryption. So the missing bootstrap DNS you identified affects not just the initial DoH startup, but also any situation where the service on port 5453 is unavailable — including simply disabling AdGuard Home. ---
**Author:** ![MsX](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/m/4af34b/32.png) [@MsX](https://forum.gl-inet.com/u/MsX)\ **Post date:** [March 27, 2026, 1:54pm UTC](https://forum.gl-inet.com/t/bug-encrypted-dns-doh-not-working-on-mt6000-flint-2-firmware-4-8-4/67827/5 "2026-03-27T13:54:29Z")
Thank you, this is very valuable — you've just confirmed the bug is actually much broader than DoH specifically. The root issue is clear now: in 4.8.4, dnsmasq is hardcoded to forward everything to 127.0.0.1#5453 with noresolv=1, but there is no guarantee anything is listening on that port. This means the bug affects multiple scenarios: DoH enabled with hostname-based preset → port 5453 service fails to bootstrap → DNS outage AdGuard Home disabled → nothing on port 5453 → DNS outage Any future case where the port 5453 service crashes or fails to start In 4.8.3 this was handled correctly. Something changed in 4.8.4 that removed the safety net. The actual fix GL.iNet needs to implement: dnsmasq should always have at least one plain DNS fallback (e.g. the WAN-provided DNS from resolv.conf) for cases when port 5453 is unavailable. The noresolv=1 + single upstream approach with no fallback is the real architectural problem introduced in 4.8.4. This is not just a DoH bug — it's a DNS architecture regression that can cause a complete outage in multiple common scenarios. ---
**Author:** ![Aashish.007](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/a/ea5d25/32.png) [@Aashish.007](https://forum.gl-inet.com/u/Aashish.007)\ **Post date:** [March 27, 2026, 2:22pm UTC](https://forum.gl-inet.com/t/bug-encrypted-dns-doh-not-working-on-mt6000-flint-2-firmware-4-8-4/67827/6 "2026-03-27T14:22:14Z")
You are using DOH in glui or Adguard settings? Cause adguard has its own bootstrap servers. ---
**Author:** ![MsX](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/m/4af34b/32.png) [@MsX](https://forum.gl-inet.com/u/MsX)\ **Post date:** [March 27, 2026, 2:32pm UTC](https://forum.gl-inet.com/t/bug-encrypted-dns-doh-not-working-on-mt6000-flint-2-firmware-4-8-4/67827/7 "2026-03-27T14:32:51Z")
I'm using DoH configured via the GL.iNet UI (Network → DNS → Encrypted DNS), not AdGuard Home. AdGuard Home is completely disabled on my setup. That's exactly the point — AdGuard Home has its own bootstrap DNS mechanism which handles this correctly (as the previous reply confirmed: DoH works fine when AGH is enabled). The problem is that the GL.iNet native DoH implementation (https-dns-proxy on port 5453) has no working bootstrap in 4.8.4. So to summarize the two confirmed scenarios: AGH enabled → DoH works ✅ (AGH handles bootstrap internally) AGH disabled, GL.iNet native DoH → DNS outage ❌ (no bootstrap, noresolv=1, nothing on port 5453) This means the native GL.iNet DoH implementation is effectively broken in 4.8.4 for anyone not using AdGuard Home. ---
**Author:** ![59jg1p](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/5/8dc957/32.png) [@59jg1p](https://forum.gl-inet.com/u/59jg1p)\ **Post date:** [March 27, 2026, 2:39pm UTC](https://forum.gl-inet.com/t/bug-encrypted-dns-doh-not-working-on-mt6000-flint-2-firmware-4-8-4/67827/8 "2026-03-27T14:39:48Z")
DoH is configured in both places: **GL.iNet GUI:** Network → DNS → Encrypted DNS (DoH) **AdGuard Home:** Custom upstream DoH servers with bootstrap DNS configured AGH bootstrap servers: - 9.9.9.9 - 149.112.112.112 AGH upstream (DoH): - [https://94.140.14.14/dns-query](https://94.140.14.14/dns-query) - [https://94.140.15.15/dns-query](https://94.140.15.15/dns-query) - [https://adblock.dns.mullvad.net/dns-query](https://adblock.dns.mullvad.net/dns-query) AGH fallback: - [https://dnsforge.de/dns-query](https://dnsforge.de/dns-query) Note that AGH uses IP-based DoH URLs for the primary upstreams — which avoids the bootstrap deadlock entirely (no hostname to resolve at startup). The Mullvad fallback uses a hostname, but that’s covered by the bootstrap servers. This is exactly why DNS works fine with AGH enabled: AGH has a proper bootstrap configuration. The problem only appears when AGH is disabled, because then dnsmasq falls back to 127.0.0.1#5453 with noresolv=1 and nothing listening on that port — no bootstrap, no fallback, complete outage. ---
**Author:** ![Aashish.007](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/a/ea5d25/32.png) [@Aashish.007](https://forum.gl-inet.com/u/Aashish.007)\ **Post date:** [March 27, 2026, 2:46pm UTC](https://forum.gl-inet.com/t/bug-encrypted-dns-doh-not-working-on-mt6000-flint-2-firmware-4-8-4/67827/9 "2026-03-27T14:46:48Z")
Mine on 4.8.3 doesnt use https-dns-proxy at all, it is using dnscrypt-proxy. Has this changed between versions? ---
**Author:** ![MsX](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/m/4af34b/32.png) [@MsX](https://forum.gl-inet.com/u/MsX)\ **Post date:** [March 27, 2026, 2:55pm UTC](https://forum.gl-inet.com/t/bug-encrypted-dns-doh-not-working-on-mt6000-flint-2-firmware-4-8-4/67827/10 "2026-03-27T14:55:15Z")
This is a crucial finding — it could explain everything. According to the GL.iNet docs, the Encrypted DNS section supports multiple backends: DNSCrypt-Proxy, DNS over HTTPS, DNS over TLS, and Oblivious DoH . If 4.8.3 used dnscrypt-proxy as the backend for DoH presets and 4.8.4 switched to https-dns-proxy, that would explain exactly why 4.8.3 worked and 4.8.4 doesn't. The key difference: dnscrypt-proxy has a built-in bootstrap resolver mechanism by design. https-dns-proxy in its default OpenWrt configuration requires bootstrap\_dns to be explicitly set (e.g. option bootstrap\_dns '1.1.1.1,8.8.8.8'). If GL.iNet migrated to https-dns-proxy in 4.8.4 but forgot to configure the bootstrap DNS field, the service will always deadlock on hostname-based resolvers . Can you check on your 4.8.3 device which process is running for DoH? ps | grep -E 'dnscrypt|https-dns' And on 4.8.4 (my device) I can confirm only https-dns-proxy is running — with no bootstrap DNS configured. If this backend switch is confirmed, the fix for GL.iNet is straightforward: add bootstrap\_dns '8.8.8.8' to the https-dns-proxy config in 4.8.4. ---
**Author:** ![Aashish.007](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/a/ea5d25/32.png) [@Aashish.007](https://forum.gl-inet.com/u/Aashish.007)\ **Post date:** [March 27, 2026, 2:59pm UTC](https://forum.gl-inet.com/t/bug-encrypted-dns-doh-not-working-on-mt6000-flint-2-firmware-4-8-4/67827/11 "2026-03-27T14:59:43Z")
> grep -E 'dnscrypt|https-dns' > 2563 root 1210m S /usr/sbin/dnscrypt-proxy -config /etc/dnscrypt-proxy2/dnscrypt-proxy.toml > 13694 root 1340 S grep -E dnscrypt|https-dns ---
**Author:** ![MsX](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/m/4af34b/32.png) [@MsX](https://forum.gl-inet.com/u/MsX)\ **Post date:** [March 27, 2026, 3:03pm UTC](https://forum.gl-inet.com/t/bug-encrypted-dns-doh-not-working-on-mt6000-flint-2-firmware-4-8-4/67827/12 "2026-03-27T15:03:17Z")
Update: I ran the check on my 4.8.4 device and it's also using dnscrypt-proxy, not https-dns-proxy: 2563 root 1210m S /usr/sbin/dnscrypt-proxy -config /etc/dnscrypt-proxy2/dnscrypt-proxy.toml So the backend did not change between 4.8.3 and 4.8.4 — both use dnscrypt-proxy. This makes the bug even more interesting: dnscrypt-proxy IS running, which means the service itself starts fine. The failure must happen at a different stage — most likely when the GL.iNet UI writes a new server stamp to dnscrypt-proxy.toml and restarts the service. During that restart, the new server can't be reached, dnscrypt-proxy crashes or goes into error state, and since dnsmasq has noresolv=1 pointing exclusively to port 5453, there is zero fallback. The next diagnostic step would be to compare the content of /etc/dnscrypt-proxy2/dnscrypt-proxy.toml in two states: Before selecting a DoH preset (working state) After selecting a preset (broken state) cat /etc/dnscrypt-proxy2/dnscrypt-proxy.toml This would tell us exactly what GL.iNet UI writes into the config when a preset is applied, and whether the stamp or listen\_addresses port changes. ---
**Author:** ![Aashish.007](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/a/ea5d25/32.png) [@Aashish.007](https://forum.gl-inet.com/u/Aashish.007)\ **Post date:** [March 27, 2026, 3:12pm UTC](https://forum.gl-inet.com/t/bug-encrypted-dns-doh-not-working-on-mt6000-flint-2-firmware-4-8-4/67827/13 "2026-03-27T15:12:29Z")
> bootstrap\_resolvers = ['9.9.9.11:53', '8.8.8.8:53'] > > ignore\_system\_dns = true Found this in 4.8.3 ---
**Author:** ![Trident](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/t/8dc957/32.png) [@Trident](https://forum.gl-inet.com/u/Trident)\ **Post date:** [March 27, 2026, 5:18pm UTC](https://forum.gl-inet.com/t/bug-encrypted-dns-doh-not-working-on-mt6000-flint-2-firmware-4-8-4/67827/14 "2026-03-27T17:18:41Z")
I have the same issue. I was using Cloudflare DoH. ---
**Author:** ![PapyPom](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/p/eb9ed0/32.png) [@PapyPom](https://forum.gl-inet.com/u/PapyPom)\ **Post date:** [March 28, 2026, 10:10am UTC](https://forum.gl-inet.com/t/bug-encrypted-dns-doh-not-working-on-mt6000-flint-2-firmware-4-8-4/67827/15 "2026-03-28T10:10:57Z")
Same issue here, had to revert to basic Quad9. If this is any help, I’ve removed the package `gl-sdk4-ddns` and installed via LuCI the packages `acme`, `acme-dnsapi` and `luci-app-acme`. This shouldn’t modify the behavior for DoH. If there’s any test I can run, just let me know. ---
**Author:** ![MsX](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/m/4af34b/32.png) [@MsX](https://forum.gl-inet.com/u/MsX)\ **Post date:** [March 28, 2026, 10:17am UTC](https://forum.gl-inet.com/t/bug-encrypted-dns-doh-not-working-on-mt6000-flint-2-firmware-4-8-4/67827/16 "2026-03-28T10:17:54Z")
Thanks for confirming — this is now at least 3 users on 4.8.4 with the same issue, which makes it clearly a regression and not an isolated config problem. The packages you installed (acme, luci-app-acme) don't touch the DNS stack so they shouldn't be relevant — good to rule that out. If you're willing to run some tests, these would help narrow down the exact failure point: 1 — Check dnscrypt-proxy status after applying a DoH preset: > ps | grep dnscrypt > > logread | grep dnscrypt | tail -20 2 — Check what's actually listening on port 5453: > netstat -tlnup | grep 5453 3 — Check the dnscrypt-proxy config after selecting a preset: > cat /etc/dnscrypt-proxy2/dnscrypt-proxy.toml | grep -E 'listen|server\_names|urls|stamp' 4 — Most important: run step 3 in working state (before selecting a preset or after reverting to plain DNS), then select a DoH preset, wait 10 seconds, and run it again. Compare the two outputs. This would tell us exactly what the GL.iNet UI writes to the config when a preset is applied and whether dnscrypt-proxy actually restarts cleanly after that change. ---
**Author:** ![Medwards](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/m/5f9b8f/32.png) [@Medwards](https://forum.gl-inet.com/u/Medwards)\ **Post date:** [March 28, 2026, 8:06pm UTC](https://forum.gl-inet.com/t/bug-encrypted-dns-doh-not-working-on-mt6000-flint-2-firmware-4-8-4/67827/17 "2026-03-28T20:06:09Z")
I have the same issue - updating to 4.8.4 has resulted in no internet connection. I had to disable Cloudflare DoH. Poor testing… ---
**Author:** ![PapyPom](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/p/eb9ed0/32.png) [@PapyPom](https://forum.gl-inet.com/u/PapyPom)\ **Post date:** [March 28, 2026, 8:21pm UTC](https://forum.gl-inet.com/t/bug-encrypted-dns-doh-not-working-on-mt6000-flint-2-firmware-4-8-4/67827/18 "2026-03-28T20:21:38Z")
Did the test, so here’s the output. 1. Check dnscrypt-proxy status after applying a DoH preset: ```auto root@GL-MT6000:~# ps | grep dnscrypt 15022 root 1244 S grep dnscrypt ``` ```auto root@GL-MT6000:~# logread | grep dnscrypt | tail -20 root@GL-MT6000:~# -> no logs ``` 1. Check what's actually listening on port 5453: ```auto root@GL-MT6000:~# netstat -tlnup | grep 5453 root@GL-MT6000:~# -> once again, no output ``` 1. Check the dnscrypt-proxy config after selecting a preset: Regular DNS, tested working : ```auto root@GL-MT6000:~# cat /etc/dnscrypt-proxy2/dnscrypt-proxy.toml | grep -E 'listen|server_names|urls|stamp' server_names = ["dns4eu","dns4eu-ipv6"] ## List of local addresses and ports to listen to. Can be IPv4 and/or IPv6. ## listen_addresses = ['127.0.0.1:53', '[::1]:53'] ## To listen to all IPv4 addresses, use `listen_addresses = ['0.0.0.0:53']` ## To listen to all IPv4+IPv6 addresses, use `listen_addresses = ['[::]:53']` listen_addresses = ['127.0.0.1:5453'] ## Switch to a different system user after listening sockets have been created. disabled_server_names = [] # cert_ignore_timestamp = false ## They will never be used if lists have already been cached, and if the stamps ## `listen_addrs` must not be empty. ## Addresses that the local DoH server should listen to # listen_addresses = ['127.0.0.1:3000'] ## For each `listen_address` the complete URL to access the server will be: ## `https://` (ex: `https://127.0.0.1/dns-query`) ## different servers. In that case, names listed in `server_names` ## If the `urls` property is missing, cache files and valid signatures urls = ['https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v3/public-resolvers.md', 'https://download.dnscrypt.info/resolvers-list/v3/public-resolvers.md'] urls = ['https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v3/relays.md', 'https://download.dnscrypt.info/resolvers-list/v3/relays.md'] # urls = ['https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v3/odoh-servers.md', 'https://download.dnscrypt.info/resolvers-list/v3/odoh-servers.md'] # urls = ['https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v3/odoh-relays.md', 'https://download.dnscrypt.info/resolvers-list/v3/odoh-relays.md'] # urls = ['https://www.quad9.net/quad9-resolvers.md'] urls = ["https://quad9.net/dnscrypt/quad9-resolvers.md", "https://raw.githubusercontent.com/Quad9DNS/dnscrypt-settings/main/dnscrypt/quad9-resolvers.md"] # urls = ['https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v3/parental-control.md', 'https://download.dnscrypt.info/resolvers-list/v3/parental-control.md'] ## A relay can be specified as a DNS Stamp (either a relay stamp, or a ## DNSCrypt stamp) or a server name. ## and "example-server-2" via the relay whose relay DNS stamp is # stamp = 'sdns://AQcAAAAAAAAAAAAQMi5kbnNjcnlwdC1jZXJ0Lg' urls = ['https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v3/odoh-servers.md', 'https://download.dnscrypt.info/resolvers-list/v3/odoh-servers.md'] ``` DoH activated, tested not working : ```auto oot@GL-MT6000:~# cat /etc/dnscrypt-proxy2/dnscrypt-proxy.toml | grep -E 'listen|server_names|urls|stamp' server_names = ["dns4eu","dns4eu-ipv6"] ## List of local addresses and ports to listen to. Can be IPv4 and/or IPv6. ## listen_addresses = ['127.0.0.1:53', '[::1]:53'] ## To listen to all IPv4 addresses, use `listen_addresses = ['0.0.0.0:53']` ## To listen to all IPv4+IPv6 addresses, use `listen_addresses = ['[::]:53']` listen_addresses = ['127.0.0.1:5453'] ## Switch to a different system user after listening sockets have been created. disabled_server_names = [] # cert_ignore_timestamp = false ## They will never be used if lists have already been cached, and if the stamps ## `listen_addrs` must not be empty. ## Addresses that the local DoH server should listen to # listen_addresses = ['127.0.0.1:3000'] ## For each `listen_address` the complete URL to access the server will be: ## `https://` (ex: `https://127.0.0.1/dns-query`) ## different servers. In that case, names listed in `server_names` ## If the `urls` property is missing, cache files and valid signatures urls = ['https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v3/public-resolvers.md', 'https://download.dnscrypt.info/resolvers-list/v3/public-resolvers.md'] urls = ['https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v3/relays.md', 'https://download.dnscrypt.info/resolvers-list/v3/relays.md'] # urls = ['https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v3/odoh-servers.md', 'https://download.dnscrypt.info/resolvers-list/v3/odoh-servers.md'] # urls = ['https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v3/odoh-relays.md', 'https://download.dnscrypt.info/resolvers-list/v3/odoh-relays.md'] # urls = ['https://www.quad9.net/quad9-resolvers.md'] urls = ["https://quad9.net/dnscrypt/quad9-resolvers.md", "https://raw.githubusercontent.com/Quad9DNS/dnscrypt-settings/main/dnscrypt/quad9-resolvers.md"] # urls = ['https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v3/parental-control.md', 'https://download.dnscrypt.info/resolvers-list/v3/parental-control.md'] ## A relay can be specified as a DNS Stamp (either a relay stamp, or a ## DNSCrypt stamp) or a server name. ## and "example-server-2" via the relay whose relay DNS stamp is # stamp = 'sdns://AQcAAAAAAAAAAAAQMi5kbnNjcnlwdC1jZXJ0Lg' urls = ['https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v3/odoh-servers.md', 'https://download.dnscrypt.info/resolvers-list/v3/odoh-servers.md'] ``` Soo … basically the same output. I’m a loss. ---
**Author:** ![bluephi](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/b/ea666f/32.png) [@bluephi](https://forum.gl-inet.com/u/bluephi)\ **Post date:** [March 29, 2026, 8:43am UTC](https://forum.gl-inet.com/t/bug-encrypted-dns-doh-not-working-on-mt6000-flint-2-firmware-4-8-4/67827/19 "2026-03-29T08:43:30Z")
Exact the same for me after the upgrade to 4.8.4. Ping to 8.8.8.8 was possible, but no internet connection with DoH (Quad9). On top of that this update decreased my 5GHz performance. Had to downgrade to 4.8.3 Edit: - i’m not able to choose Quad9 inside the DoH-app. There’s no more quad9 server available. ---
**Author:** ![RouteMe](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/r/b2d939/32.png) [@RouteMe](https://forum.gl-inet.com/u/RouteMe)\ **Post date:** [March 30, 2026, 1:20am UTC](https://forum.gl-inet.com/t/bug-encrypted-dns-doh-not-working-on-mt6000-flint-2-firmware-4-8-4/67827/20 "2026-03-30T01:20:29Z")
Adding no helpful input here, but just want to say I too have the same issue. Upgraded this morning before my kids come online and internet connected but couldn’t browse anything on my phone. Which also tells me the WiFi has no internet. My PC uses Quad9 over TLS and that is working. It’s important I get this working as I use filtering from the DNS provider to protect my children. [Next page](https://forum.gl-inet.com/t/bug-encrypted-dns-doh-not-working-on-mt6000-flint-2-firmware-4-8-4/67827.md?page=2)