[GH-ISSUE #3346] Add ability to inject custom headers into a DoH / DoQ query #1173

New issue

Closed

opened 2026-03-16 01:48:28 +03:00 by kerem · 4 comments

kerem commented

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

Owner

Originally created by @lpraneis on GitHub (Nov 10, 2025).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/3346

Is your feature request related to a problem? Please describe.
The DoH / DoQ client doesn't have a way to add custom headers to the request.

Describe the solution you'd like
Similar to the query_path parameter ( https://github.com/hickory-dns/hickory-dns/pull/2226 ), I would like to implement a new field in the name server configuration that allows the user to provide either a static header or an async callback to get a header dynamically. This header will be used when building a request for DoH or DoQ.

Describe alternatives you've considered
An alternative is to implement a custom ConnectionProvider but this requires re-implementing DNS pipelining for H2, etc. and seems overkill for a simple feature.

Additional context
I'm happy to do this work, I'm mostly just interested to see if there is any appetite to include this.

Originally created by @lpraneis on GitHub (Nov 10, 2025). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/3346 **Is your feature request related to a problem? Please describe.** The DoH / DoQ client doesn't have a way to add custom headers to the request. **Describe the solution you'd like** Similar to the `query_path` parameter ( https://github.com/hickory-dns/hickory-dns/pull/2226 ), I would like to implement a new field in the name server configuration that allows the user to provide either a static header or an async callback to get a header dynamically. This header will be used when building a request for DoH or DoQ. **Describe alternatives you've considered** An alternative is to implement a custom `ConnectionProvider` but this requires re-implementing DNS pipelining for H2, etc. and seems overkill for a simple feature. **Additional context** I'm happy to do this work, I'm mostly just interested to see if there is any appetite to include this.

kerem closed this issue

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

kerem commented

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

Author

Owner

@djc commented on GitHub (Nov 10, 2025):

Not sure I'd want to specifically enable this in the resolver config types. It does feel like a custom ConnectionProvider is the right way forward, maybe we can modularize the API for H2 to facilitate header injection without a bunch of duplication?

What's the goal here? Why do you want to inject headers?

@djc commented on GitHub (Nov 10, 2025): Not sure I'd want to specifically enable this in the resolver config types. It does feel like a custom ConnectionProvider is the right way forward, maybe we can modularize the API for H2 to facilitate header injection without a bunch of duplication? What's the goal here? Why do you want to inject headers?

kerem commented

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

Author

Owner

@lpraneis commented on GitHub (Nov 10, 2025):

I have a use-case that involves a DoH server that requires authentication and expects that authentication to be provided via a header. Currently, this is implemented using a custom ConnectionProvider with a custom HTTP client but this is a lot of code to upkeep for what is essentially a less optimized solution than what is provided by hickory.

maybe we can modularize the API for H2 to facilitate header injection without a bunch of duplication?

This could work. I will look into if it's feasible to create a minimal custom ConnectionProvider that uses the preexisting DnsExchange and HttpsClientConnect. The config could then be added to the HttpsClientConnect type for DoH and QuicClientConnect for DoQ

@lpraneis commented on GitHub (Nov 10, 2025): I have a use-case that involves a DoH server that requires authentication and expects that authentication to be provided via a header. Currently, this is implemented using a custom ConnectionProvider with a custom HTTP client but this is a lot of code to upkeep for what is essentially a less optimized solution than what is provided by hickory. > maybe we can modularize the API for H2 to facilitate header injection without a bunch of duplication? This could work. I will look into if it's feasible to create a minimal custom `ConnectionProvider` that uses the preexisting `DnsExchange` and `HttpsClientConnect`. The config could then be added to the `HttpsClientConnect` type for DoH and `QuicClientConnect` for DoQ

kerem commented

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

Author

Owner

@lpraneis commented on GitHub (Nov 10, 2025):

yeah that works and is pretty straightforward. It does require re-implementing some generic types like GenericConnection since the inner tuple data isn't pub, but idk if we want to expose those and it's easy enough to do.

Would you be open to a configuration option on the HttpsClientConnect?

I'm imagining something like an Option<Arc<dyn GetHeaders>> in the TlsConfig struct that currently holds the other HTTP-config like http_endpoint

@lpraneis commented on GitHub (Nov 10, 2025): yeah that works and is pretty straightforward. It does require re-implementing some generic types like `GenericConnection` since the inner tuple data isn't pub, but idk if we want to expose those and it's easy enough to do. Would you be open to a configuration option on the `HttpsClientConnect`? I'm imagining something like an `Option<Arc<dyn GetHeaders>>` in the `TlsConfig` struct that currently holds the other HTTP-config like `http_endpoint`

kerem commented

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

Author

Owner

@djc commented on GitHub (Nov 10, 2025):

yeah that works and is pretty straightforward. It does require re-implementing some generic types like GenericConnection since the inner tuple data isn't pub, but idk if we want to expose those and it's easy enough to do.

Would you be open to a configuration option on the HttpsClientConnect?

I'm imagining something like an Option<Arc<dyn GetHeaders>> in the TlsConfig struct that currently holds the other HTTP-config like http_endpoint

Please PR a draft so I can have a look.

@djc commented on GitHub (Nov 10, 2025): > yeah that works and is pretty straightforward. It does require re-implementing some generic types like `GenericConnection` since the inner tuple data isn't pub, but idk if we want to expose those and it's easy enough to do. > > Would you be open to a configuration option on the `HttpsClientConnect`? > > I'm imagining something like an `Option<Arc<dyn GetHeaders>>` in the `TlsConfig` struct that currently holds the other HTTP-config like `http_endpoint` Please PR a draft so I can have a look.

kerem referenced this issue

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

[PR #1173] [MERGED] Make EDNS optional for resolvers #2039