The good news is that the Overview page shows that the IPv6 DNS servers should be only the ones that I have configured.
The bad news is dnsleakstest.com still shows my ISP's advertised DNS resolver are resolving my DNS queries.
With everyone's help and support and persistence, it seems more likely that the ISP is hijacking my DNS queries.
Enable DoH in your browser, does the DNS leak test still report the same ?
When I enable DoH on FireFox and select Cloudflare, dnsleaktest.com reports Cloudflare as the DNS resolver.
Plain DNS traffic is inherently vulnerable to DNS hijacking, and if your ISP is actually involved, then you need to use DNS encryption to bypass it, e.g. DoH, DoT, DNS-over-VPN/Tor, etc.
I am having a similar problem and have DNS over TLS via stubby.
My System Status Overview:
IPv4 Upstream
Protocol: DHCP client
Address: 71.85.37.47/23
Gateway: 71.85.36.1
DNS 1: 71.10.216.1
DNS 2: 71.10.216.2
Expires: 0h 53m 49s
Connected: 0h 6m 11s
Device: Switch port: "wan"
MAC address: 30:23:03:B6:48:B9.
I ran through the trouble shooting on the Stubby web page and Cloudflare's test pages shows DNS over TLS to be working:
Debug Information
Connected to 1.1.1.1 Yes
Using DNS over HTTPS (DoH) No
Using DNS over TLS (DoT) Yes
Using DNS over WARP No
AS Name Cloudflare
AS Number 13335
Cloudflare Data Center SEA
Connectivity to Resolver IP Addresses
1.1.1.1 Yes
1.0.0.1 Yes
2606:4700:4700::1111 No
2606:4700:4700::1001 No
So I'm confused - Is my DNS being hijacked? I do not think it is illegal to utilize Cloudflare's services in my country (US) but hijacked DNS requests irritate me and on general principals I'm interested in taking back my privacy.
Probably you have network->interfaces->wan [edit]->advanced settings->Use DNS servers advertised by peer selected. Try without selecting that option.
If you need to block the ISP's DNS, you must use some secure connection with PKI e.g. DoH, DoT (as suggested), or via some VPN. You should also block port 53 over the WAN via the firewall. If not blocked any misconfiguration may still leak some traffic which could be intercepted.
I remember the PPPoE was handled by pppd, so it may worth running ps | grep pppd in order to check the arguments being used.
Thank you adding your suggestions. I am currently using the https-dns-proxy package to achieve secure DNS. Curiously, only certain DoH providers are able to circumvent the ISP's attempt to intercept all DNS queries. A VPN is being used client side when needed.
I ran the command and the output doesn't show much of interest:
3677 root 1112 S /usr/sbin/pppd nodetach ipparam wan ifname pppoe-wan lcp-echo-interval 1 lcp-echo-failure 5 lcp-echo-adaptive +i
8723 root 1120 S grep pppd
Okay. Another avenue investigation seemed to reveal that my ISP has RDNS enabled, but they allow me to set the host for the RDNS on their customer portal. I have set this to 127.0.0.1. Does this seem right? The changes should reflect in 24 hours. As you can see the formatting of the address is odd in that it uses hyphens, but this format is what I gathered they use since my public ip address was formatted as such in the default settings.
This is irrelevant to your problem.
Your ISP lets you to create a PTR record for your IP address. The hostname can be something that you have already set in your dns zone, like router.llethur.com or llethour.ddns.com
Thanks Trendy. Back to the drawing board.
There is no such option. The closest one is +ipv6. The output is possibly truncated.
If the usepeerdns argument is used it will pass the values to the ppp scripts and will create environment variables. Then it's upto these scripts if the received addresses will be used. If you have anything in the /tmp/resolv.conf.ppp, the argument is being used. However I don't know if usepeerdns will be omitted if option peerdns '0' was used or it will be handled by the PPP scripts.
Use ps wwww | grep ppp
Ah. This is how it looks, minus my username.
3676 root 1112 S /usr/sbin/pppd nodetach ipparam wan ifname pppoe-wan lcp-echo-interval 1 lcp-echo-failure 5 lcp-echo-adaptive +ipv6 set PEERDNS=0 nodefaultroute usepeerdns maxfail 1 user *username* password ???????? ip-up-script /lib/netifd/ppp-up ipv6-up-script /lib/netifd/ppp6-up ip-down-script /lib/netifd/ppp-down ipv6-down-script /lib/netifd/ppp-down mtu 1492 mru 1492 plugin pppoe.so nic-eth1.911
4053 root 832 S odhcp6c -s /lib/netifd/dhcpv6.script -Ntry -P0 -t120 pppoe-wan
21173 root 1120 R grep ppp
So you are taking the DNS servers form the ISP and possibly it's up to the ppp scripts to install them or not.
I forgot to ask you to run logread -e nameserver after a PPPoE reconnect. If the provider's DNS is not present in the system log, but the test returns it, then the ISP intercepts the DNS traffic, so you need to stay to the tunneled approach. Keep in mind that there is possibility the ISP is being legally obligated to log the DNS request and some more metatadta. Some applications/browsers may still use their own DNS, so the request will be just forwarded as a regular data packet and not being processed by the router. If the provider's DNS is not being used by dnsmasq, but the test fails, you may need to block port 53 over the WAN in order to drop any non-tunneled DNS traffic.
Sat May 6 04:31:56 2023 daemon.info dnsmasq[1]: using nameserver 127.0.0.1#5053
Sat May 6 04:31:56 2023 daemon.info dnsmasq[1]: using nameserver 127.0.0.1#5054
Sat May 6 04:32:01 2023 daemon.info dnsmasq[1]: using nameserver 127.0.0.1#5053
Sat May 6 04:32:01 2023 daemon.info dnsmasq[1]: using nameserver 127.0.0.1#5054
Sat May 6 05:09:07 2023 daemon.info dnsmasq[1]: using nameserver 9.9.9.9#53
Sat May 6 05:09:07 2023 daemon.info dnsmasq[1]: using nameserver 149.112.112.112#53
Sat May 6 05:09:07 2023 daemon.info dnsmasq[1]: using nameserver 2620:fe::fe#53
Sat May 6 05:09:07 2023 daemon.info dnsmasq[1]: using nameserver 2620:fe::9#53
Sat May 6 05:09:07 2023 daemon.info dnsmasq[1]: using nameserver 9.9.9.9#53
Sat May 6 05:09:07 2023 daemon.info dnsmasq[1]: using nameserver 149.112.112.112#53
Sat May 6 05:09:07 2023 daemon.info dnsmasq[1]: using nameserver 2620:fe::fe#53
Sat May 6 05:09:07 2023 daemon.info dnsmasq[1]: using nameserver 2620:fe::9#53
Sat May 6 05:09:07 2023 daemon.info dnsmasq[1]: using nameserver 9.9.9.9#53
Sat May 6 05:09:07 2023 daemon.info dnsmasq[1]: using nameserver 149.112.112.112#53
Sat May 6 05:09:07 2023 daemon.info dnsmasq[1]: using nameserver 2620:fe::fe#53
Sat May 6 05:09:07 2023 daemon.info dnsmasq[1]: using nameserver 2620:fe::9#53
Sat May 6 05:09:55 2023 daemon.info dnsmasq[1]: using nameserver 9.9.9.9#53
Sat May 6 05:09:55 2023 daemon.info dnsmasq[1]: using nameserver 149.112.112.112#53
Sat May 6 05:09:55 2023 daemon.info dnsmasq[1]: using nameserver 2620:fe::fe#53
Sat May 6 05:09:55 2023 daemon.info dnsmasq[1]: using nameserver 2620:fe::9#53
Sat May 6 05:09:55 2023 daemon.info dnsmasq[1]: using nameserver 9.9.9.9#53
Sat May 6 05:09:55 2023 daemon.info dnsmasq[1]: using nameserver 149.112.112.112#53
Sat May 6 05:09:57 2023 daemon.info dnsmasq[1]: using nameserver 9.9.9.9#53
Sat May 6 05:09:57 2023 daemon.info dnsmasq[1]: using nameserver 149.112.112.112#53
Sat May 6 05:09:57 2023 daemon.info dnsmasq[1]: using nameserver 2620:fe::fe#53
Sat May 6 05:09:57 2023 daemon.info dnsmasq[1]: using nameserver 2620:fe::9#53
Sat May 6 05:09:57 2023 daemon.info dnsmasq[1]: using nameserver 9.9.9.9#53
Sat May 6 05:09:57 2023 daemon.info dnsmasq[1]: using nameserver 149.112.112.112#53
Sat May 6 05:09:57 2023 daemon.info dnsmasq[1]: using nameserver 2620:fe::fe#53
Sat May 6 05:09:57 2023 daemon.info dnsmasq[1]: using nameserver 2620:fe::9#53
The dnsleaktest.com still shows the ISP's DNS resolver being used in this scenario.
It is a legal requirement in the country of my residence for ISPs to log DNS queries made using their DNS resolvers and provide those to law enforcement agencies when and if needed; however, they are not required by law to force you to use their DNS resolver. My previous ISP complied with the law by logging the DNS queries if you used their default DNS resolvers, but not require you to use them. Let us be honest, if they really wanted to know which sites I am visiting, knowing what my DNS queries are, is only one way to find out. The fact of the matter is that they still need to deliver the content to my home. I use encrypted DNS, because it is more secure and, in some cases, it also allows you to have more control over the content being delivered i.e., ads.
That is why the https-over-dns-proxy package is so useful, because you can force compliance client-side.
Your log shows that you are still contacting directly some potentially unsecure resolvers outside the tunnel. When using DoT or DoH, you should leave only the localhost and the port configured for the respective service.
So will it prevent the LAN hosts to bypass the DNS service of the router?
Some public resolvers may not comply to your local privacy regulations - e.g. you may not need to give them consent your data to be transfered/sold to third parties, so if you care about your privacy you should read their policy, before using.
Also, most of the well-known resolvers tend to be anycast - e.g. hosted over different locations, connected to different providers, with the same IP, so your provider could be directly involved in their service.
Yes. I had stopped the dns-over-https-proxy service for testing purposes. That is also why you see the loop back configuration with the 127.0.0.1 addresses. When I start the dns-over-https-proxy service, the log reads very differently.
Mostly, if they are configured to receive DNS resolvers automatically via DHCP, which most of my devices do.
Good advice for anyone who reads these posts retrospectively. That is why I prefer Quad 9 and ControlD.
Just an update: since the initial post I have moved to the Release Candidates of 23.05 and noticed that the dnsleaks website now reports my chosen https-over-DOH provider as opposed to the ISP DNS. I do not think changing to the RC had anything to do with it, but rather an adjustment of settings on the ISP side.