Live data from Hacker News

DNS over TLS – Thoughts and Implementation

sagi.io

61–70 of 88 posts

Re: DNS over TLS – Thoughts and Implementation

#61
post #58

Earlier quoted context omitted.

Its based Vyatta/VyOS [1]. There's a way to get OpenBSD running on it as well, but I don't have a link handy. The router isn't open hardware but its a good bang for the buck (I also run WireGuard on it, btw). If you want a fully open source router, I can recommend having a look at Router7 [2]. The author's using a PC Engines APU2. Downside is you gotta do a lot of work yourself, just like with OPNSense. But I like OP…

> ... do a lot of work yourself What work? Install is super easy ... I use OPNsense on small, fanless, cheap 'mini PC' with 2 LAN ports, you buy from aliexpress. Full x86-64, Intel with AES-NI support, for like $200 with 4GB RAM and 40GB ssd

4 GB RAM and a 40 GB SSD on a router??? I don't need that.

What work? Work to maintain it, test it, etc. Essentially, every time a software update is rolled out you do not know for sure if it is going to work flawless on your platform. For a random home network that might be sufficient; for a corporate network not so much.

I know about Aliexpress (and the like), but I don't find comparing Chinaware with non-Chinaware fair without taking that into account as a minus. Not that I wouldn't go that route if I would go for DIY though.

Router7 uses coreboot and a heartbeat to restart the machine if it fails.

x86-64 still uses more kWh than this MIPS machine. The ER-L has 3 ports, allowing physically separated networks. Depending on your setup you can even use both. The ER-X is less powerful and is MIPS32, though does support more hardware offloading (and WireGuard has optimalisations written in C for MIPS32).

Re: DNS over TLS – Thoughts and Implementation

#62
post #61

Earlier quoted context omitted.

> ... do a lot of work yourself What work? Install is super easy ... I use OPNsense on small, fanless, cheap 'mini PC' with 2 LAN ports, you buy from aliexpress. Full x86-64, Intel with AES-NI support, for like $200 with 4GB RAM and 40GB ssd

4 GB RAM and a 40 GB SSD on a router??? I don't need that. What work? Work to maintain it, test it, etc. Essentially, every time a software update is rolled out you do not know for sure if it is going to work flawless on your platform. For a random home network that might be sufficient; for a corporate network not so much. I know about Aliexpress (and the like), but I don't find comparing Chinaware with non-Chinaware…

Routers must run open source software, no exceptions, they are keys to the kingdom, corporate or home, no difference. FreeBSD/OpenBSD is de facto standard. Good projects like OPNsense test their production releases extensively.

Hardware is your choice, but x86 gives you the best compatibility, and kWh is good, x86 CPU power management, mine uses less than 1W, max TDP is 6W.

Cisco, Juniper, and other closed source ones have a history of backdoors [0]. Consumer grade routers are joke.

[0] https://www.bleepingcomputer.com/news/security/cisco-removes...

Re: DNS over TLS – Thoughts and Implementation

#63
post #54

I recently configured my OPNsense router, for DNS over TLS with Quad9, with certificate domain validation. It uses included Unbound resolver. Not sure what I achieved, but it does feel good :) https://forum.opnsense.org/index.php?topic=9197.msg41265#msg...

I've done the very same thing, on an EdgeRouter Lite [1]. Quad9 also supports DNSSEC. [1] https://www.chameth.com/2017/12/17/dns-over-tls-on-edgeroute...

Switching to unbound seems like extra work. I kept dnsmasq on my EdgeRouter and just pointed it at doh-client from [0] which is trivial to cross-compile. I’m using Google’s dns servers as upstream.

[0] https://github.com/m13253/dns-over-https/tree/master/doh-cli...

Re: DNS over TLS – Thoughts and Implementation

#64
post #61

Earlier quoted context omitted.

