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 Unbound does not distribute the labels evenly on the remaining queries after the MINIMIZE_ONE_LAB. I am curious about this anomaly. Is it by design? If so, what was the reasoning behind it?

Appreciate any insight into Unbound's QNAME Minimization implementation.

[gthess]

Hi :)

What you refer to can be found at: https://github.com/NLnetLabs/unbound/blob/22dc376392b5d9f815089a6e4fd43f8fdf113c98/iterator/iterator.c#L2500-L2553

A summary:

• MAX_MINIMISE_ONE_LAB will always send that many initial single labels
• More than that will get increases of MINIMISE_MULTIPLE_LABS
• Based on the actual numbers, you could get +-1 labels per minimize iteration or just the whole query if there are less than MINIMISE_MULTIPLE_LABS to send or the iterator has already done MAX_MINIMISE_COUNT minimization attempts (including the multilabel attempts) at this point.

Do you see something else happening? Maybe with a concrete example we can follow the code more closely.

[Arcnilya]

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

Unbound then have a signature of 3A-4A-5A-6A-9A-12A-15A-18A-22A-24A (as viewed from fpdns.se). Assuming the SLD is cached (fpdns.se), a single label is prepended 4 times before distributing the remaining labels on the remaining 6 queries. The FQDN consists of 24 labels, 2 are cached and 4 have already been prepended. This means that 18 labels should be evenly distributed on the remaining 6 queries, resulting in three-label skips. Note the second-to-last query, having 22 labels, this is the anomaly the sparked my curiosity.

[gthess]

Small correction on your numbers: there are 25 labels including the root, 3 are cached (Unbound already has information about the "fpdns.se." delegation point so it starts from there) and indeed 4 have already been prepended. But Unbound counts 20 labels to be distributed as it calculates from the original query (25) minus the root (1) minus the single label ones (4) regardless of where it starts. So then the distribution is not even that's why you get the extra label from 18 to 22. Maybe marking where qname minimization actually started, in case of cached delegation points, could improve the calculations but I don't have the capacity for this at the moment. At least I hope now it is clear what is happening in your case :)