[PR #3294] [MERGED] Reintroduce bailiwick filtering #3724

New issue

Closed

opened 2026-03-16 11:59:08 +03:00 by kerem · 0 comments

kerem commented

2026-03-16 11:59:08 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/hickory-dns/hickory-dns/pull/3294
Author: @marcus0x62
Created: 10/2/2025
Status: ✅ Merged
Merged: 10/3/2025
Merged by: @marcus0x62

Base: main ← Head: reintroduce-bailiwick-filtering

📝 Commits (3)

28a8c5f fix out-of-bailiwick records in recursor_metrics test
7f919a2 conformance: out of bailiwick rejection test
cba72c9 reintroduce bailiwick filtering

📊 Changes

5 files changed (+201 additions, -6 deletions)

View changed files

📝 conformance/e2e-tests/src/recursor/security/scenarios.rs (+138 -1)
📝 conformance/test-server/src/handlers.rs (+38 -0)
📝 conformance/test-server/src/main.rs (+1 -0)
📝 crates/recursor/src/metrics_tests.rs (+2 -2)
📝 crates/recursor/src/recursor_pool.rs (+22 -3)

📄 Description

In #3043, our explicit out-of-bailiwick record detection was removed. This is mostly a non-issue presently due to the cache changes introduced in that PR, however:

We should test for this behavior explicitly to ensure a future redesign doesn't re-introduce any exposure to bailiwick cache poisoning
Without explicit record filtering, there is the possibility of a server returning an out-of-bailiwick response as part of a CNAME chain and for that record to be used when resolving that CNAME. I don't think this is much of a practical security issue -- a malicious authoritative server could just as easily return a malicious A record to hijack a CNAME it was part of the resolution path for, but, in any case, accepting these records is inappropriate and something we shouldn't do.

_{🔄 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/3294 **Author:** [@marcus0x62](https://github.com/marcus0x62) **Created:** 10/2/2025 **Status:** ✅ Merged **Merged:** 10/3/2025 **Merged by:** [@marcus0x62](https://github.com/marcus0x62) **Base:** `main` ← **Head:** `reintroduce-bailiwick-filtering` --- ### 📝 Commits (3) - [`28a8c5f`](https://github.com/hickory-dns/hickory-dns/commit/28a8c5fe767e1c69ad79b7072c7c73a5d57d4302) fix out-of-bailiwick records in recursor_metrics test - [`7f919a2`](https://github.com/hickory-dns/hickory-dns/commit/7f919a277252985cbdcc4438f51807c317e153ba) conformance: out of bailiwick rejection test - [`cba72c9`](https://github.com/hickory-dns/hickory-dns/commit/cba72c941757ee64cd29a87ffcc663529b8b4014) reintroduce bailiwick filtering ### 📊 Changes **5 files changed** (+201 additions, -6 deletions) <details> <summary>View changed files</summary> 📝 `conformance/e2e-tests/src/recursor/security/scenarios.rs` (+138 -1) 📝 `conformance/test-server/src/handlers.rs` (+38 -0) 📝 `conformance/test-server/src/main.rs` (+1 -0) 📝 `crates/recursor/src/metrics_tests.rs` (+2 -2) 📝 `crates/recursor/src/recursor_pool.rs` (+22 -3) </details> ### 📄 Description In #3043, our explicit out-of-bailiwick record detection was removed. This is *mostly* a non-issue presently due to the cache changes introduced in that PR, however: 1) We should test for this behavior explicitly to ensure a future redesign doesn't re-introduce any exposure to bailiwick cache poisoning 2) Without explicit record filtering, there is the possibility of a server returning an out-of-bailiwick response as part of a CNAME chain and for that record to be used when resolving that CNAME. I don't think this is much of a practical security issue -- a malicious authoritative server could just as easily return a malicious A record to hijack a CNAME it was part of the resolution path for, but, in any case, accepting these records is inappropriate and something we shouldn't do. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>