kgc wrote: ↑Wed Feb 07, 2024 5:26 pm
Actually.... we just haven't said anything. I see no particular advantage to using DoH to these servers vs using traditional DNS protocols since more or less the whole point of DoH is to hide the contents of your DNS queries from the prying eyes of your ISP.
Surprisingly, we see virtually no DoH requests coming in. This may be due to the majority of customer's equipment running caching resolvers and providing themselves as the single DNS server via DHCP. This has the unfortunate result of not picking up Firefox which instead sends all traffic to a cloudflare which pinky swears to not use the data they can glean from it for anything.
I would encourage Firefox users to just go ahead and disable DoH so long as they understand the implication of doing so regarding public WiFi and/or use of VPNs.
Code: Select all
$ dig @50.0.1.1 +https sonic.com
; <<>> DiG 9.18.20 <<>> @50.0.1.1 +https sonic.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38701
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: e5538d0450d92ae30100000065c42c6cecfa4d728222edba (good)
;; QUESTION SECTION:
;sonic.com. IN A
;; ANSWER SECTION:
sonic.com. 5146 IN A 184.23.169.173
;; Query time: 3 msec
;; SERVER: 50.0.1.1#443(50.0.1.1) (HTTPS)
;; WHEN: Wed Feb 07 17:20:44 PST 2024
;; MSG SIZE rcvd: 82
There are some scenarios where traditional DNS is problematic, but perhaps you can provide clues as how to overcome those without using Sonic's VPN or wishing for DoH.
I use Sonic's Fibre to Node, which runs over ATT resold lines. As far as I can tell, ATT appears to intercept traditional DNS requests via port 53, so that Sonic servers cannot be reached for address resolution. However, the servers can be pinged. I do not believe the observations below are due to misconfiguration on my part, but that is always possible.
Any request to resolve an address using only 50.0.1.1 or 50.0.2.2 results in failure. I am glad you used dig in your post, because that application is a favorite of mine too. To be fair, I have already informed support previously about this, so you can get more details from them...I am sure they remember. All they could say is that on ATT resold lines, there is nothing they can do about DNS
But...like I said, you may provide a clue for readers in other situations here too.
If I have only 50.0.1.1 and 50.0.2.2 for resolving, here is the result I sent support:
Code: Select all
dig -4 wikipedia.org
;; communications error to 50.0.1.1#53: timed out
;; communications error to 50.0.1.1#53: timed out
;; communications error to 50.0.1.1#53: timed out
;; communications error to 50.0.2.2#53: timed out
; <<>> DiG 9.18.19-1~deb12u1-Debian <<>> -4 wikipedia.org
;; global options: +cmd
;; no servers could be reached
Doesn't look too promising does it? It's ditto for Ipv6 too. If I place ATT's modem gateway IP first (or presumably, any ATT DNS server), then all of a sudden, Wikipedia resolution works just fine...just like in the real world, which is where I guess you are. Without that modem being first, I cannot even start Sonic's VPN, because the provided configuration file tries to resolve ovpn.sonic.net...which does not exist...not without that ATT modem first. But put the VPN aside for now, since not all Sonic customers use it.
I noticed you used dig with +https. Funny enough, I provided Sonic support with an example of that too:
Code: Select all
dig -4 +https wikipedia.org
;; communications error to 50.0.1.1#443: failure
;; communications error to 50.0.1.1#443: failure
;; communications error to 50.0.1.1#443: failure
;; communications error to 50.0.2.2#443: failure
; <<>> DiG 9.18.19-1~deb12u1-Debian <<>> -4 +https wikipedia.org
;; global options: +cmd
;; no servers could be reached
Definitely, doesn't look inviting either!
For those who don't use dig, they might say I missed the @ sign or I wasn't referring to Sonic's DNS server. To accommodate those, I typed exactly what you used:
Code: Select all
dig @50.0.1.1 +https sonic.co
;; communications error to 50.0.1.1#443: failure
;; communications error to 50.0.1.1#443: failure
;; communications error to 50.0.1.1#443: failure
; <<>> DiG 9.18.19-1~deb12u1-Debian <<>> @50.0.1.1 +https sonic.com
; (1 server found)
;; global options: +cmd
;; no servers could be reached
Hmmm!
Before your post, I was told that DoH was coming to Sonic servers, but not ready yet. I tried it again after your post and got the same results. So if you believe it's working...then it works for you...not me, or perhaps anyone using Sonic's Fibre to node. However, from the Sonic VPN all the above work i.e. the latter two came back with those capital HTTPS entries.
So, back to you encouraging folks to disable DoH? There you mention Cloudflare and it's "pinky". I've got nothing against Cloudflare. I simply say that if I had a choice, it would always be Sonic DNS servers. If I have no choice, then I would pick Cloudflare DNS servers...if you see what I mean
But you could not have missed the point that Firefox only sends to Cloudflare by default when the users explicitly pick "Increased Protection"
and they leave the default. There is also an option for NextDNS (who I don't know), and furthermore a Custom field. IP addresses don't work in it, nor should they since it would be limited. But research showed that when Cloudflare is picked, under the covers the field looks like this...and actually accepts this if you paste it there:
Code: Select all
https://mozilla.cloudflare-dns.com/dns-query
I contacted Sonic support again because I could do a test with ipleak.org using that Custom field in the DoH settings, if I had something similar for Sonic and Sonic DoH was working i.e something like:
It would have stated categorically whether my reason for posting was worthwhile, if I then saw Sonic servers in ipleak.org. It was only a test, but for unknown reasons support refused to provide anything that could be "looked up and resolved". So, that doorway was closed. They also said that this problem went beyond their support, which which I guess could be considered the final nail. Fortunately, I had been advised previously that folks in the forum might be in a better position to help. And here you are...I hope.
I really thought it might even be useful to let Sonic know of the situation where dig above using +https failed, which means that even Firefox's Custom field with a valid Sonic DNS server might not work either...not for my case. In fact, DoH might simple be just as off the cards as traditional DNS as far as Sonic Fiber to node is concerned. But then again, there are other customers reading this who might still benefit by having their browsers tied to Sonic DNS servers via DoH. And besides, I have the VPN and there all looks great, including fast, efficient and reliable Sonic DNS servers.
Finally, as for your recommendation to turn off Firefox DoH. Well, if I do that, and check with ipleak.org, all ATT servers show up...not Sonic DNS servers. If I use what FF calls "Default Protection", all ATT DNS servers show up there too. The only time I can see any other DNS servers other than ATT's is to use Firefox's "Increased Protection" which has Cloudflare as the default. Then and only then does ipleak.org show other DNS servers, which just happen to be those of Cloudflare. So, it's back to what do you suggest now?
Note, that I am neither promoting FF as a browser nor Cloudflare as a DNS provider, pinky or otherwise. I believe DoH is available in other browsers, or may be in the future, and it can be implemented via the OS outside of the browser to be more effective. If you see alternative scenarios, outside of a VPN, then feel free to let us know.