3 ms·

This doesn't seems it should be the function of the browser; rather, to run a local DNS service which is only accessible on your computer, and then you can make

This doesn't seems it should be the function of the browser; rather, to run a local DNS service which is only accessible on your computer, and then you can make it to access the DNS data by use of whatever you want to use, whether HTTPS or Namecoin or whatever, possibly even more than one. Then you can use it with any programs, and not only with Firefox. The ISP should not censor it. (I also think that HTTPS is probably not the best protocol for DNS, although it can still be used; just making DNS as TCP instead of UDP and then adding TLS, would help. But regardless of which way is done, it should be a separate program that the browser and other program using internet does not need to know the implementation of.)

pcr0 7y ago
In an ideal world yes, this should be implemented at the OS level. However, the vast majority of users would not see any benefit until OSX/Windows/Android/iOS/<insert Linux flavor> receives an update for DoH-by-default and then users either have auto-updates turned on or manually apply the update. Until that time comes, this is a fine step in the right direction, and you can disable Firefox's DNS if you don't want it.
- zzo38computer 7y ago
  As long as there is a setting in the browser to disable its own DNS implementation (possibly hidden so that you will need to set it in about:config or whatever), OK.
JoshTriplett 7y ago
Getting all operating systems to do that, across the board, is much harder than changing a cross-platform browser. Also, operating systems would have a much harder time doing that, especially if they don't all have integrated support for captive portal detection and similar. > just making DNS as TCP instead of UDP and then adding TLS, would help Then systems in the middle can tell it's DNS, and block it. We're moving towards a world where all traffic will look like HTTPS, or eventually like http/3.
- zzo38computer 7y ago
  If they block the internet, or inject stuff in, then they should not be allow to call it the Internet Service Provider; it is not internet, then. The ISP shouldn't care what application protocol you use. If carrier NAT is enabled (which in my opinion, it should be enabled by default, but the customer ought to have the ability to disable it if they want to disable it, so that you can have a real internet connection), then they might legitimately filter some transport protocols (e.g. TCP and UDP and other protocols in that layer) (but not application protocols), but if you disable NAT then you can use other transport protocols. I use a lot of stuff that isn't HTTP(S). (Still, the system domain name system should be independent of the implementation and the protocol in use. Whether you want to use HTTPS or something else for DNS, the browser shouldn't care.)
- zrm 7y ago
  > Getting all operating systems to do that, across the board, is much harder than changing a cross-platform browser. Is it? I understand that Debian has just added support. It should be as easy for Google to add it to Android as add it to Chrome. That leaves only Apple and Microsoft -- and even before that, anyone who likes to can set the DNS server in those operating systems to a stub that makes queries via DoH, either running on the local machine or connected via VPN. (I'm making that sound very tech nerd, but actually doing it isn't inherently any harder than installing Firefox.) > Also, operating systems would have a much harder time doing that, especially if they don't all have integrated support for captive portal detection and similar. Wouldn't it be the same issue for Firefox? > We're moving towards a world where all traffic will look like HTTPS, or eventually like http/3. Sad but true. Though at least HTTP/3 looks to support UDP, at which point it becomes a lot more reasonable to encapsulate whatever inside it.
- TeMPOraL 7y ago
  > especially if they don't all have integrated support for captive portal detection and similar. How so? Windows does this at OS-level. Android seems capable too. AFAIK, captive portal detection involves sending request to a known server on the Internet and getting back something that's a proper response from that server. This operation doesn't require a browser. Beyond that, from the system's POV, it's equivalent to being in a network that's not connected to the Internet. I don't see why we need to browsers to handle anything except captive portal's UI itself here.

pcr0 7y ago

In an ideal world yes, this should be implemented at the OS level. However, the vast majority of users would not see any benefit until OSX/Windows/Android/iOS/<insert Linux flavor> receives an update for DoH-by-default and then users either have auto-updates turned on or manually apply the update. Until that time comes, this is a fine step in the right direction, and you can disable Firefox's DNS if you don't want it.

zzo38computer 7y ago
As long as there is a setting in the browser to disable its own DNS implementation (possibly hidden so that you will need to set it in about:config or whatever), OK.

JoshTriplett 7y ago

Getting all operating systems to do that, across the board, is much harder than changing a cross-platform browser. Also, operating systems would have a much harder time doing that, especially if they don't all have integrated support for captive portal detection and similar. > just making DNS as TCP instead of UDP and then adding TLS, would help Then systems in the middle can tell it's DNS, and block it. We're moving towards a world where all traffic will look like HTTPS, or eventually like http/3.

zzo38computer 7y ago
If they block the internet, or inject stuff in, then they should not be allow to call it the Internet Service Provider; it is not internet, then. The ISP shouldn't care what application protocol you use. If carrier NAT is enabled (which in my opinion, it should be enabled by default, but the customer ought to have the ability to disable it if they want to disable it, so that you can have a real internet connection), then they might legitimately filter some transport protocols (e.g. TCP and UDP and other protocols in that layer) (but not application protocols), but if you disable NAT then you can use other transport protocols. I use a lot of stuff that isn't HTTP(S). (Still, the system domain name system should be independent of the implementation and the protocol in use. Whether you want to use HTTPS or something else for DNS, the browser shouldn't care.)
zrm 7y ago
> Getting all operating systems to do that, across the board, is much harder than changing a cross-platform browser. Is it? I understand that Debian has just added support. It should be as easy for Google to add it to Android as add it to Chrome. That leaves only Apple and Microsoft -- and even before that, anyone who likes to can set the DNS server in those operating systems to a stub that makes queries via DoH, either running on the local machine or connected via VPN. (I'm making that sound very tech nerd, but actually doing it isn't inherently any harder than installing Firefox.) > Also, operating systems would have a much harder time doing that, especially if they don't all have integrated support for captive portal detection and similar. Wouldn't it be the same issue for Firefox? > We're moving towards a world where all traffic will look like HTTPS, or eventually like http/3. Sad but true. Though at least HTTP/3 looks to support UDP, at which point it becomes a lot more reasonable to encapsulate whatever inside it.
TeMPOraL 7y ago
> especially if they don't all have integrated support for captive portal detection and similar. How so? Windows does this at OS-level. Android seems capable too. AFAIK, captive portal detection involves sending request to a known server on the Internet and getting back something that's a proper response from that server. This operation doesn't require a browser. Beyond that, from the system's POV, it's equivalent to being in a network that's not connected to the Internet. I don't see why we need to browsers to handle anything except captive portal's UI itself here.