[NCAP-Discuss] Root Cause Analysis Reports - Final Call for Comments

Warren Kumari warren at kumari.net
Mon Aug 8 21:37:36 UTC 2022


On Wed, Aug 03, 2022 at 12:11 PM, Casey Deccio <casey at deccio.net> wrote:

> Dear NCAP DG members,
>
> As you know, I have written two reports associated with root cause
> analysis for name collisions reports received by ICANN. Some time ago I
> distributed earlier versions of these documents to this mailing list, which
> resulted in feedback that I have addressed in the latest versions. Most of
> the changes are relatively minor. The one significant addition is the
> inclusion of a section on "Qname minimization considerations", which is now
> section 7.3 of the "Root Cause Analysis - new gTLD" report. The final
> version of these reports will be included as appendices in the Study 2
> document, along with other reports that have been written in conjunction
> with Study 2.
>
> I invite you to read the documents, with particular attention to the new
> section. I will consider this a final call for comments from the NCAP DG.
>
> Root Cause Analysis - wpad.domain.name
>
> https://docs.google.com/document/d/1y5jcWeH3gOKzxtF7_BnqNdwbbvlyqvshNVIZvJ19wDg/edit?usp=sharing
>
> Root Cause Analysis - New gTLD Collisions
> https://docs.google.com/document/d/
> 1YSvdH9Slws0iW3e6yoS04s5zANBnyMMFn9DUNE19fkg/edit?usp=sharing
>
>
>
Apologies, I've been traveling and so have missed a number of calls /
updates, so this may all have been covered in a discussion that I missed.


I'm quite confused by section "7.3. Qname Minimization Considerations" and
the finding: "Based on the analysis presented herein, we conclude that the
trends related to name collision DNS queries observed at the root servers
from DITL collection data are not affected by qname minimization behaviors."

>From what I can tell, the methodology used is flawed — it says (Sec 7.3.1):
"A resolver was evaluated for qname minimization by testing for the
following two query behaviors during the collection period: 1) the resolver
issued a minimum of five queries for qnames other than the root name; and
2) the resolver issued no query with a qname having more than one label."

I have configured a test name-server (BIND 9.16.27 (Extended Support
Version)) with QNAME minimization (qname-minimization strict;)
and then restarted it, while doing a tcpdump towards the root servers.

