OpenBSD Disabled DoH by Default in Firefox(undeadly.org)
undeadly.org
OpenBSD Disabled DoH by Default in Firefox
https://undeadly.org/cgi?action=article;sid=20190911113856
8 comments
It's not a matter of knowledge. If each application ignores the OS DNS configuration in favor of its own, it's no longer possible to make a system-wide change to it. You have to change each application individually, and then go back and do it again for each one that updates to a version that adds its own support for DoH.
You also then end up with each application using its own implementation, but DoH is a complex protocol (DNS+TLS+HTTP), so that's a lot of attack surface. Better to have one high-quality up-to-date implementation in the OS than dozens of applications that each get their own chance to screw it up.
It also breaks all of the usual things that make local DNS work. Your local DHCP server provides your local DNS server which includes entries for the local names with RFC1918 addresses that are only accessible on the local network. Move to DoH via some default external provider and that breaks and requires touching every application on every client to fix it.
You also then end up with each application using its own implementation, but DoH is a complex protocol (DNS+TLS+HTTP), so that's a lot of attack surface. Better to have one high-quality up-to-date implementation in the OS than dozens of applications that each get their own chance to screw it up.
It also breaks all of the usual things that make local DNS work. Your local DHCP server provides your local DNS server which includes entries for the local names with RFC1918 addresses that are only accessible on the local network. Move to DoH via some default external provider and that breaks and requires touching every application on every client to fix it.
> It also breaks all of the usual things that make local DNS work. Your local DHCP server provides your local DNS server which includes entries for the local names with RFC1918 addresses that are only accessible on the local network. Move to DoH via some default external provider and that breaks and requires touching every application on every client to fix it.
This is not true, Firefox will fallback to your OS configured name resolver if it can't find a name. You can also set it to strict mode so it will only use DOH, but this is not the option that Firefox set by default.
https://blog.mozilla.org/futurereleases/2019/09/06/whats-nex...
This is not true, Firefox will fallback to your OS configured name resolver if it can't find a name. You can also set it to strict mode so it will only use DOH, but this is not the option that Firefox set by default.
https://blog.mozilla.org/futurereleases/2019/09/06/whats-nex...
Better, but still broken because in many cases the names also exist in the global DNS but should have different addresses, e.g. because they have port mappings from public addresses but you don't want to have to use hairpin NAT for local connections, or the local router doesn't support that.
It also implies that you're sending all queries for local names to an external provider when that otherwise wouldn't be happening.
It also implies that you're sending all queries for local names to an external provider when that otherwise wouldn't be happening.
This is also covered (mostly) by Firefox. In enterprise configurations DOH will be disabled by default, and this should cover most of the cases above.
https://blog.mozilla.org/futurereleases/2019/09/06/whats-nex...
https://blog.mozilla.org/futurereleases/2019/09/06/whats-nex...
That's really the opposite of those cases. If you're using group policy then Mozilla's default doesn't matter very much because you can set it to whatever you want using group policy anyway. Where the default really matters is on the devices where it has to be changed via high friction individualized action, e.g. BYOD.
I completely understand why they want to support DoH. And then Firefox users with untrustworthy DNS providers would have a solution to it which is no more complicated than a single checkbox to enable it. But what is really being gained over that, which is worth all the trouble of making it the default even for all the people whose existing DNS providers are no less trustworthy than Cloudflare and far less centralized?
I completely understand why they want to support DoH. And then Firefox users with untrustworthy DNS providers would have a solution to it which is no more complicated than a single checkbox to enable it. But what is really being gained over that, which is worth all the trouble of making it the default even for all the people whose existing DNS providers are no less trustworthy than Cloudflare and far less centralized?
> But what is really being gained over that
Try to explain for a common person what benefits DOH brings to them, or why their DNS provider is unstrustworthy.
> [...] which is worth all the trouble of making it the default even for all the people whose existing DNS providers are no less trustworthy than Cloudflare and far less centralized?
A small number of people will actually have those "trouble" that you speak, and for most of them the case is so specific that they probably are power users that can figure out themselves.
Try to explain for a common person what benefits DOH brings to them, or why their DNS provider is unstrustworthy.
> [...] which is worth all the trouble of making it the default even for all the people whose existing DNS providers are no less trustworthy than Cloudflare and far less centralized?
A small number of people will actually have those "trouble" that you speak, and for most of them the case is so specific that they probably are power users that can figure out themselves.
While I agree with everything you're saying, maybe this should be a wake up call about who Mozilla is as a company. They are very manipulative too, so expect anything negative about them to get downvoted.
I have mixed feelings about this. Yes, we should do what is best for most people, and in particular those who cannot or will not configure it by themselves. But I, too, would like to have good defaults.
In this particular case it seems relatively easy: have a blacklist of bad ISPs (similar to how we keep track of phishing sites) and enable it by default for those users (they already have lots of remote calls built in, such as http://detectportal.firefox.com/success.txt or the update check, which could easily check to which ISP the request comes from).
In the general case, I guess it would be something to choose on first run, which nobody wants. Perhaps there should be a flag/setting "I do want first-run questions for questionable defaults", so that I don't have to hear through the media which settings I have to change after the next update?
In this particular case it seems relatively easy: have a blacklist of bad ISPs (similar to how we keep track of phishing sites) and enable it by default for those users (they already have lots of remote calls built in, such as http://detectportal.firefox.com/success.txt or the update check, which could easily check to which ISP the request comes from).
In the general case, I guess it would be something to choose on first run, which nobody wants. Perhaps there should be a flag/setting "I do want first-run questions for questionable defaults", so that I don't have to hear through the media which settings I have to change after the next update?
Also what would I change it to? Cloudflare was already my selected dns provider. Is the issue that DoH will leak individual pages, not just domains? If not I'm not clear what the issue is. I trust cloudflare more than my isp.
Quite literally anything you wanted to change it too. Google. Cloudflare. Your local ISP. Amazon. Verasign. Level3.
Or you can run your own and do your own recursive lookups.
Or you can run your own and do your own recursive lookups.
Running one's own sounds like the only one that would increase your privacy more than cloudflare... but I worry if I slip up and don't keep patches etc up to date a private dns server could be more harmful. Probably better to leave such things to professionals.
You can also argue that an OpenBSD user is not your average user. So I think the default from Firefox makes sense (since most of Firefox users are on Windows and should probably be average users), and the fact that OpenBSD override that default also makes sense.
Possible Future abuses aside, I much prefer knowing who I'm trusting Mozilla and CloudFlare with a public reputations to preserve than ISPs that make no assertions and regularly voilate privacy.
Instead of using a different DoH server than the user set DNS servers, Firefox should test if the user supplied DNS servers support DoH and opportunistically switch over to that.
DoH should be supported on the OS network stack, if needed.
I can’t understand this move. Firefox should retreat from this default.
I can’t understand this move. Firefox should retreat from this default.
Are Linux/Mac/Windows actually working on adding DoH to their network stack? I never heard anything regarding this.
And what would be the relationship to DHCP?
And what would be the relationship to DHCP?
Not sure about Linux/Mac/Windows, but for OpenBSD, you can simply use unbound in base system to enable DoH (EDIT: No, it's not DoH, it's DoT) for everything in your system.
https://man.openbsd.org/unbound.conf
https://man.openbsd.org/unbound.conf
I don't think unbound supports DoH yet (the manpage you link doesn't mention it either). But AFAIK it does DoT.
EDIT: clearly shouldn't have used unexplained acronyms: DoH = DNS over HTTPS, DoT = DNS over TLS (which typically uses port 853)
EDIT: clearly shouldn't have used unexplained acronyms: DoH = DNS over HTTPS, DoT = DNS over TLS (which typically uses port 853)
Which is better, since it avoids ridiculously complicated web standards like HTTP2 for simple DNS lookups.
It sounds bad, but the fact that it can’t be blocked is important in terms of censorship.
DNS over TLS can be easily blocked by blocking port 853. To block DNS over HTTPS you need to block the entire HTTPS traffic.
DNS over TLS can be easily blocked by blocking port 853. To block DNS over HTTPS you need to block the entire HTTPS traffic.
If that's the concern, you can run a DNS server on port 443.
DOH also doesn't help much with censorship: If you look at traffic patterns, you can detect and block DOH servers pretty easily: look for small queries to a constant endpoint that come just before new connections.
DOH also doesn't help much with censorship: If you look at traffic patterns, you can detect and block DOH servers pretty easily: look for small queries to a constant endpoint that come just before new connections.
“You” need to run port 443 DNS server. Instead we can make this mandatory for everyone.
Your explained method is nearly impossible to implement for medium to large scale networks.
Your explained method is nearly impossible to implement for medium to large scale networks.
Why? I can't imagine it'd make most flow inspecting firewalls and middleboxes break a sweat. If you want extra confirmation before banning, you can fire off a DNS query before killing the connection.
Hell, you can go even more trivial with barely any effort: for every new https connection to an unknown server, send a DNS query. If you get a response, block the IP.
HTTP adds nothing but complexity.
Hell, you can go even more trivial with barely any effort: for every new https connection to an unknown server, send a DNS query. If you get a response, block the IP.
HTTP adds nothing but complexity.
The primary advantage to HTTP is that you can run the DNS server on the same host as an ordinary HTTP server that serves other pages. And then, especially for the likes of Cloudflare, that makes it harder to block.
But what they should have done (and still could) is to have the server use SNI to determine whether it should speak HTTPS or DoT and then let the clients use DoT by providing the relevant server name.
But what they should have done (and still could) is to have the server use SNI to determine whether it should speak HTTPS or DoT and then let the clients use DoT by providing the relevant server name.
Oh no no no, it does add security.
Think DNS over TLS. Okay. You think $ip:$port is a dns connection. You send query with DoT protocol. You get answers. Bingo! It’s DNS.
If it’s DNS over HTTPS, you can’t tell. What domain(dns.quad9.net or cloudflare-dns.com or dns.google or whatever you can imagine) is it? What endpoint and method(/dns-query?url= or whatever you can imagine) is it? You can’t tell.
HTTP adds complexity. Complexity adds security.
Think DNS over TLS. Okay. You think $ip:$port is a dns connection. You send query with DoT protocol. You get answers. Bingo! It’s DNS.
If it’s DNS over HTTPS, you can’t tell. What domain(dns.quad9.net or cloudflare-dns.com or dns.google or whatever you can imagine) is it? What endpoint and method(/dns-query?url= or whatever you can imagine) is it? You can’t tell.
HTTP adds complexity. Complexity adds security.
If I can't tell, neither can the legitimate users. This makes queries that would out of the box rather hard.
And you still have the traffic patterns that will give you the information with sufficient confidence.
And you still have the traffic patterns that will give you the information with sufficient confidence.
Why should legit users need to check whether a packet is to a dns server or not?
And blocking https packets with mere confidence is impossible.
And blocking https packets with mere confidence is impossible.
[deleted]
It's called TLS upstream.
(I guess DNS over https and DNS over TLS is the same thing.)
> tls-upstream: <yes or no> > Enabled or disable whether the upstream queries use TLS only for transport.
BTW, you can also use it on Linux.
https://www.dnsknowledge.com/unbound/configure-unbound-dns-o...
(I guess DNS over https and DNS over TLS is the same thing.)
> tls-upstream: <yes or no> > Enabled or disable whether the upstream queries use TLS only for transport.
BTW, you can also use it on Linux.
https://www.dnsknowledge.com/unbound/configure-unbound-dns-o...
The problem with this is that the language runtimes now have to have an http client implementation. DNS isn’t super simple but I would argue it’s much simpler than http. DoH is a very good idea and we need the security it provides but I think using http as the protocol is probably a mistake and will prevent it from being widely adopted.
Yes. A DNS client was trivial to implement for Myrddin. 550 lines of code. HTTP2 would be incredibly big in comparison.
https://git.eigenstate.org/ori/mc.git/tree/lib/std/resolve+p...
https://git.eigenstate.org/ori/mc.git/tree/lib/std/resolve+p...
(note, more than half of the code is in reading the hosts file and parsing resolv.conf, so DNS itself is about 200 lines)
You probably don't need a full-fledged general-purpose HTTP implementation to do DOH.
However you'd need a pretty complete TLS implementation in the network stack. Which I guess you also need to provide DNS over TLS.
However you'd need a pretty complete TLS implementation in the network stack. Which I guess you also need to provide DNS over TLS.
Yes. I wish we were discussing dnscurve: https://en.m.wikipedia.org/wiki/DNSCurve
Dnscurve didn't secure the stub to recursive link but the recursive to authoritative link. Idea was you wouldn't use recursive. The performance impact plus politics were too much so no adoption. Plus some operational problems with name server names.
Yes, this really is the correct way to do this. Mozilla adds a lot of complexity when it isn't necessary. I often feel like they are disingenuous.
Why? I assumed everyone asking for it to be OS level would mean that the system resolver does DoH while normal clients continue doing regular DNS. Otherwise what would it even mean to be OS-level if all the client applicatios are doing DoH themselves...?
Some argue that it's better than nothing, seeing the lack of progress on this matter at the OS level
I don’t see anything sinister here. Many of us who care about utilizing DoH may already have an appliance that performs this task, but leaving it as an option users can eventually opt into is a good thing.
If Google was the one offering DoH, and Otto made this change basically saying, “We don’t want all our traffic going to Google,” I think it would add perspective.
If Google was the one offering DoH, and Otto made this change basically saying, “We don’t want all our traffic going to Google,” I think it would add perspective.
There are arguments against Mozilla's current DoH rollout. DNS should be an OS setting and it should not default to a single commercial company. Both are totally valid and I hope be addressed as DoH matures.
Or do you mean nothing sinister in this OpenBSD move? Well, it is kind of ironic to downgrade Firefox defaults to unencrypted DNS, since the absence of any modern & encrypted DNS on OSes was likely the only reason Mozilla felt the need for the switch in the first place. And this move doesn't seem to address this underlying issue of unsafe defaults caused by OSes like OpenBSD and thus feels a lot like some "no, shut up, everything is fine" reaction to criticism.
Or do you mean nothing sinister in this OpenBSD move? Well, it is kind of ironic to downgrade Firefox defaults to unencrypted DNS, since the absence of any modern & encrypted DNS on OSes was likely the only reason Mozilla felt the need for the switch in the first place. And this move doesn't seem to address this underlying issue of unsafe defaults caused by OSes like OpenBSD and thus feels a lot like some "no, shut up, everything is fine" reaction to criticism.
Agreed. But I do see it as very similar to preloaded/preselected search. We're numb to that feature of browsers and sometimes fail to remember we don't need them. In many regards DNS in the browser gives back control to the end user. As governments and service providers encroach DoH and DoT are leveling the playing field.
Also keep in mind there are different modes DoH in Firefox can operate in. [0] Ultimately I welcome the feature and hope we see more not-for-profit options as defaults in Firefox.
[0] https://wiki.mozilla.org/Trusted_Recursive_Resolver
Also keep in mind there are different modes DoH in Firefox can operate in. [0] Ultimately I welcome the feature and hope we see more not-for-profit options as defaults in Firefox.
[0] https://wiki.mozilla.org/Trusted_Recursive_Resolver
> If Google was the one offering DoH, ...
Related: With Chrome 78, Google is starting to "experiment" with ("an auto-upgrade approach" to) DNS over HTTPS (DoH) [0], as previously discussed [1] a few days ago.
There are some very notable differences from Firefox's testing, however (in particular, they will be "keeping the user’s DNS provider unchanged").
[0]: https://www.chromium.org/developers/dns-over-https
[1]: https://news.ycombinator.com/item?id=20929720
Related: With Chrome 78, Google is starting to "experiment" with ("an auto-upgrade approach" to) DNS over HTTPS (DoH) [0], as previously discussed [1] a few days ago.
There are some very notable differences from Firefox's testing, however (in particular, they will be "keeping the user’s DNS provider unchanged").
[0]: https://www.chromium.org/developers/dns-over-https
[1]: https://news.ycombinator.com/item?id=20929720
As a European, I also find it very weird to enable this globally by default. I really don't want to send my traffic to a third party on some other continent that gives me a service for free. I pay my ISP good money to do this for me.
No idea how common this is in other countries, but my ISP doesn't sniff or sell my traffic. I've only ever heard about that on HN or Reddit, which are USA-centric. I guess it also happens in other countries, but in the EU such a thing would have to be made known to the user because it processes personal data.
Somehow, adding a Pocket button is bad but sending all visited websites to Cloudflare is good. The top two comments (and many others) on the thread about Pocket can be applied here as well if you just replace the name "Pocket" with "Cloudflare": https://news.ycombinator.com/item?id=9667809
No idea how common this is in other countries, but my ISP doesn't sniff or sell my traffic. I've only ever heard about that on HN or Reddit, which are USA-centric. I guess it also happens in other countries, but in the EU such a thing would have to be made known to the user because it processes personal data.
Somehow, adding a Pocket button is bad but sending all visited websites to Cloudflare is good. The top two comments (and many others) on the thread about Pocket can be applied here as well if you just replace the name "Pocket" with "Cloudflare": https://news.ycombinator.com/item?id=9667809
Indian here. My ISP does inject ads into plain HTTP traffic, so based on that user-hostile behaviour I assume that they also record my DNS queries and/or sell them. Also whether or not they do that, they are mandated by govt to keep DNS query records for at least 18 months (last I looked) and then anonymise them. Under the current authoritarian leaning govt, I wouldn't be surprised if rules have been revised mandating indefinite recording.
Interesting, thanks for adding that data point. I'm wondering if there is a list of this somewhere, it seems like the kind of thing we'd want to track (similar to e.g. the press freedom map https://rsf.org/en/ranking )
But the proper solution for that is DNS-over-TLS and picking or running your own recursive DNS resolver.
Is it not possible to have a recursive DNS resolver with DNS over HTTPS? I.e. are their more differences between DoH and DNS over TLS than just the port number?
i think DoH is DNS wireformat via http over TLS whereas DNS over TLS is the plain wireformat over TLS.
EDIT: so for DoH you would need to speak HTTP but for DNS over TLS you only need to wrap TLS around for example by using stunnel or something.
EDIT: so for DoH you would need to speak HTTP but for DNS over TLS you only need to wrap TLS around for example by using stunnel or something.
Sorry if I'm dense, but that would mean that the two protocols _are_ the same except for port number for practical purposes right? I mean there's no reason why the same actions could be taken when running straight wireformat vs over http right?
edit: In response to your edit :)
So is the main objection to this that it breaks traditional layering then? E.g. here's a post in a thread that I found a bit helpful:
https://old.reddit.com/r/privacy/comments/89pr15/dnsoverhttp...
(The rest of the thread is interesting as well.)
I guess one downside with DoH is that now there's a larger incentive to break through your https in general?
edit: In response to your edit :)
So is the main objection to this that it breaks traditional layering then? E.g. here's a post in a thread that I found a bit helpful:
https://old.reddit.com/r/privacy/comments/89pr15/dnsoverhttp...
(The rest of the thread is interesting as well.)
I guess one downside with DoH is that now there's a larger incentive to break through your https in general?
i was only responding to your question whether there is any difference between the two beside the port number used which there is, in a significant way. You can not point a DoH client to a DNS over TLS server or vice versa. That said there is no reason a DoH server could not be recursive or consult a traditional (probably recursive) resolver for its response.
I think the only benefit of DoH is that is unlikely to be blocked. Otherwise it feels more like a hack and at least i am not concerned about OSI models ;)
Actually, i tried to setup a DNS over TLS server some weeks ago but while it worked like intended i had a hard time to get reasonable response times even after somewhat serious fine tuning for the session setup (i used haproxy at server side). But this was mainly caused by the fact that systemd-resolved established a new connection for each and every request and i did not find a stub resolver that did not either.
I think the only benefit of DoH is that is unlikely to be blocked. Otherwise it feels more like a hack and at least i am not concerned about OSI models ;)
Actually, i tried to setup a DNS over TLS server some weeks ago but while it worked like intended i had a hard time to get reasonable response times even after somewhat serious fine tuning for the session setup (i used haproxy at server side). But this was mainly caused by the fact that systemd-resolved established a new connection for each and every request and i did not find a stub resolver that did not either.
> i was only responding to your question whether there is any difference between the two beside the port number used which there is, in a significant way. You can not point a DoH client to a DNS over TLS server or vice versa. That said there is no reason a DoH server could not be recursive or consult a traditional (probably recursive) resolver for its response.
> I think the only benefit of DoH is that is unlikely to be blocked. Otherwise it feels more like a hack and at least i am not concerned about OSI models ;)
Thanks for the response, but I'm still a little confused. If you live in the DoH stack you must stay there sure, but the same apparently applies to the DNS over TLS. What to you exactly is hacky about the DoH method if you don't care about the layering violations?
> I think the only benefit of DoH is that is unlikely to be blocked. Otherwise it feels more like a hack and at least i am not concerned about OSI models ;)
Thanks for the response, but I'm still a little confused. If you live in the DoH stack you must stay there sure, but the same apparently applies to the DNS over TLS. What to you exactly is hacky about the DoH method if you don't care about the layering violations?
There's a huge difference though. Regardless of what you choose, your DNS requests have to go somewhere. The alternative to sending everything encrypted to Cloudflare is sending everything in plain text to your ISP and anyone else who wants to snoop on your DNS.
> The alternative to sending everything encrypted to Cloudflare is sending everything in plain text to your ISP and anyone else who wants to snoop on your DNS.
It's not the alternative. With DoH you are sending DNS queries, IP addresses, OS information and possibly even tracking cookies to Cloudflare over an encrypted channel, but Cloudflare still makes plain text queries to authoritative DNS servers from there. While your ISP's network is actually private, sometimes even encrypted, and sending plain text queries over it to its DNS servers is almost the same as having an encrypted channel. On top of that whether you use DoH to Cloudflare or not, your ISP sitll has the ability to spy on what websites you are visiting and in fact is what an ISP typically would use for that purpose anyway, not DNS data.
It's not the alternative. With DoH you are sending DNS queries, IP addresses, OS information and possibly even tracking cookies to Cloudflare over an encrypted channel, but Cloudflare still makes plain text queries to authoritative DNS servers from there. While your ISP's network is actually private, sometimes even encrypted, and sending plain text queries over it to its DNS servers is almost the same as having an encrypted channel. On top of that whether you use DoH to Cloudflare or not, your ISP sitll has the ability to spy on what websites you are visiting and in fact is what an ISP typically would use for that purpose anyway, not DNS data.
That’s right. It knows what IPs you connect to and can do a reverse lookup
You're going to have to explain that last bit: "and everyone else who wants to snoop"? Are you talking about someone who MITMs the connection between every subscriber and the ISP's DNS servers, e.g. intelligence agencies? Or like evil employees at the ISP? In either case, sending it plaintext to a benevolent foreign entity doesn't make it any better (Cloudflare still has employees that can be evil, and I'd rather the AIVD snoops on me than the NSA), so I guess there is some other risk you're talking about?
Flat out here in the USA, My ISP Sells my DNS Traffic to third parties for money, On top of charging me for shitty internet. It happens more often then not since its easy to do and no one will notice that you are doing it.
[deleted]
> Somehow, adding a Pocket button is bad but sending all visited websites to Cloudflare is good.
I think this is an interesting point. Given that quite a few people here on HN have problems with both of these "features", should OpenBSD be disabling them both on their builds?
I think this is an interesting point. Given that quite a few people here on HN have problems with both of these "features", should OpenBSD be disabling them both on their builds?
Pocket is opt-in. You can remove or ignore the button and it will not be used.
"Pocket" as a product now also includes advertising shown by default on the new tab page, so I'm referring to that too.
Firefox is only making this change in the US.
Are they? I've not seen that mentioned anywhere.
What do you know! Thanks for the link, I guess that means my comment is invalid.
ISPs in Sweden have been working hard at "dis-earning" my trust. Telia shared user data to torrening blackmail companies and some other ISP apparently had many of their clients get blackmails concerning their porn surfing.
Cloudflare discloses what data it logs and with whom they share it (APNIC gets properly anonymised data that can only be used for limited purposes iirc).
My ISP has a blanket "we share your data with selected partners as a way to better provide you with our services" (as has all my previous ISPs). When I have time I am hitting them and my bank with GDPR requests.
Cloudflare discloses what data it logs and with whom they share it (APNIC gets properly anonymised data that can only be used for limited purposes iirc).
My ISP has a blanket "we share your data with selected partners as a way to better provide you with our services" (as has all my previous ISPs). When I have time I am hitting them and my bank with GDPR requests.
GDPR requests shouldn't be a lot of work, most data protection agencies provide example letters. I usually customize them a little, but it's mostly copy-paste. I guess the most laborious part is censoring and watermarking a picture/scan of your ID/passport.
At least Pocket belongs to Mozilla.
https://en.wikipedia.org/wiki/Pocket_%28service%29
https://en.wikipedia.org/wiki/Pocket_%28service%29
I thought so too but it turns out they are only owned by Mozilla as of 2017. The Pocket integration launched in 2015.
Does anyone know a good resource for someone who hasn't done a deep dive on networking in a while, but wants to brush up on the technicals of how DoH works?
How about this APNIC blog post?
https://blog.apnic.net/2018/10/12/doh-dns-over-https-explain...
https://blog.apnic.net/2018/10/12/doh-dns-over-https-explain...
https://en.wikipedia.org/wiki/Zooko%27s_triangle
There have been attempts at solving this through P2P DNS resolution. But, it's just hard to store all those records locally and keep them up-to-date regularly. Perhaps, we could cache and update records for the "popular" domains regularly and reach out to Cloudflare/other DoH or DoTLS providers when the tier 1 lookup fails?
There have been attempts at solving this through P2P DNS resolution. But, it's just hard to store all those records locally and keep them up-to-date regularly. Perhaps, we could cache and update records for the "popular" domains regularly and reach out to Cloudflare/other DoH or DoTLS providers when the tier 1 lookup fails?
Anyone who needs some other configuration, clearly is knowledgeable enough to change the behavior.