QNAME Minimization Implementation Inquiry

[Arcnilya]

Hi,

I am conducting some research measurements on QNAME Minimization
implementations of popular open-source resolvers in light of RFC 9156, having
replaced RFC 7816. While running some tests I noticed that pdns recursor does not take the
cache into account when minimizing queries. RFC 9156 mentions that a minimizing resolver
will look for the closest-known delegation point in its cache and start the minimization from there.
I am curious about pdns recursor's implementation. Is it by design? If that is the case, what was the
reasoning behind it?

Appreciate any insight into recursor's QNAME Minimization implementation.

[rgacogne]

While running some tests I noticed that pdns recursor does not take the cache into account when minimizing queries.

Would you care to elaborate? The recursor does look at for the closest-known delegation point, called ancestor in our code, you can search for getBestNSFromCache() call in SyncRes::doResolve.

[omoerbeek]

The recursor certainly takes the cache into account to determine the closest-known delegation point when resolving client queries.

There are a few cases where the recursor falls back to not using qname minimization to work around buggy authoritative servers.

Starting with version 5.0.0 the recursor will not use QM when resolving addresses of name servers, these so called infra queries are generated by the recursor itself.

Please show logs of what you observed, so we can see what made you draw your conclusions.

[Arcnilya]

I am sending the following query to the recursor:
l24.l23.l22.l21.l20.l19.l18.l17.l16.l15.l14.l13.l12.l11.l10.l9.l8.l7.l6.l5.l4.foo.fpdns.se. A
and observe the incoming queries at the name server of fpdns.se:
foo.fpdns.se A (3A)
l4.foo.fpdns.se A (4A)
l5.l4.foo.fpdns.se A (5A)
l6.l5.l4.foo.fpdns.se A (6A)
l9.l8.l7.l6.l5.l4.foo.fpdns.se A (9A)
l12.l11.l10.l9.l8.l7.l6.l5.l4.foo.fpdns.se A (12A)
l15.l14.l13.l12.l11.l10.l9.l8.l7.l6.l5.l4.foo.fpdns.se A (15A)
l18.l17.l16.l15.l14.l13.l12.l11.l10.l9.l8.l7.l6.l5.l4.foo.fpdns.se A (18A)
l21.l20.l19.l18.l17.l16.l15.l14.l13.l12.l11.l10.l9.l8.l7.l6.l5.l4.foo.fpdns.se A (21A)
l24.l23.l22.l21.l20.l19.l18.l17.l16.l15.l14.l13.l12.l11.l10.l9.l8.l7.l6.l5.l4.foo.fpdns.se A (24A)

Recursor then have a signature of 3A-4A-5A-6A-9A-12A-15A-18A-21A-24A (as viewed from fpdns.se).
Assuming an empty cache, a single label is prepended 6 times before distributing the remaining labels on the remaining 6 queries.

Immediately after this query, I send a new one but replacing foo with bar:
l24.l23.l22.l21.l20.l19.l18.l17.l16.l15.l14.l13.l12.l11.l10.l9.l8.l7.l6.l5.l4.bar.fpdns.se

Recursor still have the signature of 3A-4A-5A-6A-9A-12A-15A-18A-21A-24A.
Reading the RFC 9156 I would expect to see the single-label prepending starting from the new closest-known delegation in cache,
resulting in a new signature.

[omoerbeek]

I'm starting to grasp what you are hinting at. For the first query the closest-known delegation is the root, for the second fpdns.se. I will collect traces from rec itself to show you the steps taken from the recursor's point of view later. Those will show that for the second query it will skip asking the root and .se nameservers (as that info is cached) and start the resolving proces at fpdns.se. Then I think it boils down to the question if we count the labels from the closest-known delegation or from the root when determining the step sizes.

Note: collecting traces did not work out, as 193.10.227.206 refuses queries.