[GH-ISSUE #1476] Intercepting/Overriding ForwardAuthority #678

New issue

Closed

opened 2026-03-15 23:47:16 +03:00 by kerem · 3 comments

kerem commented

2026-03-15 23:47:16 +03:00

Owner

Originally created by @moschroe on GitHub (May 2, 2021).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1476

Beg your pardon if this was asked already but I am trying to build a simple server that basically only forwards queries (no entries/zone on its own) and is able to intercept (and possibly modify) both, request and response. Use case would be surveillance of outgoing connections/firewalling requirements.

My first approach was implementing a RequestHandler directly, encapsulating a Catalog with a ForwardingAuthority created from the system resolver and then adding code to handle_request(). But due to the interface, this requires also a custom ResponseHandler, which has no usable access to the response at all and I'd need to read any A or CNAME (or any at all) records.

The second approach was implementing a custom Authority with an inner ForwardingAuthority field. Here the sync signature makes awaiting impossible but I can create a chained future with and_then() that is in the loop. On querying for A records for (example) "marketplace-cdn.atlassian.com", the upstream DNS answers with A and CNAME records. CNAME records are not contained in the Lookup struct returned. Where are these filtered out and why? They have to be traced back to the original query, so they would need to be accessible in its context. Also, being able to change the query on the fly would be great for later extensions.

Any hints on how to approach this endeavor would be much appreciated.

Originally created by @moschroe on GitHub (May 2, 2021). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1476 Beg your pardon if this was asked already but I am trying to build a simple server that basically _only_ forwards queries (no entries/zone on its own) and is able to intercept (and possibly modify) both, request and response. Use case would be surveillance of outgoing connections/firewalling requirements. My first approach was implementing a `RequestHandler` directly, encapsulating a Catalog with a `ForwardingAuthority` created from the system resolver and then adding code to `handle_request()`. But due to the interface, this requires also a custom `ResponseHandler`, which has no usable access to the response at all and I'd need to read any A or CNAME (or any at all) records. The second approach was implementing a custom `Authority` with an inner `ForwardingAuthority` field. Here the sync signature makes `await`ing impossible but I can create a chained future with `and_then()` that is in the loop. On querying for A records for (example) "marketplace-cdn.atlassian.com", the upstream DNS answers with A and CNAME records. CNAME records are not contained in the `Lookup` struct returned. Where are these filtered out and why? They have to be traced back to the original query, so they would need to be accessible in its context. Also, being able to change the query on the fly would be great for later extensions. Any hints on how to approach this endeavor would be much appreciated.

kerem

2026-03-15 23:47:16 +03:00

closed this issue
added the
question
label

kerem commented

2026-03-15 23:47:32 +03:00

Author

Owner

@bluejekyll commented on GitHub (May 3, 2021):

I get what you're asking for. I wonder if we should change some of the internal interfaces to work a little better for your needs? It sounds like you've already dived through the code and looks like you have some ideas where things need to be changed potentially.

I think it would be nice if you could do what you're asking for by modifying the FowardingAuthority to work they way you want... I have been planning to expand the Lookup type to provide access to all of the fields from a Message, as similar issues have been brought up. Would that fix the issue you're having now or are more changes needed?

@bluejekyll commented on GitHub (May 3, 2021): I get what you're asking for. I wonder if we should change some of the internal interfaces to work a little better for your needs? It sounds like you've already dived through the code and looks like you have some ideas where things need to be changed potentially. I think it would be nice if you could do what you're asking for by modifying the FowardingAuthority to work they way you want... I have been planning to expand the Lookup type to provide access to all of the fields from a Message, as similar issues have been brought up. Would that fix the issue you're having now or are more changes needed?

kerem commented

2026-03-15 23:47:37 +03:00

Author

Owner

@moschroe commented on GitHub (May 3, 2021):

Juggling a few projects at the moment but maybe I can try my hand at a POC this weekend. Knowing you're fundamentally open to necessary changes is great to know!

@moschroe commented on GitHub (May 3, 2021): Juggling a few projects at the moment but maybe I can try my hand at a POC this weekend. Knowing you're fundamentally open to necessary changes is great to know!

kerem commented

2026-03-15 23:47:43 +03:00

Author

Owner

@moschroe commented on GitHub (Jan 5, 2022):

Recently picked up development again.

The issue with CNAME records being filtered became clear to me after perusing the source code, setting opts.preserve_intermediates = true resolves that.
Due to the introduction of async_trait (in the 0.21. RC releases), my initial complaint about it being difficult to create customized trait implementation also was resolved.

@moschroe commented on GitHub (Jan 5, 2022): Recently picked up development again. 1. The issue with CNAME records being filtered became clear to me after perusing the source code, setting `opts.preserve_intermediates = true` resolves that. 1. Due to the introduction of `async_trait` (in the 0.21. RC releases), my initial complaint about it being difficult to create customized trait implementation also was resolved.

kerem referenced this issue

2026-03-16 02:15:10 +03:00

[PR #678] [CLOSED] Bump tokio from 0.1.14 to 0.1.15 #1596