Hacker News new | past | comments | ask | show | jobs | submit login

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



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)


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?


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.


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


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.


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


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.


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.


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.


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!?


I think Jonnax meant ISPs, not you.


In which case he is wrong. You are the operator of your own network.

If applications decide to bypass you, they are hostile and cannot be trusted.


Then DNS protocol is old and needs to be updated. Security considerations need to be forward looking rather than clinging to the past.

DNS is unencrypted and a security risk. For the user. It's an old technology that needs to be updated.

DNS over TLS/HTTPS allows the browser to get a trusted record of IP which is a public register.

The bypass here is looking up what the corresponding IP address for a hostname is.

DNS based blocking isn't as effective as IP blocking.

You can feed a DNS based list of IPs you want to block into a firewall and have the exact same behaviour.

Both Firefox and Chrome have the ability to set enterprise user settings that can force certain configurations.

So you should have the ability to disable it if you want in your network.

If you're worried about the security of your network don't allow devices that you don't trust into it and restrict internet access properly.

What's more anyone can configure a custom DNS resolver on their device when connecting to a network.


You seem to forget that Domain Name Resolution became a problem after the more generic Name Resolution (ie Novel/lanman/NetBIOS). The Generic Name resolution system used lmhosts, which became hosts to more easily associate IPs and names. [0]

> Originally these names were stored in and provided by a hosts file but today most such names are part of the hierarchical Domain Name System (DNS).

[0] https://en.wikipedia.org/wiki/NetBIOS#NetBIOS_name


The lack of trust I mentioned was about ISP provided DNS servers. You don't own your WAN network and the majority of people use the DNS provided by their ISP.

On your own network, if you feel like doing a DNS lookup to what amounts to a public address book is unethical then don't allow arbitrary clients on the network.

If you want to do blocking based on a DNS list, configure your firewall to do that.


Knowing better than the owners is a matter of tradeoff.

There are whole isps and even countries (including the UK shortly) which mess with DNS requests. Helping the millions of users who are in that situation, and don't even know what D Sits, seems like a net good. As you say, experts can choose to disable it.


> As you say, experts can choose to disable it.

As long as they can. The problem with these ideas is that it can get increasingly difficult to work around them. How many hoops you have to jump through to pcap your own software on your own machines now that certificate pinning is becoming popular? What when someone will have the bright idea of implementing certificate pinning for DoH inside browsers, "because security"?

(I could live with the choice between having to somehow acquire Chrome Enterprise Edition vs. switching to Firefox, to have a browser I can control. I'm worried now that Firefox might be turning into Chrome, though.)


> including the UK shortly

If you're implying the porn filter, no, the porn filter has been shelved 'indefinitely' because a) it's against EU law, b) it was May's personal project (she pushed heavily for it when she was Home Secretary, and it became a thing under her PM-ship).


Firefox could provide an opt-out flag.


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


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.


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'


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.


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.


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.


> 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.


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".


Hi Dima - I'm assuming you're aware of dnscrypt-proxy and wrote nss-tls because you wanted a lighter weight implementation of a subset of dnscrypt-proxy's features on a specific platform (linux/glibc, for example this won't work on linux/musl afaik)? I use dnscrypt-proxy happily but was interested in nss-tls, yet couldn't find a rationale/comparison in the readme.


I believe Debian Burster (released just today) uses stubby (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.


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.


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


> 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.


What do you mean?

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.


What the parent poster means is that each application does its own DNS lookup separately and independently. The family of functions you linked to, plus the newer getaddrinfo family of functions, is implemented in the C library within each process, not as a system call or as a separate daemon. These functions read the /etc/nsswitch.conf file, load the C library plugins listed there, and call each one in sequence - still within the same process. The most common setting is a variation of "hosts: files dns", which first reads /etc/hosts, then reads /etc/resolv.conf and connects directly to the DNS servers listed there, without using any system level "DNS lookup" daemon (unless you have nscd enabled).


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


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

src for above: https://jrl.ninja/etc/2/getaddrinfo.go.txt




Consider applying for YC's Summer 2025 batch! Applications are open till May 13

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: