Hacker News new | ask | show | jobs
by cookiengineer 1651 days ago
After reading through the draft I think I don't understand the argument about user privacy.

Does QNAME minimization try to prevent the scenario where a malicious party has setup a DNS tracker that responds with the same A/AAAA entries for a specific subdomain in the sense that e.g. "session-id.actualserver.company.tld" results in the same entries as "actualserver.company.tld"?

How would a client detect this before actually resolving it? I mean, if TTL is 0, no client will cache the results and therefore the minimization aspects are kind of irrelevant because the client has to resolve all over again, right?

I think I am having questions about the logical conditions "when" a client tries to resolve "_" before resolving the actual domain, which I am assuming is what the draft proposed...because to me this scenario would have the requirement that the very same party also has ownership of the HTML/actual links in the code, so I don't understand what it's trying to prevent because the same party could just read their apache logs to gain better datasets.

Maybe I'm missing something here?

1 comments

QNAME minimization is for recursive resolvers.

The scenario is that you want to resolve alice.example.com but you don't want the root servers or the .com servers to know any more information than they need to.

Historically you would send the whole query to all servers. Even the root servers would see the entire fully-qualified domain name (alice.example.com) even though all they're going to do is refer you to the .com servers. With QNAME minimization the root servers only know that you want something under .com and the .com servers only know you want something under .example.com and so on.

Now suppose the root servers don't do any kind of encryption but example.com supports DNSCurve or some other opportunistic encryption and so do you. Your ISP used to see the query going to the root servers or the .com servers and know the FQDN even if the query to example.com was encrypted. Now they don't.

Likewise, if someone is sitting on the root servers watching all the queries from everyone, they used to see FQDNs, now they only see top level domains.

Ahhh! Now it makes sense.

I didn't have in mind that an ISP could have their own map of all zones where they simply map observed specific DNS traffic to the zones themselves because they know which server is responsible as well.

Thanks for the explanation! :)

> Your ISP used to see the query going to the root servers or the .com servers and know the FQDN even if the query to example.com was encrypted. Now they don't.

In practice your recursive resolver either is your ISP (in which case this helps nothing) or is outside of your ISP (and your ISP can't see its queries). The only realistic privacy leaks that is addresses is leaking subdomains to the root servers and other delegating servers higher up the chain an their network operators.

Many organizations operate their own recursive resolvers. There is also nothing stopping an individual from doing so, even if most don't.