Hacker News Reader

Comment by amaccuish | Hacker News Reader

It's still not clear to me how this will work in internal networks. AFAIK it's not possible to distribute internal DoH servers via DHCP, and it seems orthagonal to the goals of DoH since "cafe wifi" could give you dodgy servers. But how do I as a network administrator with internal DNS domains serve my users?

Maybe browsers and OSs could look at the local search domain, and send queries matching to DHCP servers, and everything else over DoH, kinda like split dns with a VPN?

View on HN

"everything else over DoH"

I have local DNS servers set to resolve both our intranet and all external queries. Some external queries are blocked for various reason. Either a browser uses the local network settings or it gets banned from the network. This is not a discussion because the real world intrudes on what browser vendors think is best.

Implicit proxying and inspection has always been a farce when it comes to "locking down clients". If you want to control traffic to clients you operate you should do it as an explicit proxy. If you want to control traffic to clients you don't operate it's not actually possible to both respect the client and inspect the traffic enough to meet security goals.

This tradeoff has always been true but everyone settled on the "good enough" that means security isn't actually strong, clients aren't actually treated as internal or external, and protocols are ossified because the FW expects wxyz to implement the above two failures.

We don't want Google or Mozilla to have a running list of our users DNS requests. We don't want Google or Mozilla to have a list of our internal servers. They are browsers and can use the same network stack as any other program. I have other types of filtering, but the whole idea of a browser ignoring internal services is going to get it banned.

It sounds like you will have to ban all browsers on whatever network you manage.

Why would I have to ban all browsers? Why would anyone accept Google or Mozilla knowing all the sites they visit?

This set of concerns has little to do with DoH, Chrome has been doing a hell of a lot more user tracking than which DNS lookups were made for longer than DoH has been around.

Just because they do other user tracking, doesn't mean I want DoH to add to the list.

Ok, so suppose I have a non-rooted Android phone or iPhone. Also suppose, they go all-in with DoH, without any override option.

The user doesn't control the client, because it's locked down.

The admin doesn't control the client, because DoH is tamper-resistant.

Who exactly does control it?

If it's your devices: You. Get an MDM, stop letting users install apps that ignore the device proxy settings (or install their own apps in general).

If it's not your device: Them. It's their device, you aren't (and shouldn't be able to) control their traffic.

Yeah, but the owners of those devices can't control the traffic either.

I'm not sure what exactly you mean here, why can't a user control their own traffic and what does it have to do with DoH or it's impact on existing security implementations in businesses?

Because, if they use a non-rooted phone or device, a part of traffic will come from system apps or the OS itself that the user has no control over. Before, this traffic could be blocked by intercepting DNS - now, there wouldn't be a way to do it at all.

Firstly you still can, add a root certificate and continue using VPN/explicit proxy.

Secondly, again none of this has anything to do with DoH. Users still set the system DoH/DoT DNS server the same as they always set the system DNS server and assumed system apps/installed apps weren't using custom sockets/transports/encoding to get around it. Users still control the browser feature enablement and can change destination server.

Finally back to the original point - "malicious use doesn't follow the rulebook". System apps have always had the right to make an HTTPS connection to an IP address. Users have always had the right to make an HTTPS connection to an IP address. JavaScript from an ad has always had the right to make an HTTPS connection to an IP address. The user never had any control of this unless they were using an explicit proxy or intercepting traffic with a cert structure. The only thing users/enterprises following the "let me look at udp 53" mantra have had is the illusion of security and control.

DoH changes none of this and is irrelevant to it, DoH is just a standard serialization of something anyone has been able to do for decades now. What DoH DOES do is prevent every random node inbetween a device and the DNS server from inspecting/modifying the traffic unless the end station is explicitly configured to allow it.

"Either a browser uses the local network settings or it gets banned from the network."

How would you detect that a browser isn't using the local network settings?

In this case, when we are testing the initial setup before we create our images, we would see a bunch of traffic we didn't expect or we read articles that tell us our preferred browser is doing something we find unacceptable. Its not like most enterprise / educational institutions don't test their staff setups.

You require all Internet access to traverse a proxy server, the hostname of which only resolves internally.

I think its going to come down to smart network management in the client OS.

If I'm on a trusted network, use the network resolvers (either via UDP 53 or DoH, or whatever) and if I'm not use preconfigured resolvers like 1.1.1.1 or something, part of not trusting the network should also be not trusting the resolver. Before DoH this was a moot point since UDP 53 can be trivially captured and redirected, now the client OS can actually do something about it.

