Wikipedia:Reference desk/Archives/Computing/2020 June 19
| Computing desk | ||
|---|---|---|
| < June 18 | << May | June | Jul >> | Current desk > |
| Welcome to the Wikipedia Computing Reference Desk Archives |
|---|
| The page you are currently viewing is a transcluded archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages. |
June 19
[edit]How do DoH resolvers communicate with DNS Root Servers?
[edit]Dear Wikipedians:
DoH (DNS-over-HTTPS) resolvers are about to become the norm. I am just wondering how do DoH resolvers communicate with DNS Root Name Servers (and, by extension, TLD Name Servers and the Authoritative Name Servers of the actual destination domains themselves). Do DoH resolvers communicate with DNS Root Servers also via HTTPS or via good-old plain-text. In the latter case wouldn't it defeat the purpose of DoH as spies and forgers can simply move their operations upstream?
Any insights are much appreciated.
174.138.195.251 (talk) 15:16, 19 June 2020 (UTC)
- Are you talking about nameservers or resolvers? DoH resolvers are the end-points, such as the Firefox browser. A nameserver which receives DoH queries will typically communicate upstream via UDP. Elizium23 (talk) 15:29, 19 June 2020 (UTC)
- Link: DNS over HTTPS. The root nameservers are DNSSEC-enabled. DNSSEC defeats forgers as it provides authentication. Not spies, but they gain no information as the root nameserver file is public and they can see you're communicating with the root nameservers regardless. --47.146.63.87 (talk) 16:25, 19 June 2020 (UTC)
- I apologize for the unclear terminologies. Allow me to illustrate what I want to really ask: Let's say a Firefox user in China sends a DoH query to 1.1.1.1, but the Chinese Government does not like the fact that 1.1.1.1 will send the true (as opposed to a fake) IP address for Wikipedia to the Firefox user in China (and that the Great Firewall of China is unable to tamper with DoH query results as it's encrypted with HTTPS), therefore the Chinese Government has the Great Firewall of China block 1.1.1.1 at the IP level (which is quite easy to do as there is only one IP address to block). Left with no choices, the Firefox user in China sends the same DoH query to a domestic Chinese equivalent of 1.1.1.1, since the domestic Chinese equivalent of 1.1.1.1 will likely not have the entire DNS directory at its disposal, it too will need to reach across the Great Firewall to communicate with the DNS root server, and from there down the cascade (TLD, second-level domain authoritative name servers) until it gets the final IP address, since all these communications will cross the Great Firewall, if they are in UDP and clear-text, they could be tampered with by the Great Firewall. Even if it's DNSSEC enabled, still doesn't prevent the Great Firewall from seeing that it is "Wikipedia" that the Firefox user in China is looking for, and to forcibly shut down the whole transaction at that point. 174.138.195.251 (talk) 16:41, 19 June 2020 (UTC)
- Well yeah, that's correct. The Great Firewall works mainly by IP address blocking anyway, as you touched on. Having the wikipedia.org IP addresses doesn't do you any good if you're behind it since it just blocks those addresses. Remember, DNS is just a "phonebook" that exists primarily so humans don't have to remember IP addresses. --47.146.63.87 (talk) 17:14, 19 June 2020 (UTC)
- Oh bummer, I supposed there's no way to encrypt the IP address so that the Great Firewall won't know that it's Wikipedia's IP address, right? 174.138.195.251 (talk) 02:35, 20 June 2020 (UTC)
- No letter can be delivered if it doesn't have a legible address on it. Similarly no packet can be delivered to an IP address if the servers in the network can't know the destination address. If China has a list of all outside DoH servers and blocks them all, job done. That's why this Mozilla initiative is complete bullshit. It introduces a "protection" for which the countermeasure is truly trivial, but was often not implemented before because a very small number of people depended on DoH. As it becomes popular, those people are going to be screwed. A victory for censors. 93.136.75.126 (talk) 13:51, 20 June 2020 (UTC)
- Totally agree with you on the letter delivery analogy. With respect to the "countermeasure being trivial": the only exception I can see to that is if Cloudflare decides to add DoH roles to its CDN servers, that way China dare not block those IP addresses without effectively shutting down the entire Internet (which will severely affect China's ability to conduct trade with the rest of the world and impact severely negatively China's economy), this strategy is known as "collateral freedom" I believe. 174.138.195.251 (talk) 16:20, 20 June 2020 (UTC)
- That's an interesting idea. A CDN whose IP addresses don't correspond to web pages it's serving, along with its own DoH server would essentially function like a walled garden VPN. The question is, is Cloudflare big enough not to get blocked and brave enough not to collaborate with China like Google, Facebook & co. Also I'm not sure how this would work with SSL certificates, the hidden websites might have to use Cloudflare's certificates without references to the domain name (some of that might be happening already, I don't know much about CDNs). 93.136.75.126 (talk) 02:17, 21 June 2020 (UTC)
- Actually I think CDN's purpose is to serve many different websites using the same IP address, so "IP addresses don't correspond to web pages it's serving" would be the norm for CDN, and that ESNI can be used to further hide which website visitors are actually trying to see by encrypting the only plaintext instance of the domain name used during ClientHello handshaking. 174.138.195.251 (talk) 04:11, 21 June 2020 (UTC)
- That's an interesting idea. A CDN whose IP addresses don't correspond to web pages it's serving, along with its own DoH server would essentially function like a walled garden VPN. The question is, is Cloudflare big enough not to get blocked and brave enough not to collaborate with China like Google, Facebook & co. Also I'm not sure how this would work with SSL certificates, the hidden websites might have to use Cloudflare's certificates without references to the domain name (some of that might be happening already, I don't know much about CDNs). 93.136.75.126 (talk) 02:17, 21 June 2020 (UTC)
- Totally agree with you on the letter delivery analogy. With respect to the "countermeasure being trivial": the only exception I can see to that is if Cloudflare decides to add DoH roles to its CDN servers, that way China dare not block those IP addresses without effectively shutting down the entire Internet (which will severely affect China's ability to conduct trade with the rest of the world and impact severely negatively China's economy), this strategy is known as "collateral freedom" I believe. 174.138.195.251 (talk) 16:20, 20 June 2020 (UTC)
- Sorry misunderstood your question here. You can connect to Wikipedia via a proxy or VPN tunnel which has both ends on different sides of the the Great Firewall. That way the Great Firewall doesn't see the Wikipedia IP or the contents of the DNS query. It only sees the IP of the proxy server or VPN server to which you're connecting, and which is outside China. But that setup has no need for DoH whatsoever, as everything is already encrypted. 93.136.75.126 (talk) 13:55, 20 June 2020 (UTC)
- No problem at all, in fact I quite like your. Of course I know that proxy/VPN/VPS/shadowsocks are the answers, but the problem with proxy/VPN is that Wikipedia has now banned so much VPN/proxy addresses as to render editing of contents practically impossible for anyone visiting Wikipedia via VPN/proxy. It would help very much if people in China are able to visit Wikipedia directly from their own home ISP IP addresses without having to use any proxy/VPN, that way they then can edit Wikipedia and communicate much as I'm doing right now. (And even for me it was not easy to be able to edit like this, my entire house runs on ExpressVPN router, all the addresses of which are banned from editing on Wikipedia, and even if I use my VPS at Bandwagon, that IP address is STILL banned by the English version of Wikipedia (not the CHinese), there is only one computer in the entire house that's hooked up directly to the DSL modem and not the ExpressVPN router, which can then be used to upload posts like this to Wikipedia). 174.138.195.251 (talk) 16:20, 20 June 2020 (UTC)
- There are some whitelisted proxies, and you can also get an IP block exemption for an account that let you edit while logged in. See Wikipedia:Open proxies. --47.146.63.87 (talk) 22:32, 20 June 2020 (UTC)
- No problem at all, in fact I quite like your. Of course I know that proxy/VPN/VPS/shadowsocks are the answers, but the problem with proxy/VPN is that Wikipedia has now banned so much VPN/proxy addresses as to render editing of contents practically impossible for anyone visiting Wikipedia via VPN/proxy. It would help very much if people in China are able to visit Wikipedia directly from their own home ISP IP addresses without having to use any proxy/VPN, that way they then can edit Wikipedia and communicate much as I'm doing right now. (And even for me it was not easy to be able to edit like this, my entire house runs on ExpressVPN router, all the addresses of which are banned from editing on Wikipedia, and even if I use my VPS at Bandwagon, that IP address is STILL banned by the English version of Wikipedia (not the CHinese), there is only one computer in the entire house that's hooked up directly to the DSL modem and not the ExpressVPN router, which can then be used to upload posts like this to Wikipedia). 174.138.195.251 (talk) 16:20, 20 June 2020 (UTC)
- That's what HTTPS does: encrypt the traffic. Nothing personal but something apparently isn't clicking for you. Having Wikipedia's IP addresses doesn't do you any good if you're behind the Great Firewall, because the Great Firewall blocks you from being able to connect to those addresses. That's the point of a firewall. You seem to have the idea that the Firewall works by mucking with DNS traffic. It doesn't, primarily. It just stops all traffic going to/from "bad" IP addresses. If you're in the PRC and I send you Wikipedia's IP addresses on paper concealed in innocuous printed material and ciphered with an unbreakable one-time pad, you will find them useless because you will just be unable to connect to them when you tell your computer to do so. --47.146.63.87 (talk) 22:32, 20 June 2020 (UTC)
- The reason you feel it didn't click for me is because you thought I meant if somehow I can encrypt the Wikipedia IP address in the result returned from a DNS query (which is what DoH is designed to do), then I should be able to use it to connect to the actual Wikipedia itself; whereas I do understand that DNS is merely a phonebook, and that knowing Wikipedia's correct IP address (obtained via encryption or steganography) behind the Firewall does me no good at all in helping me to actually connect to the actual Wikipedia servers because the IP addresses themselves have been blacklisted by the Firewall. By "encrypting the IP address", what I meant to say is: wouldn't it be great if in the actual connection payload packets that were being sent to Wikipedia to establish a connection to Wikipedia, if somehow the "DESTINATION IP ADDRESS" header fields of those payload IP packets can be encrypted so that the Firewall won't be able to decipher which IP address those packets are being sent to, but that the ultimate destination, Wikipedia, will know that these payload packets were intended for it. 174.138.195.251 (talk) 04:11, 21 June 2020 (UTC)
- To restate your premise: wouldn't it be great if the computers making up the Internet could route packets to their destinations without being told what those destinations are. Well yes, I suppose it would be more efficient. Only problem is we need omniscient routers. Or to put it another way: the PRC government mandates that ISPs pass all their traffic through the Great Firewall computers. These throw out packets addressed to "bad" hosts. You want some way to fool these computers so they see packets addressed to "good" places, but once they're through, the "smuggled" packet is unpacked and then sent to the real destination. That's exactly what a proxy does. The proxy is your smuggling partner; you send the proxy your packets through the firewall with "smuggled" data concealed inside, and it unpacks them and then sends off the concealed packets to the real destination. But the fundamental problem remains: if the firewall operators learn about your partner's smuggling, they can add them to their "bad" list and start blocking packets addresses to them as well. This only works as long as the proxy stays "under the radar". The central thing to understand here: the Firewall has to send the packets along to somebody, and the only way it knows who is for you to tell it. Unless you're directly connected to the destination with no intermediates (like two computers linked with a crossover cable), each intermediary has to know what to do with the packet. If the packet isn't addressed to anyone it knows how to reach, the packet just goes to the /dev/null dead letter office. --47.146.63.87 (talk) 04:42, 21 June 2020 (UTC)
- Again totally agree with what you said and especially like your analogy of smuggling. Lemme be a bit more explicit about what I want to say: notice how when the Internet was created a long time ago, everything was in clear-text: DNS, and the entire HTTP protocol (and thus the contents of all the webpages exchanged). Overtime, people realized that privacy matters, therefore piece by piece, these fundamental parts of the Internet that people take for granted (and thought wouldn't work unless in plain-text), got redesigned into their current, encrypted versions. Note that it's not done with hacks or workarounds like proxy or VPN, but through solidly redesigning parts of the Internet to make it more surveillance/censorship resistant. And at each stage there were people that said "oh that's impossible to encrypt, it's a fundamental part of how the Internet works and so needs to be in clear-text". People said it when HTTP went to HTTPS, when DNS went to DoH, and when SNI went to ESNI, but piece by piece they've become encrypted and censorship/surveillance-resistant. So now we've come, at last, to the final part of the Internet that is still in clear-text: IP addresses. And once again people are saying how it's impossible to encrypt IP address without omniscient routers or smugglers in the form of proxy/VPNs. I agree that IP address routing is the core of what Internet is and presents a different sort of issue than all the previous encryption efforts. What I am asking: is it possible for us to think outside of the box, to rethink how Internet routes packets, to be creative at a fundamental level, and to re-design this final part of the Internet in a fundamental way (without resorting to hacks like VPN/proxy) that makes it fundamentally more resistant against censorship and surveillance, a new type of/paradigm for IP architecture, so to speak. (I can think of a few examples: TOR-routing, abstract geographical routing that gets specific once it crosses borders, Bittorrent style DHT peer discovery routing, etc). 174.138.195.251 (talk) 16:09, 21 June 2020 (UTC)
- To restate your premise: wouldn't it be great if the computers making up the Internet could route packets to their destinations without being told what those destinations are. Well yes, I suppose it would be more efficient. Only problem is we need omniscient routers. Or to put it another way: the PRC government mandates that ISPs pass all their traffic through the Great Firewall computers. These throw out packets addressed to "bad" hosts. You want some way to fool these computers so they see packets addressed to "good" places, but once they're through, the "smuggled" packet is unpacked and then sent to the real destination. That's exactly what a proxy does. The proxy is your smuggling partner; you send the proxy your packets through the firewall with "smuggled" data concealed inside, and it unpacks them and then sends off the concealed packets to the real destination. But the fundamental problem remains: if the firewall operators learn about your partner's smuggling, they can add them to their "bad" list and start blocking packets addresses to them as well. This only works as long as the proxy stays "under the radar". The central thing to understand here: the Firewall has to send the packets along to somebody, and the only way it knows who is for you to tell it. Unless you're directly connected to the destination with no intermediates (like two computers linked with a crossover cable), each intermediary has to know what to do with the packet. If the packet isn't addressed to anyone it knows how to reach, the packet just goes to the /dev/null dead letter office. --47.146.63.87 (talk) 04:42, 21 June 2020 (UTC)
- Also the Chinese Wikipedia has been hard at working monitoring the state of censorship, you'd be surprised to learn that the Great Firewall so far has not banned the IP addresses of Wikipedia (only the Los Angeles Data Centre has its IP addresses banned), that so far the Firewall has only been mucking around DNS, (and certain Wikipedia sites, such as upload.wikimedia.org, is totally accessible in China, even the DNS is not mucked around with, which allows one to visit upload to "prime the pump", and then to load actual Wikipedia using the same "hot" HTTPS channel that is already established). It's rumoured that once ESNI is here, it will push the Firewall to finally ban all Wikipedia-associated IP addresses. 174.138.195.251 (talk) 04:11, 21 June 2020 (UTC)
- There is a concept known as "collateral freedom" that can resist IP-blocking without resorting to VPN/Proxy, and that's by hosting Wikipedia along with millions of other web sites on a CDN such as CloudFlare. That way, websites that are important for China's foreign commerce (and hence propping up China's economy) will be served from the same IP address(es) as Wikipedia, and with the DoH and ESNI combo coming in the near future, the Great Firewall will not be able to know what site is actually being requested out of those IP addresses, and so it is faced with the dilemma of either allowing all traffic to those IP addresses, or banning the said CDN IP addresses, blocking off all websites, and risking severely damaging China's economy (because it cannot differentiate Wikipedia traffic from regular commerce website traffic). 174.138.195.251 (talk) 04:11, 21 June 2020 (UTC)
- I'm not up with the state of play on the latest proposals but from what I've seen most of them seem to be intended for markets with some degree of freedom or at least a lack of overwhelming state control with the resources and willingness and ability to say screw you to standards or what the world thinks or wants, and a citizenry who are some combination of willing and forced to accept said control and actions. (But as a case in point, I'm aware of the now dead HTTP Public Key Pinning. And I also know when I use a locally hosted interception proxy to analyse traffic once I've installed its root I generally get no complaints from my browsers.) It's questionable if this applies in the Chinese case. For example, the government may very well be willing to make some sort of Great Firewall root server, completely separate from the commercial ones they've tried hard to get external vendors to trust, which they require all computers and phones sold in China to trust. If Chrome and other such browsers make attempts to block said root server, they'll just be banned in China and people will be required to use Baidu or whatever's browser which complies with the government's requirements. Even if proposals are made to try and stop this, worst case China could just implement their own systems and expect browsers and apps to use them in China. (I mean many apps in China are already distinct from those common elsewhere anyway. And for Android, they already have their own app stores, and Apple has so far been fairly willing to follow what China demands. If they really start to refuse despite the high status symbol of iPhones, I'm unconvinced this means the government won't be willing to ban them if needed.) However they do it, they then force encryption to be client/end to great firewall and great firewall to server/end rather than end to end. Sure the world may say how evil this is, but so what? Will Cloudfare etc actually make attempts to block the great firewall? I'm doubtful especially since block wars really work out in the end even more so when the other site is a government with a lot of resources and willingness to play dirty and ignore standards. (Since fundamentals of the internet were brought up, they could for example mess with they way routing works so from Cloudflare's PoV they're simply sending traffic to the IP of some Chinese internet user but in reality this traffic will always go through the great firewall who can do what they want with it before deciding whether to send it on to it's final destination of the actual internet user.) Nil Einne (talk) 02:01, 22 June 2020 (UTC)
- P.S. To put it a different way, you say China won't dare block Cloudflare (or AWS etc) because it will prevent people in China from accessing those sites and services that are in some way important to their economy. But it's unclear to me why you think they won't be willing to block direct access while still allowing indirect access through the great firewall. In fact people have already brought up proxies and VPNs etc to try and bypass the Great Firewall. That's great for those able to work out how to do this despite all the attempts by the Chinese government to stop them. For a lot of people especially with the Chinese efforts to stop them e.g. banning their apps, blocked them as far as they possible, from what I gather it can actually be fairly difficult. Meanwhile there's no reason why China can't require people to use the great firewall proxy/VPN in China. It seems somewhat unnecessary given their pervasive control and it's true this doesn't really solve the problem of encryption (since most normal proxies don't try MITM encryption) but it's difficult to ward off MITM when what's in the "middle" is a pervasive state security apparatus able to require you to let them MITM if you want to use the internet. MITM every Cloudfare and AWS etc connection is going to be very expensive but again I'm not sure if there's any reason to think it will be a barrier. It seems to me more likely they will do what they must, because they can. Nil Einne (talk) 02:24, 22 June 2020 (UTC)
- Totally agree with what you said. If China starts to mandate and force the use of totally customized Chinese terminal devices (smartphones, tablets, laptops) with built-in trust of China-specific security certificates, or better yet, direct-state-monitoring baked-in to all the said terminal devices, then of course it's game-over for most of people in China (either MITM or just out-right kill-screen if state detects you are visiting Wikipedia). In that case, for the built-in China security certificates scenario, StarLink might come in handy. But for the terminal devices scenario, nothing short of actually smuggling in OEM equipments from outside of China will resolve the issue. 174.138.195.251 (talk) 14:01, 22 June 2020 (UTC)
- P.S. To put it a different way, you say China won't dare block Cloudflare (or AWS etc) because it will prevent people in China from accessing those sites and services that are in some way important to their economy. But it's unclear to me why you think they won't be willing to block direct access while still allowing indirect access through the great firewall. In fact people have already brought up proxies and VPNs etc to try and bypass the Great Firewall. That's great for those able to work out how to do this despite all the attempts by the Chinese government to stop them. For a lot of people especially with the Chinese efforts to stop them e.g. banning their apps, blocked them as far as they possible, from what I gather it can actually be fairly difficult. Meanwhile there's no reason why China can't require people to use the great firewall proxy/VPN in China. It seems somewhat unnecessary given their pervasive control and it's true this doesn't really solve the problem of encryption (since most normal proxies don't try MITM encryption) but it's difficult to ward off MITM when what's in the "middle" is a pervasive state security apparatus able to require you to let them MITM if you want to use the internet. MITM every Cloudfare and AWS etc connection is going to be very expensive but again I'm not sure if there's any reason to think it will be a barrier. It seems to me more likely they will do what they must, because they can. Nil Einne (talk) 02:24, 22 June 2020 (UTC)
- I'm not up with the state of play on the latest proposals but from what I've seen most of them seem to be intended for markets with some degree of freedom or at least a lack of overwhelming state control with the resources and willingness and ability to say screw you to standards or what the world thinks or wants, and a citizenry who are some combination of willing and forced to accept said control and actions. (But as a case in point, I'm aware of the now dead HTTP Public Key Pinning. And I also know when I use a locally hosted interception proxy to analyse traffic once I've installed its root I generally get no complaints from my browsers.) It's questionable if this applies in the Chinese case. For example, the government may very well be willing to make some sort of Great Firewall root server, completely separate from the commercial ones they've tried hard to get external vendors to trust, which they require all computers and phones sold in China to trust. If Chrome and other such browsers make attempts to block said root server, they'll just be banned in China and people will be required to use Baidu or whatever's browser which complies with the government's requirements. Even if proposals are made to try and stop this, worst case China could just implement their own systems and expect browsers and apps to use them in China. (I mean many apps in China are already distinct from those common elsewhere anyway. And for Android, they already have their own app stores, and Apple has so far been fairly willing to follow what China demands. If they really start to refuse despite the high status symbol of iPhones, I'm unconvinced this means the government won't be willing to ban them if needed.) However they do it, they then force encryption to be client/end to great firewall and great firewall to server/end rather than end to end. Sure the world may say how evil this is, but so what? Will Cloudfare etc actually make attempts to block the great firewall? I'm doubtful especially since block wars really work out in the end even more so when the other site is a government with a lot of resources and willingness to play dirty and ignore standards. (Since fundamentals of the internet were brought up, they could for example mess with they way routing works so from Cloudflare's PoV they're simply sending traffic to the IP of some Chinese internet user but in reality this traffic will always go through the great firewall who can do what they want with it before deciding whether to send it on to it's final destination of the actual internet user.) Nil Einne (talk) 02:01, 22 June 2020 (UTC)
- The reason you feel it didn't click for me is because you thought I meant if somehow I can encrypt the Wikipedia IP address in the result returned from a DNS query (which is what DoH is designed to do), then I should be able to use it to connect to the actual Wikipedia itself; whereas I do understand that DNS is merely a phonebook, and that knowing Wikipedia's correct IP address (obtained via encryption or steganography) behind the Firewall does me no good at all in helping me to actually connect to the actual Wikipedia servers because the IP addresses themselves have been blacklisted by the Firewall. By "encrypting the IP address", what I meant to say is: wouldn't it be great if in the actual connection payload packets that were being sent to Wikipedia to establish a connection to Wikipedia, if somehow the "DESTINATION IP ADDRESS" header fields of those payload IP packets can be encrypted so that the Firewall won't be able to decipher which IP address those packets are being sent to, but that the ultimate destination, Wikipedia, will know that these payload packets were intended for it. 174.138.195.251 (talk) 04:11, 21 June 2020 (UTC)
- No letter can be delivered if it doesn't have a legible address on it. Similarly no packet can be delivered to an IP address if the servers in the network can't know the destination address. If China has a list of all outside DoH servers and blocks them all, job done. That's why this Mozilla initiative is complete bullshit. It introduces a "protection" for which the countermeasure is truly trivial, but was often not implemented before because a very small number of people depended on DoH. As it becomes popular, those people are going to be screwed. A victory for censors. 93.136.75.126 (talk) 13:51, 20 June 2020 (UTC)
- Oh bummer, I supposed there's no way to encrypt the IP address so that the Great Firewall won't know that it's Wikipedia's IP address, right? 174.138.195.251 (talk) 02:35, 20 June 2020 (UTC)
- Well yeah, that's correct. The Great Firewall works mainly by IP address blocking anyway, as you touched on. Having the wikipedia.org IP addresses doesn't do you any good if you're behind it since it just blocks those addresses. Remember, DNS is just a "phonebook" that exists primarily so humans don't have to remember IP addresses. --47.146.63.87 (talk) 17:14, 19 June 2020 (UTC)
- I apologize for the unclear terminologies. Allow me to illustrate what I want to really ask: Let's say a Firefox user in China sends a DoH query to 1.1.1.1, but the Chinese Government does not like the fact that 1.1.1.1 will send the true (as opposed to a fake) IP address for Wikipedia to the Firefox user in China (and that the Great Firewall of China is unable to tamper with DoH query results as it's encrypted with HTTPS), therefore the Chinese Government has the Great Firewall of China block 1.1.1.1 at the IP level (which is quite easy to do as there is only one IP address to block). Left with no choices, the Firefox user in China sends the same DoH query to a domestic Chinese equivalent of 1.1.1.1, since the domestic Chinese equivalent of 1.1.1.1 will likely not have the entire DNS directory at its disposal, it too will need to reach across the Great Firewall to communicate with the DNS root server, and from there down the cascade (TLD, second-level domain authoritative name servers) until it gets the final IP address, since all these communications will cross the Great Firewall, if they are in UDP and clear-text, they could be tampered with by the Great Firewall. Even if it's DNSSEC enabled, still doesn't prevent the Great Firewall from seeing that it is "Wikipedia" that the Firefox user in China is looking for, and to forcibly shut down the whole transaction at that point. 174.138.195.251 (talk) 16:41, 19 June 2020 (UTC)