4 GB RAM and a 40 GB SSD on a router??? I don't need that. What work? Work to maintain it, test it, etc. Essentially, every time a software update is rolled out you do not know for sure if it is going to work flawless on your platform. For a random home network that might be sufficient; for a corporate network not so much. I know about Aliexpress (and the like), but I don't find comparing Chinaware with non-Chinaware…

Routers must run open source software, no exceptions, they are keys to the kingdom, corporate or home, no difference. FreeBSD/OpenBSD is de facto standard. Good projects like OPNsense test their production releases extensively. Hardware is your choice, but x86 gives you the best compatibility, and kWh is good, x86 CPU power management, mine uses less than 1W, max TDP is 6W. Cisco, Juniper, and other closed source one…

You were dependant on Cisco and Juniper routers whilst you posted this very message.

I've used the mess called Quagga back in '00s. No, thank you. I did like OpenBGPd, but it isn't a necessity to have BGP support on every router. Linux can be suffice on a router. Even though I do prefer PF, nftables seems promising.

I don't want to use x86-32 for a myriad of reasons. I don't need the software compatibility x86-32 offers.

Re: DNS over TLS – Thoughts and Implementation

#65
post #63
post #54

Earlier quoted context omitted.

I've done the very same thing, on an EdgeRouter Lite [1]. Quad9 also supports DNSSEC. [1] https://www.chameth.com/2017/12/17/dns-over-tls-on-edgeroute...

Switching to unbound seems like extra work. I kept dnsmasq on my EdgeRouter and just pointed it at doh-client from [0] which is trivial to cross-compile. I’m using Google’s dns servers as upstream. [0] https://github.com/m13253/dns-over-https/tree/master/doh-cli...

From what I learned, for DNS over TLS (DoT) you have three options:

- dnsmasq resolver using Stubby for DoT stuff

- Unbound resolver using Stubby for DoT stuff

- Unbound doing it all

The last one, as of today, is not quite ready, missing some stuff Stubby [0] does better.

[0] https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Daemon+-+...

Re: DNS over TLS – Thoughts and Implementation

#66
post #63
post #54

Earlier quoted context omitted.

I've done the very same thing, on an EdgeRouter Lite [1]. Quad9 also supports DNSSEC. [1] https://www.chameth.com/2017/12/17/dns-over-tls-on-edgeroute...

Switching to unbound seems like extra work. I kept dnsmasq on my EdgeRouter and just pointed it at doh-client from [0] which is trivial to cross-compile. I’m using Google’s dns servers as upstream. [0] https://github.com/m13253/dns-over-https/tree/master/doh-cli...

Thanks for mentioning an alternative.

It is extra work either way. What is better performance though?

I'm using dnsmasq with Pi-Hole's blocklists, and forwarding to unbound for DNS over TLS. Forwarding to another client such as doh-client could also work though I'm not sure how this would work with Quad9.

My router is being backup for this ensure there's less load on the MIPS machine.

Go is cross-platform, sure. However dnscrypt-proxy [1] is also very portable.

[1] https://github.com/jedisct1/dnscrypt-proxy

Re: DNS over TLS – Thoughts and Implementation

#67
post #56
post #48

Earlier quoted context omitted.

Besides public wlan this isn't an issue. In corporate networks it may be company policy to use their resolvers. External resolvers might not work for internal names, so their use is probably limited in the first place. Mobile networks should allow all ports, if not call your regulator. So 1 out of your 3 are actually important. Also, firewall rules can be changed.

I'll give you corporate networks though that's more guesswork than actual hard data on that. Plus point still stands that other protocols will be blocked unless using 443 or 80 ports. Mobile networks in my experience block a variety of protocols and intercept DNS fairly regularly, even in presence of DNSSEC or DNSCrypt. Not sure what calling the regulator would give me, they're not responsible for what ports the netw…

>I'll give you corporate networks though that's more guesswork than actual hard data on that. Plus point still stands that other protocols will be blocked unless using 443 or 80 ports.

