In addition to reducing the load on the root servers, QNAME minimization improves privacy at each stage of a request.
quoting isc.org:
“Let’s say you want to visit a blog site at https://someblogname.bloghosting.com.pl. In order to determine which IP address to connect to to reach that link, your computer sends a request to your ISP’s resolver, asking for the full name - someblogname.bloghosting.com.pl, in this case. Your ISP (or whoever is running the network you are using) will ask the DNS root, and then the top-level domain (.pl in this case), and then the secondary domain (.com.pl), for the full domain name. In fact, all you are finding out from the root is “where is .pl?” and all you are asking .pl is “where is .com.pl?” Neither of these requests needs to include the full name of the website you are looking for to answer the query, but both receive this information. This is how the DNS has always worked, but there is no practical reason for this today.”
For BIND, it’s qname-minimization ( strict | relaxed | disabled | off ); for unbound, it’s qname-minimisation: yes.
What is the encryption for? In general, encryption is there to preserve two properties: confidentiality and integrity. The integrity is already handled by DNSSEC and has the nice property that the response is the same for everyone (more on this later). The confidentiality matters only when it leaks secret information. The fact that some ISP’s user has looked for a specific domain name may well leak private information (e.g. have they been looking up a site that shares information critical of the government) that can have serious real-world consequences. The fact that some ISP’s user has looked up a domain in Poland or a domain with a .com ending is not, I would suggest, leaking any information that people would care about being leaked. If my anonymity set is all of my DNS server’s users and the only information that leaks is that I’ve looked up some .com domain, I fundamentally don’t care.
The desire to have the same response for everyone is driven by the fact that, to scale up to the performance, the root DNS resolvers that I know about (operated by VeriSign) pre-prepare packets in memory, update the destination addresses and the checksums, and then send the DMA request. They get phenomenal throughput and latency from this approach.
My slight worry about this argument for confidentiality comes from the fact that 97% of root DNS responses return NXDOMAIN. They are the result in typos in the domain. For example, if you omit the .com by accident and type example instead of example.com, then the root DNS will be queried with the second-level domain name, example. In this case, any passive observer of the traffic knows that you’ve typed example. That’s probably easy to work around in the querying servers by using encrypted DNS queries for any TLD that they haven’t seen before, but that only helps performance for the 3%. The TLDs typically have quite long TTLs, but when that expires you take a TLD completely off the Internet for users of the caching resolver if there’s a denial of service on the root servers.
The integrity is already handled by DNSSEC and has the nice property that the response is the same for everyone (more on this later).
DNSSEC suffers from complexity, architechtural fragility, and extremely low adoption. In fact, DNSSEC’s failings are one of the biggest arguments in favour of DoH and DoT.
like @david_chisnall said, they are mostly trying to solve different things. DNSSEC lets the large DNS providers(read roots) the ability to scale. DoH and DoT don’t. You are single-sourcing your DNS to an exact entity, just like with an ISP, except instead of your ISP knowing what you are looking up , it’s Google and Cloudfare(or whoever your DoH & DoT provider is, but they are the defaults). Who wouldn’t want to be Google/Cloudfare. They say they are not doing bad things with your information, but we don’t actually know that, we just have to trust them.
So you are avoiding your ISP from seeing your lookups, you could have done that with a VPN/tunnel just as easily, without any DoH or DoT. DoH and DoT don’t fix the problem of a nation state/ISP seeing where you are going, as SNI headers are still not encrypted(last I checked). Of course this is only HTTP problems, many such exist. Information leakage on the internet happens ALL over the place, and while DoH and DoT mostly can help, they are not magic bullets.
DoH and DoT don’t solve the problem of your DNS provider lying to you. DNSSEC can, in theory(provided it was fully deployed, which it clearly isn’t).
Before DoH and DoT, your actual OS was generally 100% in charge of where your DNS requests are going, but now it’s a guessing game as to who is answering a given DNS request. Web browsers have stolen control of that too, further proving that web browsers are Operating Systems in disguise.
The only reason DoH/DoT has gotten such adoption is because Web Browsers forced it on us.
I’m not against DoH or DoT, but they aren’t magical solutions to the problem(s), but obviously DNSSEC isn’t either.
In addition to reducing the load on the root servers, QNAME minimization improves privacy at each stage of a request.
quoting isc.org:
“Let’s say you want to visit a blog site at https://someblogname.bloghosting.com.pl. In order to determine which IP address to connect to to reach that link, your computer sends a request to your ISP’s resolver, asking for the full name - someblogname.bloghosting.com.pl, in this case. Your ISP (or whoever is running the network you are using) will ask the DNS root, and then the top-level domain (.pl in this case), and then the secondary domain (.com.pl), for the full domain name. In fact, all you are finding out from the root is “where is .pl?” and all you are asking .pl is “where is .com.pl?” Neither of these requests needs to include the full name of the website you are looking for to answer the query, but both receive this information. This is how the DNS has always worked, but there is no practical reason for this today.”
For BIND, it’s qname-minimization ( strict | relaxed | disabled | off ); for unbound, it’s qname-minimisation: yes.
About 51% of DNS resolvers do QNAME minimization now: https://dnsthought.nlnetlabs.nl/#qnamemin
+1 I am in the middle of switching to PowerDNS from BIND, so I thought I’d respond on how PowerDNS is doing.
For PowerDNS, both QNAME and aggressive caching are enabled by default now.
These are nice to have features but do not function as replacements for encryption.
What is the encryption for? In general, encryption is there to preserve two properties: confidentiality and integrity. The integrity is already handled by DNSSEC and has the nice property that the response is the same for everyone (more on this later). The confidentiality matters only when it leaks secret information. The fact that some ISP’s user has looked for a specific domain name may well leak private information (e.g. have they been looking up a site that shares information critical of the government) that can have serious real-world consequences. The fact that some ISP’s user has looked up a domain in Poland or a domain with a .com ending is not, I would suggest, leaking any information that people would care about being leaked. If my anonymity set is all of my DNS server’s users and the only information that leaks is that I’ve looked up some .com domain, I fundamentally don’t care.
The desire to have the same response for everyone is driven by the fact that, to scale up to the performance, the root DNS resolvers that I know about (operated by VeriSign) pre-prepare packets in memory, update the destination addresses and the checksums, and then send the DMA request. They get phenomenal throughput and latency from this approach.
My slight worry about this argument for confidentiality comes from the fact that 97% of root DNS responses return NXDOMAIN. They are the result in typos in the domain. For example, if you omit the .com by accident and type
exampleinstead ofexample.com, then the root DNS will be queried with the second-level domain name,example. In this case, any passive observer of the traffic knows that you’ve typedexample. That’s probably easy to work around in the querying servers by using encrypted DNS queries for any TLD that they haven’t seen before, but that only helps performance for the 3%. The TLDs typically have quite long TTLs, but when that expires you take a TLD completely off the Internet for users of the caching resolver if there’s a denial of service on the root servers.DNSSEC suffers from complexity, architechtural fragility, and extremely low adoption. In fact, DNSSEC’s failings are one of the biggest arguments in favour of DoH and DoT.
like @david_chisnall said, they are mostly trying to solve different things. DNSSEC lets the large DNS providers(read roots) the ability to scale. DoH and DoT don’t. You are single-sourcing your DNS to an exact entity, just like with an ISP, except instead of your ISP knowing what you are looking up , it’s Google and Cloudfare(or whoever your DoH & DoT provider is, but they are the defaults). Who wouldn’t want to be Google/Cloudfare. They say they are not doing bad things with your information, but we don’t actually know that, we just have to trust them.
So you are avoiding your ISP from seeing your lookups, you could have done that with a VPN/tunnel just as easily, without any DoH or DoT. DoH and DoT don’t fix the problem of a nation state/ISP seeing where you are going, as SNI headers are still not encrypted(last I checked). Of course this is only HTTP problems, many such exist. Information leakage on the internet happens ALL over the place, and while DoH and DoT mostly can help, they are not magic bullets.
DoH and DoT don’t solve the problem of your DNS provider lying to you. DNSSEC can, in theory(provided it was fully deployed, which it clearly isn’t).
Before DoH and DoT, your actual OS was generally 100% in charge of where your DNS requests are going, but now it’s a guessing game as to who is answering a given DNS request. Web browsers have stolen control of that too, further proving that web browsers are Operating Systems in disguise.
The only reason DoH/DoT has gotten such adoption is because Web Browsers forced it on us.
I’m not against DoH or DoT, but they aren’t magical solutions to the problem(s), but obviously DNSSEC isn’t either.