[PR #3265] [MERGED] recursor: tidy up builder filters, recursor handle construction #3694

New issue

Closed

opened 2026-03-16 11:57:31 +03:00 by kerem · 0 comments

kerem commented

2026-03-16 11:57:31 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/hickory-dns/hickory-dns/pull/3265
Author: @cpu
Created: 9/5/2025
Status: ✅ Merged
Merged: 9/22/2025
Merged by: @cpu

Base: main ← Head: cpu-tidying-recursor-handle_dev

📝 Commits (2)

4ea3470 recursor: untangle recommended filters from additional ones
1e6077e recursor: tidy up handle construction

📊 Changes

4 files changed (+141 additions, -142 deletions)

View changed files

📝 crates/recursor/src/metrics_tests.rs (+1 -0)
📝 crates/recursor/src/recursor.rs (+55 -90)
📝 crates/recursor/src/recursor_dns_handle.rs (+83 -51)
📝 crates/server/src/store/recursor.rs (+2 -1)

📄 Description

First, untangle the default recommended filters from the builder method that allows extending the filters with additional IP networks. I bumped into this in the next commit when I was updating a unit test that previously side-stepped the builder that failed when I converted it to use it. The root cause was the surprising way that RecursorBuilder::nameserver_filter() applied defaults in addition to the networks the user provides. See the commit message for more detail.

Second, rejig the RecursorDnsHandle construction to use the RecursorBuilder and return a RecursorMode. In practice, 98% of the arguments to RecursorDnsHandle::new() were coming directly from the builder, and then a few additional ones were used to build the RecursorMode. Instead, pass the whole builder into the RecursorDnsHandle and return the RecursorMode that wraps the constructed handle. This requires promoting some pieces of recursor.rs to pub(super). Alternatively we could consider folding recursor_dns_handle.rs into recursor.rs since they're so closely intertwined.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/hickory-dns/hickory-dns/pull/3265 **Author:** [@cpu](https://github.com/cpu) **Created:** 9/5/2025 **Status:** ✅ Merged **Merged:** 9/22/2025 **Merged by:** [@cpu](https://github.com/cpu) **Base:** `main` ← **Head:** `cpu-tidying-recursor-handle_dev` --- ### 📝 Commits (2) - [`4ea3470`](https://github.com/hickory-dns/hickory-dns/commit/4ea34705b6e5aed5a44ce640fab9bafa70c64da2) recursor: untangle recommended filters from additional ones - [`1e6077e`](https://github.com/hickory-dns/hickory-dns/commit/1e6077e12877a1edf614ec6812fdd8981bec705e) recursor: tidy up handle construction ### 📊 Changes **4 files changed** (+141 additions, -142 deletions) <details> <summary>View changed files</summary> 📝 `crates/recursor/src/metrics_tests.rs` (+1 -0) 📝 `crates/recursor/src/recursor.rs` (+55 -90) 📝 `crates/recursor/src/recursor_dns_handle.rs` (+83 -51) 📝 `crates/server/src/store/recursor.rs` (+2 -1) </details> ### 📄 Description First, untangle the default recommended filters from the builder method that allows extending the filters with additional IP networks. I bumped into this in the next commit when I was updating a unit test that previously side-stepped the builder that failed when I converted it to use it. The root cause was the surprising way that `RecursorBuilder::nameserver_filter()` applied defaults in addition to the networks the user provides. See the commit message for more detail. Second, rejig the `RecursorDnsHandle` construction to use the `RecursorBuilder` and return a `RecursorMode`. In practice, 98% of the arguments to `RecursorDnsHandle::new()` were coming directly from the builder, and then a few additional ones were used to build the `RecursorMode`. Instead, pass the whole builder into the `RecursorDnsHandle` and return the `RecursorMode` that wraps the constructed handle. This requires promoting some pieces of `recursor.rs` to `pub(super)`. Alternatively we could consider folding `recursor_dns_handle.rs` into `recursor.rs` since they're so closely intertwined. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>