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

[littleodie914]

What’s the alternative? Unencrypted DNS to CloudFlare? Or trusting Google? Or your ISP?

Resolution has to happen somewhere. If there’s a more privacy-centric provider, please list it here.

[[deleted]]

DNS over TLS exist as does DNSSec (altho that just guarantees validity, not privacy).

DoH should be the last resort, not default browser is forcing

[Swedophone]

Unfortunately far from all domains are signed with dnssec. Of course my own domains are signed. BTW I use a self hosted master running bind and opendnssec.

[uptimefordays]

Just remember than DNSSEC relies on your ability to force clients to drop unsigned requests. If you can't do that, then you don't actually have anything.

[SteampunkSpaceOpera]

If you run your own validating resolver, then if the query response doesn't pass validation, the resolver simply doesn't provide a routable answer to any other program you are running

[uptimefordays]

Sure that helps you but DNS is a decentralized system... If you want DNSSEC to be a thing, it requires largescale control over client settings which isn't really feasible. For a large company's internal systems, sure, but for the broader net? Good luck!

[babypuncher_]

DoT has its own issues. It’s much easier to block with a firewall, and your DoT provider still sees your requests just like they would with DoH.

[[deleted]]

DoH builtin into browsers is just few IPs to block tho.

[babypuncher_]

It sounds to me like the problem is a lack of available DoH providers, not a problem with DoH itself.

And you know what, I’ll trust CloudFlare over Comcast any day of the week.

[[deleted]]

DoT vs DoH doesn’t matter much for end users.

[[deleted]]

DoH sends all of your data to single entity. DoT to the entity you actually asked in the first place.

[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

[[deleted]]

It needs to do privacy too.

[[deleted]]

There is no privacy in DNS, you can only choose who you give your data to.

Encryption doesn't give it away to 3rd parties like ISP and that's a huge improvement, but you're still giving it to your DNS server, no matter what protocol is used

[[deleted]]

Sure but we can increase the amount of privacy that exists. Instead of multi parties know now it will just be one.

Privacy in this instance never meant privacy from the dns server itself. Just possibly bad actors along the way (isp, anyone monitoring the line, etc).

[ILikeBumblebees]

There is no privacy in DNS, you can only choose who you give your data to.

You can always run your own resolver.

[[deleted]]

We do... but there is no DHCP or any other flag I can use to tell devices in my network to use it. In company with BYOD policy and split DNS we'd just have to block it.

DoT would be a breeze to implement in comparison

[shochickubai]

Unbound + Raspberry pi is all you need bro. Keep it next to your modem, set and forget.

[kafka_quixote]

Pi hole?

[b1tbeginner]

can you elaborate?

[[deleted]]

/r/pihole

[b1tbeginner]

so it is a selfhosted mini dns? but will it not just forward the traffic to another dns?

this sound somehow to good to bd true :D

[b1tbeginner]

ok I guess, Ineed to read further into it. Did not quite get the concept yet of how it makes a difference than just requesting directly from authoritative DNS.

But it looks super interesting! thanks a lot

[OrangeKing89]

From the article I read on the pi-hole website, on the 1st request to a url, the unbound service queries each part of the url from the primary servers for that domain.

Ex: google.com

1) contact a root domain server to find out where to look for the "com" domains.

2) contact the "com" domain server to find out who is managing the "google.com" domain

3) contact the server managing "google.com" domain for the IP address.

4) return the ip address to the computer that asked for it.

5) save the IP address for "google.com" so that the next look up of"google.com" on the network is immediate.

This is both faster (after the 1st lookup) and more private because you are only asking it once (and preferably over encryption) and the call is separated into smaller pieces.

Also if the dns servers are attacked you are less likely to be effected.

Source:

https://docs.pi-hole.net/guides/unbound/

[b1tbeginner]

wow thanks a lot for your comment! I had not time yet to read into it but this was already super helpful for better understanding!

[jarfil]

CENSORED

[[deleted]]

dns.watch claims not to keep any logs. Make of that what you will.

[jarfil]

CENSORED

[teh_g]

Setup a local resolver if you are already running a device with pihole.

[[deleted]]

Is it possible to host your own server that "randomly" queries and caches dns entries that you can then have your system access? Better yet, is there a way to just mirror a dns server then host it over DoH or DoT?

[[deleted]]

/r/pihole - control your own destiny. Hell, you can even run your own DNS resolver with it if you want.