Live data from Hacker News

DNS-over-HTTPS Policy Requirements for Resolvers

blog.mozilla.org

71–80 of 301 posts

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#71
"To that end, today we are releasing a list of DOH requirements, available on the Mozilla wiki, that we will use to vet potential resolvers for Firefox. The requirements focus on three areas: 1) limiting data collection and retention from the resolver, 2) ensuring transparency for any data retention that does occur, and 3) limiting any potential use of the resolver to block access or modify content."

I sometimes use a local resolver bound to localhost that blocks ads by pointing to a custom root.

If someone aiming to be on the TRR list sets up a remote resolver that blocks ads (or replaces them with blank images) perhaps using the same technique, it could allow Firefox users to get ad blocking by default, by using DOH.

I wonder if that would violate Mozilla's requirements?

Are ads considered "content"?

There is of course precedent for blocking undesirable content via DNS as a "service".

Third party DNS service, for example the famous one that starts with "O", has been used to block certain content, e,g, at schools.

This was offered as a fee-based service.

If I remember correctly they also offered "free" service which was subject to redirection of NXDOMAIN to paid placement "search" results/ads.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#72

I replied sub-thread, but adding here to give some more visibility to some of the issues DoH is causing and will cause: I work at a k12 school and I am involved on many k12 IT communities. Some schools already removed Firefox from the students computers because it was being used as a "VPN" by some elementary students to access porn - at school. Guess what this VPN was? Just DNS over HTTPS. There is a fine line betwee…

Why did the schools remove Firefox rather than enforcing no-DoH in the Firefox config files (not about:config)?

Of course you can lock stuff via enterprise settings so that about:config entries can't be modified by local users, but that takes time to find out and test, while removing the weird non-Chrome browser that's still present mostly for inertia reasons but nowadays only gets used for evil porn is much easier.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#73
post #71

"To that end, today we are releasing a list of DOH requirements, available on the Mozilla wiki, that we will use to vet potential resolvers for Firefox. The requirements focus on three areas: 1) limiting data collection and retention from the resolver, 2) ensuring transparency for any data retention that does occur, and 3) limiting any potential use of the resolver to block access or modify content. " I sometimes use…

This is talking about requirements for resolvers that will be included by default:

    We have implemented DNS over HTTPS [RFC8484] and would like to
    deploy it by default for our users. We intend to select a set of
    Trusted Recursive Resolvers (TRRs) that we will use for DoH
    resolution.
https://mailarchive.ietf.org/arch/msg/doh/po6GCAJ52BAKuyL-dZ...

Presumably you can still configure your machine to use whichever resolver(s) you want.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#74
post #4

Earlier quoted context omitted.

His main argument seems to be that the network operator should have control over DNS requests for safety reasons. Control and monitoring. This is the antithesis of privacy and encryption. I wouldn't be surprised if he was pro http over https either.

> His main argument seems to be that the network operator should have control over DNS requests And why is that an unreasonable position for a network operator to hold?

The issue comes from network operators wanting to control DNS from being a middleman in the connection, but there is no way to ensure the people acting as middlemen in the connection are authorized to be in the middle or authorized to change those DNS requests.

If a network operator can change DNS, then the ISP, network hops, or a malicious twin AP can as well.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#75

Earlier quoted context omitted.

Ultimately we cannot secure content without being able to look at it (encryption is the problem). We need to be able to look at what the kids are looking at if we want to control what information gets to them. DNS is a band-aid solution with side effects.

Band-aid solution that worked pretty well. Very cheap to implement, widely supported and used by many schools. Our student's data was still private (no emails or passwords being decrypted) and we did the filtering only based on the domain name. It also didn't require an expensive appliance that would be need if did the filtering based on SNI.

When you allow BYOD you give up the ability to control the client, and you allow the mess of kids bringing their family computers to school, as well as this difference where other kids bring their own much-better computer.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#76
post #10

Earlier quoted context omitted.

