Hi, so you would suggest to remove the user agent parameter from the header? Or to use some fake/specific value?

Hi @0xERR0R, maybe simply removing it will be good enough for me ;)

Fake it may not be too helpful when somebody trying to do some deep analysis about the behavior, the same thing on removing the user-agent header, but at least those https reverse proxies (in front of the DoH servers, some may be CDNs) will have one less thing to know about the users. That may be the reason why Apple and Mozilla is doing it.

Just FYR, m13253/dns-over-https has an option to empty the user-agent, though they don't recommend it, maybe you'll also be interested in their opinion:

It is generally not recommended to disable submitting User-Agent because it
is still possible to probe client version according to behavior differences,
such as TLS handshaking, handling of malformed packets, and specific bugs.
Additionally, User-Agent is an important way for the server to distinguish
buggy, old, or insecure clients, and to workaround specific bugs.
(e.g. doh-server can detect and workaround certain issues of DNSCrypt-Proxy
and older Firefox.)
(copied from doh-client/doh-client.conf in the repo)

Could this be parameterized in the config.yml to consume a user-crafted user-agent string? Alternatively you could likely create a struct with multiple types and have it randomly iterate as the resolver queries the upstream services. I'd rather fake an agent string vs keeping the default signature the golang http-client sends.

Currently blocky sends out a constant signature which as @PeterDaveHello mentioned could be profiled easily

ok, so we can provide a configuration property to set the user agent string in the config.yaml (default empty, which means so user agent string will be sent).

@0xERR0R I tried to make a patch here: #518, would you like to help take a look? Thanks.