Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DNS over TLS – Thoughts and Implementation

sagi.io

Post reply on HN
Print view View original

71–80 of 88 posts

Re: DNS over TLS – Thoughts and Implementation

#71

Post by js2 »

Fnoord wrote: post #66
js2 wrote: 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...

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

I’m not sure about better performance. Once it’s cached it doesn’t matter.

Using unbound won’t survive an EdgeOS upgrade will it? Maybe a script under /config/scripts could ensure unbound is installed and configured though.

Re: DNS over TLS – Thoughts and Implementation

#72

Post by Fnoord »

auslander wrote: post #68
Fnoord wrote: post #64

Earlier quoted context omitted.

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 :)

You don't have control over every hop between news.ycombinator.com and whatever it is you are located. Lets stop this game.

Re: DNS over TLS – Thoughts and Implementation

#73

Post by bwoodcock »

bogomipz wrote: post #4

I used Stubby and Quad9 for a few months last year but I found the latency pretty terrible unfortunately. I would be curious to hear what other people are using and what their experience has been.

Did you open a ticket? What AS and city are you originating from, and which Quad9 location were your queries going to?

Re: DNS over TLS – Thoughts and Implementation

#74

Post by bwoodcock »

bubblethink wrote: post #23
bogomipz wrote: post #4

I used Stubby and Quad9 for a few months last year but I found the latency pretty terrible unfortunately. I would be curious to hear what other people are using and what their experience has been.

Try cloudflare ? I found it beats quad9 in latency by a margin.

Again, if that's the case, you should open a trouble ticket, so the problem can be fixed. It won't get fixed if there isn't a work ticket and nobody knows where your traffic is coming from or going to.

Re: DNS over TLS – Thoughts and Implementation

#75

Post by auslander »

Fnoord wrote: post #72
auslander wrote: post #68

Earlier quoted context omitted.

> You were dependant on Cisco and Juniper routers I don't think so, i have my own fortress :)

You don't have control over every hop between news.ycombinator.com and whatever it is you are located. Lets stop this game.

There is a HTTPS, between HN and me. "HTTPS creates a secure channel over an insecure network. This ensures reasonable protection from eavesdroppers and man-in-the-middle attacks ..."

https://en.wikipedia.org/wiki/HTTPS

Re: DNS over TLS – Thoughts and Implementation

#76

Post by Fnoord »

Fnoord wrote: post #72
auslander wrote: post #68

Earlier quoted context omitted.

> You were dependant on Cisco and Juniper routers I don't think so, i have my own fortress :)

You don't have control over every hop between news.ycombinator.com and whatever it is you are located. Lets stop this game.

Yeah, and? There's HTTPS between my browser and news.ycombinator.com as well. So what does that have to do with my ER-L?

There's no need to link to Wikipedia's HTTPS either. We both know what that is.

FYI: The malware you linked was for older or badly configured versions of those routers. If you don't upgrade OPNSense or Linux/BSD in general you're also in trouble.

Re: DNS over TLS – Thoughts and Implementation

#77

Post by gsich »

zaarn wrote: post #70
gsich wrote: post #67

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

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

Some do and I would complain about it. Maybe port 25 has a spam related reason, but every other port has not.

But to come back: crappy networks are not a reason to ditch "custom" ports. Fix the network.

Re: DNS over TLS – Thoughts and Implementation

#78

Post by amaccuish »

fanf2 wrote: post #47

I deployed DNS-over-TLS on Cambridge University’s central recursive DNS servers last week, and they immediately started receiving traffic from Android P users - not very much traffic, a few queries per second, but not negligible. I did some followup investigation of how Android behaves in the wild and posted them to the IETF DoH list (and the dprive list but for some reason those copies did not go through) - see http…

Is there a new dhcp option to indicate availability, or is it opportunistic, when the device notices port 853 is open?

Re: DNS over TLS – Thoughts and Implementation

#79

Post by ggm »

bogomipz wrote: post #7
ggm wrote: post #6

Earlier quoted context omitted.

I used SSH SOCKS tunnels with stubby to keep myself online inside China's state firewall two recent trips. commercial VPN are routinely slowed down or blocked, if you have the luxury of an SSH enabled host "outside" you can use, Stubby and this are good, to get around DNS rewriting tricks and port/ip filters. Yes, you have have slower paths, trombone paths. But in the circumstances I was in, Stubby was a godsend. Als…

Interesting. Can I ask what you used for your SSH host so that latency was bearable?

A node in Brisbane. I checked path, the AS path was pretty tight, china-telecom to telstra-reach and then into the IX where I have a FreeBSD host. I was testing web speeds to the company on non-SSH/SOCKS paths, they were pretty bad oddly, quite heavily asymmetric, via the US and Japan and in some cases Europe. China-Australia via Europe is not very optimal.

It has to be said if you're trying to bypass DPI, speed isn't your main concern. I tolerated pretty low packet rates. If I had to VOIP it would have been awful

Re: DNS over TLS – Thoughts and Implementation

#80

Post by zaarn »

gsich wrote: post #77
zaarn wrote: post #70

Earlier quoted context omitted.

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

>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. Some do and I would complain about it. Maybe port 25 has a spam related reason, but every other port has not. But to come back: crappy networks are not a reason to ditch "custom" ports. Fix the network.

>But to come back: crappy networks are not a reason to ditch "custom" ports. Fix the network.

I heavily disagree. Broken and crappy networks exist and for the user it's easier if the software we write works on broken and crappy networks. Most users will not complain to the network if YOUR software doesn't work on it but other software works fine.

That's simply the reality of the situation.

Post reply on HN