DoH has already more adoption than all previous approaches combined. (Note: I don't think DNS-over-QUIC is really any different from DoH. QUIC is just another way of transmitting HTTPS, so you can just do DoH over QUIC.)

> DoH has already more adoption than all previous approaches combined Are you sure? My experience so far has shown that only dnscrypt is widely supported. Nevertheless, surely they must had some kind of issue with the existing solutions when they started working on it. As for DNS over QUIC, I was under the impression that said solution did not make use of HTTP.

> As for DNS over QUIC, I was under the impression that said solution did not make use of HTTP.

I believe it's possible to do both direct DNS over QUIC and ((DNS over HTTPS) over QUIC).

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#77
post #14

I hadn't been paying much attention to DNS-over-HTTPS, but I recently listened to a talk that Dr. Paul Vixie (of BIND fame) gave that where DNS-over-HTTPS was discussed: https://youtu.be/OxFFTxJv1L4?t=2799 After hearing Dr. Vixie discuss DNS-over-HTTPS from a network operator perspective I'm a lot more wary of the protocol.

(full disclosure: I'm affiliated to Cloudflare, but opinions here are my own of course) Thanks for posting this. I knew Paul is against DoH, but never understood his specific arguments. He has great comment about DoT (dns over TLS) couple of minutes before the linked youtube (I agree with him on that). Personally I'm not an "owner" of the networks I'm connecting to. My home router is managed by my ISP, I don't run pi…

> I have couple of unique domain names that I have open in my browser which have unique and non-guessable DNS names, which are crawled by some bots today. Even though I never shared them in any way with anyone! The only way they could be exposed for crawling is by my DNS provider leaking the DNS traffic to some shady third-party.

Not true.

They may be connecting directly by IP (it's typically not possible to determine if they did just from access logs). The web (or other application) server may also leak the name when connected to.

If you use TLS, which is likely, your domain names would leak through the certificate transparency logs.

...and there are surely more leak vectors than the above, so it's far from certain that the crawlers you see found their target by sniffing your DNS requests.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#78

I replied sub-thread, but adding here to give some more visibility to some of the issues DoH is causing and will cause: I work at a k12 school and I am involved on many k12 IT communities. Some schools already removed Firefox from the students computers because it was being used as a "VPN" by some elementary students to access porn - at school. Guess what this VPN was? Just DNS over HTTPS. There is a fine line betwee…

I don't think there is a good solution. Yes, you own the network and think you should be technologically able to block access to certain websites (which the school has the right to do), but ISPs also "own" the network and would also be able to block access to certain websites if it were possible with DoH+eSNI. I guess a solution is MDM, but that's still getting students to install something on their device.

I would not install a school managed backdoor on my device.

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#79
post #72

Earlier quoted context omitted.

Why did the schools remove Firefox rather than enforcing no-DoH in the Firefox config files (not about:config)?

Of course you can lock stuff via enterprise settings so that about:config entries can't be modified by local users, but that takes time to find out and test, while removing the weird non-Chrome browser that's still present mostly for inertia reasons but nowadays only gets used for evil porn is much easier.

Saving time by applying a non-solution 9like removing one browser instead of treating the root cause) is not actually saving anything. You just kick the problem further down the road. Firefox prefs are documented even if not in the most user friendly way [0][1][2][3]. For the most part performing some basic hardening and other useful config on the browser takes less than a day. A person with some IT background shouldn't have too much problems doing it and it's more or less a one time thing.

[0] https://dxr.mozilla.org/mozilla-release/source/modules/libpr...

[1] https://dxr.mozilla.org/mozilla-release/source/browser/app/p...

[2] https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Ent...

[3] https://support.mozilla.org/en-US/products/firefox-enterpris...

Re: DNS-over-HTTPS Policy Requirements for Resolvers

#80
post #55

Still no explanation on why dns-over-https rather than the already widespread dnscrypt or the lesser known dnscurve, dns-over-quic, and dns-over-tor.

DNSCrypt and other solutions typically involve changes to the DNS resolver in the underlying operating system. That's a lot harder to get changed and deployment can take a long time. DOH can be implemented directly inside of the web browser application, since those browsers are obviously already doing everything over HTTPS. So the browser developers just have to build in a DNS client. From their perspective, I would…

Yandex has been shipping support for DNSCrypt in their web browser since 2016.
Post reply on HN