Live data from Hacker News

DNS over HTTPS

github.com

101–110 of 195 posts

Re: DNS over HTTPS

#101
post #21

Where does the privacy advantage come from? Once you resolve a hostname privately, don't you still need to use its IP address publicly for your traffic to be routed there?

One case where it might help is shared hosting: you don't know which of the domains hosted on that IP you're accessing. Narrows it down to just a few though, so IMHO not a big improvement.

You'll need to mask page size if your trying to hide your access, even on a shared host with 100 domains I doubt you'll have pages where the byte-size isn't unique.

I think with https the results were something like 90% of page access could be guessed using meta-data (see eg https://web.archive.org/web/20090308103611/http://sysd.org/s...). That's going to drop when you don't know the site but you're going to need more counter-measures to hide your access effectively.

Re: DNS over HTTPS

#102

Earlier quoted context omitted.

Can anyone give examples of cases where “performant” would be better than “efficient”? To my mind, the difference is that “performant” delivers results quickly, whereas “efficient” uses little energy. A performant solution might be efficient, but not necessarily, and vice versa. Does anyone else share this understanding or am I living in a linguistic bubble? Not sure about Swedish (Daniel is Swedish), but in Finnish,…

I think the word that was being grasped for is 'faster'. It suffers in that doesn't sound very technical.

GPU can perform more operations than CPU, but GPU is slower than CPU, not faster.

Re: DNS over HTTPS

#103
post #78
post #74

Earlier quoted context omitted.

why shady? (assuming that shady is meant in a negative way)

It's clearly to evade a security control.. As if you approached a door, to find it locked, but then discovered the front window was unlocked and let yourself in.. Clearly the occupant didn't want you to enter, and just failed to secure the entire building. Pretty sure nobody would ever suggest it was okay for you to enter in such a way.

I doubt that. If DNS traffic is not filtered or blocked, it is clearly intended to transmit data that way.

On a public wlan I first try to use VPN with port 53 (not DNS). If it works, I'll use it that way.

Re: DNS over HTTPS

#104
post #63

Earlier quoted context omitted.

Why not?

In USA and UK at least unauthorised access or use of a computer is criminalised. On some situations you can argue for assumed consent, the law doesn't operate on "if I can do it then it's authorised". Unless you can show you have permission then it's not authorised, ergo not legal. AIUI; not legal advice.

But the premise was to circumvent crap such as captive portals. Doing that on your own computer (mostly in a public wlan), I don't see any reason against it.

Re: DNS over HTTPS

#105
post #30

Anyone has good pointers on DNS over DTLS (draft RFC 8094) vs DNS over TLS (RFC 7858) vs DNS over HTTPS (this draft) ? And if you could throw in DNSSEC in the mix, that would be helpful.

With pleasure - (CTO of DNSFilter, this is my world)

DNS over DTLS (RFC 8094) speaks only to UDP This could be compared with DNSCrypt's implementation

DNS over TLS (RFC 7858) is TCP focused

DNS over HTTPs is focused on... you guessed it, HTTPs

So all the same thing, all trying to add security and privacy, just over different transport mechanisms.

While we're at it -- you did not mention DNS over QUIC: https://tools.ietf.org/id/draft-huitema-quic-dnsoquic-00.htm...

Some factors which start to come in to play with the various options are: Compatibility with firewalls and proxies (DNS over HTTPs wins, others over port 853 have a disadvantage, even if you put them on port 443, they may get stopped by deep packet inspection)

TLS Improvement knobs: 0-RTT, TCP Fast Open, etc. (You can find a summary of these here: https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Implement... )

And closely related, performance. It's tough to beat a lossy protocol with minimal overhead (UDP), but there have been a lot of improvements with Keep alive, eDNS0, pipelining, etc.

We're currently doing a lot of testing around this, as we are working to offer useragents and LAN proxies implementing DNS over TLS, compared with DNSCrypt.

Finally: DNSSEC. It lives in a different part of the 'security' spectrum here... The purpose of DNSSEC is to be able to authenticate the validity of an answer when traveling through untrusted parties (say you're using a third-party resolver, or do you trust your ISP's DNS to not mangle with responses). It does not encrypt request/responses. It does not provide privacy. It answers the question: "Can I trust this response I received for example.org to be the one that example.org intended me to receive?"

Re: DNS over HTTPS

#106
post #89

Earlier quoted context omitted.

Performant to me implies performing better against the relevant metrics. So faster, maybe, but perhaps smaller and more energy efficient too. If the context of the metrics is already understood then it seems quite a cromulent word.

What's cromulent mean? I looked it up at dictionary.com and couldn't find anything. Or are you making up more words to point out the irony? :)

Others have filled in the detail of origin and meaning. Yes, my intent was to use another neologism to add an ironic tone. Language is always changing.

Re: DNS over HTTPS

#107
post #43
post #20

So what use does this have? DNSSEC already gives us validation of the records, and thanks to SNI, this doesn't give us any privacy. It is more complex, more centralized, and ends up slower than using actual DNS, and doesn't seem to provide any benefits. Am I missing something?

don't you think SNI leaks will get fixed eventually?

Yes. https://www.ietf.org/proceedings/94/slides/slides-94-tls-8.p...

Re: DNS over HTTPS

#108
post #42

Earlier quoted context omitted.

The algorithm doesn't perform more efficiently or accurately, though - it's less efficient (it uses more resources) and it should be the same accuracy (or we're comparing apples with oranges).

haha yah i know, it would perform terrible. imagine running a big dns server at ISP level, and having to perform 9 million tls handshakes a second. have fun with that lol. this was just an example of how to avoid the 'performant' word.

If we’re getting pedantic about linguistics, wouldn’t that be, “it would perform terribly” instead of “it would perform terrible”?

Re: DNS over HTTPS

#109

We prototyped this as an intern project at OpenDNS, too: https://github.com/opendns/OpenResolve We mostly built it because it sounded cool, but one use case that I though was important was being able to boot these images in different data centers to collect telemetry on DNS differences geographically (eg for hijacking or anycast).

Nice project!

We at DNSFilter are able to collect that same telemetry just by having resolvers at each of the anycast locations -- between the different locations, and passing along eDNS Client Subnet information, many responses will be (legitimately) different. A little hard to see a hijack in that noise.

Post reply on HN