9 ms·

Why is this supported at the application level instead of the OS? So other tools like ping or nslookup can use it too.

the_angry_angel 7y ago
This is my beef with (my understanding maybe incomplete, in which case I apologise) the implementation. Internal DNS, split brain DNS aren’t catered for without disabling support? I don’t want my internal names leaking to the internet, nor necessarily are they the same for external resolvers. Now yes the latter is a hack, but it’s one widely used still today. The idea is laudable. But it feels hostile. I can disable support, but for how long?
- tssva 7y ago
  Once Firefox starts to ignore DNS resolvers configured at the OS level other apps are sure to look at it and think it must be a good idea because Firefox is doing it. Soon there will be a multitude of applications needing this disabled in their own unique way. If the Mozilla Foundation see this as an issue they should instead be developing a separate solution to provide this system wide. If you must bundle it with Firefox and offer to install it at browser installation or upgrade time. Don't install it by default and certainly don't enable it without user permission.
- krispbyte 7y ago
  I guess it would be possible to run my own local DNS server that connects to these DoH servers. Does any DNS server support DoH? This could also allow the user to override domains using their /etc/hosts file in case DoH on Firefox doesn't support it.
  - uponcoffee 7y ago
    I use pihole + dnscrypt-proxy 2.* A fair number of resolvers support DoH and dnscrypt-proxy also supports DoT. It's fairly feature rich, you can configure a hosts file and then some. [0] https://github.com/jedisct1/dnscrypt-proxy https://github.com/jedisct1/dnscrypt-proxy
- xjay 7y ago
  Firefox could provide an opt-out flag.
  - xjay 7y ago
    A likely opt-out [1] mechanism that will prevent Firefox from enabling DoH in any future update. 5 means explicitly disabled. 0 (default) is whatever is considered default for now. 1. about:config 2. network.trr.mode = 5 [1] https://news.ycombinator.com/item?id=20373444 https://news.ycombinator.com/item?id=20373444
- Kadin 7y ago
  In that case you are better off running local DNS and using a different subdomain (internal.companyname.com or whatever) for internal DNS entries; the DNS-over-HTTPS query will go out, fail, and then Firefox will fallback to traditional UDP DNS on port 53, hit the local resolver on the LAN, and away you go. It will presumably cause a short delay the first time a host is queried, but after that I assume Firefox is smart enough to cache the result, so unless you have absurdly short TTLs the performance impact should be pretty low. The positives certainly outweigh the negatives of inconveniencing some IT admins who, as you correctly point out, are implementing a dirty hack anyway.
  - userbinator 7y ago
    the DNS-over-HTTPS query will go out, fail You completely missed the point of the parent, which is to NOT let internal hostnames out of the network. The positives certainly outweigh the negatives of inconveniencing some IT admins who, as you correctly point out, are implementing a dirty hack anyway. This is a perfect example of the irritating attitude I see from people pushing hostile features like this. Everyone wants their network to operate the way they want, and yet you think you know better than the actual owners of those networks.
    - Jonnax 7y ago
      The owners of the networks have time and time again done user hostile things that have compromised their security and privacy. Corporate networks are a small percentage of network traffic and their use cases are less important in the grand scheme of the internet. DNS over HTTPS is a solution because network owners can't be trusted. Either by blocking or by taking their DNS logs and selling it to advertiser's.
      - userbinator 7y ago
        I am the owner of my network, as is everyone who has one at home, and you are saying that I can't be trusted. WTF!?
        deleted 7y ago
