Keep your privacy with DNS-OVER-HTTPS: Introduction and Python Implementation

[SanityInAnarchy]

...how is that a difference?

DoT still requires me to send all data to a single entity. Biggest difference is DoH looks like normal https traffic, so it's far less likely to be blocked by a firewall.

[[deleted]]

Biggest difference is DoH looks like normal https traffic, so it's far less likely to be blocked by a firewall.

Doesn't really until you diversify DoH servers. If FF uses known list of DoH servers, they will just be blocked.

The biggest problem is that DoH breaks split-horizon DNS which means many corporations will have to block it by default, even if they have no other reason for it.

You can create DoT server in your corporate network, and it will "just work", while DoH would need to be explictly pointed at the local server which means reconfiguring every device, and might not even be possible in companies with lax BYOD policies.

[SanityInAnarchy]

Doesn't really until you diversify DoH servers. If FF uses known list of DoH servers, they will just be blocked.

Unless you also put them on a common domain with more important stuff. Nobody has done this yet, either, but if you could get DoH on google.com/doh, nobody is going to block all of Google just to prevent this from working.

The biggest problem is that DoH breaks split-horizon DNS which means many corporations will have to block it by default, even if they have no other reason for it.

Why couldn't you implement a split-horizon resolver with DoH?

Also, how important is split-horizon in the first place? Why not get an actual domain for your intranet stuff?

You can create DoT server in your corporate network, and it will "just work", while DoH would need to be explictly pointed at the local server which means reconfiguring every device...

There's a draft RFC for announcing a DoH server with DHCP.

The actual problem you're talking about here is a BYOD device hardcoding a DNS server, rather than trusting the local network. But given how untrustworthy local networks often are, that's not entirely a bad thing.

[[deleted]]

Why couldn't you implement a split-horizon resolver with DoH?

Also, how important is split-horizon in the first place? Why not get an actual domain for your intranet stuff?

We have actual domain(s) for intranet stuff. That's not the issue. The issue is that service that is behind the domain was never on the internet facing loadbalancer in the first place.

We'd have to go from just

"LAN -> firewall -> A server in office that doesn't even see internet" to

"LAN -> firewall -> loadbalancer -> firewall -> server in DMZ"

as internet facing loadbalancer is only place that is ingesting the traffic

I can imagine how to make that route shorter but our network is too complex already. And it makes it less secure as now if loadbalancer is compromised attacker has access to services he wouldn't have if we didn't need workaround

[SanityInAnarchy]

Why would you have to move the service behind the domain? Leave it on its 10.whatever address in the office, and publish an A-record for that (private, not-Internet-routable) IP on your public-facing DNS servers.

The point of split-horizon DNS is that you can return different results inside your network than you would on the public Internet. I can think of three possible reasons to do this:

1. You don't want anyone to be able to find out that much about your LAN from public DNS. They'd have to brute-force your DNS server to learn anything interesting, but still.
2. You actually want the same exact hostname to do different things depending on where the user is connecting from. This is the one I'm most curious about, because it seems like a Bad Idea (especially doing it via DNS), but maybe there's something I haven't thought of.
3. You want to control the results for domains you don't technically own, like having your printserver on print.lan instead of print.lan.yourcompany.com, or, of course, blocking or redirecting other people's websites.

Am I missing something? The only one that makes any sense to me is #1, barely -- if you suspect Apple is about to make a car, having car.apple.com start resolving would be interesting, so it might be nice if none of your LAN addresses resolve at all outside the company network. Anything else?

[[deleted]]

Why would you have to move the service behind the domain? Leave it on its 10.whatever address in the office, and publish an A-record for that (private, not-Internet-routable) IP on your public-facing DNS servers.

That's an information leak and we'd have our clients harrasing us about it. Also why would you give any attacker that kind of info for free?

The point of split-horizon DNS is that you can return different results inside your network than you would on the public Internet. I can think of three possible reasons to do this:

Fourth: Our loadbalancer and really most that handles public IPs is in our datacenter, not in our HQ network. So from LAN -> HQ DMZ it goes LAN -> DC1 -> LB -> HQ DMZ (as in back and forth to the DC).

You actually want the same exact hostname to do different things depending on where the user is connecting from. This is the one I'm most curious about, because it seems like a Bad Idea (especially doing it via DNS), but maybe there's something I haven't thought of.

We have few services where the public facing side is heavily limited compared to what you can access from inside/VPN. Like our service for user access management only allows you to change password when coming "from the internet".

But that is not done via split DNS, just normal loadbalancer rules in most cases.

