Hacker News Reader

Comment by adsadadsad | Hacker News Reader

Maybe. But it's trivial, for your ADSL/DSL/Fiber shitty $30 router to intercept port 53/(udp|tcp) bind it to it's own local dnsmasq or whatever and then send DNS onward to DHCP DNS servers supplied by your ISP. When I say trivial I mean I've seen it happen on several setups, old me - we'll just change the DNS on this box to bust the cache here to 1.1.1.1(CF)/8.8.8.8(EvilG) but still end up a shitty ISP dns servers (and their poisoned cache regardless). There's a reason for the push for DNS over HTTPS.

You think you're guaranteed to be querying 8.8.8.8 with "nslookup hostname.tld 8.8.8.8"?

View on HN

> bind it to it's own local dnsmasq or whatever and then send DNS onward to DHCP DNS servers supplied by your ISP... There's a reason for the push for DNS over HTTPS.

This is looking at things and totally backwards. You have a local problem, a broken router and you suggest we fix this by changing how all edge nodes on the internet works.

In the age of ever increasing, untrustworthy IOT-devices, you don’t solve this problem by taking control away from the network operator. You need to increase his control. Taking DNS out of his hands is literally madness.

Good luck trying to block their attempts to spy and report on you now!

DNS over HTTPS is going to cause a shitload more problems than it solves.

I'm not sure Im following why is HTTPS going to cause a shitload more problems?

Not HTTPS. DNS over HTTPS.

If we create internet infrastructure (like DNS over HTTPS) which prevents network operators from actually operating their networks, I’m 100% confident we will find it has bad, unintended and irreversible consequences.

If by "network operators" you mean ISP's then I don't care. They have proven beyond a shadow of a doubt that they are malicious ones more often than not and I want them to be a dumb pipe NOT someone who is mucking around with my network. I will take being able to PICK who I trust my DNS with over being forced to use my ISP's any day of the week. One of those things I can change, one of them I cannot.

By network operator I mean me, the person controlling my own local network.

Also: ISPs behave nice almost everywhere in the world where there is proper regulation.

What you have in the US is not a technical problem. It’s a regulatory one.

yup, hey i bought this device, that i cannot see what it is doing exactly. great.

Agreed. Many orgs will end up null routing the DoH resolver IP addresses. I warned them about this from the start of DoH development and they ignored me, since most end users won't block anything.

Because it's encrypted to the app rather than the endpoint's OS or local DNS, so it's more difficult for the system owner to override it or implement a systemic policy.

The performance characteristics are also rather unfortunate. TCP handshake + TLS handshake with multiple public key operations + TCP protocol overhead adds quite a lot of both latency and computation vs. UDP DNS. DoH is even worse. There would have been ways (e.g. DNSCurve) to get equivalent or better security with less latency and computation if it weren't for horrible middleboxes breaking everything they don't understand.

And all that complexity is attack surface.

In a world of mobile devices and public WiFi spots set up by random businesses, you're saying we should trust the network operator? That's a rather odd argument.

>DNS over HTTPS is going to cause a shitload more problems than it solves.

Oh, absolutely. What I wonder is if people don't notice this, or they do but believe Google is right in pushing fundamental internet design decisions that prioritize Google's incidental access to surveillance data over a high quality and resilient network for everyone.

I believe that they have created a double-edged razor blade. DoH can protect people that have malicious ISP's. It also hands over a lot more control to Google. I don't like either of those scenarios.

By control, what I mean is that once DoH usage to G servers hits critical mass, they can decide who can visit what. Not that they would, but they can. People generally do what people can do.

Yes I know. I've had it happen to me with a Huawei HG556a. You could disable it with admin access... which the ISP would not give you. Fun times.

A good way of bypassing this would be to simply have Google run their DNS server in a port other than 53. But I don't believe you can set a different port in /etc/resolv.conf

Possibly feasible with local netfilter/iptables rules or maybe userland proxy/rerouter. set /etc/resolv.conf to localhost:53, have that forward to 8.8.8.8:1053 or whatever, but without encryption it could be detected I'm guess with deep packet filtering (hopefully beyond the thoroughput constraints of eyeball ISPs)

Reply on news.ycombinator.com