- spc476 7y ago
  I'm running my own DNSoverHTTP instance at home. I have Apache, with HTTP/2 support, running, some self-signed certificates, and a CGI script that accepts the DNSoverHTTP request and makes a DNS call to my local version of bind. I found RFC-8484 to be quite easy to follow, and I've set network.trr.mode to 4 (use DNS, but also send DNSoverHTTP for testing) and network.trr.allow-rfc1918 to true (so local addresses can be resolved locally). I will do the occasional tests with network.trr.mode to 3 (only use DNSoverHTTP) but I seem to have issues resolving github. I haven't looked that far into it. EDIT: there do exist solutions to run locally.
  - the_angry_angel 7y ago
    Thanks, I’ll hace to look it up and give it a read. I’ll be honest I’ve not read the actual RFC in this instance and pieced together what I know from articles, reported behaviour, etc. I know it’s lazy and I should’ve done more work. But, burn out
detaro 7y ago
Because applications can't ship OS level support, but want to experiment with it and add it now. That doesn't mean OS-level support can't be a thing, but it's a different level (waiting until the OS vendor gets around to it, or users explicitly installing and setting up tools for it)
yegle 7y ago
I believe Debian Burster (released just today) uses stubby (https://dnsprivacy.org/wiki/m/mobile.action#page/1277989 https://dnsprivacy.org/wiki/m/mobile.action#page/1277989) as system level DNS cache instead dnsmasq. Stubby support sending DNS-over-TLS query to upstream DNS.
ubercow13 7y ago
At least on Linux, isn't DNS all at the application level anyway? There is no system level DNS lookup
- zrm 7y ago
  > At least on Linux, isn't DNS all at the application level anyway? There is no system level DNS lookup Nearly all applications use the standard library, i.e. getaddrinfo(3) or the old gethostbyname(3) or something that wraps them. Which itself uses the services configured in /etc/nsswitch.conf, one of which is DNS which will in turn query the DNS server(s) configured in /etc/resolv.conf. You can also have other services configured in nsswitch.conf like "mdns" (multicast DNS for names of devices on the LAN) and "files" for /etc/hosts, or any other name resolution system. The general result is that you can change the settings for the whole system and even add completely new name resolution services (like, for example, DoH) and have substantially everything automatically use them.
- StreamBright 7y ago
  What do you mean? https://linux.die.net/man/3/gethostbyaddr https://linux.die.net/man/3/gethostbyaddr It is one of the worst thing that can happen if this functionality moves into the application layer.
  - ubercow13 7y ago
    That's in libc. I guess that's below the application later, but doesn't some code elect to not use that, like go programs? I might be mistaken
    - JoshuaRLi 7y ago
      At least on linux, go's native resolver follows a sane subset of glibc conventions like parsing /etc/nsswitch.conf, /etc/resolv.conf, /etc/hosts [1]. As long as your dns configuration is defined there, you won't notice much of a difference between go programs using go's resolver and programs making glibc library calls for dns stuff. 1: https://jrl.ninja/etc/2/strace-go-1.12.3.txt https://jrl.ninja/etc/2/strace-go-1.12.3.txt src for above: https://jrl.ninja/etc/2/getaddrinfo.go.txt https://jrl.ninja/etc/2/getaddrinfo.go.txt
3xblah 7y ago
Here is an example of how one can use DOH "like ping or nslookup". This example uses HTTP POST and cloudflare-dns. Maybe check out "stubby" for "OS-level" DOH. Currently I think it only does DOT but future plans are for DOH. test $# = 1|| exec echo usage: $0 query # requirements: sed, wc, xxd, openssl, ldns, drill # reference: https://tools.ietf.org/html/rfc8484#section-4.1 a=$(drill -q /dev/stdout $1 |sed '1,2d;s/;.*//;s/ //g'|xxd -p -r|wc -m); (printf "POST /dns-query HTTP/1.1\r\nHost: cloudflare-dns.com\r\nAccept: /\r\nContent-Type: application/dns-message\r\nConnection: close\r\nContent-Length: $a\r\n\r\n"; drill -q /dev/stdout $1|sed '1,2d;s/;.*//;s/ //g;3s/..../0001/'|xxd -p -r)|openssl s_client -no_tls1 -no_tls1_1 -no_ssl2 -no_ssl3 -ign_eof -no_ticket -host cloudflare-dns.com -port 443 -servername 1.1.1.1|sed -n \$p|xxd -p|drill -i /dev/stdin|sed '/^;; Data: \\#/d'
dimkr1 7y ago
Because the OS (getaddrinfo(), gethostbyname(), etc') doesn't implement DoH; it implements a /etc/hosts parser and a DNS (over UDP) client. I wrote a glibc plugin that implements a caching DoH client for glibc, which can replace the DNS client or fall back to it - https://github.com/dimkr/nss-tls https://github.com/dimkr/nss-tls.
- josteink 7y ago
  The criticism (which you seemed to miss) is that everyone is rushing to implement this at the application-level(s), instead of contributing to get it implemented, once, at the OS level instead and have a fix in place for everyone.
  - pjc50 7y ago
    How do you get the three big closed source OS vendors to do this in less than a decade? Not to mention that DNS over HTTP is one of the class of features where you might want to override sysadmin policy as a user.
    - josteink 7y ago
      > Not to mention that DNS over HTTP is one of the class of features where you might want to override sysadmin policy as a user. I don’t buy that argument at all. Why should we special case policies of one internet-protocol over all the others? Also: implementing/marketing DoH as a way to bypass enterprise control and policies is a surefure way to find it permanently blocked at firewall level in said enterprises. Ie your attempt at subverting control won’t gain you anything but deserved distrust.
  - dimkr1 7y ago
    nss-tls is "at the OS level". It makes getaddrinfo(), etc', use DoH behind the scenes, so applications are transparently migrated to DoH. I think you missed the nss-tls README and think nss-tls is not at the "OS level".
- JoshuaRLi 7y ago
beagle3 7y ago
This is doable on linux/unix through an NSS plugin (and has been linked to in this discussion), but the vast majority of Firefox users are on Windows (and a minority on Android) where this cannot be done as easily. For the users, 99% of whom live in the self-updating browser these days, this is much better than waiting for an OS patch that they may or may not know how to install.

This is my beef with (my understanding maybe incomplete, in which case I apologise) the implementation. Internal DNS, split brain DNS aren’t catered for without disabling support? I don’t want my internal names leaking to the internet, nor necessarily are they the same for external resolvers. Now yes the latter is a hack, but it’s one widely used still today. The idea is laudable. But it feels hostile. I can disable support, but for how long?

tssva 7y ago
Once Firefox starts to ignore DNS resolvers configured at the OS level other apps are sure to look at it and think it must be a good idea because Firefox is doing it. Soon there will be a multitude of applications needing this disabled in their own unique way. If the Mozilla Foundation see this as an issue they should instead be developing a separate solution to provide this system wide. If you must bundle it with Firefox and offer to install it at browser installation or upgrade time. Don't install it by default and certainly don't enable it without user permission.
krispbyte 7y ago
I guess it would be possible to run my own local DNS server that connects to these DoH servers. Does any DNS server support DoH? This could also allow the user to override domains using their /etc/hosts file in case DoH on Firefox doesn't support it.
- uponcoffee 7y ago
  I use pihole + dnscrypt-proxy 2.* A fair number of resolvers support DoH and dnscrypt-proxy also supports DoT. It's fairly feature rich, you can configure a hosts file and then some. [0] https://github.com/jedisct1/dnscrypt-proxy https://github.com/jedisct1/dnscrypt-proxy
xjay 7y ago
Firefox could provide an opt-out flag.
- xjay 7y ago
  A likely opt-out [1] mechanism that will prevent Firefox from enabling DoH in any future update. 5 means explicitly disabled. 0 (default) is whatever is considered default for now. 1. about:config 2. network.trr.mode = 5 [1] https://news.ycombinator.com/item?id=20373444 https://news.ycombinator.com/item?id=20373444
Kadin 7y ago
In that case you are better off running local DNS and using a different subdomain (internal.companyname.com or whatever) for internal DNS entries; the DNS-over-HTTPS query will go out, fail, and then Firefox will fallback to traditional UDP DNS on port 53, hit the local resolver on the LAN, and away you go. It will presumably cause a short delay the first time a host is queried, but after that I assume Firefox is smart enough to cache the result, so unless you have absurdly short TTLs the performance impact should be pretty low. The positives certainly outweigh the negatives of inconveniencing some IT admins who, as you correctly point out, are implementing a dirty hack anyway.
- userbinator 7y ago
  the DNS-over-HTTPS query will go out, fail You completely missed the point of the parent, which is to NOT let internal hostnames out of the network. The positives certainly outweigh the negatives of inconveniencing some IT admins who, as you correctly point out, are implementing a dirty hack anyway. This is a perfect example of the irritating attitude I see from people pushing hostile features like this. Everyone wants their network to operate the way they want, and yet you think you know better than the actual owners of those networks.
  - Jonnax 7y ago
    The owners of the networks have time and time again done user hostile things that have compromised their security and privacy. Corporate networks are a small percentage of network traffic and their use cases are less important in the grand scheme of the internet. DNS over HTTPS is a solution because network owners can't be trusted. Either by blocking or by taking their DNS logs and selling it to advertiser's.
    - userbinator 7y ago
      I am the owner of my network, as is everyone who has one at home, and you are saying that I can't be trusted. WTF!?
      - deleted 7y ago
spc476 7y ago
I'm running my own DNSoverHTTP instance at home. I have Apache, with HTTP/2 support, running, some self-signed certificates, and a CGI script that accepts the DNSoverHTTP request and makes a DNS call to my local version of bind. I found RFC-8484 to be quite easy to follow, and I've set network.trr.mode to 4 (use DNS, but also send DNSoverHTTP for testing) and network.trr.allow-rfc1918 to true (so local addresses can be resolved locally). I will do the occasional tests with network.trr.mode to 3 (only use DNSoverHTTP) but I seem to have issues resolving github. I haven't looked that far into it. EDIT: there do exist solutions to run locally.
- the_angry_angel 7y ago
  Thanks, I’ll hace to look it up and give it a read. I’ll be honest I’ve not read the actual RFC in this instance and pieced together what I know from articles, reported behaviour, etc. I know it’s lazy and I should’ve done more work. But, burn out

detaro 7y ago

Because applications can't ship OS level support, but want to experiment with it and add it now. That doesn't mean OS-level support can't be a thing, but it's a different level (waiting until the OS vendor gets around to it, or users explicitly installing and setting up tools for it)

yegle 7y ago

I believe Debian Burster (released just today) uses stubby (https://dnsprivacy.org/wiki/m/mobile.action#page/1277989 https://dnsprivacy.org/wiki/m/mobile.action#page/1277989) as system level DNS cache instead dnsmasq. Stubby support sending DNS-over-TLS query to upstream DNS.

ubercow13 7y ago

At least on Linux, isn't DNS all at the application level anyway? There is no system level DNS lookup

zrm 7y ago
> At least on Linux, isn't DNS all at the application level anyway? There is no system level DNS lookup Nearly all applications use the standard library, i.e. getaddrinfo(3) or the old gethostbyname(3) or something that wraps them. Which itself uses the services configured in /etc/nsswitch.conf, one of which is DNS which will in turn query the DNS server(s) configured in /etc/resolv.conf. You can also have other services configured in nsswitch.conf like "mdns" (multicast DNS for names of devices on the LAN) and "files" for /etc/hosts, or any other name resolution system. The general result is that you can change the settings for the whole system and even add completely new name resolution services (like, for example, DoH) and have substantially everything automatically use them.
StreamBright 7y ago
What do you mean? https://linux.die.net/man/3/gethostbyaddr https://linux.die.net/man/3/gethostbyaddr It is one of the worst thing that can happen if this functionality moves into the application layer.
- ubercow13 7y ago
  That's in libc. I guess that's below the application later, but doesn't some code elect to not use that, like go programs? I might be mistaken
  - JoshuaRLi 7y ago
    At least on linux, go's native resolver follows a sane subset of glibc conventions like parsing /etc/nsswitch.conf, /etc/resolv.conf, /etc/hosts [1]. As long as your dns configuration is defined there, you won't notice much of a difference between go programs using go's resolver and programs making glibc library calls for dns stuff. 1: https://jrl.ninja/etc/2/strace-go-1.12.3.txt https://jrl.ninja/etc/2/strace-go-1.12.3.txt src for above: https://jrl.ninja/etc/2/getaddrinfo.go.txt https://jrl.ninja/etc/2/getaddrinfo.go.txt

3xblah 7y ago

Here is an example of how one can use DOH "like ping or nslookup". This example uses HTTP POST and cloudflare-dns. Maybe check out "stubby" for "OS-level" DOH. Currently I think it only does DOT but future plans are for DOH. test $# = 1|| exec echo usage: $0 query # requirements: sed, wc, xxd, openssl, ldns, drill # reference: https://tools.ietf.org/html/rfc8484#section-4.1 a=$(drill -q /dev/stdout $1 |sed '1,2d;s/;.*//;s/ //g'|xxd -p -r|wc -m); (printf "POST /dns-query HTTP/1.1\r\nHost: cloudflare-dns.com\r\nAccept: /\r\nContent-Type: application/dns-message\r\nConnection: close\r\nContent-Length: $a\r\n\r\n"; drill -q /dev/stdout $1|sed '1,2d;s/;.*//;s/ //g;3s/..../0001/'|xxd -p -r)|openssl s_client -no_tls1 -no_tls1_1 -no_ssl2 -no_ssl3 -ign_eof -no_ticket -host cloudflare-dns.com -port 443 -servername 1.1.1.1|sed -n \$p|xxd -p|drill -i /dev/stdin|sed '/^;; Data: \\#/d'

dimkr1 7y ago

Because the OS (getaddrinfo(), gethostbyname(), etc') doesn't implement DoH; it implements a /etc/hosts parser and a DNS (over UDP) client. I wrote a glibc plugin that implements a caching DoH client for glibc, which can replace the DNS client or fall back to it - https://github.com/dimkr/nss-tls https://github.com/dimkr/nss-tls.

josteink 7y ago
The criticism (which you seemed to miss) is that everyone is rushing to implement this at the application-level(s), instead of contributing to get it implemented, once, at the OS level instead and have a fix in place for everyone.
- pjc50 7y ago
  How do you get the three big closed source OS vendors to do this in less than a decade? Not to mention that DNS over HTTP is one of the class of features where you might want to override sysadmin policy as a user.
  - josteink 7y ago
    > Not to mention that DNS over HTTP is one of the class of features where you might want to override sysadmin policy as a user. I don’t buy that argument at all. Why should we special case policies of one internet-protocol over all the others? Also: implementing/marketing DoH as a way to bypass enterprise control and policies is a surefure way to find it permanently blocked at firewall level in said enterprises. Ie your attempt at subverting control won’t gain you anything but deserved distrust.
- dimkr1 7y ago
  nss-tls is "at the OS level". It makes getaddrinfo(), etc', use DoH behind the scenes, so applications are transparently migrated to DoH. I think you missed the nss-tls README and think nss-tls is not at the "OS level".
JoshuaRLi 7y ago

beagle3 7y ago

This is doable on linux/unix through an NSS plugin (and has been linked to in this discussion), but the vast majority of Firefox users are on Windows (and a minority on Android) where this cannot be done as easily. For the users, 99% of whom live in the self-updating browser these days, this is much better than waiting for an OS patch that they may or may not know how to install.