I don't like the idea of individual applications overriding system resolver settings.

> AFAIK it's not possible to distribute internal DoH servers via DHCP

Back in the days we used to call this DHCP option 6, i.e. DNS.

I'm not sure why you want to replace a DHCP provided DNS server with a DHCP provided DoH server.

Because why on earth would the DHCP-server provide different DNS-servers for those two use-cases? The idea itself makes no sense.

Can we please just get back to regular DNS, please? It works. It scales.

It's possibly the single last thing on the internet which is still decentralized, and I'd hate to see this become another centralized, single point of failure, walled-garden bullshit.

I assume you agree on the need for securing DNS (DNS over TLS for example).

Just watched a UKNOF presentation on DNS changes. Sounds like google/mozilla were fed up with the sluggishness of standards bodies, network operators, and OSes in securing DNS, so have gone for their own version. Charitably I'd like to think that this is a wakeup call from Mozilla, "sort out your shit or this is the future, but with google owning it"

Isn’t this a resolver configuration issue on the client?

The browsers are not respecting DHCP in this case, but that doesn’t mean that other resolvers can’t be configured via DHCP to try DoH or DoT.

If you're the admin, you can disable DoH through a group policy, no?

No. Well, not for shops that have non windows. In the bay area, it is quite common to have a mix of Windows, Mac and some Linux. We are 60+% Mac.

Serve the internal IPs from public hostname DNS records?

Internal DNS I think is largely not a good thing and I'd be happy to see it go.

Could you develop ? You think you should answer with internal IPs with external DNS records and everything is addressed at the routing level ?

The DNS zone would be public and tied to a real domain. So both private and public clients would be able to query Eg:

  ci.myorg-int.com -> 10.11.12.13

One advantage of such method is that it is possible to re-use the public CA infrastructure to provision services with TLS certificated. It also means that services can easily be migrated to public IPs once they are secured on the endpoint.

The downside is that now all the internal services are discoverable using DNS scanning techniques. It means that competitors can see what services the organisation is using. Or attackers can better prepare themselves for infiltration.

Another downside of DoH is that it's not possible to filter out DNS rebinding attacks. For example and attacker can trick your browser in requesting a resource from xxx.somedomain.com that points to 10.11.12.13. If the CI is vulnerable to CSRF then the attacker can use the browser to exfiltrate information or do some actions on the CI.

> Another downside of DoH is that it's not possible to filter out DNS rebinding attacks.

Your web server should be configured to not serve content just by IP and require Host header to be a domain you control. (like using server_name in nginx) Otherwise they can just point to 10.11.12.13 directly anyway.

Sure, the web server SHOULD... but what if it is misconfigured? Or doesn't have an option to properly validate the Host header?

This is an internal client using an internal IP address to communicate with an internal service... just so happens that a malicious user made the internal client talk to it maliciously.

DNS rebinding attacks being stopped by the resolver are a great place to start and something we can do. Bypassing that protection in the name of resolving using DoH just means you've made things less secure.

I agree. I think DoH should be put on the edge of the network, using something like dnscrypt-proxy.

I don't think it should be put in the browser. It would actually made my setup less private, since I use DoH over tor.

Though configuring the http servers (like printers or whatever) and/or putting them behind a proxy on a sparate network, if they are sensitive/not configurable, should be done too.

> Your web server should be configured

I think you underestimate the number of things on your network that run unconfigurable web servers.

DNSMASQ lets you luckily whitelist certain domains from dns rebinding protection (like Plex, which relies on resolving to internal IPs). I'm still not comfortable exposing internal network details to the internet however.

As a sysadmin I disagree strongly.

Being able to host my own authoritative servers for my domains inside my org is a fantastic feature of DNS.

It lets me do things like split-horizon, which lets me deal with clients coming from different origins that may reach certain servers with or without NAT.

I'm also not keen on putting all my records on public name servers, for everyone to discover.

You could run your own DNS server. As long as you can get the relevant TLS cert, it doesn't even need to be public. You just would need to accept DOH connections

First thing that comes to mind with this idea is that Active Directory is going to be around for a long while yet.

Second, my network filters DNS rebinding, expect from plex.com. I guess I could ad my domain to it, but that's an extra point of failure.

Reply on news.ycombinator.com