This is the result (edited to remove noise):
17:18:55.133793 IP 204.194.23.4.57696 > 199.9.14.201.53: 6466% [1au]
DNSKEY? . (40)
17:18:55.133811 IP 204.194.23.4.45279 > 199.9.14.201.53: 5337% [1au] A?
ns.example.com. (55)
17:18:55.134010 IP 204.194.23.4.40745 > 199.9.14.201.53: 18603 [1au] NS? .
(40)
17:18:55.134025 IP 204.194.23.4.37222 > 199.9.14.201.53: 59226% [1au] AAAA?
ns.example.com. (55)
17:18:55.135841 IP 204.194.23.4.38998 > 199.9.14.201.53: 62191% [1au] A?
ns.example.com. (71)
17:18:55.136058 IP 204.194.23.4.55746 > 199.9.14.201.53: 31405% [1au] AAAA?
ns.example.com. (71)
17:18:55.136125 IP 199.9.14.201.53 > 204.194.23.4.37949: 5960*-| 13/0/1 NS
a.root-servers.net., NS b.root-servers.net., NS c.root-servers.net., NS
d.root-servers.net., NS e.root-servers.net., NS f.root-servers.net., NS
g.root-servers.net., NS h.root-servers.net., NS i.root-servers.net., NS
j.root-servers.net., NS k.root-servers.net., NS l.root-servers.net., NS
m.root-servers.net. (459)
17:18:55.199919 IP 204.194.23.4.35072 > 202.12.27.33.53: 39497% [1au] A?
a.iana-servers.net. (59)
17:18:55.200079 IP 204.194.23.4.53543 > 202.12.27.33.53: 37131% [1au] A?
b.iana-servers.net. (59)
17:18:55.381516 IP 204.194.23.4.34696 > 193.0.14.129.53: 61999% [1au] A?
ns.icann.org. (53)
17:18:58.561175 IP 204.194.23.4.53967 > 199.7.83.42.53: 5955% [1au] A?
ns1.hkg1.afilias-nst.info. (66)
17:18:58.561246 IP 204.194.23.4.47519 > 199.7.83.42.53: 47603% [1au] A?
ns1.mia1.afilias-nst.info. (66)
17:18:58.561301 IP 204.194.23.4.44128 > 199.7.83.42.53: 17974% [1au] A?
ns1.sea1.afilias-nst.info. (66)
17:18:58.561372 IP 204.194.23.4.38500 > 199.7.83.42.53: 31478% [1au] A?
ns1.ams1.afilias-nst.info. (66)
17:18:59.320376 IP 204.194.23.4.38118 > 192.112.36.4.53: 63393% [1au] A?
sunic.sunet.se. (55)
17:18:59.320454 IP 204.194.23.4.53799 > 192.112.36.4.53: 53942% [1au] A?
ns-ietf.nlnetlabs.nl. (61)
17:18:59.342234 IP 204.194.23.4.42688 > 192.112.36.4.53: 27839% [1au] A?
ns1.bknix.co.th. (56)
17:18:59.342274 IP 204.194.23.4.46165 > 192.112.36.4.53: 50831% [1au] A?
ns3.bknix.co.th. (56)
17:18:59.342274 IP 204.194.23.4.51014 > 192.112.36.4.53: 41759% [1au] A?
ns0.bknix.co.th. (56)
17:18:59.344635 IP 204.194.23.4.39436 > 192.58.128.30.53: 20236% [1au] A?
ns2.dns.nl. (51)
17:18:59.344685 IP 204.194.23.4.59324 > 192.58.128.30.53: 52721% [1au] A?
ns1.dns.nl. (51)
17:18:59.344695 IP 204.194.23.4.44777 > 192.58.128.30.53: 31159% [1au] A?
ns3.dns.nl. (51)
17:18:59.366421 IP 204.194.23.4.45371 > 192.5.5.241.53: 44872% [1au] A?
b.thains.co.th. (55)
17:18:59.366546 IP 204.194.23.4.38353 > 192.5.5.241.53: 17011% [1au] A?
c.thains.co.th. (55)
17:18:59.366611 IP 204.194.23.4.57669 > 192.5.5.241.53: 40232% [1au] A?
a.thains.co.th. (55)
17:18:59.366616 IP 204.194.23.4.56667 > 192.5.5.241.53: 9030% [1au] A?
p.thains.co.th. (55)
17:18:59.500690 IP 204.194.23.4.60389 > 192.5.5.241.53: 54713% [1au] A?
ns1.sunet.se. (53)
17:18:59.523583 IP 204.194.23.4.59315 > 199.7.91.13.53: 28978% [1au] A?
nn.uninett.no. (54)
17:18:59.524834 IP 204.194.23.4.51883 > 199.7.91.13.53: 22009% [1au] A?
x.nic.no. (49)
17:18:59.524894 IP 204.194.23.4.55999 > 199.7.91.13.53: 27108% [1au] A?
y.nic.no. (49)
17:18:59.524912 IP 204.194.23.4.43732 > 199.7.91.13.53: 58903% [1au] A?
z.nic.no. (49)
17:18:59.524984 IP 204.194.23.4.36453 > 199.7.91.13.53: 24228% [1au] A?
not.norid.no. (53)
17:18:59.525033 IP 204.194.23.4.48791 > 199.7.91.13.53: 18178% [1au] A?
njet.norid.no. (54)
17:22:28.168113 IP 204.194.23.4.50911 > 192.33.4.12.53: 36830% [1au] A?
ns-1867.awsdns-41.co.uk. (64)

It sent more than 28 queries with more than one label.

Testing to make sure that it *is* actually a qname-minimizing resolver:
$ ping this.is.a.name.with.many.labels
ping: this.is.a.name.with.many.labels: Name or service not known

Gives:
17:28:22.045055 IP 204.194.23.4.48050 > 192.36.148.17.53: 45039 [1au] NS?
labels. (47)
17:28:22.045506 IP 192.36.148.17.53 > 204.194.23.4.48050: 45039 NXDomain*-|
0/0/1 (63)

So, it clearly is performing name-minimization for queries received (it
doesn't qname minimize infrastructure lookups)

So, from the criteria above, this would be classified as
non-qname-minimizing (it sent many queries with more than one label), even
though it clearly is qname-minimizing.

This seems to call the findings into significant doubt,
W



Please request access if you don't have it.
>
> Cheers,
> Casey
> _______________________________________________
> NCAP-Discuss mailing list
> NCAP-Discuss at icann.org
> https://mm.icann.org/mailman/listinfo/ncap-discuss
>
> _______________________________________________
> By submitting your personal data, you consent to the processing of your
> personal data for purposes of subscribing to this mailing list accordance
> with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and
> the website Terms of Service (https://www.icann.org/privacy/tos). You can
> visit the Mailman link above to change your membership status or
> configuration, including unsubscribing, setting digest-style delivery or
> disabling delivery altogether (e.g., for a vacation), and so on.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20220808/c0dd14cf/attachment.html>


More information about the NCAP-Discuss mailing list