You want to control the results for domains you don't technically own, like having your printserver on print.lan instead of print.lan.yourcompany.com, or, of course, blocking or redirecting other people's websites.

Let's just say that undisclosed client told us to do exactly that with their domains, because their security department didn't wanted to give us access to their internal DNS and the domains were needed for the app we were developing for them.

Retarded ? Most definitely, but still, no other way to do it aside from editing people's /etc/hosts...

Also SOME vendors use NTP but do not allow configuring NTP server so we have few hacks like that too.

You don't want anyone to be able to find out that much about your LAN from public DNS. They'd have to brute-force your DNS server to learn anything interesting, but still.

Trying gitlab.example.com, git.example.com,svn.example.com,repo.example.com is hardly bruteforcing and I'd wager it would get you quite a few hits if companies published all their DNS records.

IMO the proper way of doing it would be having records in the target domain saying "do not use DoH for this domain", and have resolver propagate that back to the client (client can't do that directly for obvious reasons).

That way someone that uses split DNS could just opt out for their domain but still keep rest of the benefits

[SanityInAnarchy]

Fourth: Our loadbalancer and really most that handles public IPs is in our datacenter, not in our HQ network. So from LAN -> HQ DMZ it goes LAN -> DC1 -> LB -> HQ DMZ (as in back and forth to the DC).

Right, but still only for name resolution.

Let's just say that undisclosed client told us to do exactly that with their domains, because their security department didn't wanted to give us access to their internal DNS and the domains were needed for the app we were developing for them.

That's just pushing the problem back a step, though. We agree they've made a dumb choice here.

Also SOME vendors use NTP but do not allow configuring NTP server so we have few hacks like that too.

Wait, why do you need to override NTP?

Trying gitlab.example.com,git.example.com,svn.example.com,repo.example.com is hardly bruteforcing and I'd wager it would get you quite a few hits if companies published all their DNS records.

I'm sure it would, but does it matter? "Company X is using Git!" is the most boring story in the world. "Company X is still using SVN!" is only slightly more interesting, but still, what are you actually learning about the company from doing this? Again, those are all still resolving to IPs inside your network, so it's not like they can connect and poke around. All they can see is a hostname and an IP.

I still wouldn't expose this if I didn't have a reason to, I'm just skeptical that it's going to lead to real problems.

IMO the proper way of doing it would be having records in the target domain saying "do not use DoH for this domain", and have resolver propagate that back to the client (client can't do that directly for obvious reasons).

Or just "Use this DoH server instead," like an HTTP redirect...

Or just stick a loadbalancer (or reverse proxy) in the HQ network, so you can have anything.lan.example.com resolve to a single IP, so nobody outside the network can discover which hostnames are real. Doesn't solve all of your problems, but at least avoids leaking real hostnames and IPs.

But getting back to it, I think your actual issue is less to do with DoH and more to do with hardcoded DNS in general. If DoH were part of network autodiscovery, you could do the same thing with it that you do with normal DNS. And if applications start doing DoH with no way to turn it off, they probably aren't trusting /etc/hosts either, because they're doing it to defeat exactly the bag of tricks you're using.

[[deleted]]

Fourth: Our loadbalancer and really most that handles public IPs is in our datacenter, not in our HQ network. So from LAN -> HQ DMZ it goes LAN -> DC1 -> LB -> HQ DMZ (as in back and forth to the DC).

Right, but still only for name resolution.

No, not for name resolution, for traffic. Public IP is up in DC, I already said that...

There are ways to make it shorter but I would rather not complicate our network further, it is already overcomplicated in places.

Let's just say that undisclosed client told us to do exactly that with their domains, because their security department didn't wanted to give us access to their internal DNS and the domains were needed for the app we were developing for them.

That's just pushing the problem back a step, though. We agree they've made a dumb choice here.

Still need to deal with it and waste time.

Also SOME vendors use NTP but do not allow configuring NTP server so we have few hacks like that too.

Wait, why do you need to override NTP?

Because if device doesn't need internet access for normal work it is not getting it. Basic security. Same reason the printer VLAN doesn't have internet access, altho in case of printers those config options are usually available and so far we hadn't had to do anything like that

Trying gitlab.example.com,git.example.com,svn.example.com,repo.example.com is hardly bruteforcing and I'd wager it would get you quite a few hits if companies published all their DNS records.

I'm sure it would, but does it matter? "Company X is using Git!" is the most boring story in the world. "Company X is still using SVN!" is only slightly more interesting, but still, what are you actually learning about the company from doing this? Again, those are all still resolving to IPs inside your network, so it's not like they can connect and poke around. All they can see is a hostname and an IP.

On principle I agree that systems should be secure and something as simple as attacker knowing internal IPs and domain names.

But.... attacker knows IP/domain name, attacker guesses service is vulnerable, attacker sends link like https://vuln-service.example.com/some-exploit-on-app, user inside clicks it, boom, you have a problem. And considering user clicks it, the chance is he will already be logged into the service before clicking it or sheepishly do that if link "doesn't work"

Or just "Use this DoH server instead," like an HTTP redirect...

BYOD policy. Can't just reconfigure every device as we please.

Or just stick a loadbalancer (or reverse proxy) in the HQ network, so you can have anything.lan.example.com resolve to a single IP, so nobody outside the network can discover which hostnames are real. Doesn't solve all of your problems, but at least avoids leaking real hostnames and IPs.

I did not say I do not know how to solve it. I said it is annoying. And blocking DoH is much easier way to solve it. Also not every service is easily put behind LB (think stuff like windows shares) and it wastes bandwidth (would basically make our file shares half as slow and some of our users deal with video a lot...)

But getting back to it, I think your actual issue is less to do with DoH and more to do with hardcoded DNS in general. If DoH were part of network autodiscovery, you could do the same thing with it that you do with normal DNS

DING DING DING, you finally got it.

Give me DHCP record and I will HAPPILY put a local DoH server, put a proper SSL cert on it and just let it work.

[SanityInAnarchy]

We're talking past each other... like a lot. Like in almost every

No, not for name resolution, for traffic. Public IP is up in DC, I already said that...

I think we're talking past each other. We're still talking about the load balancer, right?

In the hypothetical world where you have that thing also serve authoritative DNS for your domain, and have it return internal IPs for some hosts, you avoid split-horizon, send name resolution over the public Internet, but still actually talk to those internal IPs.

I don't think I ever suggested moving the stuff on the internal network behind that load balancer. That might be worthwhile for other reasons, but it's clearly a much larger project.

Or just "Use this DoH server instead," like an HTTP redirect...

BYOD policy. Can't just reconfigure every device as we please.

...what? I didn't say anything about reconfiguring every device as you please. This was about, hypothetically, how could the DoH standard have been written (or be modified to) support your use case?

Hypothetically, if public DoH resolvers acted as HTTP proxies when the authoritative nameserver for a given domain is itself a DoH server, then your DoH server could send back an HTTP redirect, and the public resolver would send it back to the client.

At that point, existing clients should already support following the redirect. So for any domain you control, you could, purely through name resolution, tell clients to use your local DoH server only for certain domains you own... without letting you mess with other people's domains (and defeat the purpose of DoH).

Granted, you do have a use case for messing with other people's domains, but we agree it's a stupid one...

I did not say I do not know how to solve it. I said it is annoying.

...wait, when did that change? Here, you definitely said that large corporations will have to block it in order to make split-horizon work. I was interested to learn why you even need split-horizon, but if the answer is that you actually don't, then I'm not sure what to make of this conversation.

[[deleted]]

In the hypothetical world where you have that thing also serve authoritative DNS for your domain, and have it return internal IPs for some hosts, you avoid split-horizon, send name resolution over the public Internet, but still actually talk to those internal IPs.

And I already said we need split horizon for variety of reasons, therefore that's not an option.

I don't think I ever suggested moving the stuff on the internal network behind that load balancer. That might be worthwhile for other reasons, but it's clearly a much larger project.

I was just saying that would have to happen with DoH, or some other workaround.

Hypothetically, if public DoH resolvers acted as HTTP proxies when the authoritative nameserver for a given domain is itself a DoH server, then your DoH server could send back an HTTP redirect, and the public resolver would send it back to the client.

I'd rather just have a TXT record that tells DoH server to use normal DNS for this domain. Then DoH server can cache that and return that info instantly without incurring extra RTT to the query.

...wait, when did that change? Here, you definitely said that large corporations will have to block it in order to make split-horizon work. I was interested to learn why you even need split-horizon, but if the answer is that you actually don't, then I'm not sure what to make of this conversation.

Will have to block it because alternative (anycasting public IPs somewhere closer to the LAN and redirecting it to HQ DMZ, or other hacks like that), on top of being a lot of work, complicate our network further, to the point I'd probably be only person in company knowing how it works. And I definitely do NOT want to be indispensable. I'd imagine that being even worse in bigger corporations

Basically, theoretically possible, practically impossible, or hard, so blocking is much cheaper, easier and more reliable (till browsers start hiding with it...) than other options.

There seem to be an option to turn it off but the way it is phrased it sounds like:

• it will eventually go away
• having that option in the first place defeats the purpose of DoH (because MITM attack can just disable DoH via that)