Yes. But this is a corporate network. It's not up to you to decide which protocols should be allowed or not. (Unless you are in the position to do so of course) I know it's quite easy to tunnel everything through something, but why do that in a corporate environment. If you need to access X then get access to it (via proper channels?)

>Mobile networks in my experience block a variety of protocols and intercept DNS fairly regularly, even in presence of DNSSEC or DNSCrypt.

But do they block port 853 and if so, on what grounds? They sell you an Internet access, if a port is blocked, this is no longer a valid Internet access. If the port is not blocked however, then the ISP can no longer play around in DNS responses.

Re: DNS over TLS – Thoughts and Implementation

#68
post #64

Earlier quoted context omitted.

Routers must run open source software, no exceptions, they are keys to the kingdom, corporate or home, no difference. FreeBSD/OpenBSD is de facto standard. Good projects like OPNsense test their production releases extensively. Hardware is your choice, but x86 gives you the best compatibility, and kWh is good, x86 CPU power management, mine uses less than 1W, max TDP is 6W. Cisco, Juniper, and other closed source one…

You were dependant on Cisco and Juniper routers whilst you posted this very message. I've used the mess called Quagga back in '00s. No, thank you. I did like OpenBGPd, but it isn't a necessity to have BGP support on every router. Linux can be suffice on a router. Even though I do prefer PF, nftables seems promising. I don't want to use x86-32 for a myriad of reasons. I don't need the software compatibility x86-32 off…

> You were dependant on Cisco and Juniper routers

I don't think so, i have my own fortress :)

Re: DNS over TLS – Thoughts and Implementation

#69
post #63

Earlier quoted context omitted.

Switching to unbound seems like extra work. I kept dnsmasq on my EdgeRouter and just pointed it at doh-client from [0] which is trivial to cross-compile. I’m using Google’s dns servers as upstream. [0] https://github.com/m13253/dns-over-https/tree/master/doh-cli...

From what I learned, for DNS over TLS (DoT) you have three options: - dnsmasq resolver using Stubby for DoT stuff - Unbound resolver using Stubby for DoT stuff - Unbound doing it all The last one, as of today, is not quite ready, missing some stuff Stubby [0] does better. [0] https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Daemon+-+...

Ah right, I’m using DoH, not DoT.

Re: DNS over TLS – Thoughts and Implementation

#70
post #67
post #56

Earlier quoted context omitted.

I'll give you corporate networks though that's more guesswork than actual hard data on that. Plus point still stands that other protocols will be blocked unless using 443 or 80 ports. Mobile networks in my experience block a variety of protocols and intercept DNS fairly regularly, even in presence of DNSSEC or DNSCrypt. Not sure what calling the regulator would give me, they're not responsible for what ports the netw…

>I'll give you corporate networks though that's more guesswork than actual hard data on that. Plus point still stands that other protocols will be blocked unless using 443 or 80 ports. Yes. But this is a corporate network. It's not up to you to decide which protocols should be allowed or not. (Unless you are in the position to do so of course) I know it's quite easy to tunnel everything through something, but why do…

>But do they block port 853 and if so, on what grounds?

I don't know why they decide to block it but they do. Most of the time it's to prevent spam or to protect customers (ports lower than 1024 are sometimes blocked for that reason).

>They sell you an Internet access, if a port is blocked, this is no longer a valid Internet access.

That's a laughable argument, they don't sell you unrestricted internet access, that's already given by the fact we have datacaps and SMTP traffic from port 25 blocked.

Fact is, ports get blocked. The mentioned networks do it a lot. We should accomodate these restrictions because alternatively the software breaks for a consumer and if it's a choice between "uninstall DNSCrypt/DoT/DoH" or "complain to ISP or operator" then most consumers will not complain to the ISP because prior to DNSCrypt their internet worked for all they care.

Post reply on HN