Hacker News Reader

Comment by mattnewport | Hacker News Reader

I must be missing something here: "The ODNS server can thus return the answer to the client’s stub resolver directly, possibly over a confidential channel such as D-TLS."

How does this not just move the trust problem to the ODNS server? Doesn't it now know both the requesting IP and the requested domain?

View on HN

Yeah, the figure[1] on the side in the article seems to show something different, because there the response goes over the recursive resolver again. Maybe the text is wrong?

All seems to hinge on the recursive resolver acting as a proxy, so a direct response from ODNS server to the client stub doesn't seem safe.

[1] https://s3.amazonaws.com/ftt-uploads/wp-content/uploads/2018...

My reading of it is that the DNS request gets encrypted on the client and sent to ODNS. ODNS doesn't know how to decrypt the request so it can't see what you are looking for, just that it is you that is looking.

The ODNS resolver then sends the encrypted request to the DNS resolver on your behalf, and the DNS resolver decrypts the request and services it. This meanst that the DNS resolver knows what website you are looking for, but doesn't know that it is you that is looking for it.

The DNS resolver then encrypts the result and returns it to the ODNS, which then returns it to you.

It is basically decoupling the identity of the requester from the domain being requested.

So is my thought. Surely they have yet to come up with something akin to an onion routing layer where the machine performing the lookup is not owned by the same entity as those who know its origin?

How is the middle path between current DNS and Tor-level anonymity defined, exactly?

> How does this not just move the trust problem to the ODNS server?

That's how I read this as well. It does appear that a simple DNS proxy would accomplish the same goal without all the encryption. Are we missing something?

Reply on news.ycombinator.com