[GH-ISSUE #3373] Recursive Resolution is comparatively slow #1175

New issue

Open

opened 2026-03-16 01:48:59 +03:00 by kerem · 2 comments

kerem commented

2026-03-16 01:48:59 +03:00

Owner

Originally created by @marcus0x62 on GitHub (Dec 3, 2025).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/3373

Our recursor implementation is slow compared to other name servers when resolving certain names. This is particularly noticeable when resolving names with lengthy CNAME chains from a cold start -- with no cache entries populated.

A few examples:

FQDN	Hickory - `c97a271`	Bind 9.20.16	Unbound 1.24.2
www.juniper.net	~ 2400ms	750ms	616ms
www.adobe.com	1093ms	1066ms	823ms
www.akamai.com	1060ms	763ms	963ms

I think this is likely caused by a combination of our server selection and zone cut detection behavior.

Originally created by @marcus0x62 on GitHub (Dec 3, 2025). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/3373 Our recursor implementation is slow compared to other name servers when resolving certain names. This is particularly noticeable when resolving names with lengthy CNAME chains from a cold start -- with no cache entries populated. A few examples: | FQDN | Hickory - c97a271 | Bind 9.20.16 | Unbound 1.24.2 | | ------- | -------- | ------| -----------| | www.juniper.net | ~ 2400ms | 750ms | 616ms | | www.adobe.com | 1093ms | 1066ms | 823ms | | www.akamai.com | 1060ms | 763ms | 963ms | I think this is likely caused by a combination of our server selection and zone cut detection behavior.

kerem added the

perf

label

2026-03-16 01:48:59 +03:00

kerem commented

2026-03-16 01:49:10 +03:00

Author

Owner

@divergentdave commented on GitHub (Dec 3, 2025):

One other scenario where we're unnecessarily slow is when resolving names with many labels. RFC 9156 suggests limiting the number of queries used to find zone cuts, and dividing those queries among the list of labels in a name. We currently add labels one-by-one, which does not scale well with long traversals. Adopting the suggested mitigations is difficult with our current code organization, built around recursion, so we may want to arrange this in an iterative manner first. Edit: see also #2984

@divergentdave commented on GitHub (Dec 3, 2025): One other scenario where we're unnecessarily slow is when resolving names with many labels. RFC 9156 suggests limiting the number of queries used to find zone cuts, and dividing those queries among the list of labels in a name. We currently add labels one-by-one, which does not scale well with long traversals. Adopting the suggested mitigations is difficult with our current code organization, built around recursion, so we may want to arrange this in an iterative manner first. Edit: see also #2984

kerem commented

2026-03-16 01:49:15 +03:00

Author

Owner

@djc commented on GitHub (Dec 5, 2025):

Would be good to put some basic benchmarks in the repo so we can more easily measure (and profile).

@djc commented on GitHub (Dec 5, 2025): Would be good to put some basic benchmarks in the repo so we can more easily measure (and profile).

kerem referenced this issue

2026-03-16 04:58:22 +03:00

[PR #1175] [MERGED] Bump tokio from 0.2.21 to 0.2.22 #2041

kerem referenced this issue

2026-03-16 05:01:00 +03:00

[PR #1175] [MERGED] Bump tokio from 0.2.21 to 0.2.22 #2050