Pdns: DNS Query Name Minimisation on demand

[paddg]

• Program: Recursor
• Issue type: Feature request

"DNS Query Name Minimisation (qm)" is an important aspect in the DNS privacy efforts. And beyond that, part of the "Mozilla Policy Requirements for DNS over HTTPs Partners".

Short description

Because qm in PowerDNS Recursor is experimental yet, we want to use it only careful. But we would like to use it for DoH queries as soon as possible. It would be great if it would be possible to turn qm on/of from Recursor Lua scripts. Possibly in the dq object.

Usecase

We have one Recursor process in order to serve different client demands. To identify the required "profile", we use the IP address on which a DNS query comes in. In case the query comes in on an IP address that we use for DoH (via dnsdist), we would turn on qm for that query.

Description

I'll give you an example, of how we could imagine the functionality in Lua

function preresolve (dq)
   if DoHnmg:match(dq.localaddr) then
      dq.qm = true
   else
      dq.qm = false
   end
   return true
end

[pieterlexis]

Wouldn't it make more sense to use dnsdist to send these users to a QM-enabled backend?

[paddg]

Yes that's also possible. But this way you'd need different feature-enabled backends for each feature.
The Lua scripting addresses exactly this problem. The advantage, if we use the same Resolver backend for DoH, DoT and Do53 is the cache concentration and thus higher hit rate and lower average latency. And setup/operating is simpler what means easier troubleshooting and less sources of errors.

[paddg]

But maybe the development effort is in a bad relation to the benefit. I cannot assess that.

[omoerbeek]

The goals is to make qname minimization the default. The best way to reach that goal is using it and reporting you findings.

Your suggestion might make setup and operating more simple in your use-case, but code complexity increases and tracking problems becomes more difficult since not all queries are handled the same. Adding this kind of functionality is add once and support forever. It's not just a one-time development effort. For a use-case that should be not relevant in the near future when qname minimization is done by default.

[paddg]

There is also another aspect. Yes, the goal is to make it as default. If the way to this goal is short, the approach to not allow opt-outs or opt-ins is okay. But if the experimental status of it lasts for a year or longer and/or there are DNS zones our there which can not deal with it for a longer time, it could hinder the deployment of it. Also, at least for us it is difficult to get approval to deploy experimental features. Because of that, DoH, which is experimental as well, would be a perfect playground for qname minimization here. But it is difficult for me to assess the situation. You guys definitely have a better view of the bigger picture.

[omoerbeek]

Some of the public resolvers like 1.1.1.1 are already running with qname minimization on. It's already default for other open source resolvers. So there is already incentive for zones admins to fix their zones if needed. The experimental part is on our side: it changes the inner workings of the resolver code rather fundamentally. We need real world data to assess if it's ready for prime time.

[paddg]

If they're doing it without excluding broken domains everything's fine. Let's see what happens, I'm probably too pessimistic :-)

Thanks!!

[paddg]

Only for the record. I was too pessimistic! We have been using Query Name Minimisation for several weeks now. No complaints so far. Thanks!!