[fanf2]

It is one of the variants of qname minimization.

I wrote the draft algorithm that appears in appendix A of the first experimental RFC describing qname minimization https://datatracker.ietf.org/doc/html/rfc7816#appendix-A

I wrote it because I wanted more specific advice about how qname minimization should work, and I deliberately aimed it at an ideal world, ignoring obvious interoperability problems. I hoped that this would provoke discussion and get people working towards a more realistic algorithm. But that did not happen until years later.

So the early implementations of qname minimization had to invent their own ways of working around the inevitable interop problems, and some of those solutions were quite creative.

I think the bare _ version is trying to avoid querying delegation points directly, so that it still gets a referral as it would have done using the full qname. And the _ also avoids problems with negative responses, which are often implemented very badly - it is common to make a mess of the distinction between NXDOMAIN and NODATA.

[cookiengineer]

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?

[zrm]

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.

[cookiengineer]

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! :)

[account42]

> 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.

[zrm]

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

[skoskie]

This